Summary

  • RFC 9753 negotiates permission to use existing P and I object-header flags in stateful PCEP, so an unknown object with P cleared may be ignored while message processing continues.
  • Continuation, I-flag reporting and LSP state are bounded protocol receipts. They do not prove that the omitted constraint was immaterial, the resulting path was equivalent, device state matched the controller, or packets followed a safe route.

The decisive event can be a message that does not fail. A PCC reports an LSP with several intended attributes. One object carries a constraint that a newer peer understands but an older peer does not. Local policy has cleared that object's P flag. The receiver skips it, processes the rest of the message and keeps the session alive. No malformed packet appears. No mandatory object is absent. The exchange has behaved exactly as the negotiated relaxation permits.

What disappeared was not the message. It was a piece of its meaning.

RFC 9753, published on the IETF Standards Track in April 2025, updates the stateful PCE rules in RFC 8231. The RFC Editor record and IETF Datatracker establish the document's identity and status. Its objective is precise: selected PCEP objects may be marked optional in PCRpt, PCUpd and PCInitiate exchanges, allowing peers to relax some processing constraints instead of rejecting the whole operation.

That mechanism improves controlled evolution. A mixed-version domain can introduce new objects without making every unknown, non-mandatory object fatal. But availability and equivalence are different claims. The receiver's permission to proceed says nothing by itself about the business or engineering cost of the information it did not use.

RELAX is a bilateral grammar, not a shared policy

The base PCEP specification, RFC 5440, defines P in the common object header as the processing rule and I as an indication that an optional object was ignored. RFC 8231 had required those flags to be zero and ignored for stateful objects. RFC 9753 changes that boundary by allocating R, the RELAX flag, in the STATEFUL-PCE-CAPABILITY TLV. The current IANA PCEP registry records RELAX at bit 17.

Both peers must set R for stateful P/I processing. If a speaker did not set R but receives P or I set, it ignores those flags under the earlier rule. Mutual R is therefore a session-specific capability receipt: each side declared willingness to handle the grammar. It is not a receipt for a common list of relaxable objects. It does not prove that both sides attach the same operational weight to delay, affinity, bandwidth or any future object. Those choices remain in local configuration and policy.

RFC 9753 says senders should set P by default on a mutually capable session. Clearing it needs local configuration or policy that regards a corresponding constraint as optional, or regards the object as informational and safe to ignore. That default matters. The protocol does not discover semantic harmlessness. Somebody configures it.

The flag applies to the whole object

P and I do not reach into an object and selectively relax one nested optional TLV. Their scope is the complete PCEP object. That gives an operator a concrete review unit: object class, object type, message, direction, policy version and requested LSP. It also prevents a comforting but false interpretation in which a receiver is assumed to have preserved the important part of an object while discarding only an unfamiliar detail.

Mandatory objects remain mandatory. In PCRpt, RFC 9753 names the LSP object and the intended ERO. In PCUpd and PCInitiate it names SRP, LSP and ERO. Clearing P incorrectly on such an object requires PCErr Error-Type 10, Error-value 1. For a non-mandatory object, the fork is different. If P is set and the receiver does not understand or refuses to process it, the whole stateful message is rejected with an Unknown Object or Not supported object error. If P is clear, the receiver can ignore the object and continue.

The absence of an error is therefore ambiguous by design. It can mean every object was understood. It can also mean an object was unknown, correctly marked optional and discarded. An acceptance counter that does not retain object-level decisions cannot distinguish the two.

P moves through three messages and two authorities

In PCRpt, P tells the PCE whether an object must be considered during state maintenance, path computation or re-optimization. In PCUpd and RFC 8281 PCInitiate, it tells the PCC whether an object must be considered during path setup. The same bit therefore travels in opposite operational directions: reported intent toward the controller, then requested treatment toward the device.

Delegation complicates the record. RFC 8051 supplies the applicability context, while RFC 8231 retains LSP state ownership at the PCC and subjects PCE attributes to PCC local policy. During delegation, RFC 9753 lets the PCE change an object's treatment—marking it ignored even if the PCC had set P, or required even if the PCC had cleared it. The PCC must acknowledge the PCE's expectation in a PCRpt or follow the unacceptable-update procedure.

That sequence cannot be reconstructed from a final P bit alone. Evidence needs the delegation owner, PCEP session generation, SRP/request identifier, protocol-element identity, the before-and-after P value, the policy revision that authorized the change, and the PCC's response. Otherwise an auditor sees the last agreement but not who changed the constraint, under which authority, or for how long.

I reports processing, not satisfaction

I provides valuable negative evidence. A PCE may include an ignored optional object in PCUpd and set I. A PCC may do the same in a PCRpt that responds to PCUpd or PCInitiate. I cleared indicates processing. But the signal has strict boundaries: I has no meaning in an unsolicited PCRpt without the correlating SRP object, and it must be zero and ignored in PCInitiate.

Even where I is meaningful, “processed” is not “satisfied”. A parser can recognize an object and pass it to a policy module. A policy module can accept it while another constraint wins. A path can be computed with the object considered yet realize a different actual attribute. A PCC can report state without independently observing the forwarding hardware. I closes one question—did this peer say it ignored the optional object?—and leaves the consequential questions open.

RFC 9753's own example makes the gap tangible. PCRpt may carry intended and actual attribute lists. An intended METRIC object can bound Path Delay Variation as defined in RFC 8233. Making that object optional may be reasonable when no path meets the bound. If it is ignored, the exchange can succeed by design, but the original performance limit did not thereby survive. The receipt must retain the bound and units, the ignore decision, the replacement computation and the actual path. Traffic measurement is what establishes observed delay variation; the capability bit cannot.

State reconciliation still ends before forwarding proof

RFC 8231 calls initial synchronization a checkpoint-in-time replica of PCC LSP state at the PCE. PCRpt can carry current path, bandwidth and operational or administrative status. That is useful controller evidence, not an external witness. Between the report and the packet lie local policy, signaling, resource admission, RIB or label-table selection, next-hop resolution, hardware programming and the moving network.

For an RSVP-TE LSP, one may need signaling and reservation state plus label programming. For another setup type, the relevant installation evidence differs. RFC 9753 does not define a universal forwarding test, and this article does not invent one as a protocol requirement. The operational point is narrower: claims must stop where observation stops. A report about object processing cannot certify a later layer it never measured.

The same distinction separates this work from the published RFC 9757 Native-IP analysis. RFC 9757 owns BPI, EPR and PPA central instructions. RFC 9753 owns the earlier semantic fork in stateful object processing. The related RFC 9826 PCEP YANG model can expose management state, but a populated model remains a projection rather than independent forwarding evidence.

Secure transport does not authenticate meaning

RFC 9753 recommends activating the extension only on authenticated and encrypted PCEP sessions among peers under the same administrative authority, using PCEPS under RFC 8253 and the current TLS guidance in RFC 9325. That limits impersonation and exposure. It does not establish that an optionality policy is correct, current or jointly understood.

The document also says implementations should allow operators to configure RELAX and the related optional constraints, and to view the capability. It adds no new liveness or operation-verification requirements beyond the base PCEP specification. “No new requirement” is not “no verification needed”. It means the extension does not standardize additional machinery. Leadership still has to decide which evidence its service claim requires.

Heng Lu's Reality Layers is useful as a disclosed editorial lens: a symbol, an accepted operation, an implemented state and an observed result should not be collapsed into one fact. Applied here, RELAX is a negotiated symbol; P and I are object-handling instructions and reports; PCRpt is bounded state testimony; hardware and traffic require their own witnesses.

The reliable ledger follows eleven joins: authenticated peer and session; mutual R; exact message and object; sender policy; parser result; explicit ignore/error decision; lost or retained constraint meaning; recomputation; controller/PCC reconciliation; device and forwarding state; packet outcome and rollback. RFC 9753 gives the middle of that chain better language. Its value is greatest when the organization refuses to treat that language as the end of the proof.

Source register

The technical record is completed by the RFC 9753 document, RFC Editor metadata, Datatracker record, IANA PCEP registry, RFC 5440, RFC 8231, RFC 8281, RFC 8051, RFC 8233, RFC 8253, RFC 9325, adjacent RFC 9757, and adjacent RFC 9826. No named implementation, deployment, incident, interoperability event or adoption rate is claimed.