Кратко

  • 5 сентября 2026 года IETF опубликовала редакцию 18 документа Traffic Steering using BGP FlowSpec with SR Policy. На момент проверки это был Internet-Draft в состоянии AD Evaluation::External Party, а не одобренный RFC.
  • Редакция 17 требовала обычный Redirect-to-IP, если в инструкции был адрес перенаправления, но не было корректного Color. Редакция 18 запрещает такой откат при наличии неполного SR-намерения и требует отбросить трафик либо применить локальную политику отказа.
  • Корректный маршрут FlowSpec остаётся в Loc-RIB и продолжает объявляться, даже если SR Policy недоступна, не разрешается или не устанавливается в FIB/TCAM. Запись в плоскости управления не доказывает судьбу пакета.
  • Текущий раздел совместимости говорит, что headend без поддержки расширения может игнорировать Prefix-SID и использовать обычный Redirect-to-IP. В смешанном парке одно обновление способно вызвать отбрасывание на одном устройстве и перенаправление на другом.
  • Предыдущий Working Group Last Call относился к редакции 13. После редакции 17 Area Director попросил сопредседателей IDR снова проверить консенсус. Новое решение должно быть привязано к точной версии и её таблице отказов.

Отсутствующее поле перестало разрешать обход

FlowSpec распространяет по BGP условия выбора пакетов и связанные действия. Проект связывает их с Segment Routing Policy: адрес Redirect-to-IP и Color Extended Community образуют пару (Endpoint, Color). Она выбирает SR Policy. Во втором, SRv6-режиме атрибут BGP Prefix-SID может нести Egress Service SID для заданного действия на выходе.

Близкие комбинации имеют разный смысл. Один Redirect-to-IP без SR-признаков остаётся обычным IP-перенаправлением. Адрес с корректным Color означает steering в SR Policy. Prefix-SID рядом с адресом, но без корректного Color, уже показывает желание использовать SR, хотя ключ policy неполон.

Редакция 17 разрешала последний случай, игнорируя Prefix-SID и возвращаясь к обычному перенаправлению. Редакция 18 отказывается догадываться. Поддерживающий headend не должен искать default или null-color policy, использовать service SID либо читать сообщение как простой Redirect-to-IP. Совпавший трафик отбрасывается или попадает под заранее определённую локальную политику отказа.

Это не правило «нет Color — всегда drop». Чистый Redirect-to-IP сохраняет прежний смысл. Запрет относится к превращению неполной SR-команды в другую команду. Он не даёт незаметно доставить пакет по пути вне замысла, но может превратить отклонение от policy в явный перерыв сервиса.

Маршрут остаётся, действие исчезает

Редакция 18 разделяет корректность объявления и возможность исполнения. Если SR Policy находится в Down, не разрешается или не программируется, прошедший BGP-проверки маршрут FlowSpec остаётся в Loc-RIB и распространяется дальше. Сбой нижнего уровня сам по себе не делает инструкцию недействительной.

В плоскости данных steering-запись должна оставаться неактивной. Если policy работает, но Egress Service SID недоступен в локальной RIB/FIB, молчаливый переход на кратчайший IP-путь тоже запрещён. Проект рекомендует drop как стандартное локальное действие, сохраняя право оператора выбрать иную политику. Остальные корректные действия FlowSpec, например rate limit, продолжают применяться.

Такое разделение ускоряет восстановление: когда policy вернётся, маршрут не нужно учить заново. Но зелёный индикатор RIB становится лишь частью квитанции. Следует раздельно фиксировать принятие маршрута, его передачу, установку FIB и результат тестового пакета.

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

Неподдерживающий headend выбирает другую ветвь

Устройство может поддерживать базовый FlowSpec и Redirect-to-IP, не зная этого проекта. Prefix-SID — необязательный транзитивный атрибут. Такой headend может передать его дальше без понимания, проигнорировать при собственной пересылке и применить знакомое перенаправление.

Байты одинаковы, сервис — нет. Реализация редакции 18 распознаёт неполное SR-намерение и блокирует откат. Старая реализация не имеет такой смысловой категории и видит корректный Redirect-to-IP. Для расхождения не нужны повреждение UPDATE или разрыв BGP; достаточно неучтённой границы возможностей.

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

