Кратко

  • RFC 9857 стандартизирует передачу состояния пути-кандидата SR Policy по BGP-LS: непосредственно от headend либо через PCE, ретранслирующий сведения PCC.
  • Время приёма не подтверждает время наблюдения, текущую генерацию, установку в FIB, фактический маршрут пакетов или результат сервиса.

Обратная связь появилась, временной гарантии нет

У контроллера обычно есть точная запись о намерении: какую SR Policy он вычислил или распространил. Фактическое локальное состояние после этого часто остаётся внутри headend и соседних систем. RFC 9857 сокращает разрыв. Новые NLRI и атрибуты BGP-LS описывают политику, её пути-кандидаты и списки сегментов в форме, которую может получить внешний компонент.

Это не просто косметическое улучшение. Контроллер получает структурированное операционное утверждение вместо вывода из собственной команды. Но свежая запись в принимающей таблице может содержать старое наблюдение. После восстановления сессии возможно повторное объявление сохранённого состояния. PCE может передать сведения, ранее полученные от PCC. Локальная отметка времени говорит, когда сообщение дошло до потребителя, а не когда возник описанный факт.

Поэтому «получено» и «актуально» должны быть разными состояниями. RFC даёт первое. Второе строится из происхождения, непрерывности и допустимого возраста.

Headend остаётся предметом, но не всегда свидетелем

Local Node Descriptors по RFC 9857 всегда идентифицируют headend SR Policy. Если PCE публикует состояние, изученное от PCC по PCEP, он не должен подставлять туда собственные идентификаторы. Свои BGP Router-ID, AS или confederation PCE может указать в атрибуте BGP-LS.

Так сохраняется правильная принадлежность политики. Вместе с тем потребитель обязан хранить две роли: о каком узле сделан отчёт и кто сформировал BGP-LS-объявление. Если оставить только headend, разрешённая ретрансляция станет похожа на прямое наблюдение. Если оставить только BGP-отправителя, исчезнет субъект политики.

Protocol-Origin отвечает на третий вопрос — какой протокол или компонент инициировал создание, например PCEP, BGP SR Policy или локальная конфигурация. Он не удостоверяет наблюдателя, время измерения или аппаратную установку. BGP-LS Instance-ID тоже не является версией или часами; это идентификатор routing instance.

Флаг A силён именно в своих границах

A означает, что путь-кандидат активен и, в терминологии RFC 9256, provisioned в forwarding plane. Это содержательное утверждение производителя. Однако оно не превращается в независимую квитанцию каждого ASIC или line card только потому, что его получил внешний контроллер.

Остальные флаги не дублируют A. S обозначает административное отключение, B — резерв, E — оценивание, V — наличие хотя бы одного допустимого списка сегментов, D — делегирование, C — provisioned by PCE. I, T и U описывают определённые режимы drop и transit. Списки сегментов имеют состояния вычисления, проверки, разрешения и topology/algorithm; M указывает удаление после ошибки, обнаруженной мониторингом.

Эти признаки повышают точность диагностики локального решения. Они не измеряют количество прошедших пакетов и не подтверждают соблюдение цели сервиса.

Epoch приходится формировать потребителю

RFC 9857 не определяет обязательную отметку времени наблюдения у производителя, монотонный номер поколения, отдельную квитанцию SRPM или подтверждение FIB. RFC 9552, кроме того, допускает управляемое политикой время обновлений BGP-LS для снижения потока. Отсутствие нового сообщения может означать стабильность, задержку публикации или потерю непрерывности.

Контроллеру нужна собственная граница epoch: идентичность headend, идентичность производителя, сессия и перезапуски, время приёма, поколение намерения и максимальный допустимый возраст. При смене PCE, делегирования или сессии прежнее предположение о непрерывности должно стать неподтверждённым до новой согласованной выборки.

Это не попытка переписать RFC. Это отказ приписывать полю состояния временную семантику, которой в нём нет.

Пять квитанций нельзя сжимать в одну

Первая квитанция — BGP-LS-отчёт о состоянии, которое объявил производитель. Вторая — принятие конкретного поколения локальным SRPM. Третья — подтверждение FIB или оборудования о программировании записей. Четвёртая — телеметрия, показывающая путь реальных пакетов. Пятая — метрики сервиса: задержка, потери и доступность.

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

Практичная шкала доверия выглядит так: получено, подтверждено локальным менеджером, подтверждено forwarding plane, наблюдается в трафике, проверено сервисом. RFC 9857 качественно усиливает первую ступень и помогает запустить проверку остальных. Он не делает их избыточными.

Что подтверждают реестры

Реестр IANA содержит назначенные для механизма типы и TLV BGP-LS. На странице RFC Editor опубликована проверенная errata 8709: в трёх местах «SR Binding SID sub-TLV» заменено на «SR Binding SID TLV». Исправление уточняет термин, но не добавляет время или доказательство установки. Эти источники фиксируют интероперабельную грамматику, а не свойства конкретного продукта.

Источники