Кратко

  • RFC 9830 определяет перенос кандидатов SR Policy в BGP, но проверяет их смысл, выбирает активный путь и устанавливает состояние модуль SRPM головного узла.
  • Distinguisher сохраняет объявления раздельными, не добавляя им приоритета, версии, доверия или полномочий.
  • Доказательство должно отдельно фиксировать прием, BGP best path, импорт по Route Target, допустимость в SRPM, активный выбор, Binding SID, установку в FIB и наблюдаемый путь пакетов.

На одном узле проходят два разных голосования

Начальный эпизод — модель границы протокола, а не описание конкретной сети. Корректный UPDATE может быть принят соседом, сохранен в таблице и выиграть BGP-отбор для своего NLRI. Все эти события достоверны. Ни одно из них не показывает, какая последовательность сегментов сейчас ведет пакеты.

RFC 9830 разделяет обязанности. BGP создает и распространяет сведения о candidate path. На головном узле они передаются в Segment Routing Policy Module, SRPM. Тот же модуль может получить другие кандидаты через CLI, NETCONF, PCEP или локальную конфигурацию. Он проверяет смысл полей, формирует множество альтернатив, выбирает активного кандидата, обрабатывает Binding SID и запрашивает установку в плоскость передачи.

Первое голосование выбирает лучший BGP-маршрут для конкретного NLRI. Второе выбирает активного кандидата для политики Color–Endpoint по правилам SR Policy. Победитель BGP может уступить локальному или PCEP-кандидату с более высокой Preference. Он может быть передан в SRPM и там отклонен из-за сегмента или Binding SID.

Поэтому индикатор «BGP best» нельзя переименовывать в «policy active». Тем более нельзя из него выводить «FIB installed» или «traffic verified». В стандарте прямо сказано, что BGP сам не устанавливает SR Policy Candidate Path в плоскость данных. Запись в BGP — квитанция доставки, а не исполнения.

Distinguisher разделяет записи, но не толкует их

NLRI SR Policy включает Distinguisher, Color и Endpoint. Color и Endpoint задают ключ политики. Разные Distinguishers позволяют источнику объявить несколько кандидатов одной политики или варианты для разных головных узлов так, чтобы BGP не слил их в одну запись.

Но Distinguisher не имеет смыслового значения. Большее число не новее и не надежнее. Неизменность числа не подтверждает неизменность замысла. Оно не обозначает сервис, согласующего руководителя или право менять поток. Его функция заканчивается на различении NLRI.

Отсюда следует многоуровневая модель идентичности. NLRI различает объявление; Color–Endpoint объединяет кандидатов политики; Protocol-Origin и Discriminator различают источники внутри SRPM; originator описывает источник протокола; заявка на изменение описывает человеческое полномочие. Удобный индекс не должен подменять остальные уровни.

Получатель восстанавливает BGP-originator в заданном порядке: Route Origin Community, ORIGINATOR_ID или Router ID непосредственного соседа. Это полезно за route reflector, однако не является корпоративной идентификацией и не доказывает разрешение на перенаправление сервиса. Сосед передает, originator создает протокольное объявление, согласующий отвечает за цель.

Символические Policy Name и Candidate Path Name тоже ограничены. Они необязательны и могут быть усечены. Название удобно для человека, но не заменяет ключ политики. Соединение данных только по отображаемому имени может слить разные политики или раздвоить одну после переименования.

BGP проверяет конверт, SRPM — содержание

Граница полномочий не означает отсутствия проверки в BGP. RFC 9830 задает SAFI 73, допустимые AFI, длину NLRI и форму Tunnel Encapsulation Attribute. Для SR Policy используется Tunnel Type 15. Неверный тип, недопустимый повтор TLV или поврежденная обязательная структура могут привести к treat-as-withdraw.

Так одна плохая запись удаляется без разрушения всей сессии. Это защищает доступность, но не сертифицирует смысл выжившего объявления. BGP не должен выполнять семантическую проверку отдельных полей SR Policy и отвергать UPDATE только из-за нее. Этот суд принадлежит SRPM.

Точные названия ошибок сохраняют ответственность. «Отозвано структурной проверкой BGP», «sub-TLV проигнорирован», «не импортировано для этого headend», «отклонено SRPM», «допустимо, но не выбрано» и «выбрано, но отсутствует в FIB» требуют разных действий. Общая метка «policy invalid» стирает место решения.

