<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="utf-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.20 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pce-iana-update-03" number="9756" category="std" consensus="true" submissionType="IETF" updates="5440, 8231, 8233, 8281, 8623, 8664, 8685, 8697,8745,8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, 9604" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.24.0 -->version="3" xml:lang="en"> <front> <!--[rfced] Title a) We note that the document's title expands PCEP as "PCE Communication Protocol"; however, the IANA registry group expands it as "Path Computation Element Protocol" (see <https://www.iana.org/assignments/pcep>). Should this document's title be updated to reflect the name of the registry group being updated, with the inclusion of "Numbers", as shown below? Original: Update to the IANA PCE Communication Protocol (PCEP) Registration Procedures and Allowing Experimental Error Codes Perhaps: Update to the IANA Path Computation Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes b) FYI - To closer reflect the document's full title, we have updated the short title as follows. The short title appears in the running header in the PDF output. Original: PCEP-IANA Current: PCEP IANA Update --> <titleabbrev="PCEP-IANA">Updateabbrev="PCEP IANA Update">Update to the IANA PCE Communication Protocol (PCEP) Registration Procedures and Allowing Experimental Error Codes</title> <seriesInfoname="Internet-Draft" value="draft-ietf-pce-iana-update-03"/>name="RFC" value="9756"/> <author initials="D." surname="Dhody" fullname="Dhruv Dhody"> <organization>Huawei</organization> <address> <postal><country>IN</country><country>India</country> </postal> <email>dhruv.ietf@gmail.com</email> </address> </author> <author initials="A." surname="Farrel" fullname="Adrian Farrel"> <organization>Old Dog Consulting</organization> <address> <email>adrian@olddog.co.uk</email> </address> </author><date/> <area>Routing</area> <workgroup>Path Computation Element</workgroup><date month="February" year="2025"/> <area>RTG</area> <workgroup>pce</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <abstract><?line 59?><t>This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers"group of registries.registry group. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC8126. This memo8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and9604 for the same.</t>9604.</t> <t>Designating "experimental use" sub-ranges withincode pointcodepoint 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.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the Path Computation Element Working Group mailing list (pce@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pce/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/ietf-wg-pce/draft-ietf-pce-iana-update"/>.</t> </note></front> <middle><?line 66?><section anchor="introduction"> <name>Introduction</name> <t>The IANA "Path Computation Element Protocol (PCEP) Numbers" registry group was populated by several RFCs produced by the Path Computation Element (PCE)working group.Working Group. Most of the registries includethe "IETF Review"IETF Review <xref target="RFC8126"/> as the registrationprocedures.procedure. There are a few registries that use"Standards Action".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 IETFstreamStream to make the allocation request.</t> <t>Further, inSection 9 of<xref section="9" sectionFormat="of" target="RFC5440"/>, IANA assigns values to the PCEP parameters. The allocation policy for each of these parameters specified inRFC 5440<xref target="RFC5440"/> is IETF Review <xref target="RFC8126"/>. In consideration of the benefits of conducting experiments with PCEP and the utility of experimental codepoints <xref target="RFC3692"/>, codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use <xref target="RFC8126"/> are designated in <xref target="RFC8356"/>. However, protocol experiments may also need to return protocol error messages indicating experiment-specific error cases. <!--[rfced] To avoid repetition of "case", may we update this sentence as follows? Original: It will often be the case that previously assigned error codes (in the PCEP-ERROR Object Error Types and Valuessub-registry)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. Perhaps: It will often be 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 instances where new, experimental error codes are needed. --> It will often be the case that previously assigned error codes (in the "PCEP-ERROR Object Error Types and Values" registry) can be used to indicate the error cases within an experiment, but there may also be 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 <xref target="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 <xref target="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.</t> </section> <section anchor="standards-action-pcep-registries-affected"> <name>Standards Action PCEP Registries Affected</name> <t>The following table lists the registries under the "Path Computation Element Protocol (PCEP) Numbers"registriesregistry group whose registrationpolicypolicies will be changed from Standards Action to IETF Review.AffectedThe affected registries will list this document asaan additional reference. Where this change is applied to a specific range of values within the particular registry, that range is given in the Remarks column.</t> <table> <name>PCEP Registries Affected</name> <thead> <tr><th align="left">Registry</th> <th align="center">RFC</th> <th align="right">Remarks</th><th>Registry</th> <th>RFC</th> <th>Remarks</th> </tr> </thead> <tbody> <tr><td align="left">BU<td>BU Object Type Field</td><td align="center"> <xref<td><xref target="RFC8233"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">LSP<td>LSP Object Flag Field</td><td align="center"><td> <xref target="RFC8231"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">STATEFUL-PCE-CAPABILITY<td>STATEFUL-PCE-CAPABILITY TLV Flag Field</td><td align="center"><td> <xref target="RFC8231"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">LSP-ERROR-CODE<td>LSP-ERROR-CODE TLV Error Code Field</td><td align="center"><td> <xref target="RFC8231"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SRP<td>SRP Object Flag Field</td><td align="center"><td> <xref target="RFC8281"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SR-ERO<td>SR-ERO Flag Field</td><td align="center"><td> <xref target="RFC8664"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">PATH-SETUP-TYPE-CAPABILITY<td>PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</td><td align="center"><td> <xref target="RFC8664"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SR<td>SR Capability Flag Field</td><td align="center"><td> <xref target="RFC8664"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">WA<td>WA Object Flag Field</td><td align="center"><td> <xref target="RFC8780"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Wavelength<td>Wavelength Restriction TLV Action Values</td><td align="center"><td> <xref target="RFC8780"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Wavelength<td>Wavelength Allocation TLV Flag Field</td><td align="center"><td> <xref target="RFC8780"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">S2LS<td>S2LS Object Flag Field</td><td align="center"><td> <xref target="RFC8623"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">H-PCE-CAPABILITY<td>H-PCE-CAPABILITY TLV Flag Field</td><td align="center"><td> <xref target="RFC8685"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">H-PCE-FLAG<td>H-PCE-FLAG TLV Flag Field</td><td align="center"><td> <xref target="RFC8685"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">ASSOCIATION<td>ASSOCIATION Flag Field</td><td align="center"><td> <xref target="RFC8697"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">ASSOCIATION<td>ASSOCIATION Type Field</td><td align="center"><td> <xref target="RFC8697"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">AUTO-BANDWIDTH-CAPABILITY<td>AUTO-BANDWIDTH-CAPABILITY TLV Flag Field</td><td align="center"><td> <xref target="RFC8733"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Path<td>Path Protection Association Group TLV Flag Field</td><td align="center"><td> <xref target="RFC8745"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Generalized<td>Generalized Endpoint Types</td><td align="center"><td> <xref target="RFC8779"/></td><td align="right">0-244</td><td>0-244</td> </tr> <tr><td align="left">GMPLS-CAPABILITY<td>GMPLS-CAPABILITY TLV Flag Field</td><td align="center"><td> <xref target="RFC8779"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">DISJOINTNESS-CONFIGURATION<td>DISJOINTNESS-CONFIGURATION TLV Flag Field</td><td align="center"><td> <xref target="RFC8800"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SCHED-PD-LSP-ATTRIBUTE<td>SCHED-PD-LSP-ATTRIBUTE TLV Opt Field</td><td align="center"><td> <xref target="RFC8934"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Schedule<td>Schedule TLVs Flag Field</td><td align="center"><td> <xref target="RFC8934"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">FLOWSPEC<td>FLOWSPEC Object Flag Field</td><td align="center"><td> <xref target="RFC9168"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">Bidirectional<td>Bidirectional LSP Association Group TLV Flag Field</td><td align="center"><td> <xref target="RFC9059"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">PCECC-CAPABILITY<td>PCECC-CAPABILITY sub-TLV</td><td align="center"><td> <xref target="RFC9050"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">CCI<td>CCI Object Flag Field for MPLS Label</td><td align="center"><td> <xref target="RFC9050"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">TE-PATH-BINDING<td>TE-PATH-BINDING TLV BT Field</td><td align="center"><td> <xreftarget="RFC9050"/></td> <td align="right"> </td>target="RFC9604"/></td> <td></td> </tr> <tr><td align="left">TE-PATH-BINDING<td>TE-PATH-BINDING TLV Flag Field</td><td align="center"><td> <xref target="RFC9604"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">LSP-EXTENDED-FLAG<td>LSP-EXTENDED-FLAG TLV Flag Field</td><td align="center"><td> <xref target="RFC9357"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">LSP<td>LSP Exclusion Subobject Flag Field</td><td align="center"><td> <xref target="RFC9504"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SRv6-ERO<td>SRv6-ERO Flag Field</td><td align="center"><td> <xref target="RFC9603"/></td><td align="right"> </td><td></td> </tr> <tr><td align="left">SRv6<td>SRv6 Capability Flag Field</td><td align="center"><td> <xref target="RFC9603"/></td><td align="right"> </td><td></td> </tr> </tbody> </table> <t>Future registries in the "Path Computation Element Protocol (PCEP) Numbers" registry group should prefer to use"IETF Review"IETF Review over"Standards Action".</t>Standards Action.</t> </section> <section anchor="experimental-error-types"> <name>Experimental Error-Types</name><t>This document requests<t>Per this document, IANAfor the designation ofhas designated four PCEP Error-Type codepoints (252-255) for Experimental Use.</t> <t>IANA maintainsathe "PCEP-ERROR Object Error Types and Values" registrygroup calledunder the "Path Computation Element Protocol (PCEP) Numbers"with aregistrynamedgroup. IANA has changed the assignment policy for the "PCEP-ERROR Object Error Types andValues".Values" registry to read:</t> <!--[rfced] Would it be clearer for readers if the following information matches the IANA registry and is in table format (see <https://www.iana.org/assignments/pcep/>)? Please let us know your preference. Original: IANA is requested to change the assignment policy for this registry toread:</t> <ul spacing="normal"> <li> <t>Error-Types </t> <ul spacing="normal"> <li> <t>0-251read: Error-Types 0-251 : IETFReview</t> </li> <li> <t>252-255Review 252-255 : ExperimentalUse</t> </li> </ul> </li> <li> <t>Error-value </t> <ul spacing="normal"> <li> <t>ForUse Error-value For all IETF Review Error-Types : IETFReview</t> </li> <li> <t>ForReview For all Experimental Use Error-Types : ExperimentalUse</t>Use Perhaps: IANA has changed the assignment policy for the "PCEP-ERROR Object Error Types and Values" registry as follows: Range Registration Procedures Note - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0-251 IETF Review The IETF Review procedure applies to all Error-values (0-255) for Error-Types in this range. 252-255 Experimental Use The Experimental Use policy applies to all Error-values (0-255) for Error-Types in this range. Table 2: PCEP-ERROR Object Error Types and Values Registry Assignment Policy --> <ul spacing="normal"> <li><t>Error-Types:</t> <dl spacing="normal" newline="false"> <dt>0-251:</dt><dd>IETF Review</dd> <dt>252-255:</dt><dd>Experimental Use</dd> </dl> </li></ul><li><t>Error-values:</t> <dl spacing="normal" newline="false"> <dt>For all IETF Review Error-Types:</dt><dd>IETF Review</dd> <dt>For all Experimental Use Error-Types:</dt><dd>Experimental Use</dd> </dl> </li> </ul><t>Additionally,<t>Furthermore, IANAis requested to makehas listed this document as an additional reference for the registry and has added the following entryinto thetable as follows:</t> <table>registry:</t> <table align="center"> <name>PCEP-ERROR Object Error Types and Values Registry</name> <thead> <tr><th align="left">Error-Type</th> <th align="center">Meaning</th> <th align="center">Error-value</th> <th align="right">Reference</th><th>Error-Type</th> <th>Meaning</th> <th>Error-value</th> <th>Reference</th> </tr> </thead> <tbody> <tr><td align="left">252-255</td> <td align="center">Experimental<td>252-255</td> <td>Reserved for Experimental Use</td><td align="center">0-255<td>0-255: Reserved for Experimental Use</td><td align="right">This I-D</td><td>RFC 9756</td> </tr> </tbody> </table> <section anchor="advice-on-experimentation"> <name>Advice on Experimentation</name> <t>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 shouldagree,agree on, between all participating parties,onwhich Error-Type to use and which Error-values to use within that Error-Type. The experiment will describe what the meanings of thoseError-Type / Error-valueError-Type/Error-value pairs are. ThoseError-TypeError-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.</t> <t>If multiple experiments are taking place at the same time using the same implementations, care must be taken to keep the sets ofError-Type / Error-valueError-Types/Error-values distinct.</t> <t>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.</t> <t>If, at some future time, the experiment is declared a success and moved to IETF work targeting publication on the Standards Track, each pair ofError-Type / Error-valueError-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.</t> </section> <section anchor="handling-of-unknown-experimentation"> <name>Handling of Unknown Experimentation</name> <t>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 <xref target="RFC5440"/>). In general, PCEP implementations are not required to take specific action based on Error-Types but may log the errors for diagnostic purposes.</t> <t>An implementation that is part of an experiment may receive an experimentalError-Type,Error-Type but not recognize the Error-value. This could happen because of anyof:</t>of the following reasons:</t> <ul spacing="normal"> <li><t>A<t>a faultyimplementation.</t>implementation</t> </li> <li><t>Two<t>two implementations not being synchronized with respect to which Error-values to use in theexperiment.</t>experiment</t> </li> <li><t>More<t>more than one experiment being run at the sametime.</t>time</t> </li> </ul> <t>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.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers"registry.</t>registry group.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This memo does not change theSecurity Considerationssecurity considerations for any of the updated RFCs. Refer to <xref target="RFC5440"/> and <xref target="I-D.ietf-pce-pceps-tls13"/> for further details of the specific security measures applicable to PCEP.</t> <t><xref target="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. <xref target="RFC6709"/> provides various design considerations for protocol extensions (including those designated as experimental).</t> </section> </middle> <back> <displayreference target="I-D.ietf-pce-pceps-tls13" to="PCEPS-UPDATES"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC5440"> <front> <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title> <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/> <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/> <date month="March" year="2009"/> <abstract> <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5440"/> <seriesInfo name="DOI" value="10.17487/RFC5440"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8231"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title> <author fullname="E. Crabbe" initials="E." surname="Crabbe"/> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="J. Medved" initials="J." surname="Medved"/> <author fullname="R. Varga" initials="R." surname="Varga"/> <date month="September" year="2017"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t> <t>Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t> </abstract> </front> <seriesInfo name="RFC" value="8231"/> <seriesInfo name="DOI" value="10.17487/RFC8231"/> </reference> <reference anchor="RFC8233"> <front> <title>Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)</title> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="V. Manral" initials="V." surname="Manral"/> <author fullname="Z. Ali" initials="Z." surname="Ali"/> <author fullname="K. Kumaki" initials="K." surname="Kumaki"/> <date month="September" year="2017"/> <abstract> <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.</t> <t>IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.</t> </abstract> </front> <seriesInfo name="RFC" value="8233"/> <seriesInfo name="DOI" value="10.17487/RFC8233"/> </reference> <reference anchor="RFC8281"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title> <author fullname="E. Crabbe" initials="E." surname="Crabbe"/> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="R. Varga" initials="R." surname="Varga"/> <date month="December" year="2017"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t> <t>The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t> </abstract> </front> <seriesInfo name="RFC" value="8281"/> <seriesInfo name="DOI" value="10.17487/RFC8281"/> </reference> <reference anchor="RFC8356"> <front> <title>Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)</title> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <author fullname="D. King" initials="D." surname="King"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <date month="March" year="2018"/> <abstract> <t>IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.</t> <t>This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.</t> </abstract> </front> <seriesInfo name="RFC" value="8356"/> <seriesInfo name="DOI" value="10.17487/RFC8356"/> </reference> <reference anchor="RFC8623"> <front> <title>Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)</title> <author fullname="U. Palle" initials="U." surname="Palle"/> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <author fullname="Y. Tanaka" initials="Y." surname="Tanaka"/> <author fullname="V. Beeram" initials="V." surname="Beeram"/> <date month="June" year="2019"/> <abstract> <t>The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.</t> </abstract> </front> <seriesInfo name="RFC" value="8623"/> <seriesInfo name="DOI" value="10.17487/RFC8623"/> </reference> <reference anchor="RFC8664"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing</title> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="J. Tantsura" initials="J." surname="Tantsura"/> <author fullname="W. Henderickx" initials="W." surname="Henderickx"/> <author fullname="J. Hardwick" initials="J." surname="Hardwick"/> <date month="December" year="2019"/> <abstract> <t>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.</t> <t>This document updates RFC 8408.</t> </abstract> </front> <seriesInfo name="RFC" value="8664"/> <seriesInfo name="DOI" value="10.17487/RFC8664"/> </reference> <reference anchor="RFC8685"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture</title> <author fullname="F. Zhang" initials="F." surname="Zhang"/> <author fullname="Q. Zhao" initials="Q." surname="Zhao"/> <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/> <author fullname="R. Casellas" initials="R." surname="Casellas"/> <author fullname="D. King" initials="D." surname="King"/> <date month="December" year="2019"/> <abstract> <t>The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.</t> <t>This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.</t> </abstract> </front> <seriesInfo name="RFC" value="8685"/> <seriesInfo name="DOI" value="10.17487/RFC8685"/> </reference> <reference anchor="RFC8697"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)</title> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="E. Crabbe" initials="E." surname="Crabbe"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <author fullname="Y. Tanaka" initials="Y." surname="Tanaka"/> <date month="January" year="2020"/> <abstract> <t>This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.</t> </abstract> </front> <seriesInfo name="RFC" value="8697"/> <seriesInfo name="DOI" value="10.17487/RFC8697"/> </reference> <reference anchor="RFC8733"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE</title> <author fullname="D. Dhody" initials="D." role="editor" surname="Dhody"/> <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/> <author fullname="U. Palle" initials="U." surname="Palle"/> <author fullname="R. Singh" initials="R." surname="Singh"/> <author fullname="L. Fang" initials="L." surname="Fang"/> <date month="February" year="2020"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.</t> <t>The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs.</t> </abstract> </front> <seriesInfo name="RFC" value="8733"/> <seriesInfo name="DOI" value="10.17487/RFC8733"/> </reference> <reference anchor="RFC8745"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE</title> <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="C. Barth" initials="C." surname="Barth"/> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="M. Negi" initials="M." surname="Negi"/> <date month="March" year="2020"/> <abstract> <t>An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.</t> </abstract> </front> <seriesInfo name="RFC" value="8745"/> <seriesInfo name="DOI" value="10.17487/RFC8745"/> </reference> <reference anchor="RFC8779"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS</title> <author fullname="C. Margaria" initials="C." role="editor" surname="Margaria"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="F. Zhang" initials="F." role="editor" surname="Zhang"/> <date month="July" year="2020"/> <abstract> <t>A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025.</t> <t>This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements.</t> </abstract> </front> <seriesInfo name="RFC" value="8779"/> <seriesInfo name="DOI" value="10.17487/RFC8779"/> </reference> <reference anchor="RFC8780"> <front> <title>The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)</title> <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/> <author fullname="R. Casellas" initials="R." role="editor" surname="Casellas"/> <date month="July" year="2020"/> <abstract> <t>This document provides Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs). Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation.</t> </abstract> </front> <seriesInfo name="RFC" value="8780"/> <seriesInfo name="DOI" value="10.17487/RFC8780"/> </reference> <reference anchor="RFC8800"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling</title> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="C. Barth" initials="C." surname="Barth"/> <author fullname="M. Negi" initials="M." surname="Negi"/> <date month="July" year="2020"/> <abstract> <t>This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.</t> </abstract> </front> <seriesInfo name="RFC" value="8800"/> <seriesInfo name="DOI" value="10.17487/RFC8800"/> </reference> <reference anchor="RFC8934"> <front> <title>PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE</title> <author fullname="H. Chen" initials="H." role="editor" surname="Chen"/> <author fullname="Y. Zhuang" initials="Y." role="editor" surname="Zhuang"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/> <date month="October" year="2020"/> <abstract> <t>This document defines a set of extensions to the stateful PCE Communication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413.</t> </abstract> </front> <seriesInfo name="RFC" value="8934"/> <seriesInfo name="DOI" value="10.17487/RFC8934"/> </reference> <reference anchor="RFC9050"> <front> <title>Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs</title> <author fullname="Z. Li" initials="Z." surname="Li"/> <author fullname="S. Peng" initials="S." surname="Peng"/> <author fullname="M. Negi" initials="M." surname="Negi"/> <author fullname="Q. Zhao" initials="Q." surname="Zhao"/> <author fullname="C. Zhou" initials="C." surname="Zhou"/> <date month="July" year="2021"/> <abstract> <t>The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.</t> <t>A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label-forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.</t> <t>This document specifies the procedures and Path Computation Element Communication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP.</t> </abstract> </front> <seriesInfo name="RFC" value="9050"/> <seriesInfo name="DOI" value="10.17487/RFC9050"/> </reference> <reference anchor="RFC9059"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title> <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/> <author fullname="C. Barth" initials="C." surname="Barth"/> <author fullname="B. Wen" initials="B." surname="Wen"/> <date month="June" year="2021"/> <abstract> <t>This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.</t> </abstract> </front> <seriesInfo name="RFC" value="9059"/> <seriesInfo name="DOI" value="10.17487/RFC9059"/> </reference> <reference anchor="RFC9168"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification</title> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <author fullname="Z. Li" initials="Z." surname="Li"/> <date month="January" year="2022"/> <abstract> <t>The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.</t> <t>Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.</t> <t>This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.</t> <t>The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.</t> </abstract> </front> <seriesInfo name="RFC" value="9168"/> <seriesInfo name="DOI" value="10.17487/RFC9168"/> </reference> <reference anchor="RFC9357"> <front> <title>Label Switched Path (LSP) Object Flag Extension for Stateful PCE</title> <author fullname="Q. Xiong" initials="Q." surname="Xiong"/> <date month="February" year="2023"/> <abstract> <t>RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.</t> <t>This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field.</t> </abstract> </front> <seriesInfo name="RFC" value="9357"/> <seriesInfo name="DOI" value="10.17487/RFC9357"/> </reference> <reference anchor="RFC9504"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks</title> <author fullname="Y. Lee" initials="Y." surname="Lee"/> <author fullname="H. Zheng" initials="H." surname="Zheng"/> <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/> <author fullname="V. Lopez" initials="V." surname="Lopez"/> <author fullname="Z. Ali" initials="Z." surname="Ali"/> <date month="December" year="2023"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements for GMPLS networks.</t> <t>This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks.</t> </abstract> </front> <seriesInfo name="RFC" value="9504"/> <seriesInfo name="DOI" value="10.17487/RFC9504"/> </reference> <reference anchor="RFC9603"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing</title> <author fullname="C. Li" initials="C." role="editor" surname="Li"/> <author fullname="P. Kaladharan" initials="P." surname="Kaladharan"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="M. Koldychev" initials="M." surname="Koldychev"/> <author fullname="Y. Zhu" initials="Y." surname="Zhu"/> <date month="July" year="2024"/> <abstract> <t>Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm.</t> <t>An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE).</t> <t>Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.</t> </abstract> </front> <seriesInfo name="RFC" value="9603"/> <seriesInfo name="DOI" value="10.17487/RFC9603"/> </reference> <reference anchor="RFC9604"> <front> <title>Carrying Binding Label/SID in PCE-Based Networks</title> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="C. Filsfils" initials="C." surname="Filsfils"/> <author fullname="J. Tantsura" initials="J." surname="Tantsura"/> <author fullname="S. Previdi" initials="S." surname="Previdi"/> <author fullname="C. Li" initials="C." role="editor" surname="Li"/> <date month="August" year="2024"/> <abstract> <t>In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID), as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering (TE) Label Switched Path (LSP) or an SR TE path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or a Segment Identifier (SID). It further specifies an extension to Path Computation Element Communication Protocol (PCEP) for reporting the binding value by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based TE policies.</t> </abstract> </front> <seriesInfo name="RFC" value="9604"/> <seriesInfo name="DOI" value="10.17487/RFC9604"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8233.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8356.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8623.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8685.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8733.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8745.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8779.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8780.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8800.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8934.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9050.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9059.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9168.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9357.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9504.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9603.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9604.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC3692"> <front> <title>Assigning Experimental and Testing Numbers Considered Useful</title> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="January" year="2004"/> <abstract> <t>When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.</t> </abstract> </front> <seriesInfo name="BCP" value="82"/> <seriesInfo name="RFC" value="3692"/> <seriesInfo name="DOI" value="10.17487/RFC3692"/> </reference> <reference anchor="RFC6709"> <front> <title>Design Considerations for Protocol Extensions</title> <author fullname="B. Carpenter" initials="B." surname="Carpenter"/> <author fullname="B. Aboba" initials="B." role="editor" surname="Aboba"/> <author fullname="S. Cheshire" initials="S." surname="Cheshire"/> <date month="September" year="2012"/> <abstract> <t>This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6709"/> <seriesInfo name="DOI" value="10.17487/RFC6709"/> </reference> <reference anchor="I-D.ietf-pce-pceps-tls13"> <front> <title>Updates for PCEPS: TLS Connection Establishment Restrictions</title> <author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization>Huawei</organization> </author> <author fullname="Sean Turner" initials="S." surname="Turner"> <organization>sn3rd</organization> </author> <author fullname="Russ Housley" initials="R." surname="Housley"> <organization>Vigil Security, LLC</organization> </author> <date day="9" month="January" year="2024"/> <abstract> <t> Section 3.4 of<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3692.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6709.xml"/> <!-- [I-D.ietf-pce-pceps-tls13] IESG State: RFC8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for PCEP (Path Computation Element Communication Protocol). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the useEd Queue (MISSREF*R) as ofTLS 1.3's early data. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-tls13-04"/> </reference>02/26/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-pceps-tls13.xml"/> </references> </references><?line 169?> <section anchor="acknowledgments"> <name>Acknowledgments</name> <t>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.</t> </section><section anchor="rationale-for-updating-all-registries-with-standards-action"> <name>Rationale forupdating all registriesUpdating All Registries with Standards Action</name> <t>This specification updates all the registries with the"Standards Action"Standards Action policy. The PCE WG considered keeping"Standards Action"Standards Action for someregistriesregistries, such as flag fields with limitedbits,bits where the space istighttight, but decided against it. TheWG's last callWorking Group Last Call andIETF's last call processIETF Last Call processes should be enough to handle the case of frivolous experiments taking over the fewcode points.codepoints. The working group could also create a new protocol field and registry for future use as done in the past (see <xref target="RFC9357"/>).</t> </section> <section anchor="consideration-of-rfc-8356"> <name>Consideration of RFC 8356</name> <t>It is worth noting that <xref target="RFC8356"/> deliberately chose to make experimental codepoints available only in the PCEP messages, objects, and TLV type registries.Appendix A of that document<xref section="A" sectionFormat="of" target="RFC8356"/> gives a brief explanation of why that decision wastakentaken, stating that:</t> <blockquote> <t>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.</t> </blockquote> <t>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.</t> </section> <sectionanchor="contributor"> <name>Contributor</name> <t>Haomian Zheng <br/> Huawei Technologies <br/> Email: zhenghaomian@huawei.com <br/></t>anchor="acknowledgements" numbered="false"> <name>Acknowledgements</name> <t>Thanks to <contact fullname="John Scudder"/> for the initial discussion behind this document. Thanks to <contact fullname="Ketan Talaulikar"/>, <contact fullname="Andrew Stone"/>, <contact fullname="Samuel Sidor"/>, <contact fullname="Quan Xiong"/>, <contact fullname="Cheng Li"/>, and <contact fullname="Aijun Wang"/> for the review comments. Thanks to <contact fullname="Carlos Pignataro"/> for the OPSDIR review. Thanks to <contact fullname="Meral Shirazipour"/> for the GENART review. Thanks to <contact fullname="Paul Kyzivat"/> for the ArtArt review. Thanks to <contact fullname="Alexey Melnikov"/> for the SECDIR review.</t> </section> <section anchor="contributors" numbered="false"> <name>Contributors</name> <contact fullname="Haomian Zheng"> <organization>Huawei Technologies</organization> <address> <email>zhenghaomian@huawei.com</email> </address> </contact> </section> </back> <!--[rfced] FYI - For consistency, and because the capitalization infers that these are procedures, we have removed the quotation marks from the following terms. "Standards Action" "IETF Review" --> <!--##markdown-source: H4sIAAAAAAAAA6VaWXPbOLZ+169AuR9uXCVpnHh33TvViiwnmnFsX0uZzFLz AJGQhDZFcAjSjrP89/nOAUiCWpxMj6ujpsQD4OAs31mAXq/XKXSRqAux9zGL ZaFEYUSxVGI8uBmIu+FIDM1qVaY6koU2qbjLTWEik4hXeHe3L+7VQtsir19G Ki5zZYVMYzFIEvOk04UYfc5UrlcqLWQiRnlucswaK7vXkbNZrh6xOM3WozX3 OlhJLUz+fCFsEXc6sYlSuQKDcS7nRU+rYt7LItXTMpW9knnuHRx2bDlbaWvB RvGcgXo8ml4J8YuQiTWYX6exyhQ+0mKvK/ZUrAuTa5nQl/HgLf4HpvbG99Or vU5armYqv+jQ1Bfi6+VgOvreiUxqVWpLeyGKvFQdMH3YkbmSmPzelAX2udd5 MvnDIjdlRjuSxZKEl5WFk84oUSSCvY5jGhMdHx0ddMXZm8PX/HlIn2f0fPKG nk9Ojujz7Jg+z0/xeXpEz6dMeXp6Tp9nNMPZAX2eH4L+/OD4gD/x9vz1yRk+ D48x9vz4gN6eHBzy51GnI8tiabBN0esIoVPwc9kXl0sTP+O7E/nlMi8f699M vrgQ70v5pDS+RaZMC9LS+Abf1ErqBDqiAX3S0a8L+qUfmVWwwKAvrmSeq6Re YRBDC2nzK69xm8Ti0iwgPQg8IdE2K0ge8KtJ4tgsMH2/fOh0UpOvIORHhd2I +6shCdY/nr1+c1I9QtDN42H9eFb/enhc00IF9ePJUf14dlw/np9Wj6fNZNBQ /Xh6Xj+e1exAVdUj9OUfSWnNYzWM1Fc9QofVIxRZPUKbzSN+1el8TRKHJ+dv /OPJ6QHPPO5d9msvwr/M9orEvsZMnU6v1xNyRg4dFZ3OdKmtgP+VZLfCmy2j Qx66fVa5vXjSxVKnDX7sdIINHLlhn7N7gt1HmHm1hFa2L5gRm6lIzysgipYy XYAba1aKyAOuMIQ5EZMCMCTz2IpBxIOAbYwL9+pRqychsTs116mKYZ4kIkHW 0hduvZVamXrTeGn/I091Pur89fd7KsEoqVZAr7xFC6/pdzqXyupFKsk1AGYh vJZW7QmAYS938vEqiYC3IjMaog+khF2aeaFSMVMpBBEBEHmlrNJOMDULkGeC 25skgdBU+qhzk9JrKGmQAE/KxXJdFTQhKRkCtVaCJ2Dt7DcVFdbtb3r9F0GY bcVSPqqQd2lpl1iIpmgFkY9WdcN1nptVOL70pjwhTe++P8qkxA9RCZxJi+QZ Zo2vqSm8cW1YOVkDwYiYgTaQtqztUDCXZHsb627jt+/da6XjOFGdzi9iTIKM SzZNcrbf7zS1FJz3PMGwM5OVCXYS0waselQ52GArznhR94JEuHM5WmVfUEyj jfPUffHB2GKLv+k0SkqYGP28F/jYnvj61aPw9+/kcNuRg31cAUEk/RNzOGcw ebGUBRm22Fv36D0aV1pnC17HDEDGttiLJNl4Y1AmTWjzeW2vzcRTYN8DZQNv FXY6dAYD0QMRdaScCCuMo31OCiQBq36AGRU0EUlmEh3BOnOz+iEc4auklAlm +8weQXImOyyRt+TNipZXJPKVfHAip3EeGHP1L0ihgLldlTne5V1id6Lckuc0 J6uEjPv7966zOScYW4nQ54Bs15nMgTkF7IyBsbVWtTtIS8lo6e0Com8GVe7S YCx7FWQVbj0wkj78gkDGamzaLePNzYFUQZhFBOw5MMwGozzsM9vk+jQImVmi i2ca08JJAkTGQ+sWp0BJ4qh/Fx6Efh6+tnl92/xh3BWWOHm4t0g7aN/vzRP5 aXcb/MK05DMnsyJVGAsN5aoo8zQg5sS64hKzxxwrWxLq1eDlqCNpyffEuIDo kqSOBiw6eul8L0OSrk1p4TS1C/kJKI8Xr7xDcBY/ur+/vRe3LCOf7Tdo/Bdn YAzyHrT2K++Eh/PGPOeOiYDPKpaButlRV8zKgigh21pEM1WN4N9T9dRtaz9k XjKFilXMpmdydjbItwzXgbZ1QWarV5nJ4cmFEw0LqrYZ7z+8Ey+TUIexoZAD +iSBdTtrVZ8hBdJSYJHgjTBgXhaUVTUOZ3dFq8CjCdYZgWjOYqe/toLnthjG 8JI/tBKsgEX5g/AMoxpAz0XL0isnC2VSWs+obc9PWoGs8IXKNjaMykYw3QJY QBEN9Il59goiA4tL0j0ZQwn4JksGRjLUUvWWe4Munsx2JjjB2sYHWYPXKJME uU+fgvkGuLNA75sQNJjP4RAqdpF+bqriuJCzRIkEZC5i/P7wz3lvGPlaSmf/ Jsfg6BT/VEjq11y3c2vMRAyD39AYySRAN4fLpREM4BM7H9O4Rcl9ZJYl2qlz WyrlHSgoJBBKEHiRy+S1vXadEvNqzgXqnVo794rM1pKTlasUuvlWaeFZfOMA FP59q+n9d5BfUJrmXuKPvvUuavL6j38l8rcfK7AjxxFXWqF8BaXDdhQL8Mlv THk9uatIrxK58KQN5euacjIdTEdXH6970HRvOLgbvB1fj6d/42Dzg6FYxEFw b3h7OeIRTcvlpSXvX2TuLKTEArfbqFAH1VR3g+n73mQ0/XjXm/7trrWLCdCf +GJ5jR3aG6QK26aZ3IuhzOTMRfEfrPlp8MIWUIA1hKg0EpUu4Gn3iszaWT8x 5R3BB6ofDB402LpDNeHAyZvryQsMopasSd//pOZRc66NuboevPsZ6sFkcjsc D6bj25utpOenW0kDG99K+nF623s7uLn8NL6E/n+8gdPAPxj5COV8sjqw1qAm 5ed3XNnsmuSo2dc7Fxn0F4DMKI1dXHYhrSY/PWfyg96boyM36MPd9eRnuPUj aczlePKn2/HN9GY0wdDbm6vxu4/3XkjbR6P4b2xh+H502bu77JG/DqbT+/Hb j1PnrrdZsTbw/DBwiGiJkgkhA6R22yoh8dX17afJ3Wi42+qo81CTv9Wxzp3w EVsJrn5WBdTGaPQ4HA2HoTStd/iGuBHEcDjewh2lFKQTcS1nKtk6cDrqMca8 Hd9cjm+czb+dbrD18oAtOzk5OGqD6V+no5tLKOsFz6LOTQvmR59RD1M3msDO 7BT+8UGIdI8nO4CVmkEtupcxMSD/eiG4v/9/e7vykb3vVClyotmq5//LZKTq RdilKcFZxnkBRX2u41sdAoOiZ1tpT2nV5tGBS0/Xm5O+6rWunK0S3Lpx44rI uSk3mkRhrvfqzfGb3pvj4/1dDRyefCVBjH8u22ltNpLcF/sdUuNSIJiPuuOx Pxb5iYJqj2o4Yk7bShQux/KJF9cBnK4zG606QNtmWS4rZXzR6fRa0ka6Q2h5 /FpchPkh/+6FhjfrEqsn4ayOia+otEH6GBb/YdWxOX01YqOybg/bWLsziGPt kCx57m6XDvdPqJykk4zK5l1CLq3P0e0FpZCBwXwTH5RMKXVvJ5LBVoPk0mfD P5VYVr98E+2/OtWsRO3WWxcIBzS83fKCnWXcu8QsnV9+EYP4kXpZZJjtBi+k Fha9Ls9+0nbpCkLfcthZSntnJxc3aV01qu0+XOX67S58q6TgrmDIj19ALnKl UPmr4kkh8yfzcGWCzlzHg79xqyZFSaSjZbiuByHynvBd0/uit3UFIotg7AZD XAth61GuUVs9VR2BlbMQ60RgWtYq/tAylUzqnMtMmnuNcqN/7fdPBemM8Dqi bgXLjfoFWTmDX4tXiusqsnv+mTxqv5Yp6xlrqc9FCX1Ad/Z5NSNAYNCxNXi+ 2EinVkvQslmqJBMPSmUOdsOlRJQomRN4zlGTJ4XOknZThCpsFOmstkTCLL0M ucwuQLRenetV5uDU9US6O+r9mh2rXM9wpwpi7sBEVMjfmELVjZ2cq8vUCBuZ TLk256Ytt0vWup2TmrS3w/KrNk6uqBFvfWuFdvXZtypb3RkS/tqe+4Hj1lbh pZckL3DZtJIjMrZ0l3NaVliXdMENIN+KInV015yaZBSrCAU6bAE1fRlhT85k Vgjtcd1ToJMEqCdfKOejbK0+OKfbuvBd11UmD3lRf+yEVVs0bPPPnn0+QL2O UKbc6eONcZ+w62CH59Hpo0keq0nckU/ailIuWFMjGnmt706FQnZtRLKfanYC FO8xKxkzMMrAVNanpuW2T40ZmCO/QQdHufKn5HW0N+68z/VK26bDPRhwzr/S U6tXmMJvUQxX0Owt8SUk6HNAeY+fE5oEIz6mD6l52hZaXO61xo9r5ahI6Uee fme4oN20OvGu3+fP8RgMoa8vao1l8Ur3Vb/rPLngyLAZmPad7ulgpQjazhCP Bsazd7l3hKdOtWW1zWAl2P6SMweyN2c2QS8f+qSKYL8vBhtaYSk4Ft1hCZmI 261jxdk4ne4TrEeJsao5o4GRca3xyiol/uFbwf/cZ0P0ndLuNuEH7U2kRTp3 HkQI2rTmpKvFZ9LyuVnLGKj1TnadmEUjNRdBYi0XqYF9R3D0PDOWTWX3xiu9 tAyAJ/e28YJpuDOAXUbAduoRN2JVLmWW8TFHJDlVmTu1zjntBVpIuNPzGqN9 vJo+mQ0BulBMpm+f02iZm5Q7D+zHOQfigmS6O9HYOCaglT4Y16lOOY8KBOKW omb0epQk6foDsE3T5Ob4uuidYBlP0rUxDle9y9Dykc+YYyTNNW+V2r2GqjMh Rn65y0i5rGNUHoaHfFVFxyeo+D+4hD1SBjMzpT/oqFDqvz0mdw17FZU5hdvd bNTYElRRO4axzTsrcseOfDAT83Fx35UBJL7wnIbE9PXrrts4IKAp5+4MFwEW JWdSI3LtnbZiBxmndTfvqMEecQ2DBUkC2G5w+kLBQ+WFbY6vOA5xkfLCIan2 lxVYIi5CVUu3DmttcI65ATbIDLK1E8lWBeHXqkJ5NbFYmifi9JlQwmfufHXA cu604msp7rBSETuUo2AtHfP8VP05QE4dcgeuJuoz8k332MHtGp+2xahLN71c JHu/3VoG1dEA8mLl0O0sKAfbetRUSj3KnE5cfQtjTcbrl3Squegglu5hOEch 7wuOmxGXQhb2qwspM2Ra5BCDiBAgUfGCs0pyBJk+8P7+ZJapmERlTHus6gOd orymIzhto9LFn5lCChxv1nDVPH+GFadiKhMgrH6QEPsgjXPY0qQAznXFRK5K lYiJjg3e/X8J4r9i3kVXDJcKe7rW7pBvoH8DAn6CUwZnmdxLgPL9daRm1aHM gUTijgUhc1OPub2bXI7v/dBwxAc+W5wsdS6/6Iy6RjTk3ehmcD/dQn6H7Yg/ P3/Rj/AoohzkBf7bQjlAig8T/aCSVD+YRyaejIYBF6SJe+n6Fq7kqKGPMvsf XXHz8NW+K1edEtME2+7Jcadvo//mu0R98eldbX4wIyqr+NrZ5gDilpPqYIE6 JaIu5Zy6lH7RRK80X0/SdHT75M8KCdqoisEeCr1YFhzZUV1oyoTlgtpuSBd8 Y+DTu/+xIpH4hRpvbBlUaLR+rHDC10gzOrl1t35QtVLWGtx1oBZhrpH+k+OF JaovT7lRSdRztrTqRp27vNS+KOUzDb6NEFHmqNbzQZYF89y6w+YLLW5QkBOl dYaQ0Z44wwtazvtsMMP16zJ8l/Hw+ARFHGdX4I3qCuNDKMw0uHkC+SZ6RqMp 3nJdWDfHdkGffEQ44iDDV6mC+x8/uifTutgpBpSJxfoz0i6GSXBW93QXriIQ M9ByYEpk08t9Wj57chgHgw/denPFP906qDaKnO7rxb9KlPXfO39kPf1W2qLx jboHWs+jXWhE+KK8EIOC9GsOePORkwoDycbh20ms3uYqCBdfLuCQWDBPeOmF b5NEYdBpsrl5mbqc2/U9eOIWG9S2cd1gagVDruQVSsawhU9LDZ24myp0T93x up46r0U6b6tcVG7Qsk79clxwVRGFVmHk2Azm1g/Y6/o9aE6CI5lTOyOHy+cy 58ShUC65qKLWrtZi1wNJSvlNbqgt4Moyl8KXaarIzWnWGGaTLzif8WZJMwSX 16C2LblOWNdoNjtVFFBevZ7vhQJTOANGvqVh+Sp1qRY1/fSi8UDfBpmX7Vtc 2LHZ1uqo3Bh+AcQzeafzXpoVXY3/O0e+/53l4g9/7Ljb92KqomUKmFoQwvpX I3c//guRL93YX5dMTpfwK6p/AxkHPBrxMQAA[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>