Кратко

  • RFC 9819 обновляет RFC 9252: побитовое OR правильно строит требуемый End.DT2M Service SID только тогда, когда объявления Ethernet A-D и Inclusive Multicast используют одну и ту же структуру SID.
  • При ESI Filtering маршрут Inclusive Multicast задаёт LOC:FUNC и границу вставки, а Ethernet A-D per ES передаёт Arg.FE2. Совпадение ненулевой Argument Length обязательно, но не доказывает равенство всей структуры.
  • Получение и разбор обоих маршрутов — лишь свидетельство control plane. Оно не доказывает актуальную связь, локальный выбор, программирование FIB или Local SID, выполнение Split Horizon и правильную доставку BUM-трафика.

В отчёте об инциденте легко написать: оба маршрута есть, атрибут корректен, SID вычислен. Но закрывающий вопрос звучит иначе: по чьей структуре он вычислен?

RFC 9252 первоначально предлагал Ingress PE объединять ESI Filtering Argument из EVPN Ethernet Auto-Discovery per Ethernet Segment route с подходящим End.DT2M SID из Inclusive Multicast Ethernet Tag route посредством побитового логического OR. Это работает, если значащие биты обоих компонентов расположены одинаково. RFC 9819, опубликованный в июле 2025 года, фиксирует выявленную реализациями и интероперабельностью неоднозначность: единообразие структуры не является общим правилом.

Изменение невелико для формата, но существенно для доказательств. Два синтаксически допустимых BGP-объекта не превращаются в корректную команду пересылки только потому, что устройство умеет объединить их 128-битные значения. Получателю необходимо знать, какое объявление владеет схемой Service SID, допускается ли аргумент, какова его длина и позиция и какая сервисная связь делает его применимым.

Один SID и два источника смысла

RFC 8986 делит SRv6 SID на Locator, Function и необязательный Argument. End.DT2M декапсулирует Ethernet payload и распространяет его по L2 table. Значение Arg.FE2 локально связывается с Ethernet Segment Identifier, чтобы Disposition PE исключил нужные выходные интерфейсы и сохранил Split Horizon.

RFC 9819 разделяет роли. Inclusive Multicast Ethernet Tag route, EVPN Route Type 3, объявляет LOC:FUNC для End.DT2M в Broadcast Domain. Ethernet A-D per ES route, Route Type 1, объявляет ESI Filtering Argument. Поскольку Behavior поддерживает аргумент, оба объявления несут SRv6 SID Structure Sub-Sub-TLV.

Structure — не комментарий. Locator Block Length, Locator Node Length и Function Length определяют начало Argument, а Argument Length — допустимый размер. Endpoint, владеющий LOC:FUNC, объявляет эту структуру. SR Source строит полный LOC:FUNC:ARG как IPv6 destination либо SRH segment.

В примере RFC 9819 с несколькими Broadcast Domain аргумент в обоих случаях имеет 16 бит, однако Function Length одного Type 3 Service SID равна 32 битам, другого — 16. Один и тот же Argument должен быть вставлен на разных смещениях. Слепое OR не нейтрально: оно молча предполагает совпадение позиций.

Дерево решений важнее зелёного индикатора парсера

Если Type 3 объявляет AL=0, Service SID не ожидает ESI Filtering Argument. Ingress строит LOC:FUNC, обнуляет последующие биты и игнорирует SID value и structure из Type 1. Даже показанный интерфейсом Argument нельзя использовать.

Если AL в Type 3 ненулевая, Ingress находит соответствующий Ethernet A-D per ES route и проверяет End.DT2M. При отсутствии маршрута либо AL=0 в Type 1 пригодного Argument нет: применяется LOC:FUNC без аргумента, а ожидавшееся Filtering следует отразить в журнале.

Если обе AL ненулевые, но различаются, это ошибка конфигурации. Argument использовать нельзя, а BUM-трафик от данного Ethernet Segment не должен пересылаться из-за риска петли. При равенстве AL Ingress вставляет Argument из Type 1 на смещение, заданное Structure из Type 3, и обнуляет биты после заявленного SID.

Равенство AL — пропускное условие, а не универсальный сертификат совместимости. Оно показывает, что payload помещается в поле, заявленное владельцем. Оно не доказывает одинаковую полную разметку, принадлежность Type 1 нужному Ethernet Segment или установку полученного адреса на Endpoint.

До сборки должны быть установлены идентичность и время

RFC 7432 задаёт EVPN-контекст: Route Distinguisher, Route Target, Ethernet Tag, ESI, Originating PE и Withdrawals. Эти поля не служебный шум. Они препятствуют объединению свежего LOC:FUNC с Argument из другого сегмента, другой Broadcast Domain или другой эпохи пути.

Доказательство сборки должно называть оба полученных пути и использованную связь. Фразы «Type 1 и Type 3 присутствуют» недостаточно. Нужны Originator, EVI, Ethernet Segment, выбранные Best Paths, время наблюдения, предыдущие Withdrawals и Flavor End.DT2M. Получение маршрута не равно его свежести, а актуальный RIB не подтверждает, что каждый кэш и программируемый объект использовал ту же генерацию.

RFC 9800 определяет поведения для сжатых списков SID. RFC 9819 допускает сжатые и несжатые Flavor End.DT2M, если проверки AL проходят, но не разрешает выбросить Flavor или Structure из доказательства. Не меняется и Transposition Scheme RFC 9252: при передаче переменных битов через MPLS label offset, length и пределы поля остаются самостоятельными входами проверки.

Построенный SID ещё не является сетевым результатом

RFC 9819 непосредственно специфицирует сигнализацию, проверки согласованности и сборку. Он не утверждает, что корректный расчёт выбран политикой, записан в оборудование или исполнен пакетом. Это отдельные уровни полномочий.

Ingress должен показать поддерживаемый Behavior, Feature Version, метод сборки, Eligibility и Selection маршрута, итоговый 128-битный destination и Programming Generation. Egress должен показать, что соответствующий Local SID вызывает требуемый End.DT2M Flavor, L2 table и актуальное отображение Arg.FE2. Лишь затем пакетные данные доказывают декапсуляцию и исключение правильных интерфейсов. На уровне результата ещё надо подтвердить доставку ожидаемым получателям, отсутствие возврата на исходный сегмент, дубликатов и петель в том же окне наблюдения.

Так сохраняются границы соседних стандартов. RFC 9819 — не выбор Candidate из BGP в SR Policy Manager по RFC 9830, не PCEP Color RFC 9863, не Interdomain D-PATH RFC 10039 и не жизненный цикл P2MP Tree/Leaf RFC 10018. Он отвечает на более узкий предшествующий вопрос: можно ли сложить два объявленных компонента в требуемый Service SID, не выдумывая общую структуру?

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

Защищаемая цепочка состоит из восьми квитанций: идентичность и свежесть маршрутов; Behavior и Structure; связь двух маршрутов; точная сборка; локальный допуск и выбор; запрограммированное состояние Ingress и Egress; исполнение пакетом; наблюдаемый сервисный результат. RFC 9819 усложняет подмену середины цепочки побитовой операцией, но не превращает всю цепь в один зелёный сигнал.

Источники