Кратко

  • draft-ietf-idr-bgp-rpki-yang-02 размещает показатели валидации источника в пяти точках BGP RIB. Путь YANG, сосед и семейство адресов входят в смысл наблюдения.
  • Одинаковые значения могут описывать разные маршруты. Валидация также не доказывает выбор, экспорт, принятие соседом и фактическую пересылку пакетов.

До изменения система показывала 10 000 маршрутов со статусом valid. После изменения — те же 10 000. Если один важный префикс исчез, а другой занял его место, арифметика осталась верной, но обещанная непрерывность была нарушена.

Этот разрыв между количеством и составом особенно заметен в draft-ietf-idr-bgp-rpki-yang-02 от 30 сентября 2026 года. Проект рабочей группы IDR определяет отдельные модели для origin-AS validation, BGPsec и ASPA. В первой модели состояния unverified, unknown, invalid и valid представлены как gauge32 в пяти местах.

Пять мест — пять разных утверждений

Статистика добавляется к adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre и adj-rib-out-post для IPv4 и IPv6.

Вход до политики показывает предложение соседа; после политики — оставшийся набор. Локальный RIB отражает локальный результат выбора. Две выходные точки ограничивают обработку для конкретного соседа до и после политики экспорта.

Входной показатель не доказывает содержимое локального RIB. Локальный RIB не доказывает объявление соседу. Постполитический выход не доказывает принятие на другой стороне. Ни один из них не доказывает путь пакетов.

Путь YANG, AFI/SAFI и сосед — не косметика. Они ограничивают утверждение. Сводная сумма по соседям может скрыть потерю одного транзита равным приростом другого, хотя изменились стоимость, география и домен отказа.

Счётчик не знает, кого он считает

gauge32 хранит текущее количество, но не список и не отпечаток списка. Два множества одинакового размера могут состоять из разных элементов. Один маршрут ушёл, другой пришёл — линия не изменилась.

Для доказательства непрерывности нужен отдельный идентификатор множества: канонический хэш префикса, origin AS, AS_PATH и next hop, ограниченный список либо проверки присутствия критических префиксов. Важно восстановить, что именно считалось.

Время сбора также входит в квитанцию. Проект не обещает транзакционно синхронный снимок пяти путей. Во время сходимости несколько секунд между чтениями могут создать ложное различие или скрыть настоящее.

Valid — не универсальный вердикт

RPKI origin validation сопоставляет префикс и origin AS с валидированными данными ROA. RFC 6811 задаёт основу, RFC 8481 отделяет валидацию от политики, которой оператор не настроил.

Статус valid не означает минимальную задержку, предпочтительную коммерческую трассу, отсутствие утечки, валидность BGPsec или ASPA. Он не доказывает свежесть кэша, победу best path, экспорт, установку соседом или работу data plane.

Три модели разделены именно потому, что проверяют разные утверждения. Единый зелёный значок уничтожил бы эту точность.

Политика меняется, сумма остаётся

Валидация включается по семейству и ограничивается eligible-prefix-policy. Отдельный контейнер решает, участвует ли состояние в best-path. allow-invalid и allow-not-found управляют допустимостью состояний.

Передача Extended Community из RFC 8097 — отдельное решение. Учёт валидации при экспорте — ещё одно, со своей политикой и обработкой not-found, с отсылкой к RFC 8893.

Поэтому одна и та же статистика состояний может сопровождать разные решения. Изменение allow-invalid, allow-not-found или export policy способно заменить выбранные и объявленные маршруты, не сдвинув число valid.

Наблюдение следует связывать с реально применённой конфигурацией и эпохой политики. Намерения контроллера недостаточно. RFC 8342 различает configured и operational values, потому что обработка, протоколы и оборудование могут разводить их.

Цепочка квитанций

Нужно отдельно хранить входные данные валидации и их свежесть; применённую конфигурацию; точный путь, время и способ снимка; состав множества; решение выбора; экспортированный набор и UPDATE; принятие соседом; наблюдаемую доступность.

Каждый шаг отвечает лишь на свой вопрос. Свежие данные не доказывают policy. Счётчик не доказывает состав. Состав не доказывает выбор. Выбор не доказывает экспорт. Экспорт не доказывает принятие. Принятие не доказывает услугу.

При сбое такая схема указывает первую разошедшуюся границу. Панель могла быть совершенно точной в узком измерении и ничего не говорить о широком обещании руководства.

Статус документа и running code

Datatracker отмечает редакцию 02 как активный Internet-Draft для Standards Track в состоянии I-D Exists. Это не RFC. Зафиксированные источники не подтверждают реализацию поставщиком или промышленное внедрение.

Тем не менее существующая телеметрия уже может сохранять стадию, соседа, семейство, эпоху политики и хэш множества. Проект предлагает общую форму, а не создаёт проблему впервые.

Minimum Initial Specification и Running-Code Primacy Хэна Лу дают рамку: общая детерминированная проверка совместима с локальными решениями выбора и экспорта. Публикация модели не создаёт эксплуатационную реальность; её создают код, конфигурация и использование.

Финальный вопрос должен звучать не «индикатор остался зелёным?», а «какие маршруты, на какой стадии и при какой применённой политике были выбраны и объявлены — и куда пошли пакеты?»

Источники