Кратко

  • RFC 9752 разрешает Vendor Information Object в PCRpt, PCUpd и PCInitiate и уточняет связь Enterprise Number с реестром IANA Private Enterprise Numbers.
  • Правильный PEN обозначает частное пространство имён, но не удостоверяет издателя, версию, поддержку, полномочие менять LSP, состояние устройства или итог услуги.
  • Надёжная цепочка связывает исходные байты и decoder с capability, локальной политикой, SRP/PLSP, сверкой PCE/PCC, применением, forwarding, трафиком, rollback и межвендорным fallback.

Представим не аварию, а обычную миграцию контроллера. Новый PCE отправляет PCUpd; PCC узнаёт объект, видит привычный PEN и отвечает PCRpt. Формат совпал, но старый и новый decoder могли понимать одно поле по-разному. Без версии и hash обе стороны способны честно записать «успех» и при этом говорить о разных действиях.

RFC 9752 опубликован в апреле 2025 года как IETF Proposed Standard. Карточка RFC Editor и Datatracker фиксируют обновление RFC 7470. Стандарт расширяет перенос vendor information на stateful-операции, а не стандартизует частную семантику.

Объект получил новые места, не новый словарь

RFC 7470 задаёт VENDOR-INFORMATION Object-Class 34, Type 1 и TLV Type 7. За 32-битным Enterprise Number следуют данные, формат и толкование которых определяет указанное предприятие. Документ может быть публичным или коммерческим, однако его идентификатор, версия и hash не являются обязательной частью объекта.

RFC 9752 допускает объект в PCRpt, где PCC сообщает состояние LSP; в PCUpd, где PCE просит изменить атрибуты; и в PCInitiate, запускающем создание или удаление, причём расширенная грамматика включает private list в instantiation. TLV и раньше мог находиться в SRP, LSP и других stateful-объектах с TLV.

Эти позиции неравнозначны. Private metric в отчёте, constraint в update и параметр создания обладают разным последствием. Один PCRpt может нести несколько объектов с разными PEN. RFC 9752 не задаёт универсальный порядок между ними и не определяет, как частное значение спорит со стандартным объектом.

Реестр подтверждает запись, а не автора payload

RFC 9752 точно указывает реестр Private Enterprise Numbers и RFC 9371. IANA выдаёт PEN по First Come First Served и проверяет полномочия при изменении записи.

Но RFC 9371 отдельно говорит: никто не может запретить третьей стороне использовать чужой PEN в своих данных. Следовательно, номер не является подписью. Зарегистрированное имя не доказывает, что пакет, спецификацию или decoder выпустила нынешняя команда владельца.

Семантическая provenance должна содержать удостоверенного издателя, точную версию, даты, hash документа и decoder, допустимые message/object positions, отзыв и срок поддержки. При поглощении, отделении продукта, fork или EOL эта связка должна проверяться независимо от старого контакта IANA.

Неизвестное можно корректно проигнорировать

Если реализация знает Vendor Information Object, но не поддерживает указанный Enterprise Number, RFC 9752 требует игнорировать объект по унаследованной процедуре. Отправителю не следует включать данные, если он считает, что получатель их не поддерживает. RFC 7470 оставляет advertisement таких возможностей за пределами документа и предупреждает: функциональная межвендорная совместимость требует соглашения.

Поэтому support означает четыре разных факта: parser знает envelope; продукт знает PEN; реализована конкретная версия; локальная policy разрешает её для peer, сообщения и LSP. Ignore сохраняет базовый протокол, но может незаметно удалить ожидаемый эффект. Decode подтверждает способность, а не право действовать.

Capability receipt называет обе стороны, версию, операции, срок, downgrade и fallback. Необходимо испытание без private data и с другим vendor. Если стандартные объекты получают иной смысл молча, переносимости нет.

Аутентифицированный peer ещё должен получить разрешение

RFC 9752 рекомендует защищённую сессию по RFC 8253. TLS удостоверяет транспортную сторону и целостность обмена, но не автора частного словаря и не полномочие на конкретный LSP.

RFC 8231 требует, чтобы PCC действовал на Update Request лишь при разрешении local policy сетевого администратора. Обработанный запрос запускает setup и приводит к state report; delegation можно отозвать. RFC 8281 требует capability с обеих сторон для PCE-initiated LSP и различает неприемлемые параметры, internal error и signaling error.

Session identity, delegation, authorization, parsing, semantic validation и PCRpt нельзя свести к одному accepted. SRP-ID и PLSP-ID обеспечивают корреляцию, однако отчёт PCC не является независимым чтением RIB, FIB, label table или packet path.

Сверка должна пережить смену эпохи

Сохраняются исходные object/TLV bytes, PEN, тип, позиция, peer и session epoch; затем publisher signature, spec/decoder hash, capability, parse result, semantic checks, соседние стандартные объекты, conflict rule и local decision. PCUpd/PCInitiate связываются с PCRpt/PCErr по SRP-ID, PLSP-ID и времени.

Далее нужны device transaction, applied configuration, programmed route/labels, traffic probe, service observation и rollback. После restart, resync и timeout смысл и состояние проверяются снова. FIB snapshot доказывает состояние в момент чтения, но не постоянную доставку; probe не равен SLA.

RFC 9752 не добавляет liveness, новую проверку operation или требования к другим протоколам. Standard YANG способен показать применение объекта и PEN, не private detail. Документ также отмечает covert channel и требует знать decoder и инспектировать содержание. Счётчик присутствия не даёт такой проверки.

IANA PCEP registry подтверждает codepoints. Источники не доказывают конкретное внедрение, инцидент, дефект, атаку или улучшение. Running-Code Primacy, Minimum Initial Specification и Reality Layers Хенга Лу используются как явно названная редакционная рамка: документ координирует форму, а реализация и наблюдение подтверждают действие. Это не требование IETF.