Summary

  • RFC 9752 permits the Vendor Information object in stateful PCRpt, PCUpd and PCInitiate messages and points Enterprise Numbers to the IANA Private Enterprise Numbers registry.
  • A correct PEN is a namespace clue, not proof of the payload's publisher, version, receiver support, change authority, device application, forwarding state or service result.
  • The useful operating record joins raw bytes and decoder identity to stateful request/response correlation, PCC policy, device readback, traffic observation, rollback and a standards-based fallback.

Imagine a controller sending PCUpd with a Vendor Information object beside the standardized LSP state. The PCEP session is encrypted. The object class is recognized. Its 32-bit Enterprise Number belongs to a familiar supplier. The PCC returns a PCRpt with the same SRP identifier. A dashboard can turn that sequence green without inventing a single byte. It can still be wrong about the only thing leadership cares about: whether an authorized, understood instruction produced a safe forwarding result.

RFC 9752, published in April 2025 as an IETF Proposed Standard, solves a narrower problem. The RFC Editor record and Datatracker history establish the document's identity and its update to RFC 7470. The extension lets the Vendor Information object travel with stateful PCEP operations. It does not turn opaque enterprise data into a standardized command language.

Stateful carriage raises the consequence ceiling

The original RFC 7470 facility supplied a dedicated VENDOR-INFORMATION object and a VENDOR-INFORMATION-TLV. The object is Class 34, Type 1; the TLV is Type 7. Both contain an Enterprise Number followed by enterprise-specific information. RFC 7470 leaves the latter's format and interpretation to the identified enterprise. Publication is encouraged, but it can be an Informational RFC or commercial documentation rather than one common schema.

RFC 9752 places that carrier inside three stateful conversations. A PCC may append one or more Vendor Information objects to a PCRpt that reports LSP state. A PCE may include them in PCUpd when requesting an LSP attribute change. PCInitiate can carry them when asking a PCC to instantiate an LSP; the base operation also covers deletion. The TLV, meanwhile, was already eligible for stateful objects such as SRP and LSP objects whenever those objects support TLVs.

This matters because the same bytes can now accompany reports, proposed changes and initiated state. Message position supplies context, not verdict. A payload beside an LSP object could qualify a metric, select proprietary behavior, or be safely irrelevant. The standard does not define the private grammar, its version, its relationship to every standardized object, or the precedence between multiple vendor objects. Two objects with different PENs may legally be present in one report. The carrier does not say which private rule wins.

A PEN names territory; it does not sign the parcel

RFC 9752 corrects RFC 7470 by naming the precise registry: Enterprise Numbers are managed through the IANA Private Enterprise Numbers registry under RFC 9371. That improves reference accuracy. It does not create packet provenance.

RFC 9371 is unusually clear about the limit. IANA assigns PENs under First Come First Served, records an assignee and validates requests to change the registry entry. Yet nobody can prevent another party from using any PEN in its own data. The integer is not a signature, certificate chain, trademark entitlement or proof that the current product team approved a document. Acquisitions, divestitures, repositories and support branches can also move on different clocks from the registry contact.

Operationally, the receipt must bind the PEN to an authenticated semantic artifact: publisher identity, specification version, release date, immutable hash, decoder build, supported message/object positions and withdrawal status. Without that bundle, “PEN recognized” can mean only that software found an integer in a lookup table.

Support has at least four states

RFC 9752 says a supporting implementation that receives a Vendor Information object for an unsupported Enterprise Number must ignore it according to the inherited procedure. A speaker should not send vendor information when it believes the recipient does not support it. RFC 7470 also notes that functional cross-vendor interoperability requires cooperation, and leaves advertisement of supported Enterprise Numbers or extensions outside scope.

That produces four distinct states: the parser knows the object class; the implementation recognizes the PEN; it supports a particular semantic version; and local policy enables that version for this peer, message type and LSP. Treating the first as evidence of the fourth is the classic integration error. Silent ignore may preserve baseline protocol operation while removing the proprietary effect the sender expected. Conversely, successful decoding may activate behavior the receiver was never authorized to use.

Version agreement therefore needs an explicit capability receipt outside the opaque payload: both parties, exact semantic version, supported operations, downgrade rule, expiry and fallback. Cross-vendor fallback should remove or ignore the private extension without changing the interpretation of standardized objects. If that cannot be demonstrated, the feature is lock-in, not interoperability.

Authentication is not state-change authority

RFC 9752 carries forward the existing security model and recommends authenticated, encrypted PCE/PCC sessions using PCEPS. A protected session is valuable: it binds the transport to configured credentials and protects bytes in flight. It does not prove that the semantic publisher is genuine, that the peer may alter this LSP, or that the decoded instruction is safe.

RFC 8231 supplies the missing authority boundary. A PCC acts on an LSP Update Request only if network-manager local policy permits it. An acted-on update starts an LSP setup operation, after which the PCC reports resulting state. Delegation can be revoked; stale or non-delegated updates have defined errors. RFC 8281 separately requires both parties to advertise PCE-initiated capability and defines rejection for unacceptable parameters, internal errors and signaling failures.

Those receipts must not be collapsed. Transport authentication says who held the session credential. Delegation says which PCE may modify an LSP. Local policy says whether this request may be acted on. A PCRpt says what the PCC reports as resulting LSP state. None of them directly reads a line card, RIB, FIB, label entry or packet path.

Reconciliation must survive time

A defensible trace starts with the exact raw object or TLV bytes and records message type, object position, PEN, parser disposition and semantic validation. It then joins PCUpd or PCInitiate to PCRpt or PCErr using SRP-ID, PLSP-ID, peer and session epoch. The trace retains delegation state, local authorization decision, standardized-object values, conflict rule, decoder hash and clock quality.

Next come receipts outside PCEP: device transaction result; intended-versus-applied configuration; programmed route, label or forwarding state; traffic probe; service observation; and rollback result. A later PCRpt can reconcile PCE and PCC state, but it remains a protocol report from the PCC. A route or label readback proves installed state at an observation time, not packet delivery. A packet probe proves one observed path, not a permanent SLA.

RFC 9752 itself underlines the gap. It adds no new liveness requirement, operational-verification method or requirement on other protocols. A standard YANG module may report that vendor information and a PEN were present, but not the private detail. The RFC also warns that the opaque field can become a covert channel and asks operators to know the decoder and inspect its use. Observability must preserve the private seam rather than laundering it into a generic “extension present” counter.

Sources establish a carrier, not a deployment

The current IANA PCEP registry confirms the Vendor Information code points. RFCs 9752, 7470, 8231, 8281, 9371 and 8253 establish the protocol and registry rules summarized here. They do not establish a named implementation, production adoption, vendor defect, exploit, outage, forwarding change or performance gain.

Heng Lu's Running-Code Primacy, Minimum Initial Specification and Reality Layers supply a disclosed analytical overlay. They suggest reading the shared carrier as a thin coordination layer and leaving private meaning, adoption and refusal to locally verifiable agreements. That is this author's use of the essays, not an IETF requirement. The operational conclusion is correspondingly modest: receiving a private object proves carriage. Every later claim needs its own witness.