Кратко

  • RFC 9863 задаёт объявление цветовой возможности PCEP и передачу одного 32-битного значения COLOR TLV в объекте LSP.
  • Значение может свидетельствовать об атрибуте объекта пути; оно не является свидетельством смысла политики, маршрутизации сервиса, производительности или исполненного обязательства.

У цвета есть опасное преимущество: он легко превращается в понятное для руководства слово — «быстрый», «премиальный», «защищённый». В RFC низкая задержка приведена лишь как пример цели, с которой может быть связан TE-туннель. Нормативно передаётся беззнаковое целое число. Число не измеряет задержку, не резервирует ресурс и не фиксирует, что поток клиента действительно прошёл по данному пути.

Сначала RFC устанавливает узкую проверяемую границу. PCE или PCC объявляет поддержку цвета битом 20 в STATEFUL-PCE-CAPABILITY TLV. Затем COLOR TLV типа 67 и длины 4 может быть помещён в объект LSP. Его нельзя посылать соседу, который возможность не объявил; при повторе обрабатывается только первый TLV. Из этого следует проверяемый вывод о возможности и корректности сообщения. Из этого не следует, что разные операторы придают числу одинаковое сервисное значение.

Особая норма для SR Policy Association подчёркивает различие между кодированием и управлением. Для SR-пути с Association по RFC 9862 цвет уже включён в идентификатор Association. Он имеет приоритет, а COLOR TLV в объекте LSP игнорируется. Такая норма устраняет конфликт двух представлений. Она не выбирает поток, не программирует data plane и не превращает название политики в наблюдаемый эффект.

Ошибки также относятся к одному слою. Если PCC не может соблюсти полученный цвет, он обязан отвергнуть сообщение с Invalid Color. Если он видит несовместимые цвета у LSP одной группы защиты, требуется Inconsistent Color. Это сильное свидетельство о решении на входе протокола. Но успешное прохождение входа не завершает цепочку: остаются локальная конфигурация, сопоставление сервиса, установка пути, пересылка пакетов и независимое измерение результата.

RFC 9863 не обещает заполнить этот разрыв. Механизм отображения сервисов на цветной путь вынесен за её рамки; PCC может иметь собственную локальную политику использования цвета. Реализация должна позволять настраивать возможность и назначение цвета, а оператор может получить operational state, чтобы проверить ожидаемую метку. Нового liveness-мониторинга RFC не требует, а влияние на сеть зависит от развёртывания. Считывание корректного цвета — это не отчёт о качестве сервиса.

Не следует превращать метку и в доказательство доверия. RFC предупреждает, что неавторизованный PCE может приписать LSP неверный цвет, и отсылает к защищённому транспорту PCEP. Цвет не устанавливает личность PCE и не предоставляет ему право определять локальную политику. Надёжная запись должна отдельно хранить защиту канала и идентичность контроллера.

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

Источники