Кратко

  • RFC 9862 представляет SR Policy как PCEP Association, а каждый путь-кандидат — как LSP внутри ассоциации. Путь служит единицей сигнализации, однако смысл некоторых решений определяется только по всему множеству.
  • Флаг конфигурации D передаётся в TLV INVALIDATION на пути-кандидате. Если его включает хотя бы один путь, Drop-Upon-Invalid включён для всей SR Policy; отбрасывание начинается лишь после того, как недействительными стали все кандидаты.
  • Нужна квитанция об отбрасывании уровня политики, связывающая согласованные возможности, полный состав, конфигурационный и операционный D, момент общего порога, выбранный путь и результат для пакетов. Это редакционное предложение Daniel Kade, а не поле RFC и не требование IETF.

Красный индикатор рядом с одним маршрутом выглядит локальным. Он пришёл в объекте LSP, привязан к идентификатору пути-кандидата и естественно помещается в строку этого пути. Хранилище может точно воспроизвести формат протокола, но дать ложное объяснение, если сочтёт границу строки границей последствия.

Drop-Upon-Invalid настраивается через TLV INVALIDATION отдельного кандидата, но действует не только на него. Один конфигурационный D означает, что функция включена для всей SR Policy. Немедленного отбрасывания при этом нет. Должно выполниться второе условие: все пути-кандидаты политики становятся недействительными. Тогда политика входит в drop state, выбирает включённый путь с наибольшим значением Preference, продолжает притягивать соответствующий трафик и отбрасывает его на headend вместо обычного ухода на запасной маршрут.

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

Протокол говорит отдельными путями, решение принимает множество

SR Policy может состоять из нескольких путей-кандидатов. RFC 9862 вводит SR Policy Association, или SRPA, которая представляет политику в PCEP; каждый LSP внутри неё представляет кандидат. Такое отображение следует грамматике PCEP: именно LSP является единицей объявления, обновления и отчёта.

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

Color и endpoint идентифицируют политику, а originator и discriminator участвуют в идентичности кандидата. Один кандидат может входить не более чем в одну SRPA, его идентификатор стабилен в течение PCEP-сессии, дубликаты внутри политики недопустимы. Корреляция технически возможна. Но протокол не создаёт за оператора исторический снимок с временем и источником.

Согласование возможностей отвечает на узкий вопрос. Оба узла должны объявить поддержку SRPA до использования. Объявивший поддержку отправитель обязан включать ассоциацию для каждого исходящего LSP SR Policy. TLV SRPOLICY-CAPABILITY отдельно сообщает о computation priority, Explicit NULL, invalidation и stateless operation. SRPA без согласованной возможности вызывает ошибку и закрытие сессии. Это подтверждает общий словарь, но не недействительность всех путей и не отбрасывание пакетов.

Две буквы D принадлежат разным слоям

В TLV INVALIDATION есть поля Config и Oper. D в Config означает, что кандидат включает Drop-Upon-Invalid. D в Oper означает, что LSP прямо сейчас активно отбрасывает трафик из-за сработавшей функции. Общая буква не делает намерение исполнением.

Направление сообщения тоже меняет смысл. От PCE к PCC идёт указание включить или выключить настройку. От PCC к PCE возвращаются текущая конфигурация и состояние отбрасывания. Запись «последний D» без отправителя, направления, сессии и времени может превратить распоряжение в подтверждение, а желаемое состояние — в наблюдаемое.

Обычное поведение показывает альтернативу. Недействительный LSP перестаёт притягивать трафик, который может уйти по другому LSP или IGP. Drop-Upon-Invalid намеренно сохраняет притяжение и уничтожает пакеты на headend. Это разумный fail-closed, когда нежелательный обход хуже явного отказа. Но устаревшая или неверно ограниченная настройка способна превратить восстанавливаемый сбой в сознательную остановку. RFC определяет совместимый механизм, а не универсальный выбор риска.

