Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes
RFC 9756
Dhruv Dhody
Huawei
Adrian Farrel
Old Dog Consulting
2025-03
RTG
pce
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9756.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
- 1. Introduction
- 2. Standards Action PCEP Registries Affected
- 3. Experimental Error-Types
  - 3.1. Advice on Experimentation
  - 3.2. Handling of Unknown Experimentation
- 4. IANA Considerations
- 5. Security Considerations
- 6. References
  - 6.1. Normative References
  - 6.2. Informative References
- Appendix A. Rationale for Updating All Registries with Standards Action
- Appendix B. Consideration of RFC 8356
- Acknowledgements
- Contributors
- Authors' Addresses
Introduction
The IANA "Path Computation Element Protocol (PCEP) Numbers" registry group was populated by several RFCs produced by the Path Computation Element (PCE) Working Group. Most of the registries include IETF Review [RFC8126] as the registration procedure. There are a few registries that use Standards Action. Thus, the values in those registries can be assigned only through the Standards Track or Best Current Practice RFCs in the IETF Stream. This memo changes the policy from Standards Action to IETF Review to allow any type of RFC under the IETF Stream to make the allocation request.
Further, in Section 9 of [RFC5440], IANA assigns values to the PCEP parameters. The allocation policy for each of these parameters specified in [RFC5440] is IETF Review [RFC8126]. In consideration of the benefits of conducting experiments with PCEP and the utility of experimental codepoints [RFC3692], codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use [RFC8126] are designated in [RFC8356]. However, protocol experiments may also need to return protocol error messages indicating experiment-specific error cases. It will often be that previously assigned error codes (in the "PCEP-ERROR Object Error Types and Values" registry) can be used to indicate the error cases within an experiment, but there may also be instances where new, experimental error codes are needed. In order to run experiments, it is important that the codepoint values used in the experiments do not collide with existing codepoints or any future allocations. This document updates [RFC5440] by changing the allocation policy for the registry of PCEP Error-Types to mark some of the codepoints as assigned for Experimental Use. As stated in [RFC3692], experiments using these codepoints are not intended to be used in general deployments, and due care must be taken to ensure that two experiments using the same codepoints are not run in the same environment.
Standards Action PCEP Registries Affected
The following table lists the registries under the "Path Computation Element Protocol (PCEP) Numbers" registry group whose registration policies have been changed from Standards Action to IETF Review. The affected registries list this document as an additional reference. Where this change has been applied to a specific range of values within the particular registry, that range is given in the Remarks column.
PCEP Registries Affected
Registry | RFC | Remarks
BU Object Type Field | [RFC8233] |
LSP Object Flag Field | [RFC8231] |
STATEFUL-PCE-CAPABILITY TLV Flag Field | [RFC8231] |
LSP-ERROR-CODE TLV Error Code Field | [RFC8231] |
SRP Object Flag Field | [RFC8281] |
SR-ERO Flag Field | [RFC8664] |
PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators | [RFC8664] |
SR Capability Flag Field | [RFC8664] |
WA Object Flag Field | [RFC8780] |
Wavelength Restriction TLV Action Values | [RFC8780] |
Wavelength Allocation TLV Flag Field | [RFC8780] |
S2LS Object Flag Field | [RFC8623] |
H-PCE-CAPABILITY TLV Flag Field | [RFC8685] |
H-PCE-FLAG TLV Flag Field | [RFC8685] |
ASSOCIATION Flag Field | [RFC8697] |
ASSOCIATION Type Field | [RFC8697] |
AUTO-BANDWIDTH-CAPABILITY TLV Flag Field | [RFC8733] |
Path Protection Association Group TLV Flag Field | [RFC8745] |
Generalized Endpoint Types | [RFC8779] | 0-244
GMPLS-CAPABILITY TLV Flag Field | [RFC8779] |
DISJOINTNESS-CONFIGURATION TLV Flag Field | [RFC8800] |
SCHED-PD-LSP-ATTRIBUTE TLV Opt Field | [RFC8934] |
Schedule TLVs Flag Field | [RFC8934] |
FLOWSPEC Object Flag Field | [RFC9168] |
Bidirectional LSP Association Group TLV Flag Field | [RFC9059] |
PCECC-CAPABILITY sub-TLV | [RFC9050] |
CCI Object Flag Field for MPLS Label | [RFC9050] |
TE-PATH-BINDING TLV BT Field | [RFC9604] |
TE-PATH-BINDING TLV Flag Field | [RFC9604] |
LSP-EXTENDED-FLAG TLV Flag Field | [RFC9357] |
LSP Exclusion Subobject Flag Field | [RFC9504] |
SRv6-ERO Flag Field | [RFC9603] |
SRv6 Capability Flag Field | [RFC9603] |
Future registries in the "Path Computation Element Protocol (PCEP) Numbers" registry group should prefer to use IETF Review over Standards Action.
Experimental Error-Types
Per this document, IANA has designated four PCEP Error-Type codepoints (252-255) for Experimental Use.
IANA maintains the "PCEP-ERROR Object Error Types and Values" registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has changed the assignment policy for the "PCEP-ERROR Object Error Types and Values" registry as follows:
PCEP-ERROR Object Error Types and Values Registry Assignment Policy
Range | Registration Procedures | Note
0-251 | IETF Review | The IETF Review procedure applies to all Error-values (0-255) for Error-Types in this range.
252-255 | Experimental Use | The Experimental Use policy applies to all Error-values (0-255) for Error-Types in this range.
Furthermore, IANA has added the following entry to the registry:
PCEP-ERROR Object Error Types and Values Registry
Error-Type | Meaning | Error-value | Reference
252-255 | Reserved for Experimental Use | 0-255: Reserved for Experimental Use | RFC 9756
Advice on Experimentation
An experiment that wishes to return experimental error codes should use one of the experimental Error-Type values as defined in this document. The experiment should agree on, between all participating parties, which Error-Type to use and which Error-values to use within that Error-Type. The experiment will describe what the meanings of those Error-Type/Error-value pairs are. Those Error-Types and Error-values should not be recorded in any public (especially any IETF) documentation. Textual or symbolic names for the Error-Types and Error-values may be used to help keep the documentation clear.
If multiple experiments are taking place at the same time using the same implementations, care must be taken to keep the sets of Error-Types/Error-values distinct.
Note that there is no scope for experimental Error-values within existing non-experimental Error-Types. This reduces the complexity of the registry and implementations. Experiments should place all experimental Error-values under the chosen experimental Error-Types.
If, at some future time, the experiment is declared a success and moved to IETF work targeting publication on the Standards Track, each pair of Error-Types/Error-values will need to be assigned by IANA from the registry. In some cases, this will involve assigning a new Error-Type with its subtended Error-values. In other cases, use may be made of an existing Error-Type with new subtended Error-values being assigned. The resulting change to code in an implementation is as simple as changing the numeric values of the Error-Types and Error-values.
Handling of Unknown Experimentation
A PCEP implementation that receives an experimental Error-Type in a PCEP message and does not recognize the Error-Type (i.e., is not part of the experiment) will treat the error as it would treat any other unknown Error-Type (such as from a new protocol extension). An implementation that is notified of a PCEP error will normally close the PCEP session (see [RFC5440]). In general, PCEP implementations are not required to take specific action based on Error-Types but may log the errors for diagnostic purposes.
An implementation that is part of an experiment may receive an experimental Error-Type but not recognize the Error-value. This could happen because of any of the following reasons:
- a faulty implementation
- two implementations not being synchronized with respect to which Error-values to use in the experiment
- more than one experiment being run at the same time
As with unknown Error-Types, an implementation receiving an unknown Error-value is not expected to do more than log the received error and may close the PCEP session.
IANA Considerations
This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group.
Security Considerations
This memo does not change the security considerations for any of the updated RFCs. Refer to [RFC5440] and [PCEPS-UPDATES] for further details of the specific security measures applicable to PCEP.
[RFC3692] asserts that the existence of experimental codepoints introduces no new security considerations. However, implementations accepting experimental error codepoints need to consider how they parse and process them in case they come, accidentally, from another experiment. Further, an implementation accepting experimental codepoints needs to consider the security aspects of the experimental extensions. [RFC6709] provides various design considerations for protocol extensions (including those designated as experimental).
References
Normative References
[RFC5440]

