RFC 9756 PROPOSED STANDARD PCEP · IANA · REGISTRIES
PCEP registry procedures: Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes
Makes it easier to assign new PCEP values and sets aside four error types for experiments.
RFC EDITOR
Dhody, D. and A. Farrel, "Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes", RFC 9756, DOI 10.17487/RFC9756, March 2025, <https://www.rfc-editor.org/info/rfc9756>.
BIBTEX
@misc{rfc9756,
series = {Request for Comments},
number = 9756,
howpublished = {RFC 9756},
publisher = {RFC Editor},
doi = {10.17487/RFC9756},
url = {https://www.rfc-editor.org/info/rfc9756},
author = {D. Dhody and A. Farrel},
title = {{Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes}},
pagetotal = 11,
year = 2025,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 9756 Huawei
Updates: 5440, 8231, 8233, 8281, 8623, 8664, A. Farrel
8685, 8697, 8733, 8745, 8779, 8780, Old Dog Consulting
8800, 8934, 9050, 9059, 9168, 9357, March 2025
9504, 9603, 9604
Category: Standards Track
ISSN: 2070-1721
Update to the IANA Path Communication Element Protocol (PCEP) Numbers
Registration Procedures and the Allowance of Experimental Error Codes
Abstract
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
1. 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.
2. 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.
+========================================+===========+=========+
| 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 | [RFC8664] | |
| Type Indicators | | |
+----------------------------------------+-----------+---------+
| SR Capability Flag Field | [RFC8664] | |
+----------------------------------------+-----------+---------+
| WA Object Flag Field | [RFC8780] | |
+----------------------------------------+-----------+---------+
| Wavelength Restriction TLV Action | [RFC8780] | |
| Values | | |
+----------------------------------------+-----------+---------+
| 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 | [RFC8733] | |
| Field | | |
+----------------------------------------+-----------+---------+
| Path Protection Association Group TLV | [RFC8745] | |
| Flag Field | | |
+----------------------------------------+-----------+---------+
| Generalized Endpoint Types | [RFC8779] | 0-244 |
+----------------------------------------+-----------+---------+
| GMPLS-CAPABILITY TLV Flag Field | [RFC8779] | |
+----------------------------------------+-----------+---------+
| DISJOINTNESS-CONFIGURATION TLV Flag | [RFC8800] | |
| Field | | |
+----------------------------------------+-----------+---------+
| SCHED-PD-LSP-ATTRIBUTE TLV Opt Field | [RFC8934] | |
+----------------------------------------+-----------+---------+
| Schedule TLVs Flag Field | [RFC8934] | |
+----------------------------------------+-----------+---------+
| FLOWSPEC Object Flag Field | [RFC9168] | |
+----------------------------------------+-----------+---------+
| Bidirectional LSP Association Group | [RFC9059] | |
| TLV Flag Field | | |
+----------------------------------------+-----------+---------+
| 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] | |
+----------------------------------------+-----------+---------+
Table 1: PCEP Registries Affected
Future registries in the "Path Computation Element Protocol (PCEP)
Numbers" registry group should prefer to use IETF Review over
Standards Action.
3. 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:
+=========+==============+=====================================+
| Range | Registration | Note |
| | Procedures | |
+=========+==============+=====================================+
| 0-251 | IETF Review | The IETF Review procedure applies |
| | | to all Error-values (0-255) for |
| | | Error-Types in this range. |
+---------+--------------+-------------------------------------+
| 252-255 | Experimental | The Experimental Use policy applies |
| | Use | to all Error-values (0-255) for |
| | | Error-Types in this range. |
+---------+--------------+-------------------------------------+
Table 2: PCEP-ERROR Object Error Types and Values Registry
Assignment Policy
Furthermore, IANA has added the following entry to the registry:
+============+==================+=====================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+==================+=====================+===========+
| 252-255 | Reserved for | 0-255: Reserved for | RFC 9756 |
| | Experimental Use | Experimental Use | |
+------------+------------------+---------------------+-----------+
Table 3: PCEP-ERROR Object Error Types and Values Registry
3.1. 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.
3.2. 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.
4. IANA Considerations
This memo is entirely about updating the IANA "Path Computation
Element Protocol (PCEP) Numbers" registry group.
5. 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).
6. References
6.1. Normative References
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/info/rfc8233>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8356] Dhody, D., King, D., and A. Farrel, "Experimental
Codepoint Allocation for the Path Computation Element
Communication Protocol (PCEP)", RFC 8356,
DOI 10.17487/RFC8356, March 2018,
<https://www.rfc-editor.org/info/rfc8356>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/info/rfc8623>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
[RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and
L. Fang, "Path Computation Element Communication Protocol
(PCEP) Extensions for MPLS-TE Label Switched Path (LSP)
Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733,
DOI 10.17487/RFC8733, February 2020,
<https://www.rfc-editor.org/info/rfc8733>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/info/rfc8745>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/info/rfc8779>.
[RFC8780] Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation
Element Communication Protocol (PCEP) Extension for
Wavelength Switched Optical Network (WSON) Routing and
Wavelength Assignment (RWA)", RFC 8780,
DOI 10.17487/RFC8780, July 2020,
<https://www.rfc-editor.org/info/rfc8780>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/info/rfc8800>.
[RFC8934] Chen, H., Ed., Zhuang, Y., Ed., Wu, Q., and D. Ceccarelli,
"PCE Communication Protocol (PCEP) Extensions for Label
Switched Path (LSP) Scheduling with Stateful PCE",
RFC 8934, DOI 10.17487/RFC8934, October 2020,
<https://www.rfc-editor.org/info/rfc8934>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/info/rfc9059>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
Element Communication Protocol (PCEP) Extension for Flow
Specification", RFC 9168, DOI 10.17487/RFC9168, January
2022, <https://www.rfc-editor.org/info/rfc9168>.
[RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", RFC 9357,
DOI 10.17487/RFC9357, February 2023,
<https://www.rfc-editor.org/info/rfc9357>.
[RFC9504] Lee, Y., Zheng, H., Gonzalez de Dios, O., Lopez, V., and
Z. Ali, "Path Computation Element Communication Protocol
(PCEP) Extensions for Stateful PCE Usage in GMPLS-
Controlled Networks", RFC 9504, DOI 10.17487/RFC9504,
December 2023, <https://www.rfc-editor.org/info/rfc9504>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/info/rfc9603>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
6.2. Informative References
[PCEPS-UPDATES]
Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS:
TLS Connection Establishment Restrictions", Work in
Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pceps-tls13-04>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
Appendix A. 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]).
Appendix B. 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
Email: zhenghaomian@huawei.com
Authors' Addresses
Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
AI ELI5
On this page
PROBLEMSeveral IANA registries for the Path Computation Element Protocol (PCEP) could only be changed by Standards Track or Best Current Practice RFCs, and PCEP errors had no range reserved for experiments.
MECHANISMThe RFC changes the listed registries from Standards Action to IETF Review, and designates PCEP Error-Types 252-255 for Experimental Use.
WHY IT MATTERSAny type of RFC in the IETF Stream can now request values in those registries, and experiments can return their own error codes without clashing with real allocations.
§1Why the Registry Rules Changed
IANA keeps a registry group called "Path Computation Element Protocol (PCEP) Numbers". Several RFCs from the Path Computation Element (PCE) Working Group filled it. Most of its registries already use IETF Review as the registration procedure. A few use Standards Action, so their values can be assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream.
This memo changes those registries to IETF Review, which lets any type of RFC in the IETF Stream make the allocation request. It also deals with experiments: RFC 8356 designated experimental ranges for PCEP messages, objects and TLV types, but not for error codes. This document updates RFC 5440 to fill that gap.
The club had two rules for adding to its lists. This document makes the strict rule a bit looser, and it saves a few empty spots for tests.
§2Registries Moved to IETF Review
Section 2 lists, in Table 1, the registries in the PCEP Numbers group whose policy changed from Standards Action to IETF Review. Each affected registry now lists this document as an additional reference. Where the change applies only to part of a registry, the Remarks column gives the range. The one such case is the Generalized Endpoint Types registry from RFC 8779, where the range is 0-244.
The table covers registries defined by many earlier RFCs, for example RFC 8231 (such as the LSP Object Flag Field), RFC 8664 (the SR-ERO Flag Field), RFC 8697 (the ASSOCIATION Type Field) and RFC 9603 (the SRv6-ERO Flag Field). That is why the RFC updates such a long list of documents.
The RFC also says that future registries in this group should prefer IETF Review over Standards Action.
Lots of pages in the club book had the strict rule. Now they all follow the easier one, and new pages are told to do the same.
§3Experimental Error-Types
IANA has designated four PCEP Error-Type codepoints, 252-255, for Experimental Use. In the "PCEP-ERROR Object Error Types and Values" registry, Error-Types 0-251 use IETF Review, and the IETF Review procedure applies to all Error-values (0-255) for Error-Types in that range. Error-Types 252-255 use Experimental Use, and that policy applies to all Error-values (0-255) under them.
IANA also added a registry entry for Error-Type 252-255, meaning "Reserved for Experimental Use", with Error-values 0-255 reserved for Experimental Use and this RFC as the reference.
The reason is practical. Experiments often need to report experiment-specific errors. Existing error codes can often be reused, but sometimes new ones are needed, and they must not collide with existing or future allocations.
Four numbers are now marked as free for tests only. If you are trying a new idea, you can use one without getting in anyone's way.
| Error-Types | Registration procedure | Error-values |
|---|---|---|
| 0-251 | IETF Review | 0-255, IETF Review applies |
| 252-255 THIS RFC | Experimental Use | 0-255, Experimental Use applies |
§3.1Running and Handling Experiments
An experiment that wants to return experimental error codes should use one of the experimental Error-Type values. The participants should agree on which Error-Type and which Error-values to use, and the experiment describes what each pair means. The RFC says these values should not be recorded in any public (especially any IETF) documentation. If several experiments run at once on the same implementations, their sets of Error-Types and Error-values must be kept distinct.
There is no scope for experimental Error-values inside existing non-experimental Error-Types. This keeps the registry and implementations simpler. If an experiment succeeds and moves to Standards Track work, each pair needs a proper assignment from IANA, and the code change is as simple as changing the numeric values.
An implementation that gets an experimental Error-Type it does not recognise treats it like any other unknown Error-Type. It will normally close the PCEP session, but is not required to act on Error-Types and may just log the error. The same holds for an unknown Error-value inside an experimental Error-Type, which can happen through a faulty implementation, out-of-sync implementations or several experiments running at once.
People testing together agree on what each test number means and keep it private. A program that sees a test number it does not know just writes it down, or may hang up.
§4Security Considerations
The memo does not change the security considerations of any updated RFC. It points to RFC 5440 and to a work-in-progress draft on PCEPS for the security measures that apply to PCEP.
RFC 3692 asserts that experimental codepoints add no new security considerations. This RFC adds a caution: implementations that accept experimental error codepoints need to think about how they parse and process them, in case they come by accident from another experiment. They also need to consider the security aspects of the experimental extensions themselves, and RFC 6709 gives design considerations for protocol extensions.
Test numbers from someone else's test could show up by mistake, so a program should handle them carefully and not just trust them.
§5Why All the Registries, and Why Not Objects
Appendix A explains why every listed registry moved, even flag fields with few bits where space is tight. The PCE Working Group decided that Working Group Last Call and IETF Last Call should be enough to handle frivolous experiments taking over the few codepoints. It adds that the group could also create a new protocol field and registry for future use, as was done in the past (see RFC 9357).
Appendix B looks at RFC 8356, which gave experimental codepoints only to messages, objects and TLV types. Its reasoning was that an experiment could use a new experimental object or TLV instead. This RFC says that using an object to carry arbitrary experimental errors would cause unnecessary divergence in the code, and that experimental Error-Types are a better approach because they make it easier to move successful experiments onto the Standards Track.
Some worried that tiny lists could fill up with silly tests. The group decided that review steps would catch that, and that real test numbers are better than clumsy workarounds.
§7References
[RFC5440]RFC 5440Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.March 2009[RFC8126]RFC 8126Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017.June 2017[RFC8356]RFC 8356Dhody, D., King, D., and A. Farrel, "Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)", RFC 8356, March 2018.March 2018[RFC3692]RFC 3692Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.January 2004[RFC6709]RFC 6709Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.September 2012