Кратко

  • Одобренное IESG расширение позволяет кандидатному пути BGP SR Policy нести управляющий NRP ID того Network Resource Partition, с которым путь должен быть связан.
  • Число выражает связь внутри домена, но не выделяет ресурсы и не доказывает локальное сопоставление, установленный селектор, доступную ёмкость, изоляцию или результат услуги.

Объявление указывает раздел, но не создаёт его

Представим, что headend получил два кандидатных пути с одинаковыми color и endpoint. В одном передан NRP ID 17, в другом — 29. Для плоскости управления разница означает, что пути предназначены для разных разделов ресурсов нижележащей сети.

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

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

25 августа 2026 года в 18:03 UTC IETF объявила, что IESG одобрил редакцию 13 документа «BGP SR Policy Extensions for Network Resource Partition» как Proposed Standard. Решение меняет состояние стандартизации, но не равнозначно выпуску окончательного RFC или внедрению в рабочей сети.

После одобрения остаётся цепочка публикации

Документ подготовлен рабочей группой Inter-Domain Routing. В объявлении отражены обсуждение зависимостей от работ TEAS и SPRING, приблизительный консенсус о продвижении и решение разрешить нормативные ссылки в очереди RFC Editor.

На момент фиксации доказательств 28 августа Datatracker всё ещё показывал редакцию 13 как Active Internet-Draft. В RFC Editor она была заблокирована из-за неполученной ссылки. Проверка IANA требовала нового рассмотрения после изменения версии, а действие оставалось в работе. Поэтому нельзя заранее называть окончательный номер RFC или считать регистрацию завершённой.

Объявление сообщает о двух реализациях. В публичном отчёте IDR названы поверхности Huawei VRP и H3C Comware, однако там сохраняются формулировки о более ранней версии и строки возможностей со статусом TBD. Это свидетельство инженерной работы и осуществимости, а не полного соответствия редакции 13, масштабной совместимости или широкого включения функции.

NRP — это ресурсы и правила, а не целое число

RFC 9543 определяет Network Resource Partition как подмножество ресурсов underlay и связанных политик, способное поддерживать одну или несколько услуг сетевого среза. RFC 9732 помещает NRP в модель расширенного VPN, где конструкция связности может быть сопоставлена этим ресурсам.

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

В редакции 13 NRP ID — это 32-битное имя плоскости управления, уникальное только внутри домена NRP. Локальная конфигурация и реализация связывают его с NRP Selector ID плоскости данных. Оно не является глобальным и не содержит ресурсного обещания.

Область применения намеренно узкая: документ рассматривает выделенный, единый для домена селектор в плоскости данных. Другие способы выбора NRP могут обходиться без явного сигнала в SR Policy и не входят в эту спецификацию.

Шесть октетов устраняют структурный спор

Расширение определяет NRP ID sub-TLV внутри BGP Tunnel Encapsulation Attribute для типа туннеля SR Policy. В редакции 13 назначен тип 123, а длина должна составлять шесть октетов: один для флагов, один резервный и четыре для идентификатора.

Флаги и резервные биты передаются нулевыми и игнорируются при приёме. Значение NRP ID 0 зарезервировано: отправитель не должен его использовать, а получатель игнорирует sub-TLV с нулём. Элемент необязателен, но может появиться у одного кандидатного пути не более одного раза.

Другая длина или дубликат делает сведения NRP, связанные с SR Policy NLRI, некорректными. Получатель применяет treat-as-withdraw по RFC 7606. Так структурно неоднозначная связь не попадает в состояние маршрутизации.

Семантическая ошибка остаётся возможной. Корректно закодированный ненулевой ID может быть локально сопоставлен не тому селектору. Валидность на проводе не подтверждает правильность ресурсов.

Лучший маршрут BGP лишь переходит к следующему владельцу

Когда кандидатный путь создаётся в NRP домена с выделенным селектором, источник обязан включить sub-TLV. Принимающий BGP speaker применяет правила валидности и применимости RFC 9830. Обычный выбор лучшего маршрута BGP не меняется.

Выбранные лучшие маршруты SR Policy SAFI затем передаются в SR Policy Module. Эта граница принципиальна. Принятый маршрут может не стать активным кандидатом; полученный SRPM путь может не установиться; установленный путь может получить неправильный селектор из-за расхождения локального сопоставления.

Доказательство должно соединять выбор кандидата, установленный список сегментов, версию сопоставления NRP ID и селектора, добавление селектора в пакет, steering услуги, подготовленные очереди и линии и измеренные задержку, потери, пропускную способность и изоляцию. Успешное объявление контроллера подтверждает лишь отправку и приём связи в известном контексте сессии.

Резервный кандидат не должен тайно менять смысл

Редакция 13 разрешает кандидатам одной SR Policy быть связанными с разными NRP, но называет такую конфигурацию допустимой и не рекомендуемой. В обычных сценариях все кандидаты должны сохранять одну связь с NRP.

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

Даже одинакового числа на всех headend недостаточно. Устройства должны одинаково его понимать, плоскость данных — применять соответствующий селектор, а underlay — иметь подготовленные ресурсы. Единая цифра над различными локальными картами создаёт согласованный синтаксис и расходящееся поведение.

Масштабирование нагружает контроллеры и headend

По мере роста числа NRP могут расти количество SR Policy и кандидатных путей, а объём сведений между контроллером и headend — увеличиваться пропорционально.

Расширение не меняет процедуру объявления SR Policy или алгоритм лучшего пути BGP. Кандидатов устанавливают соответствующие headend, поэтому одинаковое дополнительное состояние не появляется на транзитных узлах. Это полезная граница, но не обещание нулевой стоимости.

Контроллеры создают и сверяют состояние, headend принимают, проверяют, передают и устанавливают его. Мониторинг должен раздельно видеть объявленные, валидные, лучшие, переданные в SRPM, активные и установленные объекты, иначе зелёная плоскость управления скроет предел headend.

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

Раздел безопасности наследует защиту BGP, SR Policy и NRP и прямо указывает локальный риск: неверная связь способна повредить изоляции трафика и гарантиям ресурсов.

Доверенный контроллер может отправить не тот ID. Доверенный headend может сопоставить правильный ID другому селектору. Правильный селектор может вести к устаревшей конфигурации ресурсов. Аутентификация компонентов не подтверждает смысл их совместного результата.

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

Для каждого эпизода следует сохранять идентичность и версию контроллера, BGP peer и сессию, ключ NLRI, происхождение и предпочтение кандидата, исходные байты sub-TLV, решения валидности и выбора, приём и выбор SRPM, установленный список сегментов, сопоставление и его версию, конфигурацию ресурсов, steering услуги, наблюдаемый селектор пакета, результаты очереди, потерь, задержки и изоляции, withdrawal, fallback, rollback и общие временные метки.

Источники