RFC 9756

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

📅 published March 2025, from ietf

RFC 9756: Update to the IANA PCEP Numbers Registration Procedures 🦋

Bestie, this one is a whole vibe. It's a Standards Track doc from March 2025 (ISSN 2070-1721) by D. Dhody (Huawei) and A. Farrel (Old Dog Consulting). It's officially titled "Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes" 💅. It updates RFCs 5440, 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604. Its job is to change how some IANA PCEP registries get new numbers, and to carve out room for experiments. 🎀

Abstract ✨

Okay, the abstract is basically the TL;DR. It changes the registration procedure for the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group. Some registries that used Standards Action now use IETF Review, as defined in RFC 8126. That's why it updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604. 🌸

Experimental sub-ranges are super useful for testing things in controlled environments 🧪. The PCEP message, object, and TLV registries already have Experimental Use sub-ranges, but the Error-Types and Error-values registry doesn't. So this document updates RFC 5440 and designates a specific range of PCEP Error-Types for Experimental Use. Iconic. 👑

Status of This Memo ✨

Quick status check: this is an Internet Standards Track document 🌈. It's a product of the Internet Engineering Task Force (IETF), it represents the IETF community's consensus, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841. For the current status, errata, and where to send feedback, go to https://www.rfc-editor.org/info/rfc9756. 🫶

Legal stuff, but make it cute 🎀: 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. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 🍓

Okay, so the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group got filled up by a bunch of RFCs from the Path Computation Element (PCE) Working Group 🧚. Most of those registries use IETF Review [RFC8126] as the registration procedure. A few use Standards Action, which means values there can only be assigned through Standards Track or Best Current Practice RFCs in the IETF Stream. This memo switches those from Standards Action to IETF Review, so any type of RFC in the IETF Stream can make the allocation request. Main character energy for the whole stream 💅.

Now, in Section 9 of [RFC5440], IANA assigns values to the PCEP parameters, and the allocation policy for each of those parameters is IETF Review [RFC8126]. Experiments with PCEP are a big deal, and experimental codepoints are useful [RFC3692], so codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use [RFC8126] were designated in [RFC8356]. 🦋

But here's the gap 👀: experiments might also need to send back protocol error messages for experiment-specific error cases. Often, error codes that were already assigned (in the "PCEP-ERROR Object Error Types and Values" registry) can cover those cases. Sometimes, though, you genuinely need brand-new experimental error codes. It's really important that experimental codepoint values don't collide with existing codepoints or future allocations, so experiments don't mess each other up 🙈. This document updates [RFC5440] by changing the allocation policy for the PCEP Error-Types registry, marking some codepoints as assigned for Experimental Use. As [RFC3692] says, experiments using these codepoints aren't meant for general deployments, and you need to take real care that two experiments using the same codepoints don't run in the same environment ⚠️.

2. Standards Action PCEP Registries Affected 🌈

Here's the table of every registry in the "Path Computation Element Protocol (PCEP) Numbers" group whose registration policy moved from Standards Action to IETF Review. Each affected registry now lists this document as an extra reference 📚. If the change only applies to a specific range within a registry, that range shows up 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

Also, the registries in this group that get added later should prefer IETF Review over Standards Action. That's the plan going forward 🔮.

3. Experimental Error-Types ✨

Okay so bestie, this section is where the experiments get their own little playground 🦋 Per this document, IANA has designated four PCEP Error-Type codepoints (252-255) for Experimental Use. Four whole codepoints, all reserved for experiments, iconic 💅

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. Think of it like group chats 💬 you don't want two friend groups mixing up their inside jokes lol

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. Keep it clean, babe 🧚

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. Glow-up arc unlocked 🦋✨

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. Not my favorite vibe, but that's the rule 😭

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. Literally the whole memo is about this one registry group, no side quests 💖

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). Okay this part is serious, bestie, so please double-check your experiment's codepoints don't leak into another one 🚨

6. References 📚

6.1. Normative References 📚

okay bestie, these are the must-read docs that the spec leans on 🫶 if you want the full picture you NEED these, no cap 💅

6.2. Informative References 🌸

these ones are the extra reading, nice to have but not required to get the spec 🧚

Appendix A. Rationale for Updating All Registries with Standards Action 💖

okay so this bit explains WHY everything got bumped to Standards Action 🎀 this spec updates every registry we mentioned to use that policy. the PCE WG did think about keeping it lighter for some registries, like flag fields where the bits are super tight 🥺 but they said nah. the vibe is that Working Group Last Call and IETF Last Call should be enough to stop silly experiments from hogging the few codepoints 🛑 and if things ever get crowded, the working group could just make a brand new protocol field and registry for the future, which they've done before (see [RFC9357]) ✨

Appendix B. Consideration of RFC 8356 🦋

this is the tea ☕ [RFC8356] deliberately made experimental codepoints available ONLY in the PCEP messages, objects, and TLV type registries. Appendix A of [RFC8356] explains the reasoning, and it says:

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.

and honestly? it's true that an experiment could just grab an experimental PCEP object, call it the "experimental errors object", and stuff arbitrary contents in there, including experimental error codes 🙈 BUT that would cause unnecessary divergence in the code, which is messy bestie 😭 so letting experimental Error-Types exist is the better move, because it makes it way easier for successful experiments to graduate onto the Standards Track 🚀💅

Acknowledgements 🫶

huge thank yous 💜 to John Scudder for kicking off the initial discussion behind this document 🌈 and to Ketan Talaulikar, Andrew Stone, Samuel Sidor, Quan Xiong, Cheng Li, and Aijun Wang for the review comments 📝 also to Carlos Pignataro for the OPSDIR review, Meral Shirazipour for the GENART review, Paul Kyzivat for the ArtArt review, and 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
📦 where this page comes from