Summary

  • RFC 9756 reserves experimental PCEP error types and requires fresh IANA assignments when successful work advances towards the Standards Track. A trial's locally agreed numbers do not become permanent by familiarity.
  • The overlooked migration work sits around the protocol: versioned error dictionaries, mixed endpoint populations, historical diagnostics and a rollback plan that can actually retire the experiment.

The cheapest line in a migration estimate can be the one that changes a number. The expensive work begins when that number has acquired a life outside the software that emits it.

Imagine a controlled network trial whose participants agree how to report a new failure. Developers implement the pair of numeric fields, test it between participating systems and demonstrate useful behavior. Months later, a formally assigned pair is available. The new build uses it correctly. Yet an operations dashboard still reads the old dictionary, a support team still searches by the former number and the emergency rollback image still emits it. This is a hypothetical acceptance problem, not an incident reported by an operator. It illustrates why changing constants and completing a migration are different jobs.

RFC 9756, published in March 2025, addresses the protocol side of this transition. PCEP carries requests and information between path-computation clients and elements. Errors need a shared vocabulary too. Under RFC 5440, a PCEP error object has an Error-Type for the class of problem and an Error-value for additional detail. The pair, rather than either integer alone, carries the intended meaning.

A trial needs a boundary, not a brand

The IANA PCEP registry now reserves Error-Types 252–255, including their values 0–255, for experimentation. Types 0–251 and their values use IETF Review. This creates room to test without occupying an ordinary allocation. It does not promise that two unrelated experiments will choose different meanings.

RFC 9756 asks participating parties to agree their type, values and meanings. If several experiments use the same implementations concurrently, their pairs must be kept distinct. There is no experimental-value refuge inside an ordinary Error-Type: experimental values belong under experimental types. An apparently convenient unused value under a familiar ordinary type is therefore not a shortcut around the experimental arrangement.

The agreement is local to the participants. RFC 3692 explains the wider principle: experimental numbers are shared testing space, unsuitable for general deployment or default-enabled product behavior. Users need an explicit way to enable the experiment and configure its numbers, with explicit reprogramming serving that purpose in appropriate products. A group of vendors agreeing a favorite number does not acquire a globally unique namespace.

For an operator, that means the experiment's boundary is an asset worth recording. Which systems are participants? Which versions share the dictionary? Who can introduce a second trial into the same environment? A laboratory diagram with no owner for those changes will age badly even if its first demonstration was flawless.

Why the error belongs in the ordinary machinery

PCEP already had experimental ranges for messages, objects and TLVs under RFC 8356. Its earlier reasoning was that an experiment needing another field could carry the function in a new experimental object or TLV. RFC 9756 revisits the error case. Wrapping arbitrary experimental errors in a separate experimental object would cause unnecessary implementation divergence; using the established error machinery makes eventual migration easier.

This is a useful economy. It reduces the amount of special-purpose protocol structure that a successful experiment must later abandon. It does not abolish the need to abandon its provisional numeric meanings. When work moves towards Standards Track publication, each error pair needs an IANA assignment, potentially as new values under an existing type or beneath a newly assigned type.

The RFC describes the implementation change as a simple numeric substitution. Read that at its proper scale. It says nothing about the completeness of a particular operator's tools, historical records or rollback packages. Nor does it define a universal negotiation mechanism allowing old and new meanings to coexist automatically. Treating that silence as a promised compatibility feature would manufacture a requirement the document never supplied.

Keep names stable without freezing temporary numbers

One unusually practical piece of advice in RFC 9756 is to avoid putting experimental numeric pairs in public documentation. Textual or symbolic names can explain the errors instead. The purpose is not to conceal protocol behavior. It helps prevent an incidental trial choice from hardening into a public expectation.

There are two different records to maintain. A public explanation can describe a failure by its stable meaning. A controlled diagnostic record needs the actual pair and the context in which it was observed. Conflating them either advertises temporary numbers as lasting identifiers or strips an incident archive of the evidence needed to understand it.

Consider the hypothetical dashboard again. Updating its current dictionary may correctly label tomorrow's events while wrongly relabeling yesterday's. Retaining the raw pair, observation time, peer and relevant experiment or decoder revision would let an investigator distinguish the two. This is an operating recommendation, not an RFC-defined telemetry schema. Its feasibility depends on the implementation and the records the operator can reliably capture.

A migration test should consequently include old evidence as well as new traffic. Can the team still interpret a retained trial failure after the new version is installed? Can it identify which meaning a rolled-back endpoint emits? A green steady-state screen answers neither question.

Broader review is not a private allocation lane

RFC 9756 also changes the listed PCEP registries from Standards Action to IETF Review. RFC 8126 makes the distinction precise: the latter permits different types of IETF-stream RFC, rather than only Standards Track or Best Current Practice documents, while retaining IETF consensus review. It is not first-come allocation and does not admit any document merely because it has an RFC number.

The working group considered retaining the narrower policy for scarce flag fields, but judged the review process sufficient to address frivolous uses. That is a stated institutional judgment, not evidence that the registry has suffered abuse. It also separates two routes sometimes confused in purchasing discussions: a locally coordinated experiment and an assignment obtained through the applicable review procedure.

An unfamiliar error needs careful interpretation

A nonparticipant receiving an experimental type treats it as another unknown type. RFC 9756 discusses logging and possible session closure; it does not make every PCEP error a mandatory teardown. RFC 5440 has different consequences for different conditions, including request cancellation and preservation of an existing session when another session is attempted.

An unknown value within a recognized experimental type may reflect a faulty implementation, unsynchronized dictionaries or another concurrent experiment. The symptom alone does not select a cause. Test the actual endpoint behavior, including its diagnostic record, instead of assuming that either continued operation or a closed session proves correct handling.

Lu Heng's reality-first account of BTW's role supplies the editorial discipline here: describe the mechanism and the assumptions under stress, without inventing an operator failure to dramatize them. These sources establish protocol rules and registry policy. They establish no vendor adoption rate, measured migration cost or observed outage. The unanswered commercial question is who owns the work between a successful trial and a genuinely retired temporary interface.