Кратко

  • RFC 9756 выделяет экспериментальные типы ошибок PCEP, смысл которых согласуют участники опыта. Такая договорённость не становится постоянным назначением автоматически.
  • При движении к публикации на Standards Track каждой паре типа и значения нужно назначение IANA.
  • Обновить числовые константы недостаточно для завершения перехода: старый смысл может сохраняться в инструментах наблюдения, архиве и плане отката.

У программного отката обычно есть понятный предмет: вернуть прежнюю сборку. У отката смысла предмет сложнее. Нужно вернуть или сохранить согласованное понимание того, что эта сборка сообщает остальным участникам.

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

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

Опубликованный в марте 2025 года RFC 9756 позволяет точнее очертить эту задачу. Документ создаёт экспериментальное пространство для ошибок PCEP и сокращает ненужные расхождения между экспериментом и будущей стандартной реализацией. Он не обещает автоматически согласовать весь парк оператора.

Значение принадлежит паре и контексту

PCEP используется для обмена, связанного с вычислением путей. В базовом RFC 5440 объект ошибки содержит Error-Type и Error-value. Первый задаёт класс ошибки, второй уточняет его. Диагностический смысл несёт пара полей, а не отдельно взятое число.

В реестре PCEP IANA типы 252–255 вместе со значениями 0–255 отведены под эксперименты. Для типов 0–251 и их значений действует IETF Review. Участникам эксперимента следует согласовать используемые пары и их значения; параллельные опыты на тех же реализациях должны использовать различающиеся наборы пар.

Резервирование не даёт поставщику исключительного пространства. Другой эксперимент может выбрать те же числа для другой цели. Нельзя и поместить экспериментальное значение под обычным, неэкспериментальным типом ошибки: RFC 9756 прямо исключает такой вариант. Незанятая позиция в обычном типе не становится от этого частной испытательной площадкой.

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

Почему временное трудно забрать обратно

RFC 3692 объясняет слабость временных назначений с последующим возвратом номера. Контакты устаревают, окончание опыта трудно установить, а продукты продолжают использовать выбранное значение. Тогда повторное назначение может затронуть устройства, о существовании которых уже нет полной информации.

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

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

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

Зачем оставлять ошибку в привычном механизме

Экспериментальные области для сообщений, объектов и TLV PCEP существовали по RFC 8356. Для функции в другой части протокола можно было использовать новый экспериментальный объект или TLV.

RFC 9756 пересматривает этот обходной путь применительно к ошибкам. Отдельный объект, несущий произвольные экспериментальные ошибки, создавал бы ненужное расхождение в коде. Использование существующего механизма ошибок облегчает продвижение успешного опыта к стандартизации.

Уменьшается объём особой конструкции, которую придётся заменять. Но сами экспериментальные пары не становятся постоянными. Когда работа движется к публикации на Standards Track, для каждой пары нужны назначения IANA: новые значения под существующим типом либо новый тип с его значениями.

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

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

Не переписывать прошлое новым словарём

RFC 9756 рекомендует не фиксировать выбранные экспериментальные числовые пары в публичных документах. Для ясного описания допускаются текстовые или символические имена. Это помогает не превращать временный номер в обещание долгосрочного интерфейса.

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

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

Поэтому тест миграции должен включать повторное чтение известных записей опыта. Проверка новых сообщений и проверка старых свидетельств подтверждают разные свойства. Третья проверка касается отката: кто понимает восстановленную версию и каким словарём пользуется дежурная смена?

Хранить возможность читать разрешённый архив не означает бесконечно принимать старые экспериментальные значения в работающей сети. Эти решения можно разделить. Иначе сохранение памяти об опыте превращается в оправдание его бессрочного продолжения.

Более широкий допуск документов, прежняя необходимость проверки

Другая часть RFC 9756 меняет политику перечисленных реестров PCEP со Standards Action на IETF Review. В RFC 8126 различие сформулировано точно: IETF Review допускает разные категории RFC потока IETF, сохраняя проверку на основе консенсуса IETF, тогда как Standards Action ограничивается Standards Track и Best Current Practice.

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

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

Текст обсуждает журналирование и возможное закрытие сессии, но не вводит обязательного разрыва для каждой ошибки PCEP. RFC 5440 предусматривает разные последствия, включая отмену запроса и сохранение существующей сессии в определённом случае. Открытое соединение не доказывает правильного понимания, а закрытое не доказывает столкновения номеров.

Подход соответствует принципу Lu Heng о реальности, а не агитации как продукте BTW. Здесь источники подтверждают механизм и пределы правил. Они не дают данных о распространённости у поставщиков, измеренной стоимости или реальном сбое. Но они позволяют определить, какой участок ответственности нельзя закрыть одним заявлением о поддержке RFC.