ietf-corpus from Lantern
rfc-9756

Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes

D. Dhody, A. Farrel
date2025-03 streamIETF areartg wgpce statusPROPOSED STANDARD pages11 canonicalhttps://www.rfc-editor.org/rfc/rfc9756 doi10.17487/RFC9756
This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC 8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604. Designating "experimental use" sub-ranges within codepoint registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not. This document updates RFC 5440 by designating a specific range of PCEP Error-Types for Experimental Use.

updates

Extracted elements (14)

design-rationale §2

Future registries in the 'Path Computation Element Protocol (PCEP) Numbers' registry group should prefer IETF Review over Standards Action, establishing this as the default posture for PCEP registry policy going forward.

registry, routing, mpls

design-rationale §B

RFC 8356 deliberately omitted experimental Error-Type codepoints because an experiment could instead implement an experimental PCEP object to carry arbitrary error codes. RFC 9756 rejects that approach as it would cause unnecessary code divergence; allowing experimental Error-Types more easily enables migration of successful experiments onto the Standards Track.

routing, mpls

design-rationale §A

The PCE WG considered retaining Standards Action for some registries such as flag fields with limited bit space, but decided against it. The Working Group Last Call and IETF Last Call processes are deemed sufficient to prevent frivolous experiments from consuming scarce codepoints, and a new registry can always be created if needed.

routing, mpls, registry

interoperability-note §3.2

A PCEP implementation that receives an experimental Error-Type (252-255) but does not recognize it will treat the error as it would treat any other unknown Error-Type. Per RFC 5440, an implementation notified of a PCEP error will normally close the PCEP session; implementations are not required to take specific action based on Error-Types but may log for diagnostics.

routing, mpls

interoperability-note §3.2

An implementation that is part of an experiment may receive an experimental Error-Type but not recognize the Error-value due to a faulty implementation, synchronization failure between implementations, or multiple experiments running simultaneously. An implementation receiving an unknown Error-value is not expected to do more than log the error and may close the PCEP session.

routing, mpls

normative-requirement §3.1 SHOULD

An experiment wishing to return experimental error codes SHOULD use one of the experimental Error-Type values (252-255). The experiment should agree among all participating parties on which Error-Type and which Error-values to use within that Error-Type.

routing, mpls

normative-requirement §3.1 SHOULD NOT

Experimental Error-Type/Error-value assignments used in an experiment should NOT be recorded in any public (especially IETF) documentation. Textual or symbolic names may be used internally to keep experiment documentation clear.

routing, mpls

normative-requirement §1 MUST

Experiments using experimental PCEP Error-Type codepoints (252-255) are not intended to be used in general deployments. Due care MUST be taken to ensure that two experiments using the same codepoints are not run in the same environment.

routing, mpls

normative-requirement §3.1 REQUIRED

If a PCEP experiment is declared successful and moved to Standards Track work, each experimental Error-Type/Error-value pair will need to be assigned by IANA from the standard registry range. Code changes required are as simple as updating the numeric values of Error-Types and Error-values.

routing, mpls, registry

normative-requirement §3.1 MUST

There is no scope for experimental Error-values within existing non-experimental Error-Types (0-251). All experimental Error-values must be placed under the chosen experimental Error-Types (252-255).

routing, mpls

protocol-element §3

PCEP Error-Type codepoints 252-255 are reserved for Experimental Use. All Error-values (0-255) within these Error-Types are also reserved for Experimental Use. This enables protocol experiments to return experiment-specific error messages without colliding with existing or future allocations.

routing, mpls

registry §3

The 'PCEP-ERROR Object Error Types and Values' registry is updated with a two-range assignment policy: Error-Types 0-251 use IETF Review (covering all Error-values 0-255 within each type), and Error-Types 252-255 are designated for Experimental Use (all Error-values 0-255 within those types are also reserved for Experimental Use).

registry, routing, mpls

registry §2

This document changes the registration procedure for approximately 37 PCEP registries under the 'Path Computation Element Protocol (PCEP) Numbers' registry group from Standards Action to IETF Review, allowing any IETF Stream RFC (not only Standards Track or BCP) to request allocations.

registry, routing, mpls

security-consideration §5

This document does not change the security considerations for any of the updated RFCs. Per RFC 3692, experimental codepoints introduce no new security considerations; however, implementations accepting experimental error codepoints must consider how they parse and process them in case they come accidentally from another experiment, and must consider security aspects of the experimental extensions per RFC 6709.

security, routing, mpls