Даже операционный D ещё не доказывает результат data plane. Нужны счётчики и наблюдение пересылки: пришли ли пакеты, сколько было отброшено и как долго. Сигнал, интерпретированное состояние и физический исход остаются отдельными свидетельствами.

Решающий момент — потеря последнего действительного пути

По RFC 9256 политика SR недействительна, когда недействительны все её пути-кандидаты. Это предикат множества. Первая потеря уменьшает резервирование, следующая может сменить активный выбор, но границу политики пересекает только отказ последнего действительного пути.

После этого политика проверяет, был ли D включён хотя бы на одном кандидате. Если да, она входит в drop state и активирует среди таких кандидатов тот, у которого Preference выше. RFC 9862 разрешает сообщить PCE только один путь с операционным D. Для сигнализации этого достаточно, для причинной истории — нет.

Представим три кандидата. На старом пути с низкой Preference остался D от прежнего решения, на двух основных его нет. Отказ основных путей не запускает отбрасывание, пока последний кандидат действителен. Когда он тоже отказывает, старая настройка делает всю политику готовой к drop state. LSP с операционным D показывает текущего носителя, но не автора исходного решения, срок его действия и последнее изменение, замкнувшее условие «все недействительны».

Preference и computation priority необходимо хранить отдельно. Preference выбирает лучший кандидат: большее значение сильнее, значение по умолчанию в RFC 9256 равно 100. Приоритет вычисления из RFC 9862 задаёт очерёдность пересчёта после изменения топологии: меньшее значение идёт раньше, условное значение по умолчанию равно 128. Универсальная колонка «priority» легко переворачивает вывод, не вызывая ошибки формата.

Отсутствующее значение может означать локальное решение

RFC 9862 задаёт значимую семантику отсутствия. При наличии возможности, но без TLV computation priority применяется 128. Если нет TLV Explicit NULL, решает локальная конфигурация. Этот TLV относится к SR-MPLS, игнорируется для SRv6, неизвестные значения тоже игнорируются, а оператор может переопределить полученное поведение локально.

Пустота может быть default, делегированием, неприменимостью или результатом переопределения. Одного null для этого недостаточно. При расследовании drop state важны фактическое значение, источник, приоритет правил, версия реализации и PCEP-сессия.

RFC 9862 требует дать оператору просмотр идентификаторов политики и кандидата, объявленных в SRPA. Также рекомендуется показывать возможности каждого peer и LSP, связанные с конкретной политикой. Это необходимая видимость. Для долговременного объяснения эти представления нужно связать в один переход.

Квитанция о расширении области действия

Предлагаемая квитанция об отбрасывании уровня политики начинается с Color, endpoint, SRPA, PCEP-сессии и возможностей, увиденных обеими сторонами. Затем она фиксирует полный состав кандидатов, использованный решением: originator, discriminator, Preference, конфигурационный D и действительность каждого.

Далее записывается ход событий. Когда и по какому источнику каждый путь стал недействительным? Какой был последним действительным? В какой момент условие «все недействительны» стало истинным? Какие кандидаты имели D, какой был выбран носителем, в каком направлении появился операционный отчёт? Несовпадение намерения PCE и отчёта PCC нельзя скрывать.

Последняя часть относится к пакетам. Продолжал ли трафик направляться в политику? Какие счётчики headend показывают отбрасывание? Когда случились первый и последний drops? Восстановление пришло из-за ожившего пути, новой конфигурации, изменившегося состава или удаления политики? В квитанцию входят владелец, защищаемый сервис, исключение, дата проверки и откат.

Это не предложение выгружать топологию центральному органу. SRPA и TLV способны раскрывать дополнительные сведения о политике. Поэтому RFC 9862 наследует рекомендацию использовать аутентифицированные и зашифрованные TLS-сессии PCEP между PCE и PCC одной административной области. Квитанция остаётся локальной, ограниченной и защищённой.

Она также не является новым расширением RFC. Это редакционная дисциплина, которая не позволяет принять место кодирования бита за границу реального решения.

Sources