Приёмочное испытание должно создавать неудобные состояния: чистый Redirect-to-IP, корректные Mode 1 и 2, отсутствующий или испорченный Color, Down policy, недоступный SID, отказ программирования и неподдерживающий приёмник. Для каждого случая нужны Loc-RIB, дальнейшее объявление, FIB, drop/redirect counters, контрольный пакет, тревога, подавление и восстановление.

Консенсус редакции 13 не подписывает редакцию 18

Shepherd write-up связывает прежнюю положительную поддержку с коротким недельным WGLC для редакции 13. Затем в ходе AD evaluation документ получил два режима, последовательное разрешение атрибутов, дополнительные service actions, новые правила отказа и совместимости, а также более подробные операционные и защитные требования.

26 августа, после редакции 17, ответственный Area Director попросил сопредседателей IDR опросить рабочую группу ещё раз до дальнейшего продвижения. Datatracker перешёл в AD Evaluation::External Party. Редакция 18 от 5 сентября вновь изменила материальное решение: запретила обычный fallback при неполном намерении, добавила недоступность service SID и уточнила сборку segment list, фильтры и наблюдаемость.

Повторный опрос — не лишний круг. Участник может поддерживать общую связку FlowSpec и SR Policy, но не выбор fail-closed. Для одного сервиса уход с заданного пути опаснее остановки, для другого — наоборот. Rough consensus означает, что техническое возражение понято и обработано; он не переходит по наследству от таблицы, предписывавшей другой результат.

Вопрос должен назвать редакцию 18 и спорные ветви: отсутствие Color, сохранение RIB, сбой policy или SID, локальную власть и legacy-поведение. Итоговая запись должна сохранять возражения и аргументацию chairs, а не только слово «консенсус» без версии.

У running code есть дата

Раздел Implementation Status перечисляет четыре маршрутизатора и четыре контроллера, участвовавшие в совместных тестах China Mobile с июля по октябрь 2021 года. Он также сообщает о производственном использовании в backbone с августа 2022 года. Обязательная оговорка указывает: данные предоставили участники, независимой проверки не было, список не является одобрением IETF.

Хронология дополнительно сужает вывод. Проверенные источники не связывают тесты 2021 года с нынешней матрицей редакции 18, случаем недоступного service SID, правилами replace/append или смешанным парком. Текст, добавленный позднее, не может задним числом добавить тестовый сценарий.

Прежний опыт следует не отвергать, а версионировать. Для каждой реализации нужны build, draft revision, включённые функции, отрицательные комбинации, способность peer и наблюдаемый пакет. Новый прогон расширит старую запись, не превращая возраст в охват.

Квитанция, связанная с версией

Первая часть фиксирует hash исходника редакции 18, даты опроса, точный вопрос, архив ответов, возражения и вывод chairs. Вторая использует тот же текст и перечисляет простое перенаправление, корректные режимы, неверный Color, Down policy, недоступный SID и ошибку FIB.

В каждой строке результаты поддерживающего и неподдерживающего headend разделены. Принятый маршрут, дальнейшее объявление, установленное действие и наблюдаемый пакет — разные поля. Счётчики, тревоги и состояние подавления завершают цепочку.

План развёртывания называет отправителя, группы приёмников, версии, фильтры, разрешённые диапазоны SID, локальную политику, retry, canary и rollback trigger. Чувствительные адреса можно заменить устойчивыми псевдонимами; версию и результат — нельзя. Исправление добавляется после первого провала, а не стирает его.

Принцип минимальной спецификации Heng Lu используется здесь только как редакционная проверка. Общее значение должно быть небольшим, детерминированным и проверяемым. Локальный выбор потери остаётся у оператора, если известны владелец решения и фактический результат. Ни имя IETF, ни «локальная политика» не оправдывают скрытую несовместимость.

Редакция 18 может оказаться лучше редакции 17. Но ей всё равно нужны согласие с нынешним правилом и испытание обеих поколений headend. Старый консенсус и старый код не могут проголосовать за новый drop.

Источники

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — текст редакции 18
  3. IETF — текст редакции 17
  4. IETF Author Tools — сравнение редакций 17 и 18
  5. IETF Datatracker — история документа
  6. Список IDR — просьба снова проверить консенсус
  7. IETF — document shepherd write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification