Summary

  • draft-ietf-pce-flexible-grid-17 became available on 13 September 2026 while the document remained in IESG Evaluation for Proposed Standard and on the agenda for the 17 September telechat.
  • Revision 16 asked for two errors under PCEP Error-Type 24 and described that type as Routing Problem; the live IANA PCEP registry assigns 24 to LSP instantiation error.
  • After an Area Director’s DISCUSS identified the RSVP-TE/PCEP vocabulary mismatch, revision 17 deleted both per-attribute response rules and their IANA allocation request. It retained a separate, new Flexi-Grid RSA error type for unsupported RSA computation.
  • The repair prevents a numeric namespace collision, but it also changes what peers can observe. Implementers need a revision-aware receipt for removed as well as added diagnostics.

The occupied drawer

Picture an equipment cabinet whose drawer 24 is labelled “LSP instantiation error.” A new manual arrives telling technicians to put two “Routing Problem” cards in that same drawer. The sentences describing the cards may be clear, but the filing system is no longer deterministic. When drawer 24 opens, two operational stories compete for one identifier.

That was the concrete problem in revision 16 of PCEP Extension for Flexible Grid Networks. The draft defines PCEP objects and TLVs that let a Path Computation Client ask a Path Computation Element to choose a route and optical frequency slot. Its Frequency Slot Selection TLV can request symmetry or a selection method such as First-Fit or Random.

Revision 16 said that an unsupported symmetry value or assignment method would generate a PathErr with Error Code 24, named Routing Problem, plus one of two new sub-codes. Section 9.9 then asked IANA to register those values under existing Error-Type 24.

The current IANA PCEP registry tells a different story. PCEP Error-Type 24 is LSP instantiation error, registered through RFC 8281. And RFC 5440, the PCEP base specification, calls its error message PCErr and its fields Error-Type and Error-value. PathErr, Error Code and routing-problem sub-codes belong to RSVP-TE vocabulary. This was not simply a capitalization defect. The draft was joining the semantics of one protocol to an occupied number in another.

On 9 September, Routing Area Director Gunter Van de Velde put that conflict in a formal DISCUSS, recorded in the Datatracker history. He also raised separate questions about the Spectrum Allocation TLV’s format, container and placement, and about reserving value zero and defining future-allocation policy for the new error type. Mohamed Boucadair entered another DISCUSS covering policy exceptions, fixed length, registry policy, parsing and discovery. These positions are part of the evaluation record; they are not a verdict that the document will fail.

The repair is a deletion

The official comparison shows the most important answer. Revision 17 removes the paragraph prescribing the two PathErr responses. It also removes Section 9.9 and the table asking IANA for the two Error-Type 24 values. The values were not moved to a different number. They disappeared from this revision’s defined error surface.

Another error remains. The draft still asks IANA for a new, as-yet-unassigned Error-Type called Flexi-Grid RSA Error, with Error-value 1 meaning RSA computation not supported. Revision 17 adds Error-value 0 as Unassigned. A separate NO-PATH-VECTOR bit still means that no path met all optical spectrum constraints. Those distinctions matter: inability to perform RSA, inability to find a feasible spectrum-constrained path, and rejection of one requested attribute are not interchangeable failure states.

The revision answers several other comments. The Frequency Slot Selection TLV length is now fixed at four. The mathematical n used to select a grid frequency may be positive, negative or zero. A Label Set return is mandatory only absent a policy or validation error. An Inclusive Range now says it contains exactly two link-identifier records. One reference is corrected to the ERO Hop Attributes subobject defined by RFC 7570. The security section adds the newer PCEP-over-TLS update, RFC 9916.

None of that establishes that every ballot concern is closed. For example, the review asked for valid placement, ordering, association, modification and size rules around the ERO container. A changed container name is not itself proof that the full request has been satisfied. The reliable statement at the reporting cutoff is narrower: a revision was posted, the conflicting Error-Type 24 requests were removed, and the IANA review state changed from IANA OK - Actions Needed to Version Changed - Review Needed.

Review is not approval

The Datatracker record identifies revision 17 as a PCE Working Group document submitted to the IESG for Proposed Standard. The document API timestamps it at 09:57:08 UTC on 13 September. The document remained in IESG Evaluation, with the telechat scheduled for 17 September. A new revision does not clear a DISCUSS automatically, complete IANA review, approve the draft or allocate a code point.

IANA’s role is similarly bounded. It checks whether requested actions fit the live registry and prepares allocations that are performed after approval. The transition back to review means the request changed and needs another look; it does not mean rejection. RFC 8126 supplies the vocabulary for registration policies, but the standards process still has to decide which policy and initial values belong in each new registry.

The discovery question shows why words and behaviour cannot be separated. Revision 16 said the design avoided a new PCEP OPEN capability and used an error-based approach, while also pointing to the OSPF and IS-IS discovery mechanisms in RFC 5088 and RFC 5089. Revision 17 deletes the paragraph defending the error-based choice but retains the statement that discovery can advertise Flexible-Grid RSA capability. That is a visible editorial repair, not evidence of how any deployed PCC selects a PCE.

The IETF Last Call also linked IPR disclosure 3053. Its presence is a notice in the standards record, not a finding here about validity, essentiality, infringement, licence need, price or freedom to operate.

Keep a registry-and-wire receipt

The minimum useful change record should bind the text revision to the executable namespace. For every diagnostic that is added, moved or removed, keep the old tuple—protocol, message, Error-Type, Error-value and condition—the conflicting or prior live registry row, the review issue, and the new tuple or explicit deletion. Add the draft hashes, implementation version, packet-level test result, IANA review state, ballot state and the date at which an operator enabled the behaviour.

This is my proposal, not an IETF or IANA requirement. It follows the control discipline in Heng Lu’s Policy Mirror: the authoritative surface is the combination of current rule, deployed copy and enforcement path, not a familiar label detached from its owner. A minimum initial specification can make the receipt small enough to use without pretending that review has centralized implementation authority. BTW Media’s evidence standard requires the text change to remain separate from any claim of deployment or harm.

No interoperability failure is established here. No packet capture shows that an implementation emitted the deleted errors. The news is that the governance machinery found a collision before publication and changed the proposed contract. The operational lesson is to record the deletion with the same care normally reserved for a new allocation.

Sources