Skip to main content

Update to the IANA PCE Communication Protocol (PCEP) Registration Procedures and Allowing Experimental Error Codes
draft-ietf-pce-iana-update-03

Document Type Active Internet-Draft (pce WG)
Authors Dhruv Dhody , Adrian Farrel
Last updated 2024-12-11 (Latest revision 2024-11-12)
Replaces draft-dhody-pce-iana-update, draft-farrel-pce-experimental-errors
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Julien Meuric
Shepherd write-up Show Last changed 2024-10-07
IESG IESG state RFC Ed Queue
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD John Scudder
Send notices to julien.meuric@orange.com
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state EDIT
Details
draft-ietf-pce-iana-update-03
Path Computation Element                                        D. Dhody
Internet-Draft                                                    Huawei
Updates: 5440, 8231, 8233, 8281, 8623, 8664,                   A. Farrel
         8685, 8697, 8745, 8733, 8779, 8780,          Old Dog Consulting
         8800, 8934, 9050, 9059, 9168, 9357,            12 November 2024
         9504, 9603, 9604 (if approved)                                 
Intended status: Standards Track                                        
Expires: 16 May 2025

   Update to the IANA PCE Communication Protocol (PCEP) Registration
            Procedures and Allowing Experimental Error Codes
                     draft-ietf-pce-iana-update-03

Abstract

   This document updates the registration procedure within the IANA
   "Path Computation Element Protocol (PCEP) Numbers" group of
   registries.  This specification changes some of the registries with
   Standards Action to IETF Review as defined in RFC 8126.  This memo
   updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745,
   8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604
   for the same.

   Designating "experimental use" sub-ranges within code point
   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.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Path Computation
   Element Working Group mailing list (pce@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/pce/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-pce/draft-ietf-pce-iana-update.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Dhody & Farrel             Expires 16 May 2025                  [Page 1]
Internet-Draft                  PCEP-IANA                  November 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 16 May 2025.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Standards Action PCEP Registries Affected . . . . . . . . . .   3
   3.  Experimental Error-Types  . . . . . . . . . . . . . . . . . .   5
     3.1.  Advice on Experimentation . . . . . . . . . . . . . . . .   6
     3.2.  Handling of Unknown Experimentation . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Appendix B.  Rationale for updating all registries with Standards
           Action  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Appendix C.  Consideration of RFC 8356  . . . . . . . . . . . . .  12
   Appendix D.  Contributor  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Dhody & Farrel             Expires 16 May 2025                  [Page 2]
Internet-Draft                  PCEP-IANA                  November 2024

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 the
   "IETF Review" [RFC8126] as registration procedures.  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 RFC 5440 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 the case that previously assigned
   error codes (in the PCEP-ERROR Object Error Types and Values sub-
   registry) can be used to indicate the error cases within an
   experiment, but there may also be cases 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 "Path Computation Element Protocol
   (PCEP) Numbers" registries whose registration policy will be changed
   from Standards Action to IETF Review.  Affected registries will list
   this document as a reference.  Where this change is applied to a
   specific range of values within the particular registry, that range
   is given in the Remarks column.

Dhody & Farrel             Expires 16 May 2025                  [Page 3]
Internet-Draft                  PCEP-IANA                  November 2024

     +========================================+===========+=========+
     | 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] |         |

Dhody & Farrel             Expires 16 May 2025                  [Page 4]
Internet-Draft                  PCEP-IANA                  November 2024

     | 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           | [RFC9050] |         |
     +----------------------------------------+-----------+---------+
     | 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

   This document requests IANA for the designation of four PCEP Error-
   Type codepoints (252-255) for Experimental Use.

   IANA maintains a registry group called "Path Computation Element
   Protocol (PCEP) Numbers" with a registry named "PCEP-ERROR Object
   Error Types and Values".  IANA is requested to change the assignment
   policy for this registry to read:

   *  Error-Types

      -  0-251 : IETF Review

Dhody & Farrel             Expires 16 May 2025                  [Page 5]
Internet-Draft                  PCEP-IANA                  November 2024

      -  252-255 : Experimental Use

   *  Error-value

      -  For all IETF Review Error-Types : IETF Review

      -  For all Experimental Use Error-Types : Experimental Use

   Additionally, IANA is requested to make an entry in the table as
   follows:

     +============+==================+==================+===========+
     | Error-Type |     Meaning      |   Error-value    | Reference |
     +============+==================+==================+===========+
     | 252-255    | Experimental Use |      0-255       |  This I-D |
     |            |                  | Experimental Use |           |
     +------------+------------------+------------------+-----------+

                                 Table 2

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, between all participating
   parties, on 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-
   Type 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-
   Type / Error-value 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-Type / Error-value 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

Dhody & Farrel             Expires 16 May 2025                  [Page 6]
Internet-Draft                  PCEP-IANA                  November 2024

   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:

   *  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.

5.  Security Considerations

   This memo does not change the Security Considerations for any of the
   updated RFCs.  Refer to [RFC5440] and [I-D.ietf-pce-pceps-tls13] for
   further details of the specific security measures applicable to PCEP.

Dhody & Farrel             Expires 16 May 2025                  [Page 7]
Internet-Draft                  PCEP-IANA                  November 2024

   [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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8356>.

Dhody & Farrel             Expires 16 May 2025                  [Page 8]
Internet-Draft                  PCEP-IANA                  November 2024

   [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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc8779>.

Dhody & Farrel             Expires 16 May 2025                  [Page 9]
Internet-Draft                  PCEP-IANA                  November 2024

   [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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc9504>.

Dhody & Farrel             Expires 16 May 2025                 [Page 10]
Internet-Draft                  PCEP-IANA                  November 2024

   [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/rfc/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/rfc/rfc9604>.

6.2.  Informative References

   [I-D.ietf-pce-pceps-tls13]
              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/rfc/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/rfc/rfc6709>.

Appendix A.  Acknowledgments

   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 GENART review.  Thanks to Paul Kyzivat for ArtArt
   review.  Thanks to Alexey Melnikov for SECDIR review.

Appendix B.  Rationale for updating all registries with Standards Action

   This specification updates all the registries with the "Standards
   Action" policy.  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 WG's last call and IETF's last
   call process should be enough to handle the case of frivolous
   experiments taking over the few code points.  The working group could
   also create a new protocol field and registry for future use as done

Dhody & Farrel             Expires 16 May 2025                 [Page 11]
Internet-Draft                  PCEP-IANA                  November 2024

   in the past (see [RFC9357]).

Appendix C.  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 that document 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.

Appendix D.  Contributor

   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

Dhody & Farrel             Expires 16 May 2025                 [Page 12]