Правила расширяемости означают, что представления могут расходиться. Резервные биты отправляются нулевыми и игнорируются; неизвестные или неприменимые поля могут быть удалены; для некоторых одиночных sub-TLV учитывается только первый экземпляр. Набор байтов у контроллера, route reflector и SRPM не обязан совпадать. На каждой границе нужен отдельный хеш.

Preference — не предпочтение BGP

Похожие термины относятся к разным решениям. Preference влияет на выбор candidate path в SRPM, но не на BGP best path. Priority задает очередность пересчета политик после изменения топологии, а не ранг маршрута. Weight распределяет нагрузку между допустимыми списками сегментов выбранного кандидата; он не подтверждает установку или фактическую долю трафика.

Если хранить три поля как одну «важность», последствия изменения теряются. Новая Preference может переключить активного кандидата при неизменной BGP-таблице. Новая Priority меняет только порядок реакции. Новый Weight перераспределяет поток внутри кандидата. У каждой величины свой субъект и результат.

Binding SID также оставляет решение на принимающей стороне. В зависимости от флагов и типа плоскости данных headend может проверить, выделить, принять или отклонить SID. Некоторые варианты поведения SRv6 можно оставить opaque для локального выбора. Traffic Class, TTL и Explicit NULL в предусмотренных случаях допускают локальное переопределение.

Объявление — не готовая команда, а структурированная кандидатура. Журнал должен различать «получено», «принято», «переопределено локально», «выбрано» и «установлено».

Предназначенный получатель еще не активный путь

В небольшой сети контроллер устанавливает прямую сессию с headend. В масштабе используются route reflectors или несколько AS внутри доверенного SR-домена. Route Targets обозначают предполагаемых получателей.

Импорт по Route Target — решение об аудитории. Он доказывает, что локальная политика сочла объявление предназначенным для этой роли. Он не доказывает семантическую допустимость, победу над PCEP, пригодность Binding SID или установку в оборудование. Недостающий Target блокирует правильного кандидата; слишком широкий раскрывает политику ненужным маршрутизаторам.

Объявление может раскрывать endpoints, адреса узлов, SIDs и коммерчески чувствительный дизайн пути. Наличие BGP-сессии не разрешает автоматически каждую address family и каждого получателя. Доверенный домен, роль peer, SAFI, Route Targets и export policy образуют отдельную запись о раскрытии.

За reflector непосредственный сосед и исходный контроллер различаются. «Получено от», «создано протокольно» и «разрешено для деловой цели» — три независимых утверждения.

Withdraw удаляет источник, а не обязательно путь

Отзыв BGP SR Policy убирает вклад одного источника. В SRPM может остаться другой BGP-кандидат с иным Distinguisher, кандидат PCEP, локальная конфигурация или резерв. Активная политика может не измениться, переключиться, стать недействительной или исчезнуть. Сам withdraw не определяет исход.

И наоборот, новый BGP best path может дойти до SRPM без изменения плоскости передачи. Он проигрывает по Preference, содержит непроверяемый сегмент, запрашивает конфликтующий Binding SID или блокируется локальной политикой. Количество UPDATE не равно количеству изменений трафика.

Доказательная цепочка длиннее: сырой UPDATE и хеш; структурный результат BGP; лучший путь NLRI; импорт Route Target; восстановленная информация originator; результат SRPM; снимок всех кандидатов; выбор активного; состояние Binding SID; установленные сегменты и веса; readback RIB/FIB; пакеты на ожидаемом пути. Для каждого события нужны время, устройство, версия и код причины.

Минимальный стандарт оставляет последствия локальным

RFC 9830 стандартизирует общую поверхность: address family, NLRI, атрибуты, поля кандидата, распространение и обработку ошибок. Независимые реализации получают общий язык обмена предложениями. Стандарту не нужно присваивать все локальные решения.

Так работает принцип минимальной начальной спецификации Heng Lu. Общий формат устраняет неоднозначность передачи; локальный SRPM сохраняет власть над локальными последствиями. Приоритет работающего кода требует показаний реального headend и FIB, а не доверия к статусу Standards Track. Разделение слоев реальности не позволяет объявлению, выбранному состоянию и поведению пакетов стать одним фактом.

Практический тест отправляет двух BGP-кандидатов для Color–Endpoint с разными Distinguishers и добавляет более предпочтительного кандидата PCEP или локальной конфигурации. Наблюдайте, что остается в BGP, что проходит SRPM, какой кандидат активируется, какой Binding SID появляется в FIB и куда идут пакеты. Затем независимо отзывайте источники. Если мониторинг описывает все переходы как «состояние BGP», он потерял границу полномочий RFC 9830.

Источники