<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" 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, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, 9604" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2025-03-12T15:43:07" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-pce-iana-update-03" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9756" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PCEP IANA Update">Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes</title>
    <seriesInfo name="RFC" value="9756" stream="IETF"/>
    <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
      <organization showOnFrontPage="true">Huawei</organization>
      <address>
        <postal>
          <country>India</country>
        </postal>
        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Farrel" fullname="Adrian Farrel">
      <organization showOnFrontPage="true">Old Dog Consulting</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>RTG</area>
    <workgroup>pce</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document updates the registration procedure within the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group. This specification changes some of the registries with Standards Action to IETF Review as defined in RFC 8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604.</t>
      <t indent="0" pn="section-abstract-2">Designating "experimental use" sub-ranges within codepoint registries is often beneficial for protocol experimentation in controlled environments. Although the registries for PCEP messages, objects, and TLV types have sub-ranges assigned for Experimental Use, the registry for PCEP Error-Types and Error-values currently does not. This document updates RFC 5440 by designating a specific range of PCEP Error-Types for Experimental Use.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9756" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-standards-action-pcep-regis">Standards Action PCEP Registries Affected</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-experimental-error-types">Experimental Error-Types</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-on-experimentation">Advice on Experimentation</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-of-unknown-experim">Handling of Unknown Experimentation</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rationale-for-updating-all-">Rationale for Updating All Registries with Standards Action</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-consideration-of-rfc-8356">Consideration of RFC 8356</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The IANA "Path Computation Element Protocol (PCEP) Numbers" registry group was populated by several RFCs produced by the Path Computation Element (PCE) Working Group. Most of the registries include IETF Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> as the registration procedure. There are a few registries that use Standards Action. Thus, the values in those registries can be assigned only through the Standards Track or Best Current Practice RFCs in the IETF Stream. This memo changes the policy from Standards Action to IETF Review to allow any type of RFC under the IETF Stream to make the allocation request.</t>
      <t indent="0" pn="section-1-2">Further, in <xref section="9" sectionFormat="of" target="RFC5440" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5440#section-9" derivedContent="RFC5440"/>, IANA assigns values to the PCEP parameters.  The allocation policy for each of these parameters specified in <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> is IETF Review <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. In consideration of the benefits of conducting experiments with PCEP and the utility of experimental codepoints <xref target="RFC3692" format="default" sectionFormat="of" derivedContent="RFC3692"/>, codepoint ranges for PCEP messages, objects, and TLV types for Experimental Use <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> are designated in <xref target="RFC8356" format="default" sectionFormat="of" derivedContent="RFC8356"/>. However, protocol experiments may also need to return protocol error messages indicating experiment-specific error cases.
