Кратко

  • RFC 9514 переносит через BGP-LS сведения об SRv6-узлах, каналах, Locators и SIDs к потребителям, включая системы вычисления пути.
  • Prefix NLRI с SRv6 Locator TLV 1162 остаётся только объявлением Locator, если рядом нет Prefix Metric TLV 1155; Errata 7737 исправляет ошибочную ссылку опубликованного текста на TLV 1095.
  • Надёжная эксплуатационная запись отдельно фиксирует объявление, классификацию достижимости, связь с SID, вычисление, установку и наблюдаемый результат прохождения пакетов.

В журнале приёма всё выглядит спокойно. Сессия BGP-LS установлена. Prefix NLRI синтаксически корректен. В нём есть SRv6 Locator TLV 1162, алгоритм и metric. Объект появился в топологической базе, а контроллер связал его с узлом-источником.

Однако состояние «получено» не отвечает на вопрос о смысле объекта. Узел объявил пространство, внутри которого размещает SIDs, или одновременно объявил обычную достижимость этого префикса?

RFC 9514 задаёт точное условие перехода. Locator передаётся как Prefix NLRI с SRv6 Locator TLV. Тот же объект становится ещё и объявлением обычной достижимости только при наличии соответствующего Prefix Metric TLV. Без него это по-прежнему только объявление Locator.

Ошибка в номере меняет проверяемый объект

В опубликованном тексте указан IGP Metric TLV 1095. Подтверждённая errata заменяет его на Prefix Metric TLV 1155: 1095 относится к Link NLRI, тогда как Locator связан с Prefix NLRI.

Исправление защищает не таблицу кодов, а переход между состояниями. Внутри Locator TLV уже есть поле Metric, скопированное из исходного объявления Locator в IS-IS или OSPFv3. Но эта величина характеризует сам Locator. Она не заменяет отдельный Prefix Metric TLV 1155, наличие которого даёт потребителю право классифицировать префикс ещё и как обычную достижимость.

Если реализация следует неверному номеру, она может искать доказательство у Link NLRI, молча принять внутреннюю metric за замену или разойтись с другой версией того же контроллера. Оба экземпляра при этом способны успешно разобрать BGP-обновление. Поэтому в архиве должны существовать разные состояния: 1162 есть, 1155 нет и 1162 есть, 1155 есть. Зелёный индикатор приёма не должен склеивать их.

Независимые NLRIs требуют независимых часов

RFC 9514 экспортирует не плоский список, а граф SRv6-объектов. Атрибуты узла несут возможности, алгоритмы и типы Maximum SID Depth. Атрибуты канала описывают End.X, LAN End.X и пределы конкретного канала. Атрибуты префикса несут Locators. Каждый SID, связанный с узлом, передаётся отдельным SRv6 SID NLRI типа 6.

Выбор отдельного NLRI для SID решает проблему масштаба: одно изменение не вынуждает заново отправлять большой атрибут узла. Одновременно появляются отдельные часы жизни. Потребитель обязан соединить SID с правильным узлом, исходным протоколом, идентификатором топологии, endpoint behavior и эпохой Locator. Если SID отозван, сохранившийся узел или соседний Locator не продлевает его существование.

Каждый SID NLRI требует Endpoint Behavior TLV. Для BGP EPE PeerNode или PeerSet SIDs добавляется контекст соседа, а необязательный SID Structure TLV может описывать длины locator-block, locator-node, function и argument. RFC 8986 определяет словарь endpoint behavior, а RFC 8402 — архитектуру Segment Routing. Код поведения остаётся заявленным свойством, а не трассой пакета, подтверждающей исполнение.

У источников также разная область полномочий. RFC 9514 копирует необходимые поля из расширений SRv6 для OSPFv3 или IS-IS. В случае BGP EPE или Direct Protocol-ID локальный узел предоставляет сведения от собственного имени. RFC 8814 задаёт передачу MSD через BGP-LS. После объединения в одном хранилище эти утверждения не приобретают общего происхождения задним числом.

BGP проверяет форму; смысл собирает потребитель

RFC 9514 прямо оставляет семантическую и содержательную проверку, в том числе правильность связи TLV с NLRI или BGP-LS Attribute, за потребителем. BGP способен проверить формат. Он не подтверждает, что Locator следует считать маршрутом, что SID всё ещё создан на устройстве, что алгоритм разрешён текущей политикой или что вычисленный путь соответствует работающей сети.

Действующая базовая спецификация BGP-LS, RFC 9552, различает производителя, распространителя и потребителя. Производитель выводит и создаёт проекцию топологии; распространитель отбирает и передаёт BGP-информацию; потребитель собирает её и применяет. Валидное обновление подтверждает передачу между ролями, но не вывод, сделанный последней ролью.

Защищаемая журналом цепочка начинается с исходного протокола, производителя, Protocol-ID, Identifier и Local Node Descriptors. Затем сохраняются точные Prefix NLRI и Locator TLV 1162, алгоритм, metric Locator и эпоха топологии. Отдельно записывается состояние Prefix Metric TLV 1155 — присутствовал, отсутствовал, дублировался или был отклонён — и версия правила, учитывающая errata.

Если в решении участвовал SID, цепочка включает SID NLRI, Information TLV 518, Endpoint Behavior TLV 1250, контекст соседа, необязательную структуру и историю отзыва. Вычисление получает собственную квитанцию: снимок потребителя, ограничения, версию политики, множество кандидатов, выбранный путь и время. Далее отдельно фиксируются принятие устройством, установка RIB/FIB или SR policy и контролируемое наблюдение пакетов.

Спецификация читается вместе с историей её исправления

Официальные материалы позволяют восстановить не только итоговый текст, но и путь проверки. RFC Editor публикует информационную карточку, текстовую версию и XML. Datatracker сохраняет историю RFC, финальную редакцию Internet-Draft и граф ссылок. А реестр параметров BGP-LS IANA фиксирует кодовые точки. Всё это доказывает общий язык и его исправленное прочтение, но не результат конкретного внедрения.

Редакционная рамка опирается на три явно указанных эссе Heng Lu: о приоритете работающего кода, о минимальной начальной спецификации и добровольном принятии и о слоях реальности. Это не требования IETF. Здесь они задают дисциплину доказательства: символ стандарта, модель контроллера, установленное состояние и наблюдаемый пакет не подменяют друг друга.