Кратко

  • RFC 9753 согласует применение существующих битов P и I в заголовке объекта для PCEP с состоянием: неизвестный объект с P=0 можно пропустить и продолжить обработку сообщения.
  • Продолжение, бит I и успешный PCRpt — ограниченные протокольные квитанции. Они не доказывают сохранность смысла, эквивалентность пути, программирование пересылки или безопасное прохождение пакетов.

Самое важное изменение может не вызвать ошибки. PCC сообщает о LSP с несколькими предполагаемыми атрибутами. Один объект несёт ограничение, которое понимает новая версия, но не знает старый сосед. Локальная политика отправителя очистила P. Получатель пропускает объект, обрабатывает остальное и сохраняет сессию. Обязательные объекты на месте, формат верен, и протокол выполнил разрешённую процедуру.

Исчезло не сообщение, а часть его смысла.

RFC 9753 опубликован в апреле 2025 года на Standards Track IETF и обновляет RFC 8231. Запись RFC Editor и Datatracker фиксируют документ и статус. Механизм делает часть объектов PCRpt, PCUpd и PCInitiate необязательными для обработки, чтобы различие возможностей не всегда уничтожало всю операцию.

RELAX согласует грамматику, а не политику

В базовом PCEP из RFC 5440 P означает правило обработки, а I указывает, что необязательный объект был проигнорирован. RFC 8231 предписывал нулевые P/I для объектов с состоянием. RFC 9753 добавляет R — RELAX — в STATEFUL-PCE-CAPABILITY TLV. Реестр PCEP IANA отводит RELAX бит 17.

R должны установить и PCE, и PCC. Участник, не объявивший R, игнорирует полученные P/I по старому правилу. Взаимный R подтверждает готовность использовать эту грамматику в конкретной сессии. Он не подтверждает общий перечень ослабляемых объектов, одинаковую редакцию политики или одинаковое значение задержки, полосы, аффинности и защиты.

RFC рекомендует P=1 по умолчанию. Очистка P допустима на основании локальной конфигурации или политики, считающей ограничение необязательным, либо объект — безопасно игнорируемой информацией. Протокол не обнаруживает безвредность автоматически. Решение принимает локальная сторона.

Единица решения — весь объект

P и I нельзя применить лишь к неизвестному необязательному TLV внутри объекта; они охватывают объект PCEP целиком. Для аудита нужны класс, тип, сообщение, направление, SRP или запрос, LSP, версия политики и хеш байтов. Иначе оператор может решить, что потеряна второстепенная деталь, хотя из расчёта исключён весь носитель требования.

Обязательные объекты остаются обязательными. В PCRpt RFC 9753 называет LSP и предполагаемый ERO; в PCUpd и PCInitiate из RFC 8281 — SRP, LSP и ERO. Ошибочный P=0 требует PCErr Error-Type 10, Error-value 1.

Для остальных объектов есть развилка. Если P=1, а получатель не понимает или не поддерживает объект, всё сообщение с состоянием отклоняется с Unknown Object или Not supported object. При P=0 объект можно игнорировать и продолжить. Поэтому «без ошибок» означает либо полное понимание, либо разрешённую потерю. Общий счётчик успеха не различает эти случаи.

Делегирование меняет полномочия над P

В PCRpt P сообщает PCE, что обязательно учитывать при поддержании состояния, расчёте или повторной оптимизации. В PCUpd и PCInitiate P сообщает PCC, что обязательно при установке пути. RFC 8051 описывает применимость; RFC 8231 оставляет собственность состояния LSP у PCC и подчиняет атрибуты PCE локальной политике PCC.

Однако во время делегирования RFC 9753 позволяет PCE изменить режим объекта: пометить игнорируемым то, для чего PCC установил P, либо потребовать то, что PCC сделал необязательным. PCC должен подтвердить ожидание в PCRpt или применить процедуру неприемлемого обновления.

Последний P не раскрывает историю. Нужны владелец делегирования, поколение сессии, SRP/запрос, объект, значение до и после, разрешившая политика и ответ PCC.

I сообщает обработку, но не выполнение условия

PCE может включить проигнорированный необязательный объект в PCUpd и установить I. PCC может сделать то же в PCRpt, отвечающем на PCUpd или PCInitiate. I=0 означает заявление об обработке. Но I бессмыслен в PCRpt без связывающего ответ SRP и должен быть нулевым в PCInitiate.

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

Пример RFC 9753 показывает цену. PCRpt может нести списки предполагаемых и фактических атрибутов. Объект METRIC способен ограничивать Path Delay Variation по RFC 8233. Сделать его необязательным разумно, если подходящего пути нет. Но последующий успех не сохраняет исходную границу. Следует хранить значение и единицу, решение игнорировать, новый расчёт, фактический путь и измерение трафика.

Реплика состояния заканчивается до пакета

RFC 8231 называет начальную синхронизацию снимком состояния LSP PCC в PCE на определённый момент. PCRpt может сообщать путь, полосу, операционный и административный статус. Между отчётом и пакетом остаются локальная политика, сигнализация, допуск ресурсов, выбор RIB или таблицы меток, разрешение следующего перехода и программирование оборудования.

Эта граница отделяет тему от RFC 9757 с центральными инструкциями Native IP и от RFC 9826 с моделью YANG для PCEP. Полная контрольная или управляющая проекция всё равно не становится независимым свидетелем пересылки.

RFC 9753 рекомендует включать расширение лишь на аутентифицированных и зашифрованных сессиях между PCE/PCC одной административной власти, используя PCEPS из RFC 8253 и практику TLS из RFC 9325. Защищённый канал подтверждает участника и связь, но не правильность решения очистить P.

Реализация также должна давать настраивать RELAX и необязательные ограничения и показывать возможность оператору. Новых требований проверки операций документ не вводит. Это граница стандарта, а не отмена внешних подтверждений.

Reality Layers Хэна Лу используется как раскрытая редакционная линза: согласованный символ, принятая операция, представленное состояние, применённая конфигурация и наблюдаемый результат — разные факты. Надёжный журнал связывает участника и сессию, взаимный R, сообщение и объект, политику отправителя, парсер, решение, утраченный смысл, перерасчёт, сверку PCE/PCC, устройство, трафик и откат.

Источники

Технический набор включает RFC 9753, запись RFC Editor, Datatracker, IANA PCEP, RFC 5440, RFC 8231, RFC 8281, RFC 8051, RFC 8233, RFC 8253, RFC 9325, соседний RFC 9757 и соседний RFC 9826. Статья не заявляет конкретных реализаций, поставщиков, развёртываний, аварий, тестов совместимости или уровня принятия.