Path Computation Element (PCE) Communication Protocol (PCEP)
JP. Vasseur, Ed.
JL. Le Roux, Ed.
March 2009
RFC 5440
DOI 10.17487/RFC5440
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8231]

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
E. Crabbe
I. Minei
J. Medved
R. Varga
September 2017
RFC 8231
DOI 10.17487/RFC8231
[RFC8233]

Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
D. Dhody
Q. Wu
V. Manral
Z. Ali
K. Kumaki
September 2017
RFC 8233
DOI 10.17487/RFC8233
[RFC8281]

Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model
E. Crabbe
I. Minei
S. Sivabalan
R. Varga
December 2017
RFC 8281
DOI 10.17487/RFC8281
[RFC8356]

Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)
D. Dhody
D. King
A. Farrel
March 2018
RFC 8356
DOI 10.17487/RFC8356
[RFC8623]

Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
U. Palle
D. Dhody
Y. Tanaka
V. Beeram
June 2019
RFC 8623
DOI 10.17487/RFC8623
[RFC8664]

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing
S. Sivabalan
C. Filsfils
J. Tantsura
W. Henderickx
J. Hardwick
December 2019
RFC 8664
DOI 10.17487/RFC8664
[RFC8685]

Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture
F. Zhang
Q. Zhao
O. Gonzalez de Dios
R. Casellas
D. King
December 2019
RFC 8685
DOI 10.17487/RFC8685
[RFC8697]

Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)
I. Minei
E. Crabbe
S. Sivabalan
H. Ananthakrishnan
D. Dhody
Y. Tanaka
January 2020
RFC 8697
DOI 10.17487/RFC8697
[RFC8733]

Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
D. Dhody, Ed.
R. Gandhi, Ed.
U. Palle
R. Singh
L. Fang
February 2020
RFC 8733
DOI 10.17487/RFC8733
[RFC8745]

Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
H. Ananthakrishnan
S. Sivabalan
C. Barth
I. Minei
M. Negi
March 2020
RFC 8745
DOI 10.17487/RFC8745
[RFC8779]

Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS
C. Margaria, Ed.
O. Gonzalez de Dios, Ed.
F. Zhang, Ed.
July 2020
RFC 8779
DOI 10.17487/RFC8779
[RFC8780]

