rfc9756.original   rfc9756.txt 
Path Computation Element D. Dhody Internet Engineering Task Force (IETF) D. Dhody
Internet-Draft Huawei Request for Comments: 9756 Huawei
Updates: 5440, 8231, 8233, 8281, 8623, 8664, A. Farrel Updates: 5440, 8231, 8233, 8281, 8623, 8664, A. Farrel
8685, 8697, 8745, 8733, 8779, 8780, Old Dog Consulting 8685, 8697, 8733, 8745, 8779, 8780, Old Dog Consulting
8800, 8934, 9050, 9059, 9168, 9357, 12 November 2024 8800, 8934, 9050, 9059, 9168, 9357, February 2025
9504, 9603, 9604 (if approved) 9504, 9603, 9604
Intended status: Standards Track Category: Standards Track
Expires: 16 May 2025 ISSN: 2070-1721
Update to the IANA PCE Communication Protocol (PCEP) Registration Update to the IANA PCE Communication Protocol (PCEP) Registration
Procedures and Allowing Experimental Error Codes Procedures and Allowing Experimental Error Codes
draft-ietf-pce-iana-update-03
Abstract Abstract
This document updates the registration procedure within the IANA This document updates the registration procedure within the IANA
"Path Computation Element Protocol (PCEP) Numbers" group of "Path Computation Element Protocol (PCEP) Numbers" registry group.
registries. This specification changes some of the registries with This specification changes some of the registries with Standards
Standards Action to IETF Review as defined in RFC 8126. This memo Action to IETF Review as defined in RFC 8126 and thus updates RFCs
updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780,
8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604 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 Designating "experimental use" sub-ranges within codepoint registries
https://github.com/ietf-wg-pce/draft-ietf-pce-iana-update. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 May 2025. 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 Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Standards Action PCEP Registries Affected . . . . . . . . . . 3 2. Standards Action PCEP Registries Affected
3. Experimental Error-Types . . . . . . . . . . . . . . . . . . 5 3. Experimental Error-Types
3.1. Advice on Experimentation . . . . . . . . . . . . . . . . 6 3.1. Advice on Experimentation
3.2. Handling of Unknown Experimentation . . . . . . . . . . . 7 3.2. Handling of Unknown Experimentation
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 11 6.2. Informative References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Appendix A. Rationale for Updating All Registries with Standards
Appendix B. Rationale for updating all registries with Standards Action
Action . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Consideration of RFC 8356
Appendix C. Consideration of RFC 8356 . . . . . . . . . . . . . 12 Acknowledgements
Appendix D. Contributor . . . . . . . . . . . . . . . . . . . . 12 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
1. Introduction 1. Introduction
The IANA "Path Computation Element Protocol (PCEP) Numbers" registry The IANA "Path Computation Element Protocol (PCEP) Numbers" registry
group was populated by several RFCs produced by the Path Computation group was populated by several RFCs produced by the Path Computation
Element (PCE) working group. Most of the registries include the Element (PCE) Working Group. Most of the registries include IETF
"IETF Review" [RFC8126] as registration procedures. There are a few Review [RFC8126] as the registration procedure. There are a few
registries that use "Standards Action". Thus, the values in those registries that use Standards Action. Thus, the values in those
registries can be assigned only through the Standards Track or Best registries can be assigned only through the Standards Track or Best
Current Practice RFCs in the IETF Stream. This memo changes the Current Practice RFCs in the IETF Stream. This memo changes the
policy from Standards Action to IETF Review to allow any type of RFC policy from Standards Action to IETF Review to allow any type of RFC
under the IETF stream to make the allocation request. under the IETF Stream to make the allocation request.
Further, in Section 9 of [RFC5440], IANA assigns values to the PCEP Further, in Section 9 of [RFC5440], IANA assigns values to the PCEP
parameters. The allocation policy for each of these parameters parameters. The allocation policy for each of these parameters
specified in RFC 5440 is IETF Review [RFC8126]. In consideration of specified in [RFC5440] is IETF Review [RFC8126]. In consideration of
the benefits of conducting experiments with PCEP and the utility of the benefits of conducting experiments with PCEP and the utility of
experimental codepoints [RFC3692], codepoint ranges for PCEP experimental codepoints [RFC3692], codepoint ranges for PCEP
messages, objects, and TLV types for Experimental Use [RFC8126] are messages, objects, and TLV types for Experimental Use [RFC8126] are
designated in [RFC8356]. However, protocol experiments may also need designated in [RFC8356]. However, protocol experiments may also need
to return protocol error messages indicating experiment-specific to return protocol error messages indicating experiment-specific
error cases. It will often be the case that previously assigned error cases. It will often be the case that previously assigned
error codes (in the PCEP-ERROR Object Error Types and Values sub- error codes (in the "PCEP-ERROR Object Error Types and Values"
registry) can be used to indicate the error cases within an registry) can be used to indicate the error cases within an
experiment, but there may also be cases where new, experimental error experiment, but there may also be cases where new, experimental error
codes are needed. In order to run experiments, it is important that codes are needed. In order to run experiments, it is important that
the codepoint values used in the experiments do not collide with the codepoint values used in the experiments do not collide with
existing codepoints or any future allocations. This document updates existing codepoints or any future allocations. This document updates
[RFC5440] by changing the allocation policy for the registry of PCEP [RFC5440] by changing the allocation policy for the registry of PCEP
Error-Types to mark some of the codepoints as assigned for Error-Types to mark some of the codepoints as assigned for
Experimental Use. As stated in [RFC3692], experiments using these Experimental Use. As stated in [RFC3692], experiments using these
codepoints are not intended to be used in general deployments, and codepoints are not intended to be used in general deployments, and
due care must be taken to ensure that two experiments using the same due care must be taken to ensure that two experiments using the same
codepoints are not run in the same environment. codepoints are not run in the same environment.
2. Standards Action PCEP Registries Affected 2. Standards Action PCEP Registries Affected
The following table lists the "Path Computation Element Protocol The following table lists the registries under the "Path Computation
(PCEP) Numbers" registries whose registration policy will be changed Element Protocol (PCEP) Numbers" registry group whose registration
from Standards Action to IETF Review. Affected registries will list policies will be changed from Standards Action to IETF Review. The
this document as a reference. Where this change is applied to a affected registries will list this document as an additional
specific range of values within the particular registry, that range reference. Where this change is applied to a specific range of
is given in the Remarks column. values within the particular registry, that range is given in the
Remarks column.
+========================================+===========+=========+ +========================================+===========+=========+
| Registry | RFC | Remarks | | Registry | RFC | Remarks |
+========================================+===========+=========+ +========================================+===========+=========+
| BU Object Type Field | [RFC8233] | | | BU Object Type Field | [RFC8233] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| LSP Object Flag Field | [RFC8231] | | | LSP Object Flag Field | [RFC8231] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| STATEFUL-PCE-CAPABILITY TLV Flag Field | [RFC8231] | | | STATEFUL-PCE-CAPABILITY TLV Flag Field | [RFC8231] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| LSP-ERROR-CODE TLV Error Code Field | [RFC8231] | | | LSP-ERROR-CODE TLV Error Code Field | [RFC8231] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| SRP Object Flag Field | [RFC8281] | | | SRP Object Flag Field | [RFC8281] | |
skipping to change at page 4, line 48 skipping to change at line 166
| ASSOCIATION Flag Field | [RFC8697] | | | ASSOCIATION Flag Field | [RFC8697] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| ASSOCIATION Type Field | [RFC8697] | | | ASSOCIATION Type Field | [RFC8697] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| AUTO-BANDWIDTH-CAPABILITY TLV Flag | [RFC8733] | | | AUTO-BANDWIDTH-CAPABILITY TLV Flag | [RFC8733] | |
| Field | | | | Field | | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| Path Protection Association Group TLV | [RFC8745] | | | Path Protection Association Group TLV | [RFC8745] | |
| Flag Field | | | | Flag Field | | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| Generalized Endpoint Types | [RFC8779] | 0-244 | | Generalized Endpoint Types | [RFC8779] | 0-244 |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| GMPLS-CAPABILITY TLV Flag Field | [RFC8779] | | | GMPLS-CAPABILITY TLV Flag Field | [RFC8779] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| DISJOINTNESS-CONFIGURATION TLV Flag | [RFC8800] | | | DISJOINTNESS-CONFIGURATION TLV Flag | [RFC8800] | |
| Field | | | | Field | | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| SCHED-PD-LSP-ATTRIBUTE TLV Opt Field | [RFC8934] | | | SCHED-PD-LSP-ATTRIBUTE TLV Opt Field | [RFC8934] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| Schedule TLVs Flag Field | [RFC8934] | | | Schedule TLVs Flag Field | [RFC8934] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| FLOWSPEC Object Flag Field | [RFC9168] | | | FLOWSPEC Object Flag Field | [RFC9168] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| Bidirectional LSP Association Group | [RFC9059] | | | Bidirectional LSP Association Group | [RFC9059] | |
| TLV Flag Field | | | | TLV Flag Field | | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| PCECC-CAPABILITY sub-TLV | [RFC9050] | | | PCECC-CAPABILITY sub-TLV | [RFC9050] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| CCI Object Flag Field for MPLS Label | [RFC9050] | | | CCI Object Flag Field for MPLS Label | [RFC9050] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| TE-PATH-BINDING TLV BT Field | [RFC9050] | | | TE-PATH-BINDING TLV BT Field | [RFC9604] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| TE-PATH-BINDING TLV Flag Field | [RFC9604] | | | TE-PATH-BINDING TLV Flag Field | [RFC9604] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| LSP-EXTENDED-FLAG TLV Flag Field | [RFC9357] | | | LSP-EXTENDED-FLAG TLV Flag Field | [RFC9357] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| LSP Exclusion Subobject Flag Field | [RFC9504] | | | LSP Exclusion Subobject Flag Field | [RFC9504] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| SRv6-ERO Flag Field | [RFC9603] | | | SRv6-ERO Flag Field | [RFC9603] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
| SRv6 Capability Flag Field | [RFC9603] | | | SRv6 Capability Flag Field | [RFC9603] | |
+----------------------------------------+-----------+---------+ +----------------------------------------+-----------+---------+
Table 1: PCEP Registries Affected Table 1: PCEP Registries Affected
Future registries in the "Path Computation Element Protocol (PCEP) Future registries in the "Path Computation Element Protocol (PCEP)
Numbers" registry group should prefer to use "IETF Review" over Numbers" registry group should prefer to use IETF Review over
"Standards Action". Standards Action.
3. Experimental Error-Types 3. Experimental Error-Types
This document requests IANA for the designation of four PCEP Error- Per this document, IANA has designated four PCEP Error-Type
Type codepoints (252-255) for Experimental Use. codepoints (252-255) for Experimental Use.
IANA maintains a registry group called "Path Computation Element IANA maintains the "PCEP-ERROR Object Error Types and Values"
Protocol (PCEP) Numbers" with a registry named "PCEP-ERROR Object registry under the "Path Computation Element Protocol (PCEP) Numbers"
Error Types and Values". IANA is requested to change the assignment registry group. IANA has changed the assignment policy for the
policy for this registry to read: "PCEP-ERROR Object Error Types and Values" registry to read:
* Error-Types * Error-Types:
- 0-251 : IETF Review 0-251: IETF Review
- 252-255 : Experimental Use
* Error-value 252-255: Experimental Use
- For all IETF Review Error-Types : IETF Review * Error-values:
- For all Experimental Use Error-Types : Experimental Use For all IETF Review Error-Types: IETF Review
Additionally, IANA is requested to make an entry in the table as For all Experimental Use Error-Types: Experimental Use
follows:
+============+==================+==================+===========+ Furthermore, IANA has listed this document as an additional reference
| Error-Type | Meaning | Error-value | Reference | for the registry and has added the following entry to the registry:
+============+==================+==================+===========+
| 252-255 | Experimental Use | 0-255 | This I-D |
| | | Experimental Use | |
+------------+------------------+------------------+-----------+
Table 2 +============+==================+=====================+===========+
| Error-Type | Meaning | Error-value | Reference |
+============+==================+=====================+===========+
| 252-255 | Reserved for | 0-255: Reserved for | RFC 9756 |
| | Experimental Use | Experimental Use | |
+------------+------------------+---------------------+-----------+
Table 2: PCEP-ERROR Object Error Types and Values Registry
3.1. Advice on Experimentation 3.1. Advice on Experimentation
An experiment that wishes to return experimental error codes should An experiment that wishes to return experimental error codes should
use one of the experimental Error-Type values as defined in this use one of the experimental Error-Type values as defined in this
document. The experiment should agree, between all participating document. The experiment should agree on, between all participating
parties, on which Error-Type to use and which Error-values to use parties, which Error-Type to use and which Error-values to use within
within that Error-Type. The experiment will describe what the that Error-Type. The experiment will describe what the meanings of
meanings of those Error-Type / Error-value pairs are. Those Error- those Error-Type/Error-value pairs are. Those Error-Types and Error-
Type and Error-values should not be recorded in any public values should not be recorded in any public (especially any IETF)
(especially any IETF) documentation. Textual or symbolic names for documentation. Textual or symbolic names for the Error-Types and
the Error-Types and Error-values may be used to help keep the Error-values may be used to help keep the documentation clear.
documentation clear.
If multiple experiments are taking place at the same time using the If multiple experiments are taking place at the same time using the
same implementations, care must be taken to keep the sets of Error- same implementations, care must be taken to keep the sets of Error-
Type / Error-value distinct. Types/Error-values distinct.
Note that there is no scope for experimental Error-values within Note that there is no scope for experimental Error-values within
existing non-experimental Error-Types. This reduces the complexity existing non-experimental Error-Types. This reduces the complexity
of the registry and implementations. Experiments should place all of the registry and implementations. Experiments should place all
experimental Error-values under the chosen experimental Error-Types. experimental Error-values under the chosen experimental Error-Types.
If, at some future time, the experiment is declared a success and If, at some future time, the experiment is declared a success and
moved to IETF work targeting publication on the Standards Track, each moved to IETF work targeting publication on the Standards Track, each
pair of Error-Type / Error-value will need to be assigned by IANA 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 from the registry. In some cases, this will involve assigning a new
Error-Type with its subtended Error-values. In other cases, use may Error-Type with its subtended Error-values. In other cases, use may
be made of an existing Error-Type with new subtended Error-values be made of an existing Error-Type with new subtended Error-values
being assigned. The resulting change to code in an implementation is being assigned. The resulting change to code in an implementation is
as simple as changing the numeric values of the Error-Types and as simple as changing the numeric values of the Error-Types and
Error-values. Error-values.
3.2. Handling of Unknown Experimentation 3.2. Handling of Unknown Experimentation
A PCEP implementation that receives an experimental Error-Type in a 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 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 of the experiment) will treat the error as it would treat any other
unknown Error-Type (such as from a new protocol extension). An unknown Error-Type (such as from a new protocol extension). An
implementation that is notified of a PCEP error will normally close implementation that is notified of a PCEP error will normally close
the PCEP session (see [RFC5440]). In general, PCEP implementations the PCEP session (see [RFC5440]). In general, PCEP implementations
are not required to take specific action based on Error-Types but may are not required to take specific action based on Error-Types but may
log the errors for diagnostic purposes. log the errors for diagnostic purposes.
An implementation that is part of an experiment may receive an An implementation that is part of an experiment may receive an
experimental Error-Type, but not recognize the Error-value. This experimental Error-Type but not recognize the Error-value. This
could happen because of any of: could happen because of any of the following reasons:
* A faulty implementation. * a faulty implementation
* Two implementations not being synchronized with respect to which * two implementations not being synchronized with respect to which
Error-values to use in the experiment. Error-values to use in the experiment
* More than one experiment being run at the same time. * more than one experiment being run at the same time
As with unknown Error-Types, an implementation receiving an unknown As with unknown Error-Types, an implementation receiving an unknown
Error-value is not expected to do more than log the received error Error-value is not expected to do more than log the received error
and may close the PCEP session. and may close the PCEP session.
4. IANA Considerations 4. IANA Considerations
This memo is entirely about updating the IANA "Path Computation This memo is entirely about updating the IANA "Path Computation
Element Protocol (PCEP) Numbers" registry. Element Protocol (PCEP) Numbers" registry group.
5. Security Considerations 5. Security Considerations
This memo does not change the Security Considerations for any of the 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 updated RFCs. Refer to [RFC5440] and [PCEPS-UPDATES] for further
further details of the specific security measures applicable to PCEP. details of the specific security measures applicable to PCEP.
[RFC3692] asserts that the existence of experimental codepoints [RFC3692] asserts that the existence of experimental codepoints
introduces no new security considerations. However, implementations introduces no new security considerations. However, implementations
accepting experimental error codepoints need to consider how they accepting experimental error codepoints need to consider how they
parse and process them in case they come, accidentally, from another parse and process them in case they come, accidentally, from another
experiment. Further, an implementation accepting experimental experiment. Further, an implementation accepting experimental
codepoints needs to consider the security aspects of the experimental codepoints needs to consider the security aspects of the experimental
extensions. [RFC6709] provides various design considerations for extensions. [RFC6709] provides various design considerations for
protocol extensions (including those designated as experimental). protocol extensions (including those designated as experimental).
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/rfc/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/rfc/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
"Extensions to the Path Computation Element Communication "Extensions to the Path Computation Element Communication
Protocol (PCEP) to Compute Service-Aware Label Switched Protocol (PCEP) to Compute Service-Aware Label Switched
Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
2017, <https://www.rfc-editor.org/rfc/rfc8233>. 2017, <https://www.rfc-editor.org/info/rfc8233>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/rfc/rfc8281>. <https://www.rfc-editor.org/info/rfc8281>.
[RFC8356] Dhody, D., King, D., and A. Farrel, "Experimental [RFC8356] Dhody, D., King, D., and A. Farrel, "Experimental
Codepoint Allocation for the Path Computation Element Codepoint Allocation for the Path Computation Element
Communication Protocol (PCEP)", RFC 8356, Communication Protocol (PCEP)", RFC 8356,
DOI 10.17487/RFC8356, March 2018, DOI 10.17487/RFC8356, March 2018,
<https://www.rfc-editor.org/rfc/rfc8356>. <https://www.rfc-editor.org/info/rfc8356>.
[RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
Path Computation Element (PCE) Protocol Extensions for Path Computation Element (PCE) Protocol Extensions for
Usage with Point-to-Multipoint TE Label Switched Paths Usage with Point-to-Multipoint TE Label Switched Paths
(LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
<https://www.rfc-editor.org/rfc/rfc8623>. <https://www.rfc-editor.org/info/rfc8623>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664, Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019, DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/rfc/rfc8664>. <https://www.rfc-editor.org/info/rfc8664>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R., [RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685, Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019, DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/rfc/rfc8685>. <https://www.rfc-editor.org/info/rfc8685>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/rfc/rfc8697>. <https://www.rfc-editor.org/info/rfc8697>.
[RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and [RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and
L. Fang, "Path Computation Element Communication Protocol L. Fang, "Path Computation Element Communication Protocol
(PCEP) Extensions for MPLS-TE Label Switched Path (LSP) (PCEP) Extensions for MPLS-TE Label Switched Path (LSP)
Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733, Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733,
DOI 10.17487/RFC8733, February 2020, DOI 10.17487/RFC8733, February 2020,
<https://www.rfc-editor.org/rfc/rfc8733>. <https://www.rfc-editor.org/info/rfc8733>.
[RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
and M. Negi, "Path Computation Element Communication and M. Negi, "Path Computation Element Communication
Protocol (PCEP) Extensions for Associating Working and Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE", Protection Label Switched Paths (LSPs) with Stateful PCE",
RFC 8745, DOI 10.17487/RFC8745, March 2020, RFC 8745, DOI 10.17487/RFC8745, March 2020,
<https://www.rfc-editor.org/rfc/rfc8745>. <https://www.rfc-editor.org/info/rfc8745>.
[RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. [RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
Zhang, Ed., "Path Computation Element Communication Zhang, Ed., "Path Computation Element Communication
Protocol (PCEP) Extensions for GMPLS", RFC 8779, Protocol (PCEP) Extensions for GMPLS", RFC 8779,
DOI 10.17487/RFC8779, July 2020, DOI 10.17487/RFC8779, July 2020,
<https://www.rfc-editor.org/rfc/rfc8779>. <https://www.rfc-editor.org/info/rfc8779>.
[RFC8780] Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation [RFC8780] Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation
Element Communication Protocol (PCEP) Extension for Element Communication Protocol (PCEP) Extension for
Wavelength Switched Optical Network (WSON) Routing and Wavelength Switched Optical Network (WSON) Routing and
Wavelength Assignment (RWA)", RFC 8780, Wavelength Assignment (RWA)", RFC 8780,
DOI 10.17487/RFC8780, July 2020, DOI 10.17487/RFC8780, July 2020,
<https://www.rfc-editor.org/rfc/rfc8780>. <https://www.rfc-editor.org/info/rfc8780>.
[RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
"Path Computation Element Communication Protocol (PCEP) "Path Computation Element Communication Protocol (PCEP)
Extension for Label Switched Path (LSP) Diversity Extension for Label Switched Path (LSP) Diversity
Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800,
July 2020, <https://www.rfc-editor.org/rfc/rfc8800>. July 2020, <https://www.rfc-editor.org/info/rfc8800>.
[RFC8934] Chen, H., Ed., Zhuang, Y., Ed., Wu, Q., and D. Ceccarelli, [RFC8934] Chen, H., Ed., Zhuang, Y., Ed., Wu, Q., and D. Ceccarelli,
"PCE Communication Protocol (PCEP) Extensions for Label "PCE Communication Protocol (PCEP) Extensions for Label
Switched Path (LSP) Scheduling with Stateful PCE", Switched Path (LSP) Scheduling with Stateful PCE",
RFC 8934, DOI 10.17487/RFC8934, October 2020, RFC 8934, DOI 10.17487/RFC8934, October 2020,
<https://www.rfc-editor.org/rfc/rfc8934>. <https://www.rfc-editor.org/info/rfc8934>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050, Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021, DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/rfc/rfc9050>. <https://www.rfc-editor.org/info/rfc9050>.
[RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation [RFC9059] Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
Element Communication Protocol (PCEP) Extensions for Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Label Switched Paths (LSPs)", Associated Bidirectional Label Switched Paths (LSPs)",
RFC 9059, DOI 10.17487/RFC9059, June 2021, RFC 9059, DOI 10.17487/RFC9059, June 2021,
<https://www.rfc-editor.org/rfc/rfc9059>. <https://www.rfc-editor.org/info/rfc9059>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation [RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
Element Communication Protocol (PCEP) Extension for Flow Element Communication Protocol (PCEP) Extension for Flow
Specification", RFC 9168, DOI 10.17487/RFC9168, January Specification", RFC 9168, DOI 10.17487/RFC9168, January
2022, <https://www.rfc-editor.org/rfc/rfc9168>. 2022, <https://www.rfc-editor.org/info/rfc9168>.
[RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag [RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag
Extension for Stateful PCE", RFC 9357, Extension for Stateful PCE", RFC 9357,
DOI 10.17487/RFC9357, February 2023, DOI 10.17487/RFC9357, February 2023,
<https://www.rfc-editor.org/rfc/rfc9357>. <https://www.rfc-editor.org/info/rfc9357>.
[RFC9504] Lee, Y., Zheng, H., Gonzalez de Dios, O., Lopez, V., and [RFC9504] Lee, Y., Zheng, H., Gonzalez de Dios, O., Lopez, V., and
Z. Ali, "Path Computation Element Communication Protocol Z. Ali, "Path Computation Element Communication Protocol
(PCEP) Extensions for Stateful PCE Usage in GMPLS- (PCEP) Extensions for Stateful PCE Usage in GMPLS-
Controlled Networks", RFC 9504, DOI 10.17487/RFC9504, Controlled Networks", RFC 9504, DOI 10.17487/RFC9504,
December 2023, <https://www.rfc-editor.org/rfc/rfc9504>. December 2023, <https://www.rfc-editor.org/info/rfc9504>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., [RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing", Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024, RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/rfc/rfc9603>. <https://www.rfc-editor.org/info/rfc9603>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., [RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024, Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/rfc/rfc9604>. <https://www.rfc-editor.org/info/rfc9604>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-pce-pceps-tls13] [PCEPS-UPDATES]
Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS: Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS:
TLS Connection Establishment Restrictions", Work in TLS Connection Establishment Restrictions", Work in
Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9 Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9
January 2024, <https://datatracker.ietf.org/doc/html/ January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pceps-tls13-04>. draft-ietf-pce-pceps-tls13-04>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004, DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/rfc/rfc3692>. <https://www.rfc-editor.org/info/rfc3692>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/rfc/rfc6709>. <https://www.rfc-editor.org/info/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 Appendix A. Rationale for Updating All Registries with Standards Action
This specification updates all the registries with the "Standards This specification updates all the registries with the Standards
Action" policy. WG considered keeping "Standards Action" for some Action policy. The PCE WG considered keeping Standards Action for
registries such as flag fields with limited bits, where the space is some registries, such as flag fields with limited bits where the
tight but decided against it. The WG's last call and IETF's last space is tight, but decided against it. The Working Group Last Call
call process should be enough to handle the case of frivolous and IETF Last Call processes should be enough to handle the case of
experiments taking over the few code points. The working group could frivolous experiments taking over the few codepoints. The working
also create a new protocol field and registry for future use as done group could also create a new protocol field and registry for future
in the past (see [RFC9357]). use as done in the past (see [RFC9357]).
Appendix C. Consideration of RFC 8356 Appendix B. Consideration of RFC 8356
It is worth noting that [RFC8356] deliberately chose to make It is worth noting that [RFC8356] deliberately chose to make
experimental codepoints available only in the PCEP messages, objects, experimental codepoints available only in the PCEP messages, objects,
and TLV type registries. Appendix A of that document gives a brief and TLV type registries. Appendix A of [RFC8356] gives a brief
explanation of why that decision was taken stating that: explanation of why that decision was taken, stating that:
| The justification for this decision is that, if an experiment | The justification for this decision is that, if an experiment
| finds that it wants to use a new codepoint in another PCEP sub- | finds that it wants to use a new codepoint in another PCEP sub-
| registry, it can implement the same function using a new | registry, it can implement the same function using a new
| experimental object or TLV instead. | experimental object or TLV instead.
While it is true that an experimental implementation could assign an While it is true that an experimental implementation could assign an
experimental PCEP object and designate it the "experimental errors experimental PCEP object and designate it the "experimental errors
object", using it to carry arbitrary contents including experimental object", using it to carry arbitrary contents including experimental
error codes, such an approach would cause unnecessary divergence in error codes, such an approach would cause unnecessary divergence in
the code. The allowance of experimental Error-Types is a better the code. The allowance of experimental Error-Types is a better
approach that will more easily enable the migration of successful approach that will more easily enable the migration of successful
experiments onto the Standards Track. experiments onto the Standards Track.
Appendix D. Contributor 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 Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Huawei
India India
 End of changes. 70 change blocks. 
174 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.48.