It will often be that previously assigned error codes (in the "PCEP-ERROR Object Error Types and Values" registry) can be used to indicate the error cases within an experiment, but there may also be instances where new, experimental error codes are needed. In order to run experiments, it is important that the codepoint values used in the experiments do not collide with existing codepoints or any future allocations. This document updates <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="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" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-standards-action-pcep-regis">Standards Action PCEP Registries Affected</name>
      <t indent="0" pn="section-2-1">The following table lists the registries under the "Path Computation Element Protocol (PCEP) Numbers" registry group whose registration policies have been changed from Standards Action to IETF Review. The affected registries list this document as an additional reference. Where this change has been applied to a specific range of values within the particular registry, that range is given in the Remarks column.</t>
      <table align="center" pn="table-1">
        <name slugifiedName="name-pcep-registries-affected">PCEP Registries Affected</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Registry</th>
            <th align="left" colspan="1" rowspan="1">RFC</th>
            <th align="left" colspan="1" rowspan="1">Remarks</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">BU Object Type Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8233" format="default" sectionFormat="of" derivedContent="RFC8233"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">LSP Object Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">STATEFUL-PCE-CAPABILITY TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">LSP-ERROR-CODE TLV Error Code Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8231" format="default" sectionFormat="of" derivedContent="RFC8231"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SRP Object Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8281" format="default" sectionFormat="of" derivedContent="RFC8281"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SR-ERO Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8664" format="default" sectionFormat="of" derivedContent="RFC8664"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8664" format="default" sectionFormat="of" derivedContent="RFC8664"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SR Capability Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8664" format="default" sectionFormat="of" derivedContent="RFC8664"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">WA Object Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8780" format="default" sectionFormat="of" derivedContent="RFC8780"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Wavelength Restriction TLV Action Values</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8780" format="default" sectionFormat="of" derivedContent="RFC8780"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Wavelength Allocation TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8780" format="default" sectionFormat="of" derivedContent="RFC8780"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">S2LS Object Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8623" format="default" sectionFormat="of" derivedContent="RFC8623"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">H-PCE-CAPABILITY TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8685" format="default" sectionFormat="of" derivedContent="RFC8685"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">H-PCE-FLAG TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8685" format="default" sectionFormat="of" derivedContent="RFC8685"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ASSOCIATION Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ASSOCIATION Type Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8697" format="default" sectionFormat="of" derivedContent="RFC8697"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">AUTO-BANDWIDTH-CAPABILITY TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8733" format="default" sectionFormat="of" derivedContent="RFC8733"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Path Protection Association Group TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8745" format="default" sectionFormat="of" derivedContent="RFC8745"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Generalized Endpoint Types</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8779"/></td>
            <td align="left" colspan="1" rowspan="1">0-244</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">GMPLS-CAPABILITY TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8779" format="default" sectionFormat="of" derivedContent="RFC8779"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">DISJOINTNESS-CONFIGURATION TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8800" format="default" sectionFormat="of" derivedContent="RFC8800"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SCHED-PD-LSP-ATTRIBUTE TLV Opt Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8934" format="default" sectionFormat="of" derivedContent="RFC8934"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Schedule TLVs Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC8934" format="default" sectionFormat="of" derivedContent="RFC8934"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">FLOWSPEC Object Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9168" format="default" sectionFormat="of" derivedContent="RFC9168"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Bidirectional LSP Association Group TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9059" format="default" sectionFormat="of" derivedContent="RFC9059"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">PCECC-CAPABILITY sub-TLV</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9050" format="default" sectionFormat="of" derivedContent="RFC9050"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">CCI Object Flag Field for MPLS Label</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9050" format="default" sectionFormat="of" derivedContent="RFC9050"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">TE-PATH-BINDING TLV BT Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9604" format="default" sectionFormat="of" derivedContent="RFC9604"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">TE-PATH-BINDING TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9604" format="default" sectionFormat="of" derivedContent="RFC9604"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">LSP-EXTENDED-FLAG TLV Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9357" format="default" sectionFormat="of" derivedContent="RFC9357"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">LSP Exclusion Subobject Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9504" format="default" sectionFormat="of" derivedContent="RFC9504"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SRv6-ERO Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9603" format="default" sectionFormat="of" derivedContent="RFC9603"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">SRv6 Capability Flag Field</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="RFC9603" format="default" sectionFormat="of" derivedContent="RFC9603"/></td>
            <td align="left" colspan="1" rowspan="1"/>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-2-3">Future registries in the "Path Computation Element Protocol (PCEP) Numbers" registry group should prefer to use IETF Review over Standards Action.</t>
    </section>
    <section anchor="experimental-error-types" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-experimental-error-types">Experimental Error-Types</name>
      <t indent="0" pn="section-3-1">Per this document, IANA has designated four PCEP Error-Type codepoints (252-255) for Experimental Use.</t>
      <t indent="0" pn="section-3-2">IANA maintains the "PCEP-ERROR Object Error Types and Values" registry under the "Path Computation Element Protocol (PCEP) Numbers" registry group.  IANA has changed the assignment policy for the "PCEP-ERROR Object Error Types and Values" registry as follows:</t>
      <table align="center" pn="table-2">
        <name slugifiedName="name-pcep-error-object-error-typ">PCEP-ERROR Object Error Types and Values Registry 
  Assignment Policy</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Range</th>
            <th align="left" colspan="1" rowspan="1">Registration Procedures</th>
            <th align="left" colspan="1" rowspan="1">Note</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0-251</td>
            <td align="left" colspan="1" rowspan="1">IETF Review</td>
            <td align="left" colspan="1" rowspan="1">The IETF Review procedure applies to all 
      Error-values (0-255) for Error-Types in 
      this range.</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">252-255</td>
            <td align="left" colspan="1" rowspan="1">Experimental Use</td>
            <td align="left" colspan="1" rowspan="1">The Experimental Use policy applies to all 
      Error-values (0-255) for Error-Types in 
      this range.</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-3-4">Furthermore, IANA has added the following entry to the registry:</t>
      <table align="center" pn="table-3">
        <name slugifiedName="name-pcep-error-object-error-type">PCEP-ERROR Object Error Types and Values Registry</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Error-Type</th>
            <th align="left" colspan="1" rowspan="1">Meaning</th>
            <th align="left" colspan="1" rowspan="1">Error-value</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">252-255</td>
            <td align="left" colspan="1" rowspan="1">Reserved for Experimental Use</td>
            <td align="left" colspan="1" rowspan="1">0-255: Reserved for Experimental Use</td>
            <td align="left" colspan="1" rowspan="1">RFC 9756</td>
          </tr>
        </tbody>
      </table>
      <section anchor="advice-on-experimentation" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-advice-on-experimentation">Advice on Experimentation</name>
        <t indent="0" pn="section-3.1-1">An experiment that wishes to return experimental error codes should use one of the experimental Error-Type values as defined in this document. The experiment should agree on, between all participating parties, which Error-Type to use and which Error-values to use within that Error-Type. The experiment will describe what the meanings of those Error-Type/Error-value pairs are. Those Error-Types and Error-values should not be recorded in any public (especially any IETF) documentation. Textual or symbolic names for the Error-Types and Error-values may be used to help keep the documentation clear.</t>
        <t indent="0" pn="section-3.1-2">If multiple experiments are taking place at the same time using the same implementations, care must be taken to keep the sets of Error-Types/Error-values distinct.</t>
        <t indent="0" pn="section-3.1-3">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 indent="0" pn="section-3.1-4">If, at some future time, the experiment is declared a success and moved to IETF work targeting publication on the Standards Track, each pair of Error-Types/Error-values will need to be assigned by IANA from the registry. In some cases, this will involve assigning a new Error-Type with its subtended Error-values. In other cases, use may be made of an existing Error-Type with new subtended Error-values being assigned. The resulting change to code in an implementation is as simple as changing the numeric values of the Error-Types and Error-values.</t>
      </section>
      <section anchor="handling-of-unknown-experimentation" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-handling-of-unknown-experim">Handling of Unknown Experimentation</name>
        <t indent="0" pn="section-3.2-1">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" format="default" sectionFormat="of" derivedContent="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 indent="0" pn="section-3.2-2">An implementation that is part of an experiment may receive an experimental Error-Type but not recognize the Error-value. This could happen because of any of the following reasons:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-3">
          <li pn="section-3.2-3.1">
            <t indent="0" pn="section-3.2-3.1.1">a faulty implementation</t>
          </li>
          <li pn="section-3.2-3.2">
            <t indent="0" pn="section-3.2-3.2.1">two implementations not being synchronized with respect to which Error-values to use in the experiment</t>
          </li>
          <li pn="section-3.2-3.3">
            <t indent="0" pn="section-3.2-3.3.1">more than one experiment being run at the same time</t>
          </li>
        </ul>
        <t indent="0" pn="section-3.2-4">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" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">This memo does not change the security considerations for any of the updated RFCs. Refer to <xref target="RFC5440" format="default" sectionFormat="of" derivedContent="RFC5440"/> and <xref target="I-D.ietf-pce-pceps-tls13" format="default" sectionFormat="of" derivedContent="PCEPS-UPDATES"/> for further details of the specific security measures applicable to PCEP.</t>
      <t indent="0" pn="section-5-2"><xref target="RFC3692" format="default" sectionFormat="of" derivedContent="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" format="default" sectionFormat="of" derivedContent="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" pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8231" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8233" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8281" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8356" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8623" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8664" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">This document updates RFC 8408.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8664"/>
          <seriesInfo name="DOI" value="10.17487/RFC8664"/>
        </reference>
        <reference anchor="RFC8685" target="https://www.rfc-editor.org/info/rfc8685" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8697" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8733" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8745" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8779" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8780" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8800" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc8934" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9050" quoteTitle="true" derivedAnchor="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 indent="0">The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.</t>
              <t indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9059" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9168" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9357" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9504" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9603" quoteTitle="true" derivedAnchor="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 indent="0">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 indent="0">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 indent="0">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" target="https://www.rfc-editor.org/info/rfc9604" quoteTitle="true" derivedAnchor="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 indent="0">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>
      </references>
      <references anchor="sec-informative-references" pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-pce-pceps-tls13" target="https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-tls13-04" quoteTitle="true" derivedAnchor="PCEPS-UPDATES">
          <front>
            <title>Updates for PCEPS: TLS Connection Establishment Restrictions</title>
            <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author fullname="Sean Turner" initials="S." surname="Turner">
              <organization showOnFrontPage="true">sn3rd</organization>
            </author>
            <author fullname="Russ Housley" initials="R." surname="Housley">
              <organization showOnFrontPage="true">Vigil Security, LLC</organization>
            </author>
            <date day="9" month="January" year="2024"/>
            <abstract>
              <t indent="0">Section 3.4 of RFC 8253 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 use of TLS 1.3's early data.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-tls13-04"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC3692" target="https://www.rfc-editor.org/info/rfc3692" quoteTitle="true" derivedAnchor="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 indent="0">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" target="https://www.rfc-editor.org/info/rfc6709" quoteTitle="true" derivedAnchor="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 indent="0">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>
      </references>
    </references>
    <section anchor="rationale-for-updating-all-registries-with-standards-action" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-rationale-for-updating-all-">Rationale for Updating All Registries with Standards Action</name>
      <t indent="0" pn="section-appendix.a-1">This specification updates all the mentioned registries with the Standards Action policy. The PCE WG considered keeping Standards Action for some registries, such as flag fields with limited bits where the space is tight, but decided against it. The Working Group Last Call and IETF Last Call processes should be enough to handle the case of frivolous experiments taking over the few codepoints. The working group could also create a new protocol field and registry for future use as done in the past (see <xref target="RFC9357" format="default" sectionFormat="of" derivedContent="RFC9357"/>).</t>
    </section>
    <section anchor="consideration-of-rfc-8356" numbered="true" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-consideration-of-rfc-8356">Consideration of RFC 8356</name>
      <t indent="0" pn="section-appendix.b-1">It is worth noting that <xref target="RFC8356" format="default" sectionFormat="of" derivedContent="RFC8356"/> deliberately chose to make experimental codepoints available only in the PCEP messages, objects, and TLV type registries. <xref section="A" sectionFormat="of" target="RFC8356" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8356#appendix-A" derivedContent="RFC8356"/> gives a brief explanation of why that decision was taken, stating that:</t>
      <blockquote pn="section-appendix.b-2">
        <t indent="0" pn="section-appendix.b-2.1">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 indent="0" pn="section-appendix.b-3">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>
    <section anchor="acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.c-1">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" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Haomian Zheng">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <email>zhenghaomian@huawei.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.e">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <postal>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </author>
      <author initials="A." surname="Farrel" fullname="Adrian Farrel">
        <organization showOnFrontPage="true">Old Dog Consulting</organization>
        <address>
          <email>adrian@olddog.co.uk</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
