Summary
- RFC 9933 делает SR-Algorithm видимым в объектах маршрута и ограничениях PCEP. Для значений 128–255 PCE всё равно выбирает победившее Flexible Algorithm Definition, применяет его метрику, ограничения, сведения об участвующих узлах и атрибуты топологии. Одинаковый номер сам по себе не доказывает неизменность политики.
- Для аудита нужен не более тяжёлый пакет маршрутизации, а квитанция разрешения политики: связь номера с конкретным победившим FAD, основанием выбора, областью, словарём метрик, целевой функцией, ослабленными объектами, версией правил отсечения и хешем TED. Секретная карта сети при этом может не раскрываться.
В журнале аварии есть две строки. До переключения — SR-Algorithm 130. После — тот же SR-Algorithm 130. Сеанс PCEP защищён, возможности согласованы, списки сегментов корректны. На панели обе строки выглядят как доказательство одной и той же политики.
Однако между ними могло появиться объявление FAD с более высоким приоритетом. Новое определение могло заменить задержку локальной метрикой стоимости, добавить ограничение на обратное направление или изменить порог пропускной способности. Узел, не поддержавший новый элемент, мог прекратить участие. Номер 130 при этом менять не требуется.
Протокол остаётся согласованным. Меняется то, что организация должна помнить о решении.
RFC 9933 стандартизирует перенос алгоритма, связанного с SID, ограничение вычисления по SR-Algorithm и новые типы метрик в PCEP. Документ подробно задаёт согласование возможностей, ошибки и поведение вычислителя. Но в случае Flexible Algorithms полная политика находится не в запросе: она разрешается из распределённых определений и текущих данных сети.
Короткий идентификатор полезен именно потому, что заменяет длинное описание. Нельзя затем требовать от него доказательств, которые были отброшены ради этой компактности.
Что действительно фиксирует RFC 9933
RFC 9933 опубликован в июле 2026 года как документ IETF Standards Track и обновляет расширения PCEP для Segment Routing в MPLS и IPv6. Поле Algorithm может передаваться в подобъектах SR-ERO и SR-RRO и их вариантах SRv6. TLV SR-Algorithm внутри LSPA позволяет головному узлу запросить определённое ограничение.
Механизм нельзя включать без объявления поддержки обеими сторонами. Попытка использовать его без согласованной возможности приводит к ошибке Invalid Operation. Несогласованная длина делает объект некорректным. Неизвестный SID имеет отдельную ошибку. Если сочетание ограничений невыполнимо, PCE возвращает пустой ERO или NO-PATH, а не незаметно строит более свободный путь.
Эти требования создают сильные технические свидетельства: стороны понимали расширение, сообщение имело правильную форму, ограничения обрабатывались по правилам, а неудача не выдавалась за успех. Но они не указывают версию институциональной политики, стоявшую за числом.
Значения 0 и 1 зарегистрированы как SPF и Strict-SPF. Диапазон 2–127 оставлен для стандартизованных алгоритмов. Значения 128–255 — Flexible Algorithms, смысл которых устанавливается конфигурацией и объявлениями оператора.
Поэтому запись «Algorithm 130» может быть точной и всё же недостаточной. Она содержит ключ, но не версию объекта, открывавшегося этим ключом.
Победившее FAD — это разрешённая политика
RFC 9350 называет Flexible Algorithm Definition, или FAD, совокупность типа вычисления, типа метрики и ограничений. Число от 128 до 255 связывается с этой совокупностью настройкой.
Несколько маршрутизаторов могут объявлять разные определения одного номера. Все участники выбирают одно по детерминированному порядку. Сначала предпочтение получает наибольший числовой приоритет. При равенстве выигрывает объявление от наибольшего числового IS-IS System-ID или OSPF Router ID. Результат называется winning FAD.
Так достигается согласие внутри области распространения. Но для аудита это означает, что смысл 130 зависит от списка кандидатов, приоритетов, источников и правила разрешения ничьей. Одно новое объявление с большим приоритетом может заменить весь набор метрик и ограничений, не меняя номер.
Более того, источник FAD не обязан сам участвовать в алгоритме. Получатели всё равно учитывают его объявление. Право определять политику можно отделить от устройств, которые её исполняют. Централизация удобна, но полномочия на публикацию и повышение приоритета должны быть видимы.
Если узел не поддерживает элемент победившего FAD, RFC 9350 требует прекратить участие и удалить соответствующее состояние пересылки. Изменение определения может вызвать перерасчёт и повторную сходимость по всей сети. Норма обеспечивает согласованное новое состояние, но не хранит решение о том, кто и зачем ввёл его в действие.
Текущее FAD не доказывает вчерашнего победителя. Нужны прежние кандидаты, их приоритеты, итог выбора и срок действия изменения.
Область действия входит в значение номера
FAD выбирается в пределах области. RFC 9350 прямо разрешает одному номеру иметь разные определения в разных областях. В одной области он может минимизировать задержку, в другой — предпочитать пропускную способность.
Это полезная локализация политики, а не ошибка. Ошибка возникает в отчёте, где все появления 130 сведены к одной глобальной метке. Число без области похоже на номер закона без юрисдикции: ссылка формально существует, но не позволяет узнать норму.
Для интерпретации нужны область OSPF, уровень IS-IS, границы объявления и эпоха политики. Если одинаковое число применяется в нескольких областях, следует явно указать, должна ли семантика совпадать или совпадает лишь удобная нумерация.
RFC 9933 оставляет вне сферы документа вариант, при котором в частях одного сквозного вычисления действуют разные ограничения SR-Algorithm или разные победившие FAD с неодинаковыми метриками. Многодоменный журнал не должен скрывать эту границу. Он обязан фиксировать каждое разрешение отдельно.
Локальная автономия не мешает аудиту, если у каждого смысла сохранена его юрисдикция.
Архив запроса не является архивом решения
Для Flexible Algorithms RFC 9933 требует выполнять расчёт по данным Traffic Engineering Database. В TED должны быть FAD, участие узлов и прикладные атрибуты каналов, полученные через расширения IGP либо механизмы вроде BGP-LS из RFC 9552.
Путь зависит и от сообщения, и от меняющейся среды фактов.
Иерархия метрик особенно показательна. PCE обязан использовать тип метрики из FAD. Если PCC передал метрику оптимизации прямо в PCEP-запросе, для Flexible Algorithm её следует игнорировать. PCE объединяет ограничения FAD с прямыми ограничениями PCC, подчиняясь правилам обработки, а PCC не должен дублировать в сообщении собственные ограничения FAD.
Такое разделение исключает противоречивые копии политики. Но те же байты запроса, воспроизведённые позднее, могут законно дать другой путь: победитель, топология, участие и правила уже изменились.
PCReq и PCRep могут полностью документировать обмен, но не вычислительный контекст. Для решения необходимо зафиксировать внешнее состояние, к которому был применён запрос.
Локальная метрика кодирует выбор организации
RFC 9843 расширяет FAD ограничениями по пропускной способности и задержке, автоматическим расчётом метрики пропускной способности и общими метриками. Типы 128–255 оператор может назначать локально.
Это позволяет измерять финансовую стоимость, джиттер, энергозатраты или договорный риск без преждевременной глобальной стандартизации. Но «metric-type 130» не раскрывает единицу, формулу или источник. RFC 9843 указывает, что при использовании пользовательской метрики между областями или уровнями домены должны придавать типу одинаковый смысл.
Даже стандартизованная метрика пропускной способности зависит от политики. Явно объявленное значение канала имеет преимущество над автоматическим выводом. При его отсутствии победившее FAD может задать эталонную полосу или таблицу порогов. Изменение центрального параметра меняет стоимость многих каналов, оставляя SR-Algorithm прежним.
Выбор измеряемого свойства распределяет ресурсы и риск. Оптимизация задержки, ёмкости или денег направляет трафик по разной инфраструктуре и расходует разные резервы отказоустойчивости.
Для локальной метрики следует сохранять владельца, единицы, нормализацию, версию, источник и область. Для автоматического вывода — метод, параметры и приоритет входных данных. Повторить арифметику без словаря значит воспроизвести число, но не основание выбора.
У самого вычислителя есть версия
Flexible Algorithm не только ранжирует каналы, но и исключает несовместимые. RFC 9917 создал в IANA упорядоченный реестр «IGP Flex-Algorithm Path Computation Rules».
В реестре параметров IGP сейчас десять проверок: исключаемые административные группы, SRLG, include-any и include-all, отсутствие метрики, пределы полосы и задержки, а также группы обратного направления. Новые правила могут добавляться через Expert Review; верхней границы числа правил нет.
Следовательно, интерпретатор политики тоже меняется. Старая и новая версии PCE могут иметь разные наборы поддерживаемых ограничений. RFC 9933 требует завершать вычисление неудачей при неподдерживаемом сочетании, что предотвращает тихое отклонение. Однако NO-PATH без версии правил и причины отсечения последнего кандидата остаётся необъяснённым результатом.
Автоматизированные системы часто хранят вход и выход, забывая о движке. Для воспроизводимости нужны три состояния: факты, политика и интерпретатор. Одна видимая алгоритмическая метка не заменяет эту тройку.
Objective Function не совпадает с SR-Algorithm
RFC 5541 определяет целевые функции PCEP. PCC может потребовать функцию обязательно либо выразить предпочтение. Во втором случае PCE вправе выбрать другую по локальным возможностям и политике.
RFC 9933 отдельно подчёркивает, что SR-Algorithm не заменяет Objective Function. Тип метрики также является иной сущностью. FAD определяет допустимое пространство и ограничения; метрика оценивает каналы; целевая функция выбирает лучший допустимый вариант; TED поставляет текущие факты.
RFC 9753 регулирует необязательную обработку некоторых объектов в stateful PCEP. Если механизм поддержан обеими сторонами, объект можно проигнорировать, сообщив об этом. Путь, выполнивший все условия, и путь после ослабления необязательного условия имеют разный статус обоснования. Это различие следует хранить.
Модель YANG из RFC 9826 открывает для управления сущности, соседей, сеансы, уведомления и статистику PCEP. RFC 9933 рекомендует также показывать возможности, FAD и участвующие узлы. Текущая наблюдаемость позволяет собрать доказательства, но сама по себе не создаёт историю.
TLS не замораживает смысл политики
RFC 9933 рекомендует защищать PCEP с помощью TLS, а RFC 9916 обновляет профиль PCEPS для современных версий TLS. Это необходимо, чтобы злоумышленник не менял ограничения и не выдавал себя за контроллер.
Но аутентичный запрос от законного узла может разрешиться через только что изменённое законное FAD. TLS подтверждает отправителя и целостность передачи. Он не сообщает, кто одобрил приоритет 200, когда должна закончиться аварийная политика и что означала локальная метрика.
Криптографическая целостность защищает имеющуюся запись. Происхождение политики определяет, содержит ли запись нужную цепочку решения. Защищённый конверт не объясняет правила, применённые адресатом.
Квитанция разрешения политики
Не следует встраивать полную топологию и протокол изменения в каждое PCEP-сообщение. Карта сети, стоимость и группы риска могут быть секретны, а протокол должен оставаться эффективным. Доказательство можно вести параллельно, связывая открытые хеши с защищёнными материалами.
Квитанция должна включать ID запроса, PCE и PCC, время и область; SR-Algorithm и место его появления; нормализованное победившее FAD и хеш; источник, приоритет, тай-брейк и область объявления; словарь метрики или параметры вывода; целевую функцию и её обязательность; прямые ограничения и судьбу необязательных объектов; версию упорядоченных правил и реализации; хеш TED, набора участников и исключений по возможностям; ERO, пустой ERO или NO-PATH с причиной; заявку на изменение, одобрившую роль, окно действия, условие отката и дату пересмотра.
Общая панель может показывать только хеши, версии, классы причин и хранителей. Уполномоченный аудитор сопоставит их с закрытым архивом. Проверяемость не требует публичного раскрытия всей инфраструктуры.
Такой документ отделит изменение фактов от изменения правил. Отказ канала меняет путь при стабильной политике. Новое FAD меняет путь при похожей топологии. Без двух независимых версий человеческое решение легко принять за естественную реакцию сети.
Sources
- Heng Lu, «The Policy Mirror»
- Heng Lu, «Minimum Initial Specification…»
- Heng Lu, «On Why BTW Media Exists…»
- RFC 9933: SR-Algorithm в PCEP
- Официальная запись RFC 9933
- RFC 9350: IGP Flexible Algorithm
- RFC 9843: полоса, задержка, метрики и ограничения
- RFC 9917: обратная аффинность
- RFC 9753: необязательная обработка объектов PCEP
- RFC 5541: целевые функции PCEP
- RFC 9826: модель YANG для PCEP
- RFC 9916: обновление PCEP over TLS
- RFC 9552: распространение BGP-LS
- Параметры IGP в IANA
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
