rfc9756.original.xml   rfc9756.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.20 (Ruby 3.3. -ietf-pce-iana-update-03" number="9756" category="std" consensus="true" submissi
3) --> onType="IETF" updates="5440, 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733, 874
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft 5, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, 9604" obsoletes="
-ietf-pce-iana-update-03" category="std" consensus="true" submissionType="IETF" " tocInclude="true" sortRefs="true" symRefs="true" version="3" xml:lang="en">
updates="5440, 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8745, 8733, 8779, 8780,
8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, 9604" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.24.0 -->
<front> <front>
<title abbrev="PCEP-IANA">Update to the IANA PCE Communication Protocol (PCE
P) Registration Procedures and Allowing Experimental Error Codes</title> <!--[rfced] Title
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-iana-update-03"/>
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
-->
<title abbrev="PCEP IANA Update">Update to the IANA PCE Communication Protoc
ol
(PCEP) Registration Procedures and Allowing Experimental Error
Codes</title>
<seriesInfo name="RFC" value="9756"/>
<author initials="D." surname="Dhody" fullname="Dhruv Dhody"> <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<country>IN</country> <country>India</country>
</postal> </postal>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Farrel" fullname="Adrian Farrel"> <author initials="A." surname="Farrel" fullname="Adrian Farrel">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<date/> <date month="February" year="2025"/>
<area>Routing</area> <area>RTG</area>
<workgroup>Path Computation Element</workgroup> <workgroup>pce</workgroup>
<abstract>
<?line 59?>
<t>This document updates the registration procedure within the IANA "Path Comput <!-- [rfced] Please insert any keywords (beyond those that appear in
ation Element Protocol (PCEP) Numbers" group of registries. This specification c the title) for use on https://www.rfc-editor.org/search. -->
hanges some of the registries with Standards Action to IETF Review as defined in
RFC 8126. This memo updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 873 <abstract>
3, 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604 fo <t>This document updates the registration procedure within the IANA "Path
r the same.</t> Computation Element Protocol (PCEP) Numbers" registry group. This specification
<t>Designating "experimental use" sub-ranges within code point registries changes some of the registries with Standards Action to IETF Review as defined i
is often beneficial for protocol experimentation in controlled environments. Alt n RFC 8126 and thus updates RFCs 8231, 8233, 8281, 8623, 8664, 8685, 8697, 8733,
hough the registries for PCEP messages, objects, and TLV types have sub-ranges a 8745, 8779, 8780, 8800, 8934, 9050, 9059, 9168, 9357, 9504, 9603, and 9604.</t>
ssigned for Experimental Use, the registry for PCEP Error-Types and Error-values <t>Designating "experimental use" sub-ranges within codepoint registries i
currently does not. This document updates RFC 5440 by designating a specific ra s often beneficial for protocol experimentation in controlled environments. Alth
nge of PCEP Error-Types for Experimental Use.</t> ough the registries for PCEP messages, objects, and TLV types have sub-ranges as
signed for Experimental Use, the registry for PCEP Error-Types and Error-values
currently does not. This document updates RFC 5440 by designating a specific ran
ge of PCEP Error-Types for Experimental Use.</t>
</abstract> </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> </front>
<middle> <middle>
<?line 66?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The IANA "Path Computation Element Protocol (PCEP) Numbers" registry gr <t>The IANA "Path Computation Element Protocol (PCEP) Numbers" registry gr
oup was populated by several RFCs produced by the Path Computation Element (PCE) oup was populated by several RFCs produced by the Path Computation Element (PCE)
working group. Most of the registries include the "IETF Review" <xref target="R Working Group. Most of the registries include IETF Review <xref target="RFC8126
FC8126"/> as registration procedures. There are a few registries that use "Stand "/> as the registration procedure. There are a few registries that use Standards
ards Action". Thus, the values in those registries can be assigned only through Action. Thus, the values in those registries can be assigned only through the S
the Standards Track or Best Current Practice RFCs in the IETF Stream. This memo tandards Track or Best Current Practice RFCs in the IETF Stream. This memo chang
changes the policy from Standards Action to IETF Review to allow any type of RFC es the policy from Standards Action to IETF Review to allow any type of RFC unde
under the IETF stream to make the allocation request.</t> r the IETF Stream to make the allocation request.</t>
<t>Further, in Section 9 of <xref target="RFC5440"/>, IANA assigns values <t>Further, in <xref section="9" sectionFormat="of" target="RFC5440"/>, IA
to the PCEP parameters. The allocation policy for each of these parameters spec NA assigns values to the PCEP parameters. The allocation policy for each of the
ified in RFC 5440 is IETF Review <xref target="RFC8126"/>. In consideration of t se parameters specified in <xref target="RFC5440"/> is IETF Review <xref target=
he benefits of conducting experiments with PCEP and the utility of experimental "RFC8126"/>. In consideration of the benefits of conducting experiments with PCE
codepoints <xref target="RFC3692"/>, codepoint ranges for PCEP messages, objects P and the utility of experimental codepoints <xref target="RFC3692"/>, codepoint
, and TLV types for Experimental Use <xref target="RFC8126"/> are designated in ranges for PCEP messages, objects, and TLV types for Experimental Use <xref tar
<xref target="RFC8356"/>. However, protocol experiments may also need to return get="RFC8126"/> are designated in <xref target="RFC8356"/>. However, protocol ex
protocol error messages indicating experiment-specific error cases. It will oft periments may also need to return protocol error messages indicating experiment-
en be the case that previously assigned error codes (in the PCEP-ERROR Object Er specific error cases.
ror Types and Values sub-registry) can be used to indicate the error cases withi
n an experiment, but there may also be cases where new, experimental error codes <!--[rfced] To avoid repetition of "case", may we update this
are needed. In order to run experiments, it is important that the codepoint val sentence as follows?
ues used in the experiments do not collide with existing codepoints or any futur
e allocations. This document updates <xref target="RFC5440"/> by changing the al Original:
location policy for the registry of PCEP Error-Types to mark some of the codepoi It will often be the case that previously assigned
nts as assigned for Experimental Use. As stated in <xref target="RFC3692"/>, ex error codes (in the PCEP-ERROR Object Error Types and Values sub-
periments using these codepoints are not intended to be used in general deployme registry) can be used to indicate the error cases within an
nts, and due care must be taken to ensure that two experiments using the same co experiment, but there may also be cases where new, experimental error
depoints are not run in the same environment.</t> 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 "PC
EP-ERROR Object Error Types and Values" registry) can be used to indicate the er
ror cases within an experiment, but there may also be cases where new, experimen
tal error codes are needed. In order to run experiments, it is important that th
e codepoint values used in the experiments do not collide with existing codepoin
ts 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 g
eneral deployments, and due care must be taken to ensure that two experiments us
ing the same codepoints are not run in the same environment.</t>
</section> </section>
<section anchor="standards-action-pcep-registries-affected"> <section anchor="standards-action-pcep-registries-affected">
<name>Standards Action PCEP Registries Affected</name> <name>Standards Action PCEP Registries Affected</name>
<t>The following table lists the "Path Computation Element Protocol (PCEP) Numbers" registries whose registration policy will be changed from Standards Ac tion to IETF Review. Affected registries will list this document as a reference. Where this change is applied to a specific range of values within the particula r registry, that range is given in the Remarks column.</t> <t>The following table lists the registries under the "Path Computation El ement Protocol (PCEP) Numbers" registry group whose registration policies will b e changed from Standards Action to IETF Review. The affected registries will lis t this document as an additional reference. Where this change is applied to a sp ecific range of values within the particular registry, that range is given in th e Remarks column.</t>
<table> <table>
<name>PCEP Registries Affected</name> <name>PCEP Registries Affected</name>
<thead> <thead>
<tr> <tr>
<th align="left">Registry</th> <th>Registry</th>
<th align="center">RFC</th> <th>RFC</th>
<th align="right">Remarks</th> <th>Remarks</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">BU Object Type Field</td> <td>BU Object Type Field</td>
<td align="center"> <td><xref target="RFC8233"/></td>
<xref target="RFC8233"/></td> <td></td>
<td align="right"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">LSP Object Flag Field</td> <td>LSP Object Flag Field</td>
<td align="center"> <td>
<xref target="RFC8231"/></td> <xref target="RFC8231"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">STATEFUL-PCE-CAPABILITY TLV Flag Field</td> <td>STATEFUL-PCE-CAPABILITY TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8231"/></td> <xref target="RFC8231"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">LSP-ERROR-CODE TLV Error Code Field</td> <td>LSP-ERROR-CODE TLV Error Code Field</td>
<td align="center"> <td>
<xref target="RFC8231"/></td> <xref target="RFC8231"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SRP Object Flag Field</td> <td>SRP Object Flag Field</td>
<td align="center"> <td>
<xref target="RFC8281"/></td> <xref target="RFC8281"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SR-ERO Flag Field</td> <td>SR-ERO Flag Field</td>
<td align="center"> <td>
<xref target="RFC8664"/></td> <xref target="RFC8664"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators< <td>PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</td>
/td> <td>
<td align="center">
<xref target="RFC8664"/></td> <xref target="RFC8664"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SR Capability Flag Field</td> <td>SR Capability Flag Field</td>
<td align="center"> <td>
<xref target="RFC8664"/></td> <xref target="RFC8664"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">WA Object Flag Field</td> <td>WA Object Flag Field</td>
<td align="center"> <td>
<xref target="RFC8780"/></td> <xref target="RFC8780"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Wavelength Restriction TLV Action Values</td> <td>Wavelength Restriction TLV Action Values</td>
<td align="center"> <td>
<xref target="RFC8780"/></td> <xref target="RFC8780"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Wavelength Allocation TLV Flag Field</td> <td>Wavelength Allocation TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8780"/></td> <xref target="RFC8780"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">S2LS Object Flag Field</td> <td>S2LS Object Flag Field</td>
<td align="center"> <td>
<xref target="RFC8623"/></td> <xref target="RFC8623"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">H-PCE-CAPABILITY TLV Flag Field</td> <td>H-PCE-CAPABILITY TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8685"/></td> <xref target="RFC8685"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">H-PCE-FLAG TLV Flag Field</td> <td>H-PCE-FLAG TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8685"/></td> <xref target="RFC8685"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">ASSOCIATION Flag Field</td> <td>ASSOCIATION Flag Field</td>
<td align="center"> <td>
<xref target="RFC8697"/></td> <xref target="RFC8697"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">ASSOCIATION Type Field</td> <td>ASSOCIATION Type Field</td>
<td align="center"> <td>
<xref target="RFC8697"/></td> <xref target="RFC8697"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">AUTO-BANDWIDTH-CAPABILITY TLV Flag Field</td> <td>AUTO-BANDWIDTH-CAPABILITY TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8733"/></td> <xref target="RFC8733"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Path Protection Association Group TLV Flag Field</t <td>Path Protection Association Group TLV Flag Field</td>
d> <td>
<td align="center">
<xref target="RFC8745"/></td> <xref target="RFC8745"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Generalized Endpoint Types</td> <td>Generalized Endpoint Types</td>
<td align="center"> <td>
<xref target="RFC8779"/></td> <xref target="RFC8779"/></td>
<td align="right">0-244</td> <td>0-244</td>
</tr> </tr>
<tr> <tr>
<td align="left">GMPLS-CAPABILITY TLV Flag Field</td> <td>GMPLS-CAPABILITY TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8779"/></td> <xref target="RFC8779"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">DISJOINTNESS-CONFIGURATION TLV Flag Field</td> <td>DISJOINTNESS-CONFIGURATION TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC8800"/></td> <xref target="RFC8800"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SCHED-PD-LSP-ATTRIBUTE TLV Opt Field</td> <td>SCHED-PD-LSP-ATTRIBUTE TLV Opt Field</td>
<td align="center"> <td>
<xref target="RFC8934"/></td> <xref target="RFC8934"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Schedule TLVs Flag Field</td> <td>Schedule TLVs Flag Field</td>
<td align="center"> <td>
<xref target="RFC8934"/></td> <xref target="RFC8934"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">FLOWSPEC Object Flag Field</td> <td>FLOWSPEC Object Flag Field</td>
<td align="center"> <td>
<xref target="RFC9168"/></td> <xref target="RFC9168"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">Bidirectional LSP Association Group TLV Flag Field< <td>Bidirectional LSP Association Group TLV Flag Field</td>
/td> <td>
<td align="center">
<xref target="RFC9059"/></td> <xref target="RFC9059"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">PCECC-CAPABILITY sub-TLV</td> <td>PCECC-CAPABILITY sub-TLV</td>
<td align="center"> <td>
<xref target="RFC9050"/></td> <xref target="RFC9050"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">CCI Object Flag Field for MPLS Label</td> <td>CCI Object Flag Field for MPLS Label</td>
<td align="center"> <td>
<xref target="RFC9050"/></td> <xref target="RFC9050"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">TE-PATH-BINDING TLV BT Field</td> <td>TE-PATH-BINDING TLV BT Field</td>
<td align="center"> <td>
<xref target="RFC9050"/></td> <xref target="RFC9604"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">TE-PATH-BINDING TLV Flag Field</td> <td>TE-PATH-BINDING TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC9604"/></td> <xref target="RFC9604"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">LSP-EXTENDED-FLAG TLV Flag Field</td> <td>LSP-EXTENDED-FLAG TLV Flag Field</td>
<td align="center"> <td>
<xref target="RFC9357"/></td> <xref target="RFC9357"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">LSP Exclusion Subobject Flag Field</td> <td>LSP Exclusion Subobject Flag Field</td>
<td align="center"> <td>
<xref target="RFC9504"/></td> <xref target="RFC9504"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SRv6-ERO Flag Field</td> <td>SRv6-ERO Flag Field</td>
<td align="center"> <td>
<xref target="RFC9603"/></td> <xref target="RFC9603"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
<tr> <tr>
<td align="left">SRv6 Capability Flag Field</td> <td>SRv6 Capability Flag Field</td>
<td align="center"> <td>
<xref target="RFC9603"/></td> <xref target="RFC9603"/></td>
<td align="right"> </td> <td></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Future registries in the "Path Computation Element Protocol (PCEP) Numb ers" registry group should prefer to use "IETF Review" over "Standards Action".< /t> <t>Future registries in the "Path Computation Element Protocol (PCEP) Numb ers" registry group should prefer to use IETF Review over Standards Action.</t>
</section> </section>
<section anchor="experimental-error-types"> <section anchor="experimental-error-types">
<name>Experimental Error-Types</name> <name>Experimental Error-Types</name>
<t>This document requests IANA for the designation of four PCEP Error-Type <t>Per this document, IANA has designated four PCEP Error-Type codepoints
codepoints (252-255) for Experimental Use.</t> (252-255) for Experimental Use.</t>
<t>IANA maintains a registry group called "Path Computation Element Protoc <t>IANA maintains the "PCEP-ERROR Object Error Types and Values" registry
ol (PCEP) Numbers" with a registry named "PCEP-ERROR Object Error Types and Valu under the "Path Computation Element Protocol (PCEP) Numbers" registry group. IA
es". IANA is requested to change the assignment policy for this registry to rea NA has changed the assignment policy for the "PCEP-ERROR Object Error Types and
d:</t> 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 to
read:
Error-Types
0-251 : IETF Review
252-255 : Experimental Use
Error-value
For all IETF Review Error-Types : IETF Review
For all Experimental Use Error-Types : Experimental 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"> <ul spacing="normal">
<li> <li><t>Error-Types:</t>
<t>Error-Types <dl spacing="normal" newline="false">
</t> <dt>0-251:</dt><dd>IETF Review</dd>
<ul spacing="normal"> <dt>252-255:</dt><dd>Experimental Use</dd>
<li> </dl>
<t>0-251 : IETF Review</t> </li>
</li> <li><t>Error-values:</t>
<li> <dl spacing="normal" newline="false">
<t>252-255 : Experimental Use</t> <dt>For all IETF Review Error-Types:</dt><dd>IETF Review</dd>
</li> <dt>For all Experimental Use Error-Types:</dt><dd>Experimental Use</
</ul> dd>
</li> </dl>
<li> </li>
<t>Error-value
</t>
<ul spacing="normal">
<li>
<t>For all IETF Review Error-Types : IETF Review</t>
</li>
<li>
<t>For all Experimental Use Error-Types : Experimental Use</t>
</li>
</ul>
</li>
</ul> </ul>
<t>Additionally, IANA is requested to make an entry in the table as follow <t>Furthermore, IANA has listed this document as an additional reference f
s:</t> or the registry and has added the following entry to the registry:</t>
<table>
<table align="center">
<name>PCEP-ERROR Object Error Types and Values Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Error-Type</th> <th>Error-Type</th>
<th align="center">Meaning</th> <th>Meaning</th>
<th align="center">Error-value</th> <th>Error-value</th>
<th align="right">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">252-255</td> <td>252-255</td>
<td align="center">Experimental Use</td> <td>Reserved for Experimental Use</td>
<td align="center">0-255 Experimental Use</td> <td>0-255: Reserved for Experimental Use</td>
<td align="right">This I-D</td> <td>RFC 9756</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<section anchor="advice-on-experimentation"> <section anchor="advice-on-experimentation">
<name>Advice on Experimentation</name> <name>Advice on Experimentation</name>
<t>An experiment that wishes to return experimental error codes should u <t>An experiment that wishes to return experimental error codes should u
se one of the experimental Error-Type values as defined in this document. The ex se one of the experimental Error-Type values as defined in this document. The ex
periment should agree, between all participating parties, on which Error-Type to periment 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 d use and which Error-values to use within that Error-Type. The experiment will d
escribe what the meanings of those Error-Type / Error-value pairs are. Those Err escribe what the meanings of those Error-Type/Error-value pairs are. Those Error
or-Type and Error-values should not be recorded in any public (especially any IE -Types and Error-values should not be recorded in any public (especially any IET
TF) documentation. Textual or symbolic names for the Error-Types and Error-value F) documentation. Textual or symbolic names for the Error-Types and Error-values
s may be used to help keep the documentation clear.</t> may be used to help keep the documentation clear.</t>
<t>If multiple experiments are taking place at the same time using the s <t>If multiple experiments are taking place at the same time using the s
ame implementations, care must be taken to keep the sets of Error-Type / Error-v ame implementations, care must be taken to keep the sets of Error-Types/Error-va
alue distinct.</t> lues distinct.</t>
<t>Note that there is no scope for experimental Error-values within exis ting non-experimental Error-Types. This reduces the complexity of the registry a nd implementations. Experiments should place all experimental Error-values under the chosen experimental Error-Types.</t> <t>Note that there is no scope for experimental Error-values within exis ting non-experimental Error-Types. This reduces the complexity of the registry a nd 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 mov ed to IETF work targeting publication on the Standards Track, each pair of Error -Type / Error-value will need to be assigned by IANA from the registry. In some cases, this will involve assigning a new Error-Type with its subtended Error-val ues. In other cases, use may be made of an existing Error-Type with new subtende d 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> <t>If, at some future time, the experiment is declared a success and mov ed 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-val ues. In other cases, use may be made of an existing Error-Type with new subtende d 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>
<section anchor="handling-of-unknown-experimentation"> <section anchor="handling-of-unknown-experimentation">
<name>Handling of Unknown Experimentation</name> <name>Handling of Unknown Experimentation</name>
<t>A PCEP implementation that receives an experimental Error-Type in a P CEP message and does not recognize the Error-Type (i.e., is not part of the expe riment) will treat the error as it would treat any other unknown Error-Type (suc h as from a new protocol extension). An implementation that is notified of a PCE P 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>A PCEP implementation that receives an experimental Error-Type in a P CEP message and does not recognize the Error-Type (i.e., is not part of the expe riment) will treat the error as it would treat any other unknown Error-Type (suc h as from a new protocol extension). An implementation that is notified of a PCE P 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 experi mental Error-Type, but not recognize the Error-value. This could happen because of any of:</t> <t>An implementation that is part of an experiment may receive an experi mental Error-Type but not recognize the Error-value. This could happen because o f any of the following reasons:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A faulty implementation.</t> <t>a faulty implementation</t>
</li> </li>
<li> <li>
<t>Two implementations not being synchronized with respect to which Error-values to use in the experiment.</t> <t>two implementations not being synchronized with respect to which Error-values to use in the experiment</t>
</li> </li>
<li> <li>
<t>More than one experiment being run at the same time.</t> <t>more than one experiment being run at the same time</t>
</li> </li>
</ul> </ul>
<t>As with unknown Error-Types, an implementation receiving an unknown E rror-value is not expected to do more than log the received error and may close the PCEP session.</t> <t>As with unknown Error-Types, an implementation receiving an unknown E rror-value is not expected to do more than log the received error and may close the PCEP session.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers" registry.</t> <t>This memo is entirely about updating the IANA "Path Computation Element Protocol (PCEP) Numbers" registry group.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This memo does not change the Security Considerations for any of the up dated RFCs. Refer to <xref target="RFC5440"/> and <xref target="I-D.ietf-pce-pce ps-tls13"/> for further details of the specific security measures applicable to PCEP.</t> <t>This memo does not change the security considerations for any of the up dated RFCs. Refer to <xref target="RFC5440"/> and <xref target="I-D.ietf-pce-pce ps-tls13"/> for further details of the specific security measures applicable to PCEP.</t>
<t><xref target="RFC3692"/> asserts that the existence of experimental cod epoints introduces no new security considerations. However, implementations acce pting experimental error codepoints need to consider how they parse and process them in case they come, accidentally, from another experiment. Further, an imple mentation accepting experimental codepoints needs to consider the security aspec ts of the experimental extensions. <xref target="RFC6709"/> provides various des ign considerations for protocol extensions (including those designated as experi mental).</t> <t><xref target="RFC3692"/> asserts that the existence of experimental cod epoints introduces no new security considerations. However, implementations acce pting experimental error codepoints need to consider how they parse and process them in case they come, accidentally, from another experiment. Further, an imple mentation accepting experimental codepoints needs to consider the security aspec ts of the experimental extensions. <xref target="RFC6709"/> provides various des ign considerations for protocol extensions (including those designated as experi mental).</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-pce-pceps-tls13" to="PCEPS-UPDATES"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC5440"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<front> 440.xml"/>
<title>Path Computation Element (PCE) Communication Protocol (PCEP)< <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
/title> 126.xml"/>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
"Vasseur"/> 231.xml"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname= <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
"Le Roux"/> 233.xml"/>
<date month="March" year="2009"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 281.xml"/>
<t>This document specifies the Path Computation Element (PCE) Comm <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
unication Protocol (PCEP) for communications between a Path Computation Client ( 356.xml"/>
PCC) and a PCE, or between two PCEs. Such interactions include path computation <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
requests and path computation replies as well as notifications of specific state 623.xml"/>
s related to the use of a PCE in the context of Multiprotocol Label Switching (M <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
PLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be fl 664.xml"/>
exible and extensible so as to easily allow for the addition of further messages <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
and objects, should further requirements be expressed in the future. [STANDARDS 685.xml"/>
-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 697.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="RFC" value="5440"/> 733.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC5440"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</reference> 745.xml"/>
<reference anchor="RFC8126"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 779.xml"/>
<title>Guidelines for Writing an IANA Considerations Section in RFCs <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</title> 780.xml"/>
<author fullname="M. Cotton" initials="M." surname="Cotton"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="B. Leiba" initials="B." surname="Leiba"/> 800.xml"/>
<author fullname="T. Narten" initials="T." surname="Narten"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="June" year="2017"/> 934.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>Many protocols make use of points of extensibility that use con 050.xml"/>
stants to identify various protocol parameters. To ensure that the values in the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
se fields do not have conflicting uses and to promote interoperability, their al 059.xml"/>
locations are often coordinated by a central record keeper. For IETF protocols, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
that role is filled by the Internet Assigned Numbers Authority (IANA).</t> 168.xml"/>
<t>To make assignments in a given registry prudently, guidance des <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
cribing the conditions under which new values should be assigned, as well as whe 357.xml"/>
n and how modifications to existing values can be made, is needed. This document <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
defines a framework for the documentation of these guidelines by specification 504.xml"/>
authors, in order to assure that the provided guidance for the IANA Consideratio <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ns is clear and addresses the various issues that are likely in the operation of 603.xml"/>
a registry.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This is the third edition of this document; it obsoletes RFC 52 604.xml"/>
26.</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) Extens
ions 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) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>Although PCEP explicitly makes no assumptions regarding the inf
ormation available to the PCE, it also makes no provisions for PCE control of ti
ming and sequence of path computations within and across PCEP sessions. This doc
ument describes a set of extensions to PCEP to enable stateful control of MPLS-T
E 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 Prot
ocol (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 inf
ormation networks (e.g., stock market data providers), network performance crite
ria (e.g., latency) are becoming as critical to data path selection as other met
rics and constraints. These metrics are associated with the Service Level Agreem
ent (SLA) between customers and service providers. The link bandwidth utilizatio
n (the total bandwidth of a link in actual use for the forwarding) is another im
portant factor to consider during path computation.</t>
<t>IGP Traffic Engineering (TE) Metric Extensions describe mechani
sms with which network performance information is distributed via OSPF and IS-IS
, respectively. The Path Computation Element Communication Protocol (PCEP) provi
des 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 b
andwidth 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) Extens
ions 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) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>The extensions for stateful PCE provide active control of Multi
protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP
s) via PCEP, for a model where the PCC delegates control over one or more locall
y 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 El
ement 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 Communicati
on 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 a
llocation policy for each of these sub-registries is IETF Review.</t>
<t>This document updates RFC 5440 by changing the allocation polic
ies for these three registries to mark some of the codepoints as assigned for Ex
perimental 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 f
or 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 ap
propriate technology for the determination of the paths of point- to-multipoint
(P2MP) TE Label Switched Paths (LSPs). This document provides extensions require
d 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) Extens
ions 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 pa
th without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). I
t 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, includ
ing an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Comput
ation Element (PCE). This document specifies extensions to the Path Computation
Element Communication Protocol (PCEP) that allow a stateful PCE to compute and i
nitiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PC
C) 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) Extens
ions 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="Gonzal
ez 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 Elemen
t 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) Extens
ions 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="Anantha
krishnan"/>
<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 groupi
ng 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 paramet
ers 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) Extens
ions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Statef
ul PCE</title>
<author fullname="D. Dhody" initials="D." role="editor" surname="Dho
dy"/>
<author fullname="R. Gandhi" initials="R." role="editor" surname="Ga
ndhi"/>
<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) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s 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 adjustm
ent of the TE LSP bandwidth reservation based on the volume of traffic flowing t
hrough the LSP. This document describes PCEP extensions for auto-bandwidth adjus
tment when employing an active stateful PCE for both PCE-initiated and PCC-initi
ated 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) Extens
ions for Associating Working and Protection Label Switched Paths (LSPs) with Sta
teful PCE</title>
<author fullname="H. Ananthakrishnan" initials="H." surname="Anantha
krishnan"/>
<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 Pro
tocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label S
witched Paths (LSPs). Furthermore, it is also possible for an active stateful PC
E 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) Extens
ions for GMPLS</title>
<author fullname="C. Margaria" initials="C." role="editor" surname="
Margaria"/>
<author fullname="O. Gonzalez de Dios" initials="O." role="editor" s
urname="Gonzalez de Dios"/>
<author fullname="F. Zhang" initials="F." role="editor" surname="Zha
ng"/>
<date month="July" year="2020"/>
<abstract>
<t>A Path Computation Element (PCE) provides path computation func
tions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) netw
orks. Additional requirements for GMPLS are identified in RFC 7025.</t>
<t>This memo provides extensions to the Path Computation Element C
ommunication Protocol (PCEP) for the support of the GMPLS control plane to addre
ss 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) Ex
tension for Wavelength Switched Optical Network (WSON) Routing and Wavelength As
signment (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 P
rotocol (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 assign
ment 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) Extens
ion 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 grou
p of Label Switched Paths (LSPs) via an extension to the Path Computation Elemen
t Communication Protocol (PCEP) with the purpose of computing diverse (disjointe
d) 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 be
longs to a particular Disjoint Association Group; thus, the PCE knows that the L
SPs 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 Switch
ed 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="Zh
uang"/>
<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 C
ommunication Protocol (PCEP) to enable Label Switched Path (LSP) path computatio
n, 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) Proced
ures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs</t
itle>
<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 Softw
are-Defined Networking (SDN) systems.</t>
<t>A PCE as a Central Controller (PCECC) can simplify the processi
ng of a distributed control plane by blending it with elements of SDN and withou
t necessarily completely replacing it. Thus, the Label Switched Path (LSP) can b
e calculated/set up/initiated and the label-forwarding entries can also be downl
oaded through a centralized PCE server to each network device along the path whi
le leveraging the existing PCE technologies as much as possible.</t>
<t>This document specifies the procedures and Path Computation Ele
ment Communication Protocol (PCEP) extensions for using the PCE as the central c
ontroller 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) Extens
ions for Associated Bidirectional Label Switched Paths (LSPs)</title>
<author fullname="R. Gandhi" initials="R." role="editor" surname="Ga
ndhi"/>
<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 Pr
otocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched
Paths (LSPs), one in each direction in the network, into an associated bidirecti
onal LSP. These PCEP extensions can be applied either using a stateful PCE for b
oth PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP proc
edures 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) Extens
ion 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 ca
pable of selecting paths through a traffic engineering (TE) network. These paths
may be supplied in response to requests for computation or may be unsolicited r
equests issued by the PCE to network elements. Both approaches use the PCE Commu
nication Protocol (PCEP) to convey the details of the computed path.</t>
<t>Traffic flows may be categorized and described using "Flow Spec
ifications". RFC 8955 defines the Flow Specification and describes how Flow Spec
ification components are used to describe traffic flows. RFC 8955 also defines h
ow 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, u
pdate, and withdrawal of Flow Specifications via PCEP and can be applied to tunn
els 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 obj
ect, 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 o
bject 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) Extens
ions 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="Gonzal
ez 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 ext
ensions do not cover all requirements for GMPLS networks.</t>
<t>This document provides the extensions required for PCEP so as t
o 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) Extens
ions 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 net
work 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, includi
ng an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computatio
n Element (PCE).</t>
<t>Since SR can be applied to both MPLS and IPv6 data planes, a PC
E should be able to compute an SR Path for both MPLS and IPv6 data planes. The P
ath Computation Element Communication Protocol (PCEP) extension and mechanisms t
o support SR-MPLS have been defined. This document outlines the necessary extens
ions 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 confidentialit
y, and service independence, Segment Routing (SR) utilizes a Binding Segment Ide
ntifier (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 P
rotocol (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>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3692"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 692.xml"/>
<title>Assigning Experimental and Testing Numbers Considered Useful< <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
/title> 709.xml"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="January" year="2004"/>
<abstract>
<t>When experimenting with or extending protocols, it is often nec
essary 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 experi
mentation purposes that implementers can use when testing protocol extensions or
other new features. This document reserves some ranges of numbers for experimen
tation 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="Abo
ba"/>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<date month="September" year="2012"/>
<abstract>
<t>This document discusses architectural issues related to the ext
ensibility of Internet protocols, with a focus on design considerations. It is i
ntended to assist designers of both base protocols and extensions. Case studies
are included. A companion document, RFC 4775 (BCP 125), discusses procedures rel
ating to the extensibility of IETF protocols. This document is not an Internet S
tandards 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 RFC 8253 specifies TLS connection establishme
nt
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> <!-- [I-D.ietf-pce-pceps-tls13] IESG State: RFC Ed Queue (MISSREF*R) as of 02/26
</abstract> /25 -->
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pceps-tls13-04 ietf-pce-pceps-tls13.xml"/>
"/>
</reference>
</references> </references>
</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, a
nd 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 f
or ArtArt review. Thanks to Alexey Melnikov for SECDIR review.</t>
</section>
<section anchor="rationale-for-updating-all-registries-with-standards-action "> <section anchor="rationale-for-updating-all-registries-with-standards-action ">
<name>Rationale for updating all registries with Standards Action</name> <name>Rationale for Updating All Registries with Standards Action</name>
<t>This specification updates all the registries with the "Standards Actio <t>This specification updates all the registries with the Standards Action
n" policy. WG considered keeping "Standards Action" for some registries such as policy. The PCE WG considered keeping Standards Action for some registries, suc
flag fields with limited bits, where the space is tight but decided against it. h as flag fields with limited bits where the space is tight, but decided against
The WG's last call and IETF's last call process should be enough to handle the c it. The Working Group Last Call and IETF Last Call processes should be enough t
ase of frivolous experiments taking over the few code points. The working group o handle the case of frivolous experiments taking over the few codepoints. The w
could also create a new protocol field and registry for future use as done in th orking group could also create a new protocol field and registry for future use
e past (see <xref target="RFC9357"/>).</t> as done in the past (see <xref target="RFC9357"/>).</t>
</section> </section>
<section anchor="consideration-of-rfc-8356"> <section anchor="consideration-of-rfc-8356">
<name>Consideration of RFC 8356</name> <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 T LV type registries. Appendix A of that document gives a brief explanation of wh y that decision was taken stating that:</t> <t>It is worth noting that <xref target="RFC8356"/> deliberately chose to make experimental codepoints available only in the PCEP messages, objects, and T LV type registries. <xref section="A" sectionFormat="of" target="RFC8356"/> give s a brief explanation of why that decision was taken, stating that:</t>
<blockquote> <blockquote>
<t>The justification for this decision is that, if an <t>The justification for this decision is that, if an
experiment finds that it wants to use a new codepoint in another PCEP experiment finds that it wants to use a new codepoint in another PCEP
sub-registry, it can implement the same function using a new sub-registry, it can implement the same function using a new
experimental object or TLV instead.</t> experimental object or TLV instead.</t>
</blockquote> </blockquote>
<t>While it is true that an experimental implementation could assign an ex perimental PCEP object and designate it the "experimental errors object", using it to carry arbitrary contents including experimental error codes, such an appro ach would cause unnecessary divergence in the code. The allowance of experiment al Error-Types is a better approach that will more easily enable the migration o f successful experiments onto the Standards Track.</t> <t>While it is true that an experimental implementation could assign an ex perimental PCEP object and designate it the "experimental errors object", using it to carry arbitrary contents including experimental error codes, such an appro ach would cause unnecessary divergence in the code. The allowance of experiment al Error-Types is a better approach that will more easily enable the migration o f successful experiments onto the Standards Track.</t>
</section> </section>
<section anchor="contributor">
<name>Contributor</name> <section anchor="acknowledgements" numbered="false">
<t>Haomian Zheng <br/> <name>Acknowledgements</name>
Huawei Technologies <br/> <t>Thanks to <contact fullname="John Scudder"/> for the initial discussion
Email: zhenghaomian@huawei.com <br/></t> behind this document. Thanks to <contact fullname="Ketan Talaulikar"/>, <contac
t fullname="Andrew Stone"/>, <contact fullname="Samuel Sidor"/>, <contact fullna
me="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 t
he GENART review. Thanks to <contact fullname="Paul Kyzivat"/> for the ArtArt re
view. 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> </section>
</back> </back>
<!-- ##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] 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"
--> -->
<!-- [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> </rfc>
 End of changes. 101 change blocks. 
1003 lines changed or deleted 405 lines changed or added

This html diff was produced by rfcdiff 1.48.