The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)
Y. Lee, Ed.
R. Casellas, Ed.
July 2020
RFC 8780
DOI 10.17487/RFC8780
[RFC8800]

Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling
S. Litkowski
S. Sivabalan
C. Barth
M. Negi
July 2020
RFC 8800
DOI 10.17487/RFC8800
[RFC8934]

PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE
H. Chen, Ed.
Y. Zhuang, Ed.
Q. Wu
D. Ceccarelli
October 2020
RFC 8934
DOI 10.17487/RFC8934
[RFC9050]

Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs
Z. Li
S. Peng
M. Negi
Q. Zhao
C. Zhou
July 2021
RFC 9050
DOI 10.17487/RFC9050
[RFC9059]

Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)
R. Gandhi, Ed.
C. Barth
B. Wen
June 2021
RFC 9059
DOI 10.17487/RFC9059
[RFC9168]

Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification
D. Dhody
A. Farrel
Z. Li
January 2022
RFC 9168
DOI 10.17487/RFC9168
[RFC9357]

Label Switched Path (LSP) Object Flag Extension for Stateful PCE
Q. Xiong
February 2023
RFC 9357
DOI 10.17487/RFC9357
[RFC9504]

Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks
Y. Lee
H. Zheng
O. Gonzalez de Dios
V. Lopez
Z. Ali
December 2023
RFC 9504
DOI 10.17487/RFC9504
[RFC9603]

Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing
C. Li, Ed.
P. Kaladharan
S. Sivabalan
M. Koldychev
Y. Zhu
July 2024
RFC 9603
DOI 10.17487/RFC9603
[RFC9604]

Carrying Binding Label/SID in PCE-Based Networks
S. Sivabalan
C. Filsfils
J. Tantsura
S. Previdi
C. Li, Ed.
August 2024
RFC 9604
DOI 10.17487/RFC9604
Informative References
[I-D.ietf-pce-pceps-tls13]

Updates for PCEPS: TLS Connection Establishment Restrictions
Dhruv Dhody
Huawei
Sean Turner
sn3rd
Russ Housley
Vigil Security, LLC
9 January 2024
Internet-Draft draft-ietf-pce-pceps-tls13-04
Work in Progress
[RFC3692]

Assigning Experimental and Testing Numbers Considered Useful
T. Narten
January 2004
BCP 82
RFC 3692
DOI 10.17487/RFC3692
[RFC6709]

Design Considerations for Protocol Extensions
B. Carpenter
B. Aboba, Ed.
S. Cheshire
September 2012
RFC 6709
DOI 10.17487/RFC6709
Rationale for Updating All Registries with Standards Action
This specification updates all the mentioned registries with the Standards Action policy. The PCE WG considered keeping Standards Action for some registries, such as flag fields with limited bits where the space is tight, but decided against it. The Working Group Last Call and IETF Last Call processes should be enough to handle the case of frivolous experiments taking over the few codepoints. The working group could also create a new protocol field and registry for future use as done in the past (see [RFC9357]).
Consideration of RFC 8356
It is worth noting that [RFC8356] deliberately chose to make experimental codepoints available only in the PCEP messages, objects, and TLV type registries. Appendix A of [RFC8356] gives a brief explanation of why that decision was taken, stating that:
The justification for this decision is that, if an experiment finds that it wants to use a new codepoint in another PCEP sub-registry, it can implement the same function using a new experimental object or TLV instead.
While it is true that an experimental implementation could assign an experimental PCEP object and designate it the "experimental errors object", using it to carry arbitrary contents including experimental error codes, such an approach would cause unnecessary divergence in the code. The allowance of experimental Error-Types is a better approach that will more easily enable the migration of successful experiments onto the Standards Track.
Acknowledgements
Thanks to John Scudder for the initial discussion behind this document. Thanks to Ketan Talaulikar, Andrew Stone, Samuel Sidor, Quan Xiong, Cheng Li, and Aijun Wang for the review comments. Thanks to Carlos Pignataro for the OPSDIR review. Thanks to Meral Shirazipour for the GENART review. Thanks to Paul Kyzivat for the ArtArt review. Thanks to Alexey Melnikov for the SECDIR review.
Contributors
Haomian Zheng
Huawei Technologies
zhenghaomian@huawei.com
Authors' Addresses
Dhruv Dhody
Huawei
India
dhruv.ietf@gmail.com
Adrian Farrel
Old Dog Consulting
adrian@olddog.co.uk