rfc9603.original.xml   rfc9603.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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
) --> -ietf-pce-segment-routing-ipv6-25" number="9603" updates="" obsoletes="" categor
<?rfc tocompact="yes"?> y="std" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" so
<?rfc tocindent="yes"?> rtRefs="false" symRefs="true" version="3" xml:lang="en">
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes"?>
<?rfc iprnotified="Yes"?>
<?rfc strict="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-pce-segment-routing-ipv6-25" category="std" consensus="true" submissionTyp
e="IETF" tocDepth="4" tocInclude="true" sortRefs="false" symRefs="true" version=
"3">
<!-- xml2rfc v2v3 conversion 3.20.1 -->
<front> <front>
<title abbrev="PCEP-SRv6">Path Computation Element Communication Protocol (P <title abbrev="PCEP SRv6">Path Computation Element Communication Protocol (P
CEP) Extensions for IPv6 Segment Routing</title> CEP) Extensions for IPv6 Segment Routing</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-segment-routing-ipv6 <seriesInfo name="RFC" value="9603"/>
-25"/> <author fullname="李呈" asciiFullname="Cheng Li" role="editor">
<author initials="C." surname="Li" fullname="Cheng Li(Editor)"> <organization ascii="Huawei Technologies">华为技术有限公司</organization>
<organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street ascii="Huawei Campus, No. 156 Beiqing Rd.">华为北研所</street>
<city>Beijing</city> <city ascii="Beijing">北京</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country ascii="China">中国</country>
</postal> </postal>
<email>c.l@huawei.com</email> <email>c.l@huawei.com</email>
</address> </address>
</author> </author>
<author initials="P." surname="Kaladharan" fullname="Prejeeth Kaladharan"> <author initials="P." surname="Kaladharan" fullname="Prejeeth Kaladharan">
<organization>RtBrick Inc</organization> <organization>RtBrick Inc</organization>
<address> <address>
<postal> <postal>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
skipping to change at line 52 skipping to change at line 45
<email>prejeeth@rtbrick.com</email> <email>prejeeth@rtbrick.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Sivabalan" fullname="Siva Sivabalan"> <author initials="S." surname="Sivabalan" fullname="Siva Sivabalan">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<email>msiva282@gmail.com</email> <email>msiva282@gmail.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Koldychev" fullname="Mike Koldychev"> <author initials="M." surname="Koldychev" fullname="Mike Koldychev">
<organization>Cisco Systems, Inc.</organization> <organization>Ciena Corporation</organization>
<address> <address>
<postal> <postal>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>mkoldych@cisco.com</email> <email>mkoldych@ciena.com</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Zhu" fullname="Yongqing Zhu"> <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
<organization>China Telecom</organization> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street>109 West Zhongshan Ave, Tianhe District</street> <street>109 West Zhongshan Ave, Tianhe District</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Guangzhou</region> <region>Guangzhou</region>
<country>P.R. China</country> <country>China</country>
</postal> </postal>
<email>zhuyq8@chinatelecom.cn</email> <email>zhuyq8@chinatelecom.cn</email>
</address> </address>
</author> </author>
<date year="2024" month="April" day="04"/> <date year="2024" month="July"/>
<area>Routing</area> <area>RTG</area>
<workgroup>PCE Working Group</workgroup> <workgroup>pce</workgroup>
<abstract>
<?line 113?>
<t>Segment Routing (SR) can be used to steer packets through a network using the <keyword>PCEP</keyword>
IPv6 or MPLS data plane, employing the source routing paradigm.</t> <keyword>SRv6</keyword>
<t>A Segment Routed Path can be derived from a variety of mechanisms, incl <keyword>IPv6</keyword>
uding an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computa
tion Element(PCE).</t> <abstract>
<t>Since SR can be applied to both MPLS and IPv6 data-planes, a PCE should <t>Segment Routing (SR) can be used to steer packets through a network
be able to compute an SR Path for both MPLS and IPv6 data-planes. The Path Comp using the IPv6 or MPLS data plane, employing the source routing
utation Element communication Protocol (PCEP) extension and mechanisms to suppor paradigm.</t>
t SR-MPLS have been defined. This document outlines the necessary extensions to <t>An SR Path can be derived from a variety of mechanisms,
support SR for the IPv6 data-plane within PCEP.</t> including an IGP Shortest Path Tree (SPT), explicit configuration, or a
Path Computation Element (PCE).</t>
<t>Since SR can be applied to both MPLS and IPv6 data planes, a PCE
should be able to compute an SR Path for both MPLS and IPv6 data
planes. The Path Computation Element Communication Protocol (PCEP)
extension and mechanisms to support SR-MPLS have been defined. This docume
nt outlines the
necessary extensions to support SR for the IPv6 data plane within
PCEP.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 121?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>As defined in <xref target="RFC8402"/>, Segment Routing (SR) architectu <t>As defined in <xref target="RFC8402"/>, Segment Routing (SR) architectu
re allows the source node to steer a packet through a path indicated by an order re allows the source node to steer a packet through a path indicated by an order
ed list of instructions, called segments. A segment can represent any instructio ed list of instructions, called "segments". A segment can represent any instruct
n, topological or service-based, and it can have a semantic local to an SR node ion, topological or service based, and it can have a semantic local to an SR nod
or global within an SR domain.</t> e or global within an SR domain.</t>
<t><xref target="RFC5440"/> describes Path Computation Element communicati <t><xref target="RFC5440"/> describes Path Computation Element Communicati
on Protocol (PCEP) for communication between a Path Computation Client (PCC) and on Protocol (PCEP) for communication between a Path Computation Client (PCC) and
a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE (in a hierar a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE (in a hierar
chical PCE environment) computes paths for MPLS Traffic Engineering LSPs (MPLS-T chical PCE environment) computes paths for MPLS Traffic Engineering Label Switch
E LSPs) based on various constraints and optimization criteria.</t> ed Paths (MPLS-TE LSPs) based on various constraints and optimization criteria.<
<t><xref target="RFC8231"/> specifies extensions to PCEP that allow a stat /t>
eful PCE to compute and recommend network paths in compliance with <xref target= <t><xref target="RFC8231"/> specifies extensions to PCEP that allow a stat
"RFC4657"/> and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensi eful PCE to compute and recommend network paths in compliance with <xref target=
ons provide synchronization of LSP state between a PCC and a PCE or between a pa "RFC4657"/> and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensi
ir of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PC ons provide synchronization of LSP state between a PCC and a PCE or between a pa
E, controlling the setup and path routing of an LSP from a PCE to a PCC. Statefu ir of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PC
l PCEP extensions are intended for an operational model in which LSPs are config E, and controlling the setup and path routing of an LSP from a PCE to a PCC. Sta
ured on the PCC, and control over them is delegated to the PCE.</t> teful PCEP extensions are intended for an operational model in which LSPs are co
nfigured on the PCC, and control over them is delegated to the PCE.</t>
<t>A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in <xref ta rget="RFC8281"/>. As per <xref target="RFC8664"/>, it is possible to use a state ful PCE for computing one or more SR-TE paths taking into account various constr aints and objective functions. Once a path is computed, the stateful PCE can ini tiate an SR-TE path on a PCC using PCEP extensions specified in <xref target="RF C8281"/> and the SR-specific PCEP extensions specified in <xref target="RFC8664" />.</t> <t>A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in <xref ta rget="RFC8281"/>. As per <xref target="RFC8664"/>, it is possible to use a state ful PCE for computing one or more SR-TE paths taking into account various constr aints and objective functions. Once a path is computed, the stateful PCE can ini tiate an SR-TE path on a PCC using PCEP extensions specified in <xref target="RF C8281"/> and the SR-specific PCEP extensions specified in <xref target="RFC8664" />.</t>
<t><xref target="RFC8664"/> specifies PCEP extensions for supporting a SR- TE LSP for the MPLS data-plane. This document extends <xref target="RFC8664"/> t o support SR for the IPv6 data-plane. Additionally, using procedures described i n this document, a PCC can request an SRv6 path from either a stateful or statel ess PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures spe cified in <xref target="RFC8408"/>.</t> <t><xref target="RFC8664"/> specifies PCEP extensions for supporting an SR -TE LSP for the MPLS data plane. This document extends <xref target="RFC8664"/> to support SR for the IPv6 data plane. Additionally, using procedures described in this document, a PCC can request an SRv6 path from either a stateful or state less PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures sp ecified in <xref target="RFC8408"/>.</t>
<t>This specification provides a mechanism for a network controller (actin g as a PCE) to instantiate candidate paths for an SR Policy onto a <t>This specification provides a mechanism for a network controller (actin g as a PCE) to instantiate candidate paths for an SR Policy onto a
head-end node (acting as a PCC) using PCEP. For more information on the SR Polic y Architecture, see <xref target="RFC9256"/> which applies to both SR-MPLS and S Rv6.</t> head-end node (acting as a PCC) using PCEP. For more information on the SR Polic y architecture, see <xref target="RFC9256"/>, which applies to both SR-MPLS and SRv6.</t>
<section anchor="requirements-language"> <section anchor="requirements-language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</section> </t>
</section>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>This document uses the following terms defined in <xref target="RFC5440 "/>: PCC, PCE, PCEP, PCEP Peer.</t> <t>This document uses the following terms defined in <xref target="RFC5440 "/>: PCC, PCE, PCEP, PCEP Peer.</t>
<t>This document uses the following terms defined in <xref target="RFC8051 "/>: Stateful PCE, Delegation.</t> <t>This document uses the following terms defined in <xref target="RFC8051 "/>: Stateful PCE, Delegation.</t>
<t>Further, the following terms are used in the document,</t> <t>Further, the following terms are used in the document:</t>
<dl> <dl newline="false" spacing="normal">
<dt>MSD:</dt> <dt>MSD:</dt>
<dd> <dd>
<t>Maximum SID Depth.</t> <t>Maximum SID Depth</t>
</dd> </dd>
<dt>PST:</dt> <dt>PST:</dt>
<dd> <dd>
<t>Path Setup Type.</t> <t>Path Setup Type</t>
</dd> </dd>
<dt>SR:</dt> <dt>SR:</dt>
<dd> <dd>
<t>Segment Routing.</t> <t>Segment Routing</t>
</dd> </dd>
<dt>SID:</dt> <dt>SID:</dt>
<dd> <dd>
<t>Segment Identifier.</t> <t>Segment Identifier</t>
</dd> </dd>
<dt>SRv6:</dt> <dt>SRv6:</dt>
<dd> <dd>
<t>Segment Routing over IPv6 data-plane.</t> <t>Segment Routing over IPv6 data plane</t>
</dd> </dd>
<dt>SRH:</dt> <dt>SRH:</dt>
<dd> <dd>
<t>IPv6 Segment Routing Header <xref target="RFC8754"/>.</t> <t>IPv6 Segment Routing Header <xref target="RFC8754"/></t>
</dd> </dd>
<dt>SRv6 Path:</dt> <dt>SRv6 path:</dt>
<dd> <dd>
<t>IPv6 Segment List (List of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document)</t> <t>IPv6 Segment List (A list of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document.)</t>
</dd> </dd>
</dl> </dl>
<t>Further, note that the term LSP used in the PCEP specifications, <!-- [rfced] We note this explanation of the term LSP. May we expand LSP to Lab
would be equivalent to an SRv6 Path (represented as a list of SRv6 el Switched Path upon first use?
Original:
Further, note that the term LSP used in the PCEP specifications,
would be equivalent to an SRv6 Path (represented as a list of SRv6
segments) in the context of supporting SRv6 in PCEP.
First occurrence in the doc - perhaps:
A PCE or a PCC operating as a PCE
(in a hierarchical PCE environment) computes paths for MPLS Traffic
Engineering Label Switched Paths (MPLS-TE LSPs) based on various constraints
and
optimization criteria.
-->
<t>Further, note that the term "LSP" used in the PCEP specifications
would be equivalent to an SRv6 path (represented as a list of SRv6
segments) in the context of supporting SRv6 in PCEP.</t> segments) in the context of supporting SRv6 in PCEP.</t>
</section> </section>
<section anchor="Overview"> <section anchor="Overview">
<name>Overview of PCEP Operation in SRv6 Networks</name> <name>Overview of PCEP Operation in SRv6 Networks</name>
<t>Basic operations for PCEP speakers are built on <xref target="RFC8664"/ >.</t> <t>Basic operations for PCEP speakers are built on <xref target="RFC8664"/ >.</t>
<t>In PCEP messages, route information is carried in the Explicit Route Ob <t>In PCEP messages, route information is carried in the Explicit Route Ob
ject (ERO), which consists of a sequence of subobjects. <xref target="RFC8664"/> ject (ERO), which consists of a sequence of subobjects. <xref target="RFC8664"/>
defined a new Explicit Route Object (ERO) subobject denoted by "SR-ERO subobjec defined a new ERO subobject denoted by "SR-ERO subobject" that is capable of ca
t" capable of carrying a SID as well as the identity of the node/adjacency repre rrying a SID as well as the identity of the node/adjacency represented by the SI
sented by the SID for SR-MPLS. SR-capable PCEP speakers can generate and/or proc D for SR-MPLS. SR-capable PCEP speakers can generate and/or process such an ERO
ess such an ERO subobject. An ERO containing SR-ERO subobjects can be included i subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path
n the PCEP Path Computation Reply (PCRep) message defined in <xref target="RFC54 Computation Reply (PCRep) message defined in <xref target="RFC5440"/>, the PCEP
40"/>, the PCEP LSP Initiate Request message (PCInitiate) defined in <xref targe LSP Initiate Request message (PCInitiate) defined in <xref target="RFC8281"/>, a
t="RFC8281"/>, as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP St s well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRp
ate Report (PCRpt) messages defined in <xref target="RFC8231"/>. <xref target="R t) messages defined in <xref target="RFC8231"/>. <xref target="RFC8664"/> also d
FC8664"/> also defines a new Reported Route Object(RRO) called SR-RRO to represe efines a new Reported Route Object (RRO), called "SR-RRO", to represent the SID
nt the SID list that was applied by the PCC, that is, the actual path taken by t list that was applied by the PCC, which is the actual path taken by the LSP in S
he LSP in SR-MPLS network.</t> R-MPLS network.</t>
<t>The SRv6 Paths computed by a PCE can be represented as an ordered list <t>The SRv6 paths computed by a PCE can be represented as an ordered list
of SRv6 segments. This document defines new subobjects "SRv6-ERO" and "SRv6-RRO" of SRv6 segments. This document defines new subobjects "SRv6-ERO" and "SRv6-RRO"
in the ERO and the RRO respectively to carry the SRv6 SID. SRv6-capable in the ERO and the RRO, respectively, to carry the SRv6 SID. SRv6-capable
PCEP speakers <bcp14>MUST</bcp14> be able to generate and/or process these subob jects.</t> PCEP speakers <bcp14>MUST</bcp14> be able to generate and/or process these subob jects.</t>
<t>When a PCEP session between a PCC and a PCE is established, both PCEP s <t>When a PCEP session between a PCC and a PCE is established, both PCEP s
peakers exchange their capabilities to indicate their ability to support SRv6 sp peakers exchange their capabilities to indicate their ability to support SRv6-sp
ecific functionality as described in <xref target="SRv6-PCE-Capability-sub-TLV"/ ecific functionality as described in <xref target="SRv6-PCE-Capability-sub-TLV"/
>.</t> >.</t>
<t>In summary, this document,</t>
<t>In summary, this document defines:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Defines a new PCEP capability for SRv6.</t> <t>a new PCEP capability for SRv6,</t>
</li> </li>
<li> <li>
<t>Defines a new subobject SRv6-ERO in ERO.</t> <t>a new subobject SRv6-ERO in ERO,</t>
</li> </li>
<li> <li>
<t>Defines a new subobject SRv6-RRO in RRO.</t> <t>a new subobject SRv6-RRO in RRO, and</t>
</li> </li>
<li> <li>
<t>Defines a new path setup type (PST) <xref target="RFC8408"/> carrie <t>a new Path Setup type (PST) <xref target="RFC8408"/>, carried in
d in the the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs.</t>
PATH-SETUP-TYPE TLV and the PATH-SETUP-TYPE-CAPABILITY TLV.</t>
</li> </li>
</ul> </ul>
<section anchor="Operation-overview"> <section anchor="Operation-overview">
<name>Operation Overview</name> <name>Operation Overview</name>
<t>In SR networks, an SR source node <xref target="RFC8754"/> steers a p acket into an SR Policy resulting in a segment list.</t> <t>In SR networks, an SR source node <xref target="RFC8754"/> steers a p acket into an SR Policy resulting in a segment list.</t>
<t>When SR leverages the IPv6 data-plane (i.e. SRv6), the PCEP procedure s and mechanisms are extended in this document.</t> <t>When SR leverages the IPv6 data plane (i.e., SRv6), the PCEP procedur es and mechanisms are extended in this document.</t>
<t>This document describes the extension to support SRv6 in PCEP. A PCC or PCE indicates its ability to support SRv6 during the PCEP <t>This document describes the extension to support SRv6 in PCEP. A PCC or PCE indicates its ability to support SRv6 during the PCEP
session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV session initialization phase via a new SRv6-PCE-CAPABILITY sub-TLV
(see details in <xref target="SRv6-PCE-Capability-sub-TLV"/>).</t> (see details in <xref target="SRv6-PCE-Capability-sub-TLV"/>).</t>
</section> </section>
<section anchor="SRv6-Specific-PCEP-Message-Extensions"> <section anchor="SRv6-Specific-PCEP-Message-Extensions">
<name>SRv6-Specific PCEP Message Extensions</name> <name>SRv6-Specific PCEP Message Extensions</name>
<t>As defined in <xref target="RFC5440"/>, a PCEP message consists of <t>As defined in <xref target="RFC5440"/>, a PCEP message consists of
a common header followed by a variable length body made up of a common header followed by a variable-length body made up of
mandatory and/or optional objects. This document does not require any mandatory and/or optional objects. This document does not require any
changes in the format of PCReq and PCRep messages specified in <xref target="RFC 5440"/>, changes in the format of PCReq and PCRep messages specified in <xref target="RFC 5440"/>,
PCInitiate message specified in <xref target="RFC8281"/>, and PCRpt and PCUpd me ssages the PCInitiate message specified in <xref target="RFC8281"/>, or PCRpt and PCUpd messages
specified in <xref target="RFC8231"/>. However, PCEP messages pertaining to SRv6 <bcp14>MUST</bcp14> specified in <xref target="RFC8231"/>. However, PCEP messages pertaining to SRv6 <bcp14>MUST</bcp14>
include PATH-SETUP-TYPE TLV in the RP (Request Parameters) or SRP (Stateful PCE Request Parameters) object to clearly include PATH-SETUP-TYPE TLV in the Request Parameters (RP) or Stateful PCE Reque st Parameters (SRP) object to clearly
identify that SRv6 is intended.</t> identify that SRv6 is intended.</t>
<!-- In other words, a PCEP speaker MUST NOT infer whether or <!-- In other words, a PCEP speaker MUST NOT infer whether or
not a PCEP message pertains to SRv6 from any other object or not a PCEP message pertains to SRv6 from any other object or
TLV. --> TLV. -->
</section> </section>
</section> </section>
<section anchor="Object-Formats"> <section anchor="Object-Formats">
<name>Object Formats</name> <name>Object Formats</name>
<section anchor="The-OPEN-Object"> <section anchor="The-OPEN-Object">
<name>The OPEN Object</name> <name>The OPEN Object</name>
<section anchor="SRv6-PCE-Capability-sub-TLV"> <section anchor="SRv6-PCE-Capability-sub-TLV">
<name>The SRv6 PCE Capability sub-TLV</name> <name>The SRv6 PCE Capability sub-TLV</name>
<t>This document defines a new Path Setup Type (PST) <xref target="RFC <t>This document defines a new Path Setup Type (PST) <xref target="RFC
8408"/> for SRv6, as follows.</t> 8408"/> for SRv6, as follows:</t>
<ul spacing="normal"> <dl newline="false" spacing="normal">
<li> <dt>PST=3:</dt>
<t>PST = 3 : Path is setup using SRv6.</t> <dd>Path is set up using SRv6.</dd>
</li> </dl>
</ul> <!-- [rfced] May we change 'this new PST "3"' to 'this new PST (value 3)'?
<t>A PCEP speaker indicates its support of the function described in t
his document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with Original:
this new PST "3" included in the PST list.</t> A PCEP speaker indicates its support of the function described in
<t>This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP sp this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN
eakers use this sub-TLV to exchange information about their SRv6 capability. If object with this new PST "3" included in the PST list.
a PCEP speaker includes PST=3 in the PST List of the PATH-SETUP-TYPE-CAPABILITY -->
TLV then it <bcp14>MUST</bcp14> also include the SRv6-PCE-CAPABILITY sub-TLV ins
ide the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, please see < <t>A PCEP speaker indicates its support of the function described in t
xref target="Procedures"/>.</t> his document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with
<t>The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the follo this new PST (value 3) included in the PST list.</t>
wing figure.</t> <t>This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP spe
akers use this sub-TLV to exchange information about their SRv6 capability. If a
PCEP speaker includes PST=3 in the PST list of the PATH-SETUP-TYPE-CAPABILITY T
LV, then it <bcp14>MUST</bcp14> also include the SRv6-PCE-CAPABILITY sub-TLV ins
ide the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, please see <
xref target="Procedures"/>.</t>
<t>The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in <xref tar
get="SRv6-PCE-CAPABILITY-sub-TLV-format" format="default"/>.</t>
<figure anchor="SRv6-PCE-CAPABILITY-sub-TLV-format"> <figure anchor="SRv6-PCE-CAPABILITY-sub-TLV-format">
<name>SRv6-PCE-CAPABILITY sub-TLV format</name> <name>SRv6-PCE-CAPABILITY Sub-TLV Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=27 | Length | | Type=27 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |N| | | Reserved | Flags |N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | MSD-Type | MSD-Value | | MSD-Type | MSD-Value | MSD-Type | MSD-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ... // // ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSD-Type | MSD-Value | Padding | | MSD-Type | MSD-Value | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The code point for the TLV type is 27 and the format is compliant w <t>The code point for the TLV type is 27, and the format is compliant
ith the PCEP TLV format defined in <xref target="RFC5440"/>. That is, the sub-TL with the PCEP TLV format defined in <xref target="RFC5440"/>. That is, the sub-T
V is composed of 2 octets for the type, 2 octets specifying the length, and a Va LV is composed of 2 octets for the type, 2 octets specifying the length, and a V
lue field. The Type field when set to 27 identifies the SRv6-PCE-CAPABILITY sub- alue field. When set to 27, the Type field identifies the SRv6-PCE-CAPABILITY su
TLV and the presence of the sub-TLV indicates the support for the SRv6 paths in b-TLV, and the presence of the sub-TLV indicates the support for the SRv6 paths
PCEP. The Length field defines the length of the value portion in octets. The su in PCEP. The Length field defines the length of the value portion in octets. The
b-TLV is padded to 4-octet alignment, and padding is not included in the Length sub-TLV is padded to 4-octet alignment, and padding is not included in the Leng
field. The (MSD-Type,MSD-Value) pairs are <bcp14>OPTIONAL</bcp14>. The number of th field. The (MSD-Type,MSD-Value) pairs are <bcp14>OPTIONAL</bcp14>. The number
(MSD-Type,MSD-Value) pairs can be determined from the Length field of the TLV.< of (MSD-Type,MSD-Value) pairs can be determined by the Length field of the TLV.
/t> </t>
<t>The value comprises of -</t> <t>The value is comprised of:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li>Reserved: 2 octets; this field <bcp14>MUST</bcp14> be set to 0
<t>Reserved: 2 octet, this field <bcp14>MUST</bcp14> be set to 0 o on transmission and ignored on receipt.</li>
n <li><t>Flags: 2 octets; one bit is currently assigned in <xref targe
transmission, and ignored on receipt.</t> t="SRv6-PCE-Capability-Flags"/></t>
</li>
</ul>
<ul empty="true">
<li>
<t>Flags: 2 octet, one bit is currently assigned in this
document. <xref target="SRv6-PCE-Capability-Flags"/></t>
</li>
</ul>
<ul empty="true">
<li>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>N bit (bit position 14): A PCC sets this flag bit to 1 to
<t>N bit (bit position 14): A PCC sets this flag bit to 1 to i indicate that it is capable of resolving a Node or Adjacency
ndicate that it Identifier (NAI) to an SRv6-SID.</li>
is capable of resolving a Node or Adjacency Identifier (NAI) <li>Unassigned bits <bcp14>MUST</bcp14> be set to 0 on
to an SRv6-SID.</t> transmission and ignored on receipt</li>
</li>
<li>
<t>Unassigned bits <bcp14>MUST</bcp14> be set to 0 on transmis
sion and ignored
on receipt</t>
</li>
</ul> </ul>
</li> </li>
<li>A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet)
is as per the IGP MSD Type registry created by <xref
target="RFC8491"/> and populated with SRv6 MSD types as per <xref
target="RFC9352"/>, and where MSD-Value (1 octet) is as per <xref
target="RFC8491"/>.</li>
</ul> </ul>
<ul empty="true"> <t>The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV
<li> conveys the SRv6 capabilities of the PCEP speaker alone. However, when it comes
<t>A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is to the computation of an SR Policy for the SRv6 data plane, the SRv6 MSD capabi
as per the IGP MSD Type registry created by <xref target="RFC8491"/> and populat lities of the intermediate SRv6 Endpoint node and the tail-end node also need to
ed be considered to ensure those midpoints are able to correctly process their seg
with SRv6 MSD types as per <xref target="RFC9352"/>; ments and for the tail-end to dispose of the SRv6 encapsulation. The SRv6 MSD ca
MSD-Value (1 octet) is as per <xref target="RFC8491"/>.</t> pabilities of other nodes might be learned as part of the topology information v
</li> ia the Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC9514"/> or
</ul> via PCEP if the PCE also happens to have PCEP sessions with those nodes.</t>
<t>The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV <t>It is recommended that the SRv6 MSD information not be included in
conveys the SRv6 capabilities of the PCEP speaker alone. However, when it comes the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able to obtain t
to the computation of an SR Policy for the SRv6 data-plane, the SRv6 MSD capabi his via IGP/BGP-LS as part of the topology information.</t>
lities of all the intermediate SRv6 Endpoint node as well as the tail-end node a
lso need to be considered to ensure those midpoints are able to correctly proces
s their segments and for the tail-end to dispose of the SRv6 encapsulation. The
SRv6 MSD capabilities of other nodes might be learned as part of the topology in
formation via BGP-LS<xref target="RFC9514"/> or via PCEP if the PCE also happens
to have PCEP sessions to those nodes.</t>
<t>It is recommended that the SRv6 MSD information be not included in
the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able to obtain t
his via IGP/BGP-LS as part of the topology information.</t>
</section> </section>
</section> </section>
<section anchor="The-SRP-Object"> <section anchor="The-SRP-Object">
<name>The RP/SRP Object</name> <name>The RP/SRP Object</name>
<t>This document defines a new Path Setup Type (PST=3) for SRv6. In orde r to indicate that the path is for SRv6, any RP or SRP object <bcp14>MUST</bcp14 > include the PATH-SETUP-TYPE TLV as specified in <xref target="RFC8408"/>, wher e PST is set to 3.</t> <t>This document defines a new Path Setup Type (PST=3) for SRv6. In orde r to indicate that the path is for SRv6, any RP or SRP object <bcp14>MUST</bcp14 > include the PATH-SETUP-TYPE TLV as specified in <xref target="RFC8408"/>, wher e PST is set to 3.</t>
</section> </section>
<section anchor="ERO"> <section anchor="ERO">
<name>ERO</name> <name>ERO</name>
<t>In order to support SRv6, a new "SRv6-ERO" subobject is defined for i nclusion in the ERO.</t> <t>In order to support SRv6, a new "SRv6-ERO" subobject is defined for i nclusion in the ERO.</t>
<section anchor="SRv6-ERO-Subobject"> <section anchor="SRv6-ERO-Subobject">
<name>SRv6-ERO Subobject</name> <name>SRv6-ERO Subobject</name>
<t>An SRv6-ERO subobject is formatted as shown in the following figure .</t> <t>An SRv6-ERO subobject is formatted as shown in <xref target="SRv6-E RO-Subobject-Format" format="default"/>.</t>
<figure anchor="SRv6-ERO-Subobject-Format"> <figure anchor="SRv6-ERO-Subobject-Format">
<name>SRv6-ERO Subobject Format</name> <name>SRv6-ERO Subobject Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=40 | Length | NT | Flags |V|T|F|S| |L| Type=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior | | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID (conditional) | | SRv6 SID (conditional) |
| (128-bit) | | (128-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, conditional) // // NAI (variable, conditional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID Structure (conditional) | | SID Structure (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>The fields in the SRv6-ERO subobject are as follows:</t> <t>The fields in the SRv6-ERO subobject are as follows:</t>
<t>The 'L' Flag: Indicates whether the subobject represents a <ul spacing="normal">
loose-hop (see <xref target="RFC3209"/>). If this flag is set to <li>The "L" flag: Indicates whether the subobject represents a
zero, a PCC <bcp14>MUST NOT</bcp14> overwrite the SID value present in the SRv6- loose hop (see <xref target="RFC3209"/>). If this flag is set to
ERO zero, a PCC <bcp14>MUST NOT</bcp14> overwrite the SID value
subobject. Otherwise, a PCC <bcp14>MAY</bcp14> expand or replace one or more SID present in the SRv6-ERO subobject. Otherwise, a PCC
values in the received SRv6-ERO based on its local policy.</t> <bcp14>MAY</bcp14> expand or replace one or more SID values in the
<t>Type: indicates the content of the subobject, i.e. when the field received SRv6-ERO based on its local policy.</li>
is set to 40, the suboject is an SRv6-ERO subobject <li>Type: Indicates the content of the subobject, i.e., when the
representing an SRv6 SID.</t> field is set to 40, the subobject is an SRv6-ERO subobject
<t>Length: Contains the total length of the subobject in octets. The representing an SRv6 SID.</li>
Length <bcp14>MUST</bcp14> be at least 24, and <bcp14>MUST</bcp14> be a multiple <li>Length: Contains the total length of the subobject in
of 4. An SRv6-ERO octets. The Length <bcp14>MUST</bcp14> be at least 24 and
subobject <bcp14>MUST</bcp14> contain at least one of an SRv6-SID or an NAI. The <bcp14>MUST</bcp14> be a multiple of 4. An SRv6-ERO subobject
S <bcp14>MUST</bcp14> contain at least one of an SRv6-SID or an
and F bit in the Flags field indicates whether the SRv6-SID or NAI NAI. The S and F bits in the Flags field indicates whether the
fields are absent.</t> SRv6-SID or NAI fields are absent.</li>
<t>NAI Type (NT): Indicates the type and format of the NAI contained <li><t>NAI Type (NT): Indicates the type and format of the NAI
in the object body, if any is present. If the F bit is set to one contained in the object body, if any are present. If the F bit is
(see below) then the NT field has no meaning and <bcp14>MUST</bcp14> be ignored set to one (see below), then the NT field has no meaning and
by <bcp14>MUST</bcp14> be ignored by the receiver. This document
the receiver. This document creates a new PCEP SRv6-ERO NAI Types creates a new PCEP SRv6-ERO NAI Types registry in <xref
registry in <xref target="IANA-NAI"/> and allocates the following values.</t> target="IANA-NAI"/> and allocates the following values:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li>If NT value is 0, the NAI <bcp14>MUST NOT</bcp14> be included.
<t>If NT value is 0, the NAI <bcp14>MUST NOT</bcp14> be included.< </li>
/t> <li>When NT value is 2, the NAI is as per the "IPv6 node ID"
</li> format defined in <xref target="RFC8664"/>, which specifies an
</ul> IPv6 address. This is used to identify the owner of the SRv6
<ul empty="true"> Identifier. This is optional, as the LOC (the locator portion)
<li> of the SRv6 SID serves a similar purpose (when present).</li>
<t>When NT value is 2, the NAI is as per the 'IPv6 Node ID' <li>When NT value is 4, the NAI is as per the "IPv6 adjacency"
format defined in <xref target="RFC8664"/>, which specifies an format defined in <xref target="RFC8664"/>, which specify a pair
IPv6 address. This is used to identify the owner of the SRv6 of IPv6 addresses. This is used to identify the IPv6 adjacency
Identifier. This is optional, as the LOC (the locator portion) and used with the SRv6 Adj-SID.</li>
of the SRv6 SID serves a similar purpose (when present).</t> <li>When NT value is 6, the NAI is as per the "link-local IPv6
</li> addresses" format defined in <xref target="RFC8664"/>, which
</ul> specify a pair of (global IPv6 address, interface ID) tuples. It
<ul empty="true"> is used to identify the IPv6 adjacency and used with the SRv6
<li> Adj-SID.</li>
<t>When NT value is 4, the NAI is as per the 'IPv6 Adjacency' </ul></li>
format defined in <xref target="RFC8664"/>, which specify a pair <li><t>Flags: Used to carry additional information pertaining to the
of IPv6 addresses. This is used to identify the IPv6 Adjacency SRv6-SID. This document defines the following flag bits. The other
and used with the SRv6 Adj-SID.</t> bits <bcp14>MUST</bcp14> be set to zero by the sender and
</li> <bcp14>MUST</bcp14> be ignored by the receiver. This document
</ul> creates a new registry SRv6-ERO Flag Field registry in <xref
<ul empty="true"> target="SRv6-ERO-flag"/> and allocates the following values.</t>
<li>
<t>When NT value is 6, the NAI is as per the 'link-local IPv6
addresses' format defined in <xref target="RFC8664"/>, which
specify a pair of (global IPv6 address, interface ID) tuples. It
is used to identify the IPv6 Adjacency and used with the SRv6
Adj-SID.</t>
</li>
</ul>
<t>Flags: Used to carry additional information pertaining to the
SRv6-SID. This document defines the following flag bits. The other
bits <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> be
ignored by the
receiver. This document creates a new registry SRv6-ERO
Flag Field registry in <xref target="SRv6-ERO-flag"/> and allocates the
following values.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>S: When this bit is set to 1, the SRv6-SID value in the
<t>S: When this bit is set to 1, the SRv6-SID value in the subobject body is absent. In this case, the PCC is responsible for
subobject body is absent. In this case, the PCC is responsible choosing the SRv6-SID value, e.g., by looking up in the SR-DB
for choosing the SRv6-SID value, e.g., by looking up in the using the NAI that, in this case, <bcp14>MUST</bcp14> be present
SR-DB using the NAI which, in this case, <bcp14>MUST</bcp14> be present in the in the subobject. If the S bit is set to 1, then the F bit
subobject. If the S bit is set to 1 then F bit <bcp14>MUST</bcp14> be set to <bcp14>MUST</bcp14> be set to zero.</li>
zero.</t> <li>F: When this bit is set to 1, the NAI value in the subobject
</li> body is absent. The F bit <bcp14>MUST</bcp14> be set to 1 if NT=0;
<li> otherwise, it <bcp14>MUST</bcp14> be set to zero. The S and F bits
<t>F: When this bit is set to 1, the NAI value in the subobject <bcp14>MUST NOT</bcp14> both be set to 1.</li>
body is absent. The F bit <bcp14>MUST</bcp14> be set to 1 if NT=0, and <li>T: When this bit is set to 1, the SID Structure value in the
otherwise <bcp14>MUST</bcp14> be set to zero. The S and F bits <bcp14>MUST NOT</ subobject body is present. The T bit <bcp14>MUST</bcp14> be set to
bcp14> both be 0 when the S bit is set to 1. If the T bit is set when the S bit is
set to 1.</t> set, the T bit <bcp14>MUST</bcp14> be ignored. Thus, the T bit
</li> indicates the presence of an optional 8-byte SID Structure when
<li> SRv6 SID is included. The SID Structure is defined in <xref
<t>T: When this bit is set to 1, the SID Structure value in the target="SID-Structure"/>.</li>
subobject body is present. The T bit <bcp14>MUST</bcp14> be set to 0 when S bit <li>V: The "SID verification" bit usage is as per <xref
is set to 1. If the T bit is set when the S bit is set, the T target="RFC9256" sectionFormat="of" section="5.1"/>. If a PCC
bit <bcp14>MUST</bcp14> be ignored. Thus, the T bit indicates the presence of "Verification fails" for a SID, it <bcp14>MUST</bcp14> report this
an optional 8-byte SID Structure when SRv6 SID is included. The error by including the LSP-ERROR-CODE TLV with LSP Error-value
SID Structure is defined in <xref target="SID-Structure"/>.</t> "SID Verification fails" in the LSP object in the PCRpt message to
</li> the PCE.</li>
<li> </ul></li>
<t>V: The "SID verification" bit usage is as per Section 5.1 of <x <li>Reserved: <bcp14>MUST</bcp14> be set to zero while sending and
ref target="RFC9256"/>. If a PCC "Verification fails" for a SID, it <bcp14>MUST< ignored on receipt.</li>
/bcp14> report this error by <li>Endpoint Behavior: A 16-bit field representing the behavior
including the LSP-ERROR-CODE TLV with LSP error-value "SID Verification fails" associated with the SRv6 SIDs.
in the LSP object in the PCRpt message to the PCE.</t> <!-- [rfced] May we update this sentence for clarity?
</li>
</ul> Original:
<t>Reserved: <bcp14>MUST</bcp14> be set to zero while sending and igno This information is optional, but
red on receipt.</t> it is recommended to signal it always if possible.
<t>Endpoint Behavior: A 16-bit field representing the behavior
associated with the SRv6 SIDs. This information is optional, but it is recommend Perhaps:
ed to signal it always if possible. It could be used for maintainability and dia This information is optional, but providing it is recommended whenever pos
gnostic purpose. If behavior is not known, value '0xFFFF' defined in the registr sible.
y "SRv6 Endpoint Behaviors" is used <xref target="RFC8986"/>.</t> -->
<t>SRv6 SID: SRv6 Identifier is an 128-bit value representing the SRv6 This information is optional, but providing it
segment.</t> is recommended whenever possible. It could be used for
<t>NAI: The NAI associated with the SRv6-SID. The NAI's format maintainability and diagnostic purposes. If behavior is not known,
depends on the value in the NT field, and is described in <xref target="RFC8664" value "0xFFFF" as defined in the "SRv6 Endpoint Behaviors" registry is
/>.</t> used <xref target="RFC8986"/>.</li>
<t>At least one SRv6-SID or the NAI <bcp14>MUST</bcp14> be included in <li>SRv6 SID: SRv6 Identifier is a 128-bit value representing the
the SRv6-ERO subobject, and both <bcp14>MAY</bcp14> be included.</t> SRv6 segment.</li>
<li>NAI: The NAI associated with the SRv6-SID. The NAI's format
depends on the value in the NT field and is described in <xref
target="RFC8664"/>.</li>
</ul>
<t>At least one SRv6-SID or the NAI <bcp14>MUST</bcp14> be included
in the SRv6-ERO subobject, and both <bcp14>MAY</bcp14> be
included.</t>
<section anchor="SID-Structure"> <section anchor="SID-Structure">
<name>SID Structure</name> <name>SID Structure</name>
<t>The SID Structure is an optional part of the SR-ERO subobject, <t>The SID Structure is an optional part of the SR-ERO subobject,
as described in <xref target="SRv6-ERO-Subobject"/>.</t> as described in <xref target="SRv6-ERO-Subobject"/>.</t>
<t><xref target="RFC8986"/> defines an SRv6 SID as consisting of LOC <t><xref target="RFC8986"/> defines an SRv6 SID as consisting of
:FUNCT:ARG, LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most
where a locator (LOC) is encoded in the L most significant bits of significant bits of the SID, followed by F bits of function
the SID, followed by F bits of function (FUNCT) and A bits of (FUNCT) and A bits of arguments (ARG). A locator may be
arguments (ARG). A locator may be represented as B:N where B is represented as B:N where B is the SRv6 SID locator block (IPv6
the SRv6 SID locator block (IPv6 prefix allocated for SRv6 SIDs by prefix allocated for SRv6 SIDs by the operator) and N is the
the operator) and N is the identifier of the parent node identifier of the parent node instantiating the SID called
instantiating the SID called locator node.</t> "locator node".</t>
<t>It is <t>The SID Structure is formatted as shown in <xref target="SID-Stru
formatted as shown in the following figure.</t> cture-Format"
format="default"/>.</t>
<figure anchor="SID-Structure-Format"> <figure anchor="SID-Structure-Format">
<name>SID Structure Format</name> <name>SID Structure Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length | | LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>where:</t> <t>Where:</t>
<t>LB Length: 1 octet. SRv6 SID Locator Block length in bits.</t> <ul spacing="normal">
<t>LN Length: 1 octet. SRv6 SID Locator Node length in bits.</t> <li>LB Length: 1 octet; SRv6 SID Locator Block length in bits</li>
<t>Fun. Length: 1 octet. SRv6 SID Function length in bits.</t> <li>LN Length: 1 octet; SRv6 SID Locator Node length in bits</li>
<t>Arg. Length: 1 octet. SRv6 SID Arguments length in bits.</t> <li>Fun. Length: 1 octet; SRv6 SID Function length in bits</li>
<t>The sum of all four sizes in the SID Structure must be lower or <li>Arg. Length: 1 octet; SRv6 SID Arguments length in bits</li>
equal to 128 bits. If the sum of all four sizes advertised in the </ul>
SID Structure is larger than 128 bits, the corresponding SRv6 SID <t>The sum of all four sizes in the SID Structure must be less than
<bcp14>MUST</bcp14> be considered invalid and a PCErr message with Error-Type = or
10 ("Reception of an invalid object") and Error-Value = 37 ("Invalid SRv6 SID St equal to 128 bits. If the sum of all four sizes advertised in the
ructure") is returned.</t> SID Structure is larger than 128 bits, the corresponding SRv6 SID
<t>Reserved: <bcp14>MUST</bcp14> be set to zero while sending and ig <bcp14>MUST</bcp14> be considered invalid and a PCErr message with
nored on Error-Type = 10 ("Reception of an invalid object") and Error-value
receipt.</t> = 37 ("Invalid SRv6 SID Structure") is returned.</t>
<t>Flags: Currently no flags are defined. Unassigned bits must be <ul spacing="normal">
set to zero while sending and ignored on receipt.</t> <li>Reserved: <bcp14>MUST</bcp14> be set to zero while sending
and ignored on receipt.</li>
<li>Flags: Currently no flags are defined.</li>
<li>Unassigned bits must be set to zero while sending and
ignored on receipt.</li>
</ul>
<t>The SRv6 SID Structure provides the detailed encoding <t>The SRv6 SID Structure provides the detailed encoding
information of an SRv6 SID, which is useful in the use cases that information of an SRv6 SID, which is helpful in the use cases that
require to know the SRv6 SID structure. When a PCEP speaker require the SRv6 SID structure to be known. When a PCEP speaker
receives the SRv6 SID and its structure information, the SRv6 SID receives the SRv6 SID and its structure information, the SRv6 SID
can be parsed based on the SRv6 SID Structure and/or possible can be parsed based on the SRv6 SID Structure and/or possible
local policies. The SRv6 SID Structure could be used by the PCE for ease local policies. The SRv6 SID Structure could be used by the PCE
of operations and monitoring. For example, this information could be for ease of operations and monitoring. For example, this
used for validation of SRv6 SIDs being instantiated in the network information could be used for validation of SRv6 SIDs being
and checked for conformance to the SRv6 SID allocation scheme chosen instantiated in the network and checked for conformance with the
by the operator as described in Section 3.2 of <xref target="RFC8986"/>. In the SRv6 SID allocation scheme chosen by the operator as described in
future, PCE might also be utilized to verify and automate the security of the S <xref target="RFC8986" sectionFormat="of" section="3.2"/>. In the f
Rv6 domain by provisioning filtering rules at the domain boundaries as described uture, PCE might
in Section 5 of <xref target="RFC8754"/>. The details of these potential appli also be utilized to verify and automate the security of the SRv6
cations are outside the scope of this document.</t> domain by provisioning filtering rules at the domain boundaries as
described in <xref target="RFC8754" sectionFormat="of" section="5"/>
. The details
of these potential applications are outside the scope of this
document.</t>
</section> </section>
<section anchor="order"> <section anchor="order">
<name>Order of the Optional fields</name> <name>Order of the Optional Fields</name>
<t>The optional elements in the SRv6-ERO subobject i.e. SRv6 SID, NA <t>The optional elements in the SRv6-ERO subobject, i.e., SRv6 SID,
I and the NAI, and the
SID Structure <bcp14>MUST</bcp14> be encoded in the order as depicted in <xref t SID Structure, <bcp14>MUST</bcp14> be encoded in the order as depicted in <xref
arget="SRv6-ERO-Subobject-Format"/>. target="SRv6-ERO-Subobject-Format"/>.
The presence or absence of each of them is indicated by the respective flags i.e The presence or absence of each of them is indicated by the respective flags, i.
. e.,
S flag, F flag and T flag.</t> S flag, F flag, and T flag.</t>
<t>In order to ensure future compatibility, any optional elements ad <t>In order to ensure future compatibility, any optional elements ad
ded to the SRv6-ERO subobject in the future must specify their order and request ded to the SRv6-ERO subobject in the future must specify their order and request
the Internet Assigned Numbers Authority (IANA) to allocate a flag to indicate t that the Internet Assigned Numbers Authority (IANA) allocate a flag to indicate
heir presence from the subregistry created in <xref target="SRv6-ERO-flag"/>.</t their presence from the subregistry created in <xref target="SRv6-ERO-flag"/>.<
> /t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="RRO"> <section anchor="RRO">
<name>RRO</name> <name>RRO</name>
<t>In order to support SRv6, a new "SRv6-RRO" subobject is defined for i nclusion in the RRO.</t> <t>In order to support SRv6, a new "SRv6-RRO" subobject is defined for i nclusion in the RRO.</t>
<section anchor="SRv6-RRO-Subobject"> <section anchor="SRv6-RRO-Subobject">
<name>SRv6-RRO Subobject</name> <name>SRv6-RRO Subobject</name>
<t>A PCC reports an SRv6 path to a PCE by sending a PCRpt message, <t>A PCC reports an SRv6 path to a PCE by sending a PCRpt message,
per <xref target="RFC8231"/>. The RRO on this message represents the per <xref target="RFC8231"/>. The RRO on this message represents the
SID list that was applied by the PCC, that is, the actual path SID list that was applied by the PCC, that is, the actual path
taken. The procedures of <xref target="RFC8664"/> with respect to taken. The procedures of <xref target="RFC8664"/> with respect to
the RRO apply equally to this specification without change.</t> the RRO apply equally to this specification without change.</t>
<t>An RRO contains one or more subobjects called "SRv6-RRO <t>An RRO contains one or more subobjects called "SRv6-RRO
subobjects" whose format is shown below.</t> subobjects", whose format is shown in <xref
target="SRv6-RRO-Subobject-Format" format="default"/>.</t>
<figure anchor="SRv6-RRO-Subobject-Format"> <figure anchor="SRv6-RRO-Subobject-Format">
<name>SRv6-RRO Subobject Format</name> <name>SRv6-RRO Subobject Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=40 | Length | NT | Flags |V|T|F|S| | Type=40 | Length | NT | Flags |V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Endpoint Behavior | | Reserved | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID(optional) | | SRv6 SID(optional) |
| (128-bit) | | (128-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable) // // NAI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID Structure (optional) | | SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>The format of the SRv6-RRO subobject is the same as that of the <t>The format of the SRv6-RRO subobject is the same as that of the
SRv6-ERO subobject, but without the L flag.</t> SRv6-ERO subobject but without the L flag.</t>
<t>The V flag has no meaning in the SRv6-RRO and is ignored on <t>The V flag has no meaning in the SRv6-RRO and is ignored on
receipt at the PCE.</t> receipt at the PCE.</t>
<t>Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains <t>The ordering of SRv6-RRO subobjects by PCC in PCRpt message
as per <xref target="RFC8664"/>.</t> remains as per <xref target="RFC8664"/>.</t>
<t>The ordering of optional elements in the SRv6-RRO subobject is the <t>The ordering of optional elements in the SRv6-RRO subobject is
same as described in <xref target="order"/>.</t> the same as described in <xref target="order"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="Procedures"> <section anchor="Procedures">
<name>Procedures</name> <name>Procedures</name>
<section anchor="Exchanging-SRv6-Capability"> <section anchor="Exchanging-SRv6-Capability">
<name>Exchanging the SRv6 Capability</name> <name>Exchanging the SRv6 Capability</name>
<t>A PCC indicates that it is capable of supporting the head-end <t>A PCC indicates that it is capable of supporting the head-end
functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the
Open message that it sends to a PCE. A PCE indicates that it is Open message that it sends to a PCE. A PCE indicates that it is
capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY
sub-TLV in the Open message that it sends to a PCC.</t> sub-TLV in the Open message that it sends to a PCC.</t>
<t>If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a <t>If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then t PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then t
he PCEP speaker <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 (R he PCEP speaker <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("
eception of an invalid object) and Error-Value = 34 (Missing PCE-SRv6-CAPABILITY Reception of an invalid object") and Error-Value = 34 ("Missing PCE-SRv6-CAPABIL
sub-TLV) and <bcp14>MUST</bcp14> then close the PCEP session. If a PCEP speaker ITY sub-TLV") and <bcp14>MUST</bcp14> then close the PCEP session. If a PCEP spe
receives a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, aker receives a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-T
but the PST list does not contain PST=3, then the PCEP speaker <bcp14>MUST</bcp1 LV, but the PST list does not contain PST=3, then the PCEP speaker <bcp14>MUST</
4> ignore the SRv6-PCE-CAPABILITY sub-TLV.</t> bcp14> ignore the SRv6-PCE-CAPABILITY sub-TLV.</t>
<t>In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the P <t>In case the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV received by t
CE he PCE
does not correspond to one of the SRv6 MSD types, the PCE <bcp14>MUST</bcp14> re spond does not correspond to one of the SRv6 MSD types, the PCE <bcp14>MUST</bcp14> re spond
with a PCErr message (Error-Type = 1 "PCEP session establishment with a PCErr message (Error-Type = 1 ("PCEP session establishment
failure" and Error-Value = 1 "reception of an invalid Open message or a failure") and Error-Value = 1 ("reception of an invalid Open message or a
non Open message.").</t> non Open message.")).</t>
<t>Note that the MSD-Type, MSD-Value exchanged via the <!-- [rfced] Should "MSD-Type, MSD-Value exchanged" be "(MSD-Type,MSD-Value) pai
r exchanged"?
Original:
Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE-
CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the
sender PCC node only.
-->
<t>Note that the (MSD-Type,MSD-Value) pair exchanged via the
SRv6-PCE-CAPABILITY sub-TLV indicates the SRv6 SID imposition limit SRv6-PCE-CAPABILITY sub-TLV indicates the SRv6 SID imposition limit
for the sender PCC node only. However, if a PCE learns these via alternate mecha for the sender PCC node only. However, if a PCE learns these via alternate mecha
nisms, e.g. routing protocols <xref target="RFC9352"/>, then it ignores the valu nisms, e.g., routing protocols <xref target="RFC9352"/>, then it ignores the val
es in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns any ot ues in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns any o
her SRv6 MSD types that may be defined in the future via alternate mechanisms, i ther SRv6 MSD types that may be defined in the future via alternate mechanisms,
t <bcp14>MUST</bcp14> use those values regardless of the values exchanged in the it <bcp14>MUST</bcp14> use those values regardless of the values exchanged in th
SRv6-PCE-CAPABILITY sub-TLV.</t> e SRv6-PCE-CAPABILITY sub-TLV.</t>
<t>During path computation, PCE must consider the MSD information of all
the nodes along the path instead of only the MSD information of the ingress PCC <!-- [rfced] We are having trouble understanding "MSD exceeding" - what is MSD e
since a packet may be dropped on any node in a forwarding path because of MSD e xceeding? Please clarify.
xceeding. The MSD capabilities of all SR nodes along the path can be learned as
part of the topology information via IGP/BGP-LS or via PCEP if the PCE also happ Current:
ens to have PCEP sessions to those nodes.</t> During path computation, PCE must consider the MSD information of all
<t>A PCE <bcp14>MUST NOT</bcp14> send SRv6 paths exceeding the SRv6 MSD the nodes along the path instead of only the MSD information of the
capabilities of the PCC. If a PCC needs to modify the SRv6 MSD value signaled vi ingress PCC since a packet may be dropped on any node in a forwarding
a the Open message, it <bcp14>MUST</bcp14> close the PCEP session and re-establi path because of MSD exceeding.
sh it with the new value. If the PCC receives an SRv6 path that exceed its SRv6 -->
MSD capabilities, the PCC <bcp14>MUST</bcp14> send a PCErr message with Error-Ty <t>During path computation, a PCE must consider the MSD information of a
pe = 10 (Reception of an invalid object) and Error-Value = 39 (Unsupported numbe ll the nodes along the path instead of only the MSD information of the ingress P
r of SRv6-ERO subobjects).</t> CC since a packet may be dropped on any node in a forwarding path because of the
SID depth exceeding the MSD of the node. The MSD capabilities of all SR nodes a
long the path can be learned as part of the topology information via IGP/BGP-LS
or via PCEP if the PCE also happens to have PCEP sessions with those nodes.</t>
<t>A PCE <bcp14>MUST NOT</bcp14> send SRv6 paths that exceed the SRv6 MS
D capabilities of the PCC. If a PCC needs to modify the SRv6 MSD value signaled
via the Open message, it <bcp14>MUST</bcp14> close the PCEP session and re-estab
lish it with the new value. If the PCC receives an SRv6 path that exceeds its SR
v6 MSD capabilities, the PCC <bcp14>MUST</bcp14> send a PCErr message with Error
-Type = 10 ("Reception of an invalid object") and
<!-- [rfced] We believe mention of Error-value 39 is incorrect, as value 39 is r
egistered as follows:
39: PCECC NATIVE-IP-TE-CAPABILITY bit is not set (TEMPORARY - registered 2023-08
-14, expires 2024-08-14)
Should the text refer to value 40 or 44 instead?
Note that Table 8.8 seems to register values 40 and 44 with the same meaning. P
lease review and let us know if an update is required.
Original:
10 Reception of an invalid object
Error-value = TBD (Unsupported number of
SRv6-ERO subobjects)
...
Error-value = TBD (Unsupported number
of SRv6-ERO subobjects)
As registered at <https://www.iana.org/assignments/pcep> and in Table 9:
40: Unsupported number of SRv6-ERO subobjects
44: Unsupported number of SRv6-ERO subobjects
-->
Error-value = 40 ("Unsupported number of SRv6-ERO subobjects").</t>
<t>The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILI TY sub-TLV are meaningful only in the Open message sent to a PCE. As such, the f lags <bcp14>MUST</bcp14> be set to zero and a (MSD-Type,MSD-Value) pair <bcp14>M UST NOT</bcp14> be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC <bcp14>MUST</bcp14> ignore flags and any (MSD- Type,MSD-Value) pair in a received Open message. If a PCE receives multiple SRv6 -PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.</t> <t>The N flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILI TY sub-TLV are meaningful only in the Open message sent to a PCE. As such, the f lags <bcp14>MUST</bcp14> be set to zero and a (MSD-Type,MSD-Value) pair <bcp14>M UST NOT</bcp14> be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC <bcp14>MUST</bcp14> ignore flags and any (MSD- Type,MSD-Value) pair in a received Open message. If a PCE receives multiple SRv6 -PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received.</t>
</section> </section>
<section anchor="ERO-Processing"> <section anchor="ERO-Processing">
<name>ERO Processing</name> <name>ERO Processing</name>
<t>The processing of ERO remains unchanged in accordance with both <xref target="RFC5440"/> and <xref target="RFC8664"/>.</t> <t>The processing of ERO remains unchanged in accordance with both <xref target="RFC5440"/> and <xref target="RFC8664"/>.</t>
<section anchor="srv6-ero-validation"> <section anchor="srv6-ero-validation">
<name>SRv6 ERO Validation</name> <name>SRv6 ERO Validation</name>
<t>If a PCC does not support the SRv6 PCE Capability and thus cannot <t>If a PCC does not support the SRv6 PCE Capability and thus cannot
recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond according to th e rules for a malformed object as described in <xref target="RFC5440"/>.</t> recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond according to th e rules for a malformed object as described in <xref target="RFC5440"/>.</t>
<t>On receiving an SRv6-ERO, a PCC <bcp14>MUST</bcp14> validate that t he Length <t>On receiving an SRv6-ERO, a PCC <bcp14>MUST</bcp14> validate that t he Length
field, the S bit, the F bit, the T bit, and the NT field are field, the S bit, the F bit, the T bit, and the NT field are
consistent, as follows.</t> consistent, as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If NT=0, the F bit <bcp14>MUST</bcp14> be 1, the S bit <bcp14>M
UST</bcp14> be zero and the <t>If NT=0, the F bit <bcp14>MUST</bcp14> be 1, the S bit
Length <bcp14>MUST</bcp14> be 24.</t> <bcp14>MUST</bcp14> be zero, and the Length <bcp14>MUST</bcp14>
be 24.</t>
</li> </li>
<li> <li>
<t>If NT=2, the F bit <bcp14>MUST</bcp14> be zero. If the S bit is <t>If NT=2, the F bit <bcp14>MUST</bcp14> be zero. If the S bit
1, the is 1, the Length <bcp14>MUST</bcp14> be 24; otherwise, the Length
Length <bcp14>MUST</bcp14> be 24, otherwise the Length <bcp14>MUST</bcp14> be 40 <bcp14>MUST</bcp14> be 40.</t>
.</t>
</li> </li>
<li> <li>
<t>If NT=4, the F bit <bcp14>MUST</bcp14> be zero. If the S bit is <t>If NT=4, the F bit <bcp14>MUST</bcp14> be zero. If the S bit
1, the is 1, the Length <bcp14>MUST</bcp14> be 40; otherwise, the Length
Length <bcp14>MUST</bcp14> be 40, otherwise the Length <bcp14>MUST</bcp14> be 56 <bcp14>MUST</bcp14> be 56.</t>
.</t>
</li> </li>
<li> <li>
<t>If NT=6, the F bit <bcp14>MUST</bcp14> be zero. If the S bit is <t>If NT=6, the F bit <bcp14>MUST</bcp14> be zero. If the S bit
1, the is 1, the Length <bcp14>MUST</bcp14> be 48; otherwise, the Length
Length <bcp14>MUST</bcp14> be 48, otherwise the Length <bcp14>MUST</bcp14> be 64 <bcp14>MUST</bcp14> be 64.</t>
.</t>
</li> </li>
<li> <li>
<t>If T bit is 1, then S bit <bcp14>MUST</bcp14> be zero.</t> <t>If the T bit is 1, then the S bit <bcp14>MUST</bcp14> be zero.< /t>
</li> </li>
</ul> </ul>
<t>If a PCC finds that the NT field, Length field, S bit, F bit, and <t>If a PCC finds that the NT field, Length field, S bit, F bit, and
T bit are not consistent, it <bcp14>MUST</bcp14> consider the entire ERO invalid T bit are not consistent, it <bcp14>MUST</bcp14> consider the entire
and <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception of ERO invalid and <bcp14>MUST</bcp14> send a PCErr message with
an Error-Type = 10 ("Reception of an invalid object") and Error-value =
invalid object") and Error-Value = 11 ("Malformed object").</t> 11 ("Malformed object").</t>
<t>If a PCC does not recognize or support the value in the NT field, i <t>If a PCC does not recognize or support the value in the NT field,
t it <bcp14>MUST</bcp14> consider the entire ERO invalid and send a
<bcp14>MUST</bcp14> consider the entire ERO invalid and send a PCErr message PCErr message with Error-Type = 10 ("Reception of an invalid
with Error-Type = 10 ("Reception of an invalid object") and Error- object") and
value = 40 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject").</t> <!-- [rfced] Please clarify whether the Error-value or meaning is incorrect in t
<t>If a PCC receives an SRv6-ERO subobject in which the S and F bits a he following:
re
both set to 1 (that is, both the SID and NAI are absent), it <bcp14>MUST</bcp14> Original:
consider the entire ERO invalid and send a PCErr message with Error- If a PCC does not recognize or support the value in the NT field, it
Type = 10 ("Reception of an invalid object") and Error-value = 41 MUST consider the entire ERO invalid and send a PCErr message with
("Both SID and NAI are absent in the SRv6-ERO subobject").</t> Error-Type = 10 ("Reception of an invalid object") and Error- value =
<t>If a PCC receives an SRv6-ERO subobject in which the S bit is set t 40 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject").
o 1
and the F bit is set to zero (that is, the SID is absent and the NAI As registered at <https://www.iana.org/assignments/pcep>:
is present), but the PCC does not support NAI resolution, it <bcp14>MUST</bcp14> 40: Unsupported number of SRv6-ERO subobjects
consider the entire ERO invalid and send a PCErr message with Error- 41: Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject
Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported 44: Unsupported number of SRv6-ERO subobjects
parameter").</t> -->
<t>If a PCC detects that the subobjects of an ERO are a mixture of SRv
6- Error-value = 41 ("Unsupported NAI Type in the
ERO subobjects and subobjects of other types, then it <bcp14>MUST</bcp14> send a SRv6-ERO/SRv6-RRO subobject").</t>
PCErr message with Error-Type = 10 ("Reception of an invalid object") <t>If a PCC receives an SRv6-ERO subobject in which the S and F bits
and Error-value = 42 ("ERO mixes SRv6-ERO subobjects with other are both set to 1 (that is, both the SID and NAI are absent), it
subobject types").</t> <bcp14>MUST</bcp14> consider the entire ERO invalid and send a PCErr
<t>In case a PCEP speaker receives an SRv6-ERO subobject, when the PST message with Error-Type = 10 ("Reception of an invalid object") and
is not set to 3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it <bcp14>MUS
T</bcp14> send a PCErr message with Error-Type = 19 ("Invalid Operation") and Er <!-- [rfced] Similarly, please clarify whether the text is intended to refer to
ror-Value = 19 ("Attempted SRv6 when the capability was not advertised").</t> value 41 or 42.
<t>If a PCC receives an SRv6 path that exceeds the SRv6 MSD capabiliti
es, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception Original:
of an invalid object") and Error-Value = 43 ("Unsupported number of SRv6-ERO su If a PCC receives an SRv6-ERO subobject in which the S and F bits are
bobjects") as per <xref target="RFC8664"/>.</t> both set to 1 (that is, both the SID and NAI are absent), it MUST
consider the entire ERO invalid and send a PCErr message with Error-
Type = 10 ("Reception of an invalid object") and Error-value = 41
("Both SID and NAI are absent in the SRv6-ERO subobject").
As registered at https://www.iana.org/assignments/pcep>:
41: Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject
42: Both SID and NAI are absent in the SRv6-ERO subobject
-->
Error-value = 42 ("Both SID and NAI are absent in the SRv6-ERO
subobject").</t>
<t>If a PCC receives an SRv6-ERO subobject in which the S bit is set
to 1 and the F bit is set to zero (that is, the SID is absent and
the NAI is present), but the PCC does not support NAI resolution, it
<bcp14>MUST</bcp14> consider the entire ERO invalid and send a PCErr
message with Error-Type = 4 ("Not supported object") and Error-value
= 4 ("Unsupported parameter").</t>
<t>If a PCC detects that the subobjects of an ERO are a mixture of
SRv6-ERO subobjects and subobjects of other types, then it
<bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10
<!-- [rfced] It appears as though the values are off by one. Perhaps this text
should refer to value 43?
Original:
If a PCC detects that the subobjects of an ERO are a mixture of SRv6-
ERO subobjects and subobjects of other types, then it MUST send a
PCErr message with Error-Type = 10 ("Reception of an invalid object")
and Error-value = 42 ("ERO mixes SRv6-ERO subobjects with other
subobject types").
As registered at https://www.iana.org/assignments/pcep>:
42: Both SID and NAI are absent in the SRv6-ERO subobject
43: ERO mixes SRv6-ERO subobjects with other subobject types
-->
("Reception of an invalid object") and Error-value = 43 ("ERO mixes
SRv6-ERO subobjects with other subobject types").</t>
<t>In case a PCEP speaker receives an SRv6-ERO subobject, when the PST
is not set to 3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it <bcp14>MUS
T</bcp14> send a PCErr message with Error-Type = 19 ("Invalid Operation") and Er
ror-value = 19 ("Attempted SRv6 when the capability was not advertised").</t>
<t>If a PCC receives an SRv6 path that exceeds the SRv6 MSD capabiliti
es, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Reception
of an invalid object")
<!-- [rfced] Should this text instead refer to value 40 or 44?
Original:
If a PCC receives an SRv6 path that exceeds the SRv6 MSD
capabilities, it MUST send a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = 43 ("Unsupported
number of SRv6-ERO subobjects") as per [RFC8664].
As registered at https://www.iana.org/assignments/pcep>:
40: Unsupported number of SRv6-ERO subobjects
43: ERO mixes SRv6-ERO subobjects with other subobject types
44: Unsupported number of SRv6-ERO subobjects
-->
and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects") as per <xref
target="RFC8664"/>.</t>
</section> </section>
<section anchor="interpreting-the-srv6-ero"> <section anchor="interpreting-the-srv6-ero">
<name>Interpreting the SRv6-ERO</name> <name>Interpreting the SRv6-ERO</name>
<t>The SRv6-ERO contains a sequence of subobjects. According to <xref target="RFC9256"/>, each <t>The SRv6-ERO contains a sequence of subobjects. According to <xref target="RFC9256"/>, each
SRv6-ERO subobject in the sequence identifies a segment that the SRv6-ERO subobject in the sequence identifies a segment that the
traffic will be directed to, in the order given. That is, the first traffic will be directed to, in the order given. That is, the first
subobject identifies the first segment the traffic will be directed subobject identifies the first segment the traffic will be directed
to, the second SRv6-ERO subobject represents the second segment, and to, the second SRv6-ERO subobject represents the second segment, and
so on.</t> so on.</t>
</section> </section>
</section> </section>
<section anchor="RRO-Processing"> <section anchor="RRO-Processing">
<name>RRO Processing</name> <name>RRO Processing</name>
<t>The syntax checking rules that apply to the SRv6-RRO subobject are <t>The syntax-checking rules that apply to the SRv6-RRO subobject are
identical to those of the SRv6-ERO subobject, except as noted identical to those of the SRv6-ERO subobject, except as noted
below.</t> below.</t>
<t>If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 <t>If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6
SID and NAI are absent, it <bcp14>MUST</bcp14> consider the entire RRO invalid a nd SID and NAI are absent, it <bcp14>MUST</bcp14> consider the entire RRO invalid a nd
send a PCErr message with Error-Type = 10 ("Reception of an invalid send a PCErr message with Error-Type = 10 ("Reception of an invalid
object") and Error-Value = 35 ("Both SID and NAI object") and Error-value = 35 ("Both SID and NAI
are absent in are absent in
SRv6-RRO subobject").</t> SRv6-RRO subobject").</t>
<t>If a PCE detects that the subobjects of an RRO are a mixture of <t>If a PCE detects that the subobjects of an RRO are a mixture of
SRv6-RRO subobjects and subobjects of other types, then it <bcp14>MUST</bcp14> s end a SRv6-RRO subobjects and subobjects of other types, then it <bcp14>MUST</bcp14> s end a
PCErr message with Error-Type = 10 ("Reception of an invalid object") PCErr message with Error-Type = 10 ("Reception of an invalid object")
and Error-Value = 36 ("RRO mixes SRv6-RRO subobjects and Error-value = 36 ("RRO mixes SRv6-RRO subobjects
with other with other
subobject types").</t> subobject types").</t>
<t>The mechanism by which the PCC learns the path is outside the scope o f this document.</t> <t>The mechanism by which the PCC learns the path is outside the scope o f this document.</t>
</section> </section>
</section> </section>
<section anchor="Security-Considerations"> <section anchor="Security-Considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC5440"/>, sect
ion 2.5 of <xref target="RFC6952"/>, <xref target="RFC8231"/>, <xref target="RFC <t>The Security Considerations described in <xref target="RFC5440"/>,
8281"/>, <xref target="RFC8253"/> and <xref target="RFC8664"/> are applicable to <xref target="RFC6952" sectionFormat="of" section="2.5"/>,
this specification.</t> <xref target="RFC8231"/>, <xref target="RFC8281"/>, <xref
target="RFC8253"/>, and <xref target="RFC8664"/> are applicable to this
specification.</t>
<t>Note that this specification enables a network controller to <t>Note that this specification enables a network controller to
instantiate an SRv6 path in the network. This creates an additional instantiate an SRv6 path in the network. This creates an additional
vulnerability if the security mechanisms of <xref target="RFC5440"/>, <xref targ vulnerability if the security mechanisms of <xref target="RFC5440"/>,
et="RFC8231"/>, and <xref target="RFC8281"/> <xref target="RFC8231"/>, and <xref target="RFC8281"/> are not used. If
are not used. If there is no integrity protection on the there is no integrity protection on the session, then an attacker could
session, then an attacker could create an SRv6 path that may not subjected create an SRv6 path that may not be subjected to the further verification
to the further verification checks. Further, the MSD field in the Open message checks. Further, the MSD field in the Open message could disclose node
could disclose node forwarding capabilities if suitable security mechanisms forwarding capabilities if suitable security mechanisms are not in
are not in place. Hence, securing the PCEP session using Transport Layer Securit place. Hence, securing the PCEP session using Transport Layer Security
y (TLS) <xref target="RFC8253"/> is <bcp14>RECOMMENDED</bcp14>.</t> (TLS) <xref target="RFC8253"/> is <bcp14>RECOMMENDED</bcp14>.</t>
</section> </section>
<section anchor="Manage"> <section anchor="Manage">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<t>All manageability requirements and considerations listed in <xref targe <t>All manageability requirements and considerations listed in <xref
t="RFC5440"/>, <xref target="RFC8231"/>, target="RFC5440"/>, <xref target="RFC8231"/>, <xref target="RFC8281"/>,
<xref target="RFC8281"/>, and <xref target="RFC8664"/> apply to PCEP protocol ex and <xref target="RFC8664"/> apply to PCEP protocol extensions defined
tensions defined in this in this document. In addition, requirements and considerations listed in
document. In addition, requirements and considerations listed in this this section apply.</t>
section apply.</t>
<section anchor="control-of-function-and-policy"> <section anchor="control-of-function-and-policy">
<name>Control of Function and Policy</name> <name>Control of Function and Policy</name>
<t>A PCEP implementation <bcp14>SHOULD</bcp14> allow the operator to con figure the SRv6 capability. <t>A PCEP implementation <bcp14>SHOULD</bcp14> allow the operator to con figure the SRv6 capability.
Further a policy to accept NAI only for the SRv6 <bcp14>SHOULD</bcp14> be allowe d to be set.</t> Further, a policy to accept NAI only for the SRv6 <bcp14>SHOULD</bcp14> be allow ed to be set.</t>
</section> </section>
<section anchor="information-and-data-models"> <section anchor="information-and-data-models">
<name>Information and Data Models</name> <name>Information and Data Models</name>
<t>The PCEP YANG module is out of the scope of this document and defined in other documents, for example, <xref target="I-D.ietf-pce-pcep-yang"/>. An au gmented YANG module for SRv6 is also specified in another document <xref target= "I-D.ietf-pce-pcep-srv6-yang"/> that allows for SRv6 capability and MSD configur ations as well as to monitor the SRv6 paths set in the network.</t> <t>The PCEP YANG module is out of the scope of this document; it is defi ned in other documents, for example, <xref target="I-D.ietf-pce-pcep-yang"/>. An augmented YANG module for SRv6 is also specified in <xref target="I-D.ietf-pce- pcep-srv6-yang"/> that allows for SRv6 capability and MSD configurations as well as to monitor the SRv6 paths set in the network.</t>
</section> </section>
<section anchor="liveness-detection-and-monitoring"> <section anchor="liveness-detection-and-monitoring">
<name>Liveness Detection and Monitoring</name> <name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness <t>Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in <xref target="RFC5440"/>.</t> listed in <xref target="RFC5440"/>.</t>
</section> </section>
<section anchor="verify-correct-operations"> <section anchor="verify-correct-operations">
<name>Verify Correct Operations</name> <name>Verify Correct Operations</name>
<t>Verification of the mechanisms defined in this document can be built on those already listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, a nd <xref target="RFC8664"/>.</t> <t>Verification of the mechanisms defined in this document can be built on those already listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, a nd <xref target="RFC8664"/>.</t>
</section> </section>
<section anchor="requirements-on-other-protocols"> <section anchor="requirements-on-other-protocols">
<name>Requirements On Other Protocols</name> <name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new <t>Mechanisms defined in this document do not imply any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section anchor="impact-on-network-operations"> <section anchor="impact-on-network-operations">
<name>Impact On Network Operations</name> <name>Impact on Network Operations</name>
<t>Mechanisms defined in <xref target="RFC5440"/>, <xref target="RFC8231 <t>Mechanisms defined in <xref target="RFC5440"/>, <xref
"/>, and <xref target="RFC8664"/> also apply to PCEP target="RFC8231"/>, and <xref target="RFC8664"/> also apply to PCEP
extensions defined in this document.</t> extensions defined in this document.</t>
</section>
</section>
<section anchor="implementation-status">
<name>Implementation Status</name>
<t>[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to <xref target="RFC7942"/>.</t>
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>
.
The description of implementations in this section
is intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF. Furthermore,
no effort has been spent to verify the information presented here that
was supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit".</t>
<section anchor="ciscos-commercial-delivery">
<name>Cisco's Commercial Delivery</name>
<ul spacing="normal">
<li>
<t>Organization: Cisco Systems, Inc.</t>
</li>
<li>
<t>Implementation: IOS-XR PCE and PCC.</t>
</li>
<li>
<t>Description: Implementation with experimental codepoints.</t>
</li>
<li>
<t>Maturity Level: Production</t>
</li>
<li>
<t>Coverage: Partial</t>
</li>
<li>
<t>Contact: ssidor@cisco.com</t>
</li>
</ul>
</section>
<section anchor="huaweis-commercial-delivery">
<name>Huawei's Commercial Delivery</name>
<ul spacing="normal">
<li>
<t>Organization: Huawei Technologies Co.,Ltd.</t>
</li>
<li>
<t>Implementation: Huawei Routers and NCE Controller</t>
</li>
<li>
<t>Description: Huawei has Implemented this draft to support PCE-Ini
tiated SRv6 Policy.</t>
</li>
<li>
<t>Maturity Level: Production</t>
</li>
<li>
<t>Coverage: Partial</t>
</li>
<li>
<t>Contact: yuwei.yuwei@huawei.com</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="IANA-Considerations"> <section anchor="IANA-Considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="PCEP-ERO-and-RRO-subobjects"> <section anchor="PCEP-ERO-and-RRO-subobjects">
<name>PCEP ERO and RRO subobjects</name> <name>PCEP ERO and RRO Subobjects</name>
<t>This document defines a new subobject type for the PCEP explicit <!-- [rfced] Section 8.1: As the PCEP ERO and RRO subobjects have been registere
route object (ERO), and a new subobject type for the PCEP reported route d in 2 different registries, we have updated the text to include 2 tables. The
object (RRO). The code points for subobject types of these objects is registry is complicated, so we hope these updates clarify the details for the re
maintained in the RSVP parameters registry, under the EXPLICIT_ROUTE aders.
and REPORTED_ROUTE objects. IANA is requested to confirm the following allocatio
ns in the RSVP Parameters registry for each of the new subobject types
defined in this document.</t>
<artwork><![CDATA[
Object Subobject Subobject Type
--------------------- -------------------------- ------------------
EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) 40
ROUTE_RECORD SRv6-RRO (PCEP-specific) 40
]]></artwork> Note that the original text referred to "REPORTED_ROUTE", which we think should
have been "ROUTE_RECORD". This sentence no longer appears in the text, so pleas
e let us know if mistakenly removed any vital information.
Original:
The code points for subobject types of these
objects is maintained in the RSVP parameters registry, under the
EXPLICIT_ROUTE and REPORTED_ROUTE objects.
-->
<t>This document defines a new subobject type for the PCEP Explicit
Route Object (ERO) and a new subobject type for the PCEP Reported
Route Object (RRO). These have been registered in the “Resource Reservat
ion
Protocol (RSVP) Parameters” registry group as shown below.</t>
<t>IANA has allocated the following new subobject in the "Subobject type - 20 EX
PLICIT_ROUTE - Type 1 Explicit Route" registry: </t>
<table anchor="iana-1" align="center">
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>40</td>
<td>SRv6-ERO (PCEP-specific)</td>
</tr>
</tbody>
</table>
<t>IANA has allocated the following new subobject in the "Subobject type - 21 RO
UTE_RECORD - Type 1 Route Record" registry: </t>
<table anchor="iana-2" align="center">
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>40</td>
<td>SRv6-RRO (PCEP-specific)</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANA-NAI"> <section anchor="IANA-NAI">
<name>New SRv6-ERO NAI Type Registry</name> <name>New SRv6-ERO NAI Type Registry</name>
<t>IANA is requested to create a new sub-registry, named "PCEP SRv6-ERO <t>IANA has created the "PCEP SRv6-ERO NAI Types" registry within the "P
NAI Types", within the "Path Computation Element Protocol (PCEP) Numbers" regist ath Computation Element Protocol (PCEP) Numbers" registry group to manage the 4-
ry to manage the 4-bit NT field in SRv6-ERO subobject. The allocation policy for bit NT field in the SRv6-ERO subobject. The registration policy is IETF Review <
this new registry is by IETF Review<xref target="RFC8126"/>.The new registry co xref target="RFC8126"/>. IANA has registered the values in <xref target="iana-3"
ntains the following values.</t> />.</t>
<artwork><![CDATA[
Value Description Reference <!-- [rfced] As the unassigned values may eventually be allocated, we have remov
----- ----------- --------- ed the "Unassigned" values from the "PCEP SRv6-ERO NAI Types" table (table 3).
0 NAI is absent. This document Please let us know any concerns.
1 Unassigned -->
2 NAI is an IPv6 node ID. This document
3 Unassigned <table anchor="iana-3" align="center">
4 NAI is an IPv6 adjacency This document <name></name>
with global IPv6 addresses. <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>NAI is absent.</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>2</td>
<td>NAI is an IPv6 node ID.</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>4</td>
<td>NAI is an IPv6 adjacency with global IPv6 addresses.</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>6</td>
<td>NAI is an IPv6 adjacency with link-local IPv6 addresses.</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
5 Unassigned
6 NAI is an IPv6 adjacency This document
with link-local IPv6 addresses.
7-15 Unassigned
]]></artwork>
</section> </section>
<section anchor="SRv6-ERO-flag"> <section anchor="SRv6-ERO-flag">
<name>New SRv6-ERO Flag Registry</name> <name>New SRv6-ERO Flag Registry</name>
<t>IANA is requested to create a new sub-registry, named "SRv6-ERO <t>IANA has created the "SRv6-ERO Flag Field" registry within the "Path
Flag Field", within the "Path Computation Element Protocol (PCEP) Computation Element Protocol (PCEP) Numbers" registry group to manage the 12-bit
Numbers" registry to manage the 12-bit Flag field of the SRv6-ERO subobject. Flag field of the SRv6-ERO subobject. New values are to be assigned by Standar
New values are to be assigned by Standards Action <xref target="RFC8126"/>. ds Action <xref target="RFC8126"/>. Each registration should include the followi
Each bit should be tracked with the following qualities.</t> ng information:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Bit (counting from bit 0 as the most significant <t>Bit (counting from bit 0 as the most significant
bit)</t> bit)</t>
</li> </li>
<li> <li>
<t>Description</t> <t>Description</t>
</li> </li>
<li> <li>
<t>Reference</t> <t>Reference</t>
</li> </li>
</ul> </ul>
<t>The following values are defined in this document.</t> <t>The following values are defined in this document:</t>
<artwork><![CDATA[
Bit Description Reference <table anchor="iana-4">
----- ------------------ -------------- <name></name>
0-7 Unassigned <thead>
8 SID Verification (V) This document <tr>
9 SID Structure is This document <th>Bit</th>
present (T) <th>Description</th>
10 NAI is absent (F) This document <th>Reference</th>
11 SID is absent (S) This document </tr>
]]></artwork> </thead>
<tbody>
<!-- [rfced] Similar to above, we have removed the "Unassigned" row from the tab
le of initial entries in the "SRv6-ERO Flag Field" registry. Please let us know
any concerns.
-->
<tr>
<td>8</td>
<td>SID Verification (V)</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>9</td>
<td>SID Structure is present (T)</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>10</td>
<td>NAI is absent (F)</td>
<td>RFC 9603</td>
</tr>
<tr>
<td>11</td>
<td>SID is absent (S)</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="lsp-error-code-tlv"> <section anchor="lsp-error-code-tlv">
<name>LSP-ERROR-CODE TLV</name> <name>LSP-ERROR-CODE TLV</name>
<t>This document defines a new value in the sub-registry "LSP-ERROR-CODE <t>This document defines a new value in "LSP-ERROR-CODE TLV Error Code F
TLV Error Code Field" in the "Path Computation Element Protocol(PCEP) Numbers" ield" registry within the "Path Computation Element Protocol (PCEP) Numbers" reg
registry.</t> istry group.</t>
<artwork><![CDATA[
Value Meaning Reference <table anchor="iana-5">
--- ----------------------- ----------- <name></name>
TBD SID Verification fails This document <thead>
]]></artwork> <tr>
<th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>10</td>
<td>SID Verification fails</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sub-TLV-Type-Indicators"> <section anchor="sub-TLV-Type-Indicators">
<name>PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</name> <name>PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators</name>
<t>IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY <t>IANA maintains the "PATH-SETUP-TYPE-CAPABILITY
Sub-TLV Type Indicators", within the "Path Computation Element Sub-TLV Type Indicators" registry within the "Path Computation Element
Protocol (PCEP) Numbers" registry to manage the type indicator space Protocol (PCEP) Numbers" registry group to manage the type indicator space
for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA has registered the foll
confirm the following allocations in the sub-registry.</t> owing value:</t>
<artwork><![CDATA[
Value Meaning Reference <table anchor="iana-6">
----- ------- --------- <name></name>
27 SRv6-PCE-CAPABILITY This Document <thead>
]]></artwork> <tr>
<th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>27</td>
<td>SRv6-PCE-CAPABILITY</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="SRv6-PCE-Capability-Flags"> <section anchor="SRv6-PCE-Capability-Flags">
<name>SRv6 PCE Capability Flags</name> <name>SRv6 PCE Capability Flags</name>
<t>IANA is requested to create a new sub-registry, named "SRv6 <t>IANA has created the "SRv6
Capability Flag Field", within the "Path Computation Element Protocol (PCEP) Num Capability Flag Field" registry within the "Path Computation Element Protocol (P
bers" registry to manage the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TL CEP) Numbers" registry group to manage the 16-bit Flag field of the SRv6-PCE-CAP
V. New values are to be assigned by Standards Action <xref target="RFC8126"/>. E ABILITY sub-TLV. New values are to be assigned by Standards Action <xref target=
ach bit should be tracked with the following qualities.</t> "RFC8126"/>. Each registration should include the following information:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Bit (counting from bit 0 as the most significant <t>Bit (counting from bit 0 as the most significant
bit)</t> bit)</t>
</li> </li>
<li> <li>
<t>Description</t> <t>Description</t>
</li> </li>
<li> <li>
<t>Reference</t> <t>Reference</t>
</li> </li>
</ul> </ul>
<t>The following values are defined in this document.</t> <t>The following value is defined in this document.</t>
<artwork><![CDATA[
Bit Description Reference <table anchor="iana-7">
----- ------------------ -------------- <name></name>
0-13 Unassigned <thead>
14 Node or Adjacency This document <tr>
Identifier (NAI) is <th>Bit</th>
supported (N) <th>Description</th>
15 Unassigned <th>Reference</th>
]]></artwork> </tr>
</thead>
<tbody>
<!-- [rfced] We have also removed the "Unassigned" rows from the "SRv6 Capabilit
y Flag Field" registry table. Please let us know if you have any concerns.
-->
<tr>
<td>14</td>
<td>Node or Adjacency Identifier (NAI) is supported (N)</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="New-Path-Setup-Type"> <section anchor="New-Path-Setup-Type">
<name>New Path Setup Type</name> <name>New Path Setup Type</name>
<t><xref target="RFC8408"/> created a sub-registry within the "Path <t><xref target="RFC8408"/> created the "PCEP Path Setup Types" registry
Computation Element Protocol (PCEP) Numbers" registry called "PCEP within the "Path Computation Element Protocol (PCEP) Numbers" registry group. I
Path Setup Types". IANA is requested to confirm the following allocations ANA has allocated
in the sub-registry.</t> the following value:</t>
<artwork><![CDATA[
Value Description Reference <table anchor="iana-8">
3 Traffic engineering path is This Document <name></name>
setup using SRv6. <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>3</td>
<td>Traffic engineering path is set up using SRv6.</td>
<td>RFC 9603</td>
</tr>
</tbody>
</table>
]]></artwork>
</section> </section>
<section anchor="ERROR-Objects"> <section anchor="ERROR-Objects">
<name>ERROR Objects</name> <name>ERROR Objects</name>
<t>IANA is requested to confirm the following allocations in the PCEP-ER <t>IANA has allocated the following Error-values in the "PCEP-ERROR
ROR Object Error Types and Values" registry within the "Path Computation Element Pro
Object tocol (PCEP) Numbers" registry group:</t>
Error Types and Values registry for the following new error-values.</t>
<artwork><![CDATA[
Error-Type Meaning
---------- -------
10 Reception of an invalid object
Error-value = 34 (Missing
PCE-SRv6-CAPABILITY sub-TLV)
Error-value = 35 (Both SID and NAI are absent
in SRv6-RRO subobject)
Error-value = 36 (RRO mixes SRv6-RRO subobjects
with other subobject types)
Error-value = 37 (Invalid SRv6 SID Structure)
19 Invalid Operation
Error-value = 19 (Attempted SRv6 when the
capability was not advertised)
]]></artwork> <!-- [rfced] We have combined the tables that register Error-values in the "PCEP
<t>IANA is requested to make new allocations in the PCEP-ERROR Object -ERROR Object Error Types and Values". We do not believe the reader needs to kno
Error Types and Values registry for the following new error-values.</t> w that some values were registered via early allocation. In addition, our under
<artwork><![CDATA[ standing is that this document permanently registers all of the values. Please
Error-Type Meaning review table 9 and let us know if you have any objections.
---------- -------
10 Reception of an invalid object
Error-value = TBD (Unsupported number of
SRv6-ERO subobjects)
Error-value = TBD (Unsupported NAI Type
in the SRv6-ERO/SRv6-RRO subobject)
Error-value = TBD (Both SID and NAI are
absent in the SRv6-ERO subobject)
Error-value = TBD (ERO mixes SRv6-ERO
subobjects with other subobject types)
Error-value = TBD (Unsupported number
of SRv6-ERO subobjects)
]]></artwork> As noted above, the meaning for values 40 and 44 are identical. Please review a
nd let us know what updates are needed.
Current:
40: Unsupported number of SRv6-ERO subobjects
44: Unsupported number of SRv6-ERO subobjects
-->
<table anchor="iana-9">
<name></name>
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="8">10</td>
<td rowspan="8">Reception of an invalid object</td>
<td>34: Missing PCE-SRv6-CAPABILITY sub-TLV</td></tr>
<tr><td>35: Both SID and NAI are absent in SRv6-RRO subobject</td>
</tr>
<tr><td>36: RRO mixes SRv6-RRO subobjects with other subobject typ
es</td></tr>
<tr><td>37: Invalid SRv6 SID Structure</td></tr>
<tr><td>40: Unsupported number of SRv6-ERO subobjects</td></tr>
<tr><td>41: Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject
</td></tr>
<tr><td>42: Both SID and NAI are absent in the SRv6-ERO subobject</
td></tr>
<tr><td>43: ERO mixes SRv6-ERO subobjects with other subobject type
s</td></tr>
<tr>
<td>19</td><td>Invalid Operation</td><td>
19: Attempted SRv6 when the capability was not advertised</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
<displayreference target="I-D.ietf-pce-pcep-srv6-yang" to="PCEP-SRv6-YANG"/>
<references> <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="RFC3209">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.32
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title> 09.xml"/>
<author fullname="D. Awduche" initials="D." surname="Awduche"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.54
<author fullname="L. Berger" initials="L." surname="Berger"/> 40.xml"/>
<author fullname="D. Gan" initials="D." surname="Gan"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="T. Li" initials="T." surname="Li"/> 26.xml"/>
<author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
> 31.xml"/>
<author fullname="G. Swallow" initials="G." surname="Swallow"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<date month="December" year="2001"/> 81.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<t>This document describes the use of RSVP (Resource Reservation P 08.xml"/>
rotocol), including all the necessary extensions, to establish label-switched pa <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
ths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP 91.xml"/>
is completely identified by the label applied at the ingress node of the path, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
these paths may be treated as tunnels. A key application of LSP tunnels is traff 53.xml"/>
ic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
</abstract> 64.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
<seriesInfo name="RFC" value="3209"/> 86.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
</reference> 14.xml"/>
<reference anchor="RFC5440"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Path Computation Element (PCE) Communication Protocol (PCEP)< <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
/title> 74.xml"/>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname=
"Vasseur"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname=
"Le Roux"/>
<date month="March" year="2009"/>
<abstract>
<t>This document specifies the Path Computation Element (PCE) Comm
unication 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 state
s related to the use of a PCE in the context of Multiprotocol Label Switching (M
PLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be fl
exible and extensible so as to easily allow for the addition of further messages
and objects, should further requirements be expressed in the future. [STANDARDS
-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5440"/>
<seriesInfo name="DOI" value="10.17487/RFC5440"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n 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 Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
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="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="RFC8408">
<front>
<title>Conveying Path Setup Type in PCE Communication Protocol (PCEP
) Messages</title>
<author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<author fullname="I. Minei" initials="I." surname="Minei"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<author fullname="J. Hardwick" initials="J." surname="Hardwick"/>
<date month="July" year="2018"/>
<abstract>
<t>A Path Computation Element (PCE) can compute Traffic Engineerin
g (TE) paths through a network; these paths are subject to various constraints.
Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RS
VP-TE signaling protocol. However, other TE path setup methods are possible with
in the PCE architecture. This document proposes an extension to the PCE Communic
ation Protocol (PCEP) to allow support for different path setup methods over a g
iven PCEP session.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8408"/>
<seriesInfo name="DOI" value="10.17487/RFC8408"/>
</reference>
<reference anchor="RFC8491">
<front>
<title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
<author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
<author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
<author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<date month="November" year="2018"/>
<abstract>
<t>This document defines a way for an Intermediate System to Inter
mediate System (IS-IS) router to advertise multiple types of supported Maximum S
ID Depths (MSDs) at node and/or link granularity. Such advertisements allow enti
ties (e.g., centralized controllers) to determine whether a particular Segment I
D (SID) stack can be supported in a given network. This document only defines on
e type of MSD: Base MPLS Imposition. However, it defines an encoding that can su
pport other MSD types. This document focuses on MSD use in a network that is Seg
ment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="8491"/>
<seriesInfo name="DOI" value="10.17487/RFC8491"/>
</reference>
<reference anchor="RFC8253">
<front>
<title>PCEPS: Usage of TLS to Provide a Secure Transport for the Pat
h Computation Element Communication Protocol (PCEP)</title>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="D. Dhody" initials="D." surname="Dhody"/>
<date month="October" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) defi
nes the mechanisms for the communication between a Path Computation Client (PCC)
and a Path Computation Element (PCE), or among PCEs. This document describes PC
EPS -- the usage of Transport Layer Security (TLS) to provide a secure transport
for PCEP. The additional security mechanisms are provided by the transport prot
ocol supporting PCEP; therefore, they do not affect the flexibility and extensib
ility of PCEP.</t>
<t>This document updates RFC 5440 in regards to the PCEP initializ
ation phase procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8253"/>
<seriesInfo name="DOI" value="10.17487/RFC8253"/>
</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="RFC8986">
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="P. Camarillo" initials="P." role="editor" surname=
"Camarillo"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="February" year="2021"/>
<abstract>
<t>The Segment Routing over IPv6 (SRv6) Network Programming framew
ork enables a network operator or an application to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet header.</t>
<t>Each instruction is implemented on one or several nodes in the
network and identified by an SRv6 Segment Identifier in the packet.</t>
<t>This document defines the SRv6 Network Programming concept and
specifies the base set of SRv6 behaviors that enables the creation of interopera
ble overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
<reference anchor="RFC9514">
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for
Segment Routing over IPv6 (SRv6)</title>
<author fullname="G. Dawra" initials="G." surname="Dawra"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="M. Chen" initials="M." surname="Chen"/>
<author fullname="D. Bernier" initials="D." surname="Bernier"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<date month="December" year="2023"/>
<abstract>
<t>Segment Routing over IPv6 (SRv6) allows for a flexible definiti
on of end-to-end paths within various topologies by encoding paths as sequences
of topological or functional sub-paths called "segments". These segments are adv
ertised by various protocols such as BGP, IS-IS, and OSPFv3.</t>
<t>This document defines extensions to BGP - Link State (BGP-LS) t
o advertise SRv6 segments along with their behaviors and other attributes via BG
P. The BGP-LS address-family solution for SRv6 described in this document is sim
ilar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9514"/>
<seriesInfo name="DOI" value="10.17487/RFC9514"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4657">
<front>
<title>Path Computation Element (PCE) Communication Protocol Generic
Requirements</title>
<author fullname="J. Ash" initials="J." role="editor" surname="Ash"/
>
<author fullname="J.L. Le Roux" initials="J.L." role="editor" surnam
e="Le Roux"/>
<date month="September" year="2006"/>
<abstract>
<t>The PCE model is described in the "PCE Architecture" document a
nd facilitates path computation requests from Path Computation Clients (PCCs) to
Path Computation Elements (PCEs). This document specifies generic requirements
for a communication protocol between PCCs and PCEs, and also between PCEs where
cooperation between PCEs is desirable. Subsequent documents will specify applica
tion-specific requirements for the PCE communication protocol. This memo provide
s information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4657"/>
<seriesInfo name="DOI" value="10.17487/RFC4657"/>
</reference>
<reference anchor="RFC6952">
<front>
<title>Analysis of BGP, LDP, PCEP, and MSDP Issues According to the
Keying and Authentication for Routing Protocols (KARP) Design Guide</title>
<author fullname="M. Jethanandani" initials="M." surname="Jethananda
ni"/>
<author fullname="K. Patel" initials="K." surname="Patel"/>
<author fullname="L. Zheng" initials="L." surname="Zheng"/>
<date month="May" year="2013"/>
<abstract>
<t>This document analyzes TCP-based routing protocols, the Border
Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computat
ion Element Communication Protocol (PCEP), and the Multicast Source Distribution
Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying an
d Authentication for Routing Protocols Design Guidelines", RFC 6518.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6952"/>
<seriesInfo name="DOI" value="10.17487/RFC6952"/>
</reference>
<reference anchor="RFC7942">
<front>
<title>Improving Awareness of Running Code: The Implementation Statu
s Section</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="July" year="2016"/>
<abstract>
<t>This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by including an I
mplementation Status section. This will allow reviewers and working groups to as
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.</t>
<t>This process is not mandatory. Authors of Internet-Drafts are e
ncouraged to consider using the process for their documents, and working groups
are invited to think about applying the process to all of their protocol specifi
cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
ce.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="205"/>
<seriesInfo name="RFC" value="7942"/>
<seriesInfo name="DOI" value="10.17487/RFC7942"/>
</reference>
<reference anchor="RFC8051">
<front>
<title>Applicability of a Stateful Path Computation Element (PCE)</t
itle>
<author fullname="X. Zhang" initials="X." role="editor" surname="Zha
ng"/>
<author fullname="I. Minei" initials="I." role="editor" surname="Min
ei"/>
<date month="January" year="2017"/>
<abstract>
<t>A stateful Path Computation Element (PCE) maintains information
about Label Switched Path (LSP) characteristics and resource usage within a net
work in order to provide traffic-engineering calculations for its associated Pat
h Computation Clients (PCCs). This document describes general considerations for
a stateful PCE deployment and examines its applicability and benefits, as well
as its challenges and limitations, through a number of use cases. PCE Communicat
ion Protocol (PCEP) extensions required for stateful PCE usage are covered in se
parate documents.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8051"/>
<seriesInfo name="DOI" value="10.17487/RFC8051"/>
</reference>
<reference anchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="July" year="2018"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A n
ode steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segment
can have a semantic local to an SR node or global within an SR domain. SR provi
des a mechanism that allows a flow to be restricted to a specific topological pa
th, while maintaining per-flow state only at the ingress node(s) to the SR domai
n.</t>
<t>SR can be directly applied to the MPLS architecture with no cha
nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
ist of segments is encoded as a stack of labels. The segment to process is on th
e top of the stack. Upon completion of a segment, the related label is popped fr
om the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of
routing header. A segment is encoded as an IPv6 address. An ordered list of segm
ents is encoded as an ordered list of IPv6 addresses in the routing header. The
active segment is indicated by the Destination Address (DA) of the packet. The n
ext active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8754">
<front>
<title>IPv6 Segment Routing Header (SRH)</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="D. Dukes" initials="D." role="editor" surname="Duk
es"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<date month="March" year="2020"/>
<abstract>
<t>Segment Routing can be applied to the IPv6 data plane using a n
ew type of Routing Extension Header called the Segment Routing Header (SRH). Thi
s document describes the SRH and how it is used by nodes that are Segment Routin
g (SR) capable.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8754"/>
<seriesInfo name="DOI" value="10.17487/RFC8754"/>
</reference>
<reference anchor="RFC9256">
<front>
<title>Segment Routing Policy Architecture</title>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
<author fullname="P. Mattes" initials="P." surname="Mattes"/>
<date month="July" year="2022"/>
<abstract>
<t>Segment Routing (SR) allows a node to steer a packet flow along
any path. Intermediate per-path states are eliminated thanks to source routing.
SR Policy is an ordered list of segments (i.e., instructions) that represent a
source-routed policy. Packet flows are steered into an SR Policy on a node where
it is instantiated called a headend node. The packets steered into an SR Policy
carry an ordered list of segments associated with that SR Policy.</t>
<t>This document updates RFC 8402 as it details the concepts of SR
Policy and steering into an SR Policy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
<reference anchor="RFC9352">
<front>
<title>IS-IS Extensions to Support Segment Routing over the IPv6 Dat
a Plane</title>
<author fullname="P. Psenak" initials="P." role="editor" surname="Ps
enak"/>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="Z. Hu" initials="Z." surname="Hu"/>
<date month="February" year="2023"/>
<abstract>
<t>The Segment Routing (SR) architecture allows a flexible definit
ion of the end-to-end path by encoding it as a sequence of topological elements
called "segments". It can be implemented over the MPLS or the IPv6 data plane. T
his document describes the IS-IS extensions required to support SR over the IPv6
data plane.</t>
<t>This document updates RFC 7370 by modifying an existing registr
y.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9352"/>
<seriesInfo name="DOI" value="10.17487/RFC9352"/>
</reference>
<reference anchor="I-D.ietf-pce-pcep-yang">
<front>
<title>A YANG Data Model for Path Computation Element Communications
Protocol (PCEP)</title>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization>
</author>
<author fullname="Vishnu Pavan Beeram" initials="V. P." surname="Bee
ram">
<organization>Juniper Networks</organization>
</author>
<author fullname="Jonathan Hardwick" initials="J." surname="Hardwick
">
<organization>Microsoft</organization>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Nvidia</organization>
</author>
<date day="18" month="March" year="2024"/>
<abstract>
<t> This document defines a YANG data model for the management o
f Path
Computation Element communications Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs. The data model includes
configuration and state data.
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.46
</abstract> 57.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-23"/ 52.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
</reference> 51.xml"/>
<reference anchor="I-D.ietf-pce-pcep-srv6-yang"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<front> 02.xml"/>
<title>A YANG Data Model for Segment Routing (SR) Policy and SR in I <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
Pv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)</t 54.xml"/>
itle> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
<author fullname="Cheng Li" initials="C." surname="Li"> 56.xml"/>
<organization>Huawei Technologies</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
</author> 52.xml"/>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Ciena Corporation</organization> <!-- [I-D.ietf-pce-pcep-yang] IESG state: Publication Requested as of 06/07/24--
</author> >
<author fullname="Shuping Peng" initials="S." surname="Peng"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
<organization>Huawei Technologies</organization> e-pcep-yang.xml"/>
</author>
<author fullname="Mike Koldychev" initials="M." surname="Koldychev"> <!-- [I-D.ietf-pce-pcep-srv6-yang] IESG state: I-D Exists as of 06/07/24-->
<organization>Cisco Systems, Inc.</organization> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
</author> e-pcep-srv6-yang.xml"/>
<author fullname="Luc-Fabrice Ndifor" initials="L." surname="Ndifor"
>
<organization>MTN Cameroon</organization>
</author>
<date day="18" month="March" year="2024"/>
<abstract>
<t> This document augments a YANG data model for the management
of Path
Computation Element Communications Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs in support for Segment Routing in
IPv6 (SRv6) and SR Policy. The data model includes configuration
data and state data (status information and counters for the
collection of statistics).
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-srv6-yang
-05"/>
</reference>
</references> </references>
</references> </references>
<?line 986?>
<section numbered="false" anchor="acknowledgements"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun <t>The authors would like to thank <contact fullname="Jeff Tantsura"/>,
Wang, Khasanov Boris, Ketan Talaulikar, Martin Vigoureux, Hariharan Ananthakrish <contact fullname="Adrian Farrel"/>, <contact fullname="Aijun Wang"/>,
nan, Xinyue Zhang, John Scudder, Julien Meuric and Robert Varga for valuable sug <contact fullname="Khasanov Boris"/>, <contact fullname="Ketan
gestions.</t> Talaulikar"/>, <contact fullname="Martin Vigoureux"/>, <contact
<t>Thanks to Gunter Van de Velde, Eric Vyncke, Jim Guichard, and Mahesh Je fullname="Hariharan Ananthakrishnan"/>, <contact fullname="Xinyue
thanandani for their comments during the IESG review.</t> Zhang"/>, <contact fullname="John Scudder"/>, <contact fullname="Julien
Meuric"/>, and <contact fullname="Robert Varga"/> for valuable
suggestions.</t>
<t>Thanks to <contact fullname="Gunter Van de Velde"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Jim Guichard"/>, and
<contact fullname="Mahesh Jethanandani"/> for their comments during the
IESG review.</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="M. S." surname="Negi" fullname="Mahendra Singh Negi"> <contact initials="M. S." surname="Negi" fullname="Mahendra Singh Negi">
<organization>RtBrick Inc</organization> <organization>RtBrick Inc</organization>
<address> <address>
<postal> <postal>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mahend.ietf@gmail.com</email> <email>mahend.ietf@gmail.com</email>
skipping to change at line 1363 skipping to change at line 1219
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<country>China</country> <country>China</country>
</postal> </postal>
<email>chen.ran@zte.com.cn</email> <email>chen.ran@zte.com.cn</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+192XYbR5bge3xFNPUgsBqASYqkJE7ZbYqLxSpuA0JyuXx8
+iSQQSAtIBOVCylY1nzLfEt/Wd8l1swESC3u6anTrFMymZkRcePG3ePeiF6v
J+4O5DMRZ+M0mqsDGefRbdlLVHnbW4xVr1CTuUrLXp5VZZJOesnibr+3syfG
UXkgizIWRZmraH4gz06Gp2KcpYVKi6o4kGVeKbFIDoSUZTY+kE+XqnjKf2Tz
RTQug0exWpRTeLKr/07SGEZ1nxTLea5uC+9Blpf6SZrhg/x2rOKiXM6U91E1
coPxZ43Bk0WeZmVym6gYHv6kG5Z5YhuVSYmdXkflVB5B86qMyiRL5clMIWrw
2bxKkzE/vc4znOJMdq6PTq435cn7EjACbwp5m+Xy7PpuX94wUuWAkSqi0ShX
sAzYonczuNsXESD1wL6/n9A7+WOWv4O/5Q+wGgsRVeU0yw9ETyYp4OGoL88T
gJ2X8Wiq4MPzpHMSJ2WWb8KLLIduXlfRvUrkUI2naTbLJokqeL5KlfbtUQSz
LLryMuvL7b19+Uol/8BxB3EfUZiUywN89ivChiiNEefbW1tbL/cYx1Va5ksE
IkkjeKDmUTI7kOP+7PspjdCHZTBwX/f/Gs2ieBrlUWrBv87VrwDRVAbvaAaD
8hUszjt5lo4dMFE6iWZZrpAQ1ASwfQAt8zQqo3eRD9FZGiceRAs9zPd5OcJO
fbhu+vImuYtGAICDC58Ejwmko0SlEdBBvshyogI3wryAj3de7Hw/wb/9/i/6
8q/ZLF6Op+rO9n+RvFPBY91/Mc7kzbIo1RyWBWbeD9AcpVHszWr+jjv4fozt
/DF/6su/Tys72k9ZOqGF5Yc8Fq4Z0MdMYTtHGttbL+WPqijhW2hVTKNUHt6p
rhwmUTpV8jhhnlm7JD9U8PC3aVb50F/3B/06pfw2rZb/ePH9GJ+WDEp/nAqU
LzDKqCqZ7jXOIqB1EFuwLulkKi9hsD+CVuY0TB8lY7CYDMTxNK/u4N8sXoas
tqbHGNus6vA14kr+WM2TVHwK776qklkMiPg07mXmXcO7UwTnHqEJWVizxbRa
4BDXivr8fw7tQiGJEkxt4A6AeFFAGlD/Pjypce9KEQat+iCMvv+tVH1DlSLN
8jm0vFOo7QanR892tl7qX/d2d7f0ry+2d/bNrzvPtu2vL+yvu1sv7K8v3Qd7
z8yv+/u75teXL0xnL/e24WmS3tag2N3fe65/3X+5t6N/ff5y1/z6YmvPG9o+
fb5nBnm5s2cHecY9nPWO+9Y4gP8veksgjPY3RQ62Ar8WotfryWgEyw/aV4ia
BpSdm8GmHMOyjJSsChWDDQCkolQuQVu/U2UhyykoPWDvSKaqvAdFCN9hyxKE
DylVUK4X1+c3MgZGlguQziCc1Hwxy5bmsyKr8rGS2pSBnvMoTibzvhCHgUqG
4UnZa3hilQNSY3mbZ3MY/i7KYZpLmd3KOdB2lCYFCuUkHc8qJGUJrc5+uAae
ABMFBSb1NQSyh1leDzcBqveLWQKUDVSW3iaTiqmuizOIVpoZaE5sAqgg5GAO
NwMDXbSAzhhhowyaEg6iNGakIDJ6hAwAMSIjogD5O4up6WimsN2YRlMIOPRL
AKCpsr67vhwCSlcaReO1RpEyRhF17dBIy14tgBFLAKVHg0+jOwXQqhQW4jZJ
VYwjJ4UEi7WioWDFZvC8oDVO1VgVRZQv3Ri1XmlulmrcjOR9UgKzkxHWZ3qd
J3E8U0I8Acld5llcjUk8iMPCwALLLj980Az08WO3btoxYUc5aLJSjcsqByzP
Ztl94RNkCkLNEXykSd6j+AViGUxiRCeMOVriUmU5ECb8NQPNi8QICh5sboIQ
1noMw8BLbb7Dah2a34lwcgWmT4F/RenSb9oFQBYkrqEHpMhC5XcJcPQoArbs
0nol3ActTAQfzKO0TMZylmETmAfTEc0KOpjMMjCWDHb5XZyBOE0By4Q7lJEf
PwJKizEod1jIz6QqXNjwixGICqScFrY6Aq6BHqHp0SbNirkD6d42WkRJjqiF
F4RB/QF+eSSzhULGRYYvdOMOTlBOE3iBK47owMcqvUvyLMUZbBpmK2hR2Scg
Mh+C33ULWDxJJ0BYIHLQfL+5LmQHX/dAQ+Ffm5LWQcIEUA5lVYFCBKVqAqtM
88gWZTJPfuNZAkJL6CsyqEbFA6guFmqMLk9R4xLEI9BdVDKV4uoCutRtxRMJ
ZEUMRITYBqPIimSeE2ABP5uBZThmtmIeQYUEg2NTZp9CZqNfgS0Y8OH5W4cP
M2Ewwj0Irn14F3l2lwCNFct0DKySmjnDgkFLhtynAFizR6xzF2CbqUnQFZmd
2ayLbANCBJcmGERrBhwByR/76ZpGM6t9VFktCAJiZ6OFoCPgCezL9nJiejla
M3vwEAHR8GeMqgmpMjUkmaVAeHNgvxkuxT0Q4pRJCdsYncNEhIDBOMzXGmKZ
3SmSkHOJYpaxwRqGPz8hjWmlNr6Il2BZIcHPUJokZYJooTEzg3tLuNhJrv5R
gW4szKQDMiMWM+gDUFjRB58AYIaGPRkMptTHj8CoQBvQjJ+ByYRyGWQWtFlk
RZForQdmRn1gLUAWemVSkl9zcBVQGQFBMnmDn4CvAfmwSmOyFFczI9E3mA/y
tkpZNvflFbKFkeqFYSkQrkQmPkAoZi06SXQaMBxeGTt18liFHYIKx4Gu9Dfj
xzQmNFopQn95UqTeASJSa1wSkBpwonKtfa2txtq3rtSps7jwR3+cGoflj+OE
mWC27Gr0gKwYqxiovrBqhiZX+oN2NUZZQRKBMtJhAMI5EasCeUZq2q4UTrYk
P7UgVOi5GPSyKMnVDDFleO5w+Lp3czJ8c90b/nR9grKPRYODs2URwD+gRWjp
XgtD1ESOMUksWOHscVQHjHBfc20ibtEKQE2OtAYoiJMYf3NqSpuHGdiuYP0S
9YupiuIeaQDU9rVuQbE64uzLU8NM1lVBCZtqajQdH3q2UheEpuK5oysCJMDC
jG3ewtq8xlREDOJqAYqePJEDWMIkJ8OhkOfghlTRRCHylHynlhJwAvS1cfHm
ZrjR5f/Kyyv6fXDyv9+cDU6O8feb14fn5/YXob+4eX315vzY/eZaHl1dXJxc
HnNjeCqDR2Lj4vCnDRa3G1fXw7Ory8PzjQYlkqTG2bGMz8FYQwkcFSKg3ldH
1//xf7d3AUP/Aija2d5+CSjiP15sP98lfKmUR8tSEM38JyB8KQCHKsqxF+AT
WO9FUkYzdBIK9BDuwbwD6xIQ+aefETO/HMg/j8aL7d3v9AOccPDQ4Cx4SDhr
Pmk0ZiS2PGoZxmIzeF7DdAjv4U/B3wbv3sM//xu6ELK3/eLfvhP480QOVT5P
KHKx1BxnVwdUBxvwtxmaSaTh4eumV8CW7QGrWLIKkBX4X3kNVl7/s7tG5x27
9g2Erjy2tgv0fFrlKKq6rf0hhZGnnTAHWiEoxMXN8YHAuNr7ZF7N5c3ZMfS7
KKfQpbi+GeI7MqdvyKIZLhdIJ+JmgC9q/g+9ODv235xhZB8FW86t7vZb2rEN
Uhft9P1r/LwtjC5fgzCyev/5HissGoHgbbQ7R8+pc679J351dlw454h1l/a+
9AfGeTF4Q6kKygp7CFh4U3gLkGYgScmuxia4AKQLffwTSQQyveiKe+Oqoyi7
i2YItXGw9Kxkx4JLEgIANh4h7SQYD3CzBWBPRVN/zvsF+r+6Q89P3WvD+Fpe
GesSv6PvL1mzgJZ+Yr7+KMSrqACbwtqirDzM9KJ3KmfiG1XJrET5HxoYZwwD
aDFw4ycYtkBLOVQaaDRFeZ447J2YkArFb+QVmV2yczK42uxqpYGmWYImJ1rc
oFhAv6MdRmgYaT+kH9gbhuVQhd6vG8L1AG1wrclH3wC1BG/dyw0UsxR0gUFx
AkttHAGDwcLdKxDEEXN/QkzCUSYKa4B6/SaKf43GAPRS+ksOI5EGhU4Q0VoX
9vEXM1yIfDRvJirF5SE/7htoRXYHWC9FheoVHG4fbjCp+AmSDpA+00s4t8LE
ozgOVqPrhvc9UAtQR+B8wy+bZq1XiM+u6weZ5szYwwNtopnW0Jt5t9kUl2T9
dn08+wBix28Wsd8tdAdPODZgvyFpi9CjEYrgL0oLfouMJm87JCpQspl1f5my
uDto51NWZ4CEpcM4gG34E1nfBW7MohO3k2y5R+7X4UBNFaR46GVSMB7BRKvA
PSShBp4M+L/6U5weMTbbUtpq7LPBZMWNc1coDGW9lJGSdTnUDFFRLy4kFWo+
gxPEiEdWG9gIaW2DjSb6c4B/GtYHxBinBpEEMCzY5wIKw4gFMpo2MlnC9+k3
wx0i5A4ybrzg6CpOgQ7BgfREhxA/TnWgAfuDb2oRqCD+ADMHIoNBkmKKrh/Z
sSEk6j3a8RNUHCrJWXYkMyBwtnxNPFC/5nfL0ElCdBsnzzigEX0W1RyhDx8I
JwBB78gMtOzB9HrgmhjBXFTzeZQvuzW3CYxEMBB8iqaJWICXWjCRYV7/1IlO
s9AIDvzn4W8H/O2g9VsicI65lGChALPeDDd9P6qmQsQql6zFXesdHV4fvjo7
Pxv+hJ+Rvnzi6UerOkEvmoe9zGnIMw6Qau3Z1Z6VHw32bBgOCxcuLsyBB98Z
A5KvZiUHJUi3sX2DbGfIEj6eKYCA5FRb9LuT9BUzxqYncD1/tBapRxXOTnqL
J90wa11sF7t24f86tRoLhIKtR5INB0vqILMxrrKC0gFME2vDPoRhQVYKMxMe
vJ5GwLh3SaQJxdG9W1RN96KD/mesQOnNikdwyaamBProJoiuXGgl5aWDfHgS
fNej7A/9Xc9997F1v8GoxiiwlnwjR0QUDM/QkyO7mD0AI7gxYkUyDozKCbDK
KIuXcg4fSuAYaD2H9Y7KLF8awYdxZYosWluptsQZCu+spNBJghsd6VKwBLO6
lk04tihBz2rdCvrP6dBm2ENPVTj1bqe7KsrVNT0vSv0bqHI7hmhrxpr6NSDo
Di32wAbFcKIxfIDqiNpQTwht7LSGc/SUB9eyY0yK6yiP5uDJ52CNk0SEd77/
Jls/ZImHmmwGHvtsKdg4vF2yYme+KWwwGGjwz//S6wHZy4wiVRTosJSi1Ys0
Tjwa1vjRVNHHWS6kpGWsUZZGQWERwJHbdKlH0WByexSKstf7jj1pbSqf0uKT
s0APevrBR+IZtDKurk8uzdcfnsCTHj7p8RP6jL9jawTw5ZjQsKzhqhUs2pRL
gdoKvdoWnWEUGRmSzFAFKR/4Un4rn0ntGmN8jvrhAJjWfeIwXINQrhlhpk1+
o6/XBCyRk8Hg4l3nB5SUoUfCsV4s2pqhHmn2MIWNZxtNCx6ea1USIi8wZY2B
tUKU9mvGDUbfaWSzbkBW1uDxfb1oBEaxtnFo3Z1Z0Zdnt3Wy1sAXCPW3z/wp
GD//YX2On6S4Y0A8QrM0jP7ALDGGmujPHrAZKBx6ywECqfIc/oLJxzNKhlkA
p6N1SdHPa6uDdfDXl6MPAmTCeVYCmzAQ7wJBh/8HfoTcks2f7ZZnOy3PnmHz
bXj1TO7KPbkvn8sX8uWnPBP/2vvC/4nffYiQfb/dee4/Ct6fs9IL3n9tGAYK
986Bj1bAIE9n0aRw7y5//2owXNwc90iC0Zj419toVikLw9r3XwGGb75poRL3
0+/3177/5pv/IjyYn+soJiHq/3wNPBBrfTiQT1pY1OiknmZmSjP+9uk6ZuYv
n35kIYC5cHKRgd63e2EkvHC+wPZA/cZ90SPovUbcl7eyX9v5rvcVliZae14U
wRMv2GVGW7u3wNnZuMRsLQMQAtN1j9nwsglZbHp2tVvMSwNm2Szm5CJaOfqb
Ni5Qo6KagIklJob8oN6xOODYBAf8ghlYHcxPWQcb+O3eX+FcEwRNyw8GzleB
2prWg9zRlCjGymFTxgP34eFwAfTHO+y7PfoEtE4ySfWmJKUMMIEmbGLXVbQP
DnfeMaTftVS/SXkO7LmZLRD+OK3mI0UZEGua2Wy4kjZGTEJcfXgzdfaLhxYJ
SCZ5grsb8EFPiO+sfDww9KHjCtyNicPoRd+SWQptyjxKi3lCjp1ORpqkmU5m
yNVYJQu0U75j2er1jJv5I04CGFd5DoidYRCkgObOsIJ21oNd4etRvx8/4hB/
kpfUZQf/ARagTWe5vbt5oL3XgvMWcUrQir6FmWzXgjfIVSV0JzmsbQPEQK/Z
7I5Nu0udS3VoI8BuF0V2Lg/PNqkDtzXQwzAXwfgmtbMcoZXZgtcAqz5S0ZT3
EIuTPrTJMo5UnGCFqf+I+4ZO8Ha2eQU2JaE34tQMCkD8cI2fMZdjInZRgrM5
zpXJcdN290uTtbDIFtUMX0I/JL3YD4MuUMoUpm/eLn62t/Px4/+CL53Q90EJ
PuYx/EgndhoYoTE4hWWCUg4DBy2EYbkZPPA7tXRyKYzbGfvTN1mjWYZpC9b1
vNfWJ3AMR/p418YFzzllyIV/AmHlQjpd9xDnU4cDt31pqwE3mOcqJseavj5J
Y1YrFIqq7UxgLMTt+JNxnCqdf6rjDxz0RYM+LTDjsZyCfsBkSuqVBZDLPQVm
HCMzeoHVJLdRYlp5q03M2JhxlBSodnwbGMaDSRZIJLgBKofrps9eK06iANAm
0xLBRwc75fD1InKumE6JXAY0gYTw6ofr3vkNU9zeNgbrAFJ8QQuc2MVmPE1x
z509aMqd9APFeqFxRgQTBlxJWtkkO0Sp2UFsJdKRatUN64g1Qe8SU6QZ1/fE
uwZm5BK9StkIfX+WZTg94N1veO6PQVXfOviD628w6BG4+PDAefif6p1/+2zT
BZcp5IFbDk0JSxaAdsw9Hz5dYnxGh2K0U0wC0vf3WgPDtUDVzzpE8EtXIxE9
Tg4CIDDPdGAQo9sfnsC/HAS2wPpxzK6errfx4eLeiYsE4jQIzELbFnozhId6
4sLpN7a1jo3Aw559iOHF1H0cDMUrqPdzHnIjtR8JP1/oSlIPX+ZNQhdfbryj
D3COXgI5k7tb1mdwzuPv8nLofAnnz/3+9vfh76e/3/z+9SAJ0dTwLfV7K7pf
KRAxCZCI9Wb+IEg++ef3VZ2Y7TnZAS1iUvg2P7ET+uls77zogbWzovHjOnnk
z9dDbIvTDJad7JhIPaUUr8YLOM1fC5I/aolxcW+o0gDNggeW+SshNnTBA9Gn
A9CB5x0KzNPA4SbHpAj0aigyybCxceEDbvX0/ClJBi7/Y1fTRNu1I6qb2w10
0HhiloEt0JtmC9mxSZBYV4a7TBj3dH6FVTPiN5VnJonVxvdx3/EeywBsxoD2
SnUeQW06wkv7uEIg78HstZ0e/oTVS5RPmCO8swg9aj9R+uxYUP8WT+Q83KnY
IcxmgqM/wlUjC7Jk0QQHWXtQc8opYyktPc+dAexK2rMke7k06yOc1t3dssGK
zKi0qE3XiTDjK3WZAkKwsD+QR5z7oo3grASgQ1/f05yBn697cIkFJZqZRSl3
dtmDtS/kHHdxF+z+7VLWTXNV+HOdieM6ozW49d0/ySm7IEK0JSxwsFP2ghlh
rLDY305aidPvDHoSmgXYgi94pxeFFBtkl8NNn8pNAMjY8F7IGtvoOYA/p8HR
E8SdyC4az1SaVBhC1VSvzBTsMsPUeaN2pIDtNjl6T4MM9dymEYZN5FxFKS+w
Q7oJH4yWwiPWvL65yW5pkN5gycjMvxDWi6XY2dnh5WEPXmr3FStqHF6cAcXc
ggbUdzhDAJr5E4bX9IsDWHb2Uqwo0EG7+36jHdfI+bn45Clt+VMo4ez4KTRd
EfAzJROcNueS/CMMwFAfURzDmpgd4KSwJZveziQs533KQSVDSNjcJX/axmZj
uWtczPOrI9mhYBoiDHNuOICGQQ7f3UO6JDMI16VI5sksgm+rnPzCDokFTTub
7ajaXY8qG235RGQtdUkRg+tjTD2Es3BcDJgA5dCXNl5LU4dPOMTTNq39ldOa
Jem7HktcHAn7N4A9fdQMoUU4R4oE6RI/f6Zdjivcon44OwamrECuwezPMNT1
uNmvmDsGoezshY7zvdHdcbJXZCtAAgc53MXHnB8bKluRi1ZzdXQUT8dvKYIg
2oJqqIdNWh3uz2KQp1XmEBCPkzlWtliVgFOXpyTgQsFjLR0EuE36iBbp8yd5
c8CkRJZFKGK3u6E20KTGiVPSU32URUKBAy2ydXfjqFAmreiIwxrFAmNFmIAn
ufBqChaP2RkIR+pK1Z/0u4gwMIuo+qpauOFvBr3jV145OBI+UWvX7pjz+GYB
QtPHn4BVMjd1DLBaYd0TLje0xwUnHJ4+iEMEzkefZ4XIBvqGVt3VKGwb9ePl
8NstMiHwHANjqrXRojYApDUACk+fYOLhiJCgu6aJDB8mhsCYf5AirBannZ22
OW2xJUeYF9If0K7K0AfF2n3+WjFsQ8SlN4LmOBy80jtYuqvAWPH2iKADKqjU
YgTcyWVZnzODazQRpeBoxUx2X93fSWpZXPC2Z99S/PlP8u0B4WeDSF/lthZg
g6CtKBPHyfQbxRkie/1tlMNeoZRNjTiSG2+9fuQtprJt6MowGKVr8xy4tpUX
nPMRRniUiXewAenmm2sQLYOrQe/o6phjYSSdMXuYWvWYEmgGbSObHasbG3Cz
ediYrWXSjYJiU7dT1CZogdVnyuXBrNoTaoRGcJtmex/jBNpMDLwAHH2kvxRR
UWTjhDYmQj2M9SJGpYcFCs6qGVWlLj8NYrmZxG0ZVFG423cfLQvkaVOhipoS
TyHh8g/SgrhmWHmCOswEcqmWOolgvgWW4Gvjh1bfAG/2DN+lYJB1NaM+3Xp/
Cj9PfYpk+1crko1wJ8DgDBdQK282Dl6+2PfKbLDUhxHj7U+x16VDMnr8Bqr9
1HD2KZgTUFyuwr7R3PTVUxOuFLFaUOmoLi0MhK1xCfTeYSMJ2q9EOfR9K98R
CmzylpKHpoPJw/GBGuBChzb8E4rWBqLiw5NQOOitqbo48SWUH4SvF2d0xYp0
7zAS7Op7aVVd+N2TclFhckxNFfzV0cHpm8uj4cHh4Ieu4Oh3ZE33DrynDTeQ
q5m/Yy3nQLLEAiQiMJkt4bxVrVy6QcLqqXnt8uI6NCwXaBza1lE+qXg3owMA
bfYlvDPAzKNlS6HCq4NLHbR/hZuUgXthWo7gl3eyQwYqNL5N3luLKrYbClw9
pj1Jrn/KcobvElFAu22OL/RiwcIpvdcmXAmu5YuzY1MEYmDBL832kPifED0C
c/7KBuXh7/PLIER/WqV99wDeH+YT9+CPDIy3ZID5AU4ZpoB9JUiEF/L0hUg9
2hkIExfoJE44EMKi9EDqffO+Y4tzTYqviC10HAzojpwjaHv5iLYUiGg09Rar
rfGpYf5GQ29R2xoeWrHQaDkkI3xu9sRvsyoHufSbi2CGqJpXBe8Vg2iifGn1
j4rPvQEVp93DMxMSbOvVSybQ9nJDsM9AipHPzoqTeu3qWGjOrlNsqzYx5GpU
kbf/nqSg+ZLY1RzlubWuSI2ekLlGkbtvxfaW7GwMwFhaeCkGpgtdvsiijJtx
SsW38tlzaHemv7PYtpPZ2GS7B35PSdl9viknnCmnnf4jm8iTZuScc2DSHhNV
T33RKyc+w3gc+krBLZU9dQGXhutEoCWpOjyvLjjo4NbXoyZgxMYUpv9rWsO8
aHRWC9q3FqaWAsBF+60W+zJw9GVQesZ5JSauUISN+ACnwjX2Dddu8K3QKV+g
oZBYgwNcWpBhCuS0BSu8yH5izgtraRYaubZukU9jwTRogdkarpqY6pCyFE81
xQJzSYnU6n00X8yUziDz8W66F9aGJlq1i+IpbsUVVPYUDGus6EotCqCPp2r8
TveEZ+ngQOgyaofF4ZnNAxylgDZzhQEOoDOhZ2jsg0YlnnHqnvV3rFOnzWzJ
8RSsDeDjMRBNnLxCCSaIxBIcg9/YvyAHkn2EqCqzuS4WBGofV7lXXMx5Q1zV
PloyUWNSAdsOs5IPo8qrGQovzqUwX2dVGuN5eMXKaey5SXBJviRCMEVVDEKB
SZK4x5MAxVAJ69isNlBIVpU2q74YA+IaxfbGir6ihAo9rStjGutNiw9PKN9C
G9PWcFYzfUTI6n09WxrHrEs+CaeV1kS3kWk1Y5fzPAhDi2RcrjbBtY5GS3wY
xCNyDglx+qqKxmbXac5hB+9kOPbiTAmsFos4AXFDf3TBlKZAJh25Rb/2w2QU
nbXFNMYHJpcJ+5ucMtNEnU1fXYVAn2xZDpswcknpXhpDdKgYl0BRPBhDyMB8
8tDI8UvKVC3kIZ19jDTcwW0WOr/GGOQgB2mCzRpZi0+buQogNlIP22KofcEJ
PANK4Bl8QgLP4NMSeAa1BJ5BWwLPoJ7AQ4EeDuA4d41LvPV5ZLVSIT/W0hUu
E1KXwQ0ZEhb2ALKxG7wdakP8n19+Lqj8nAfz6kytuOB6eTJVNEFjsFUjiUZa
SrK9uM67bB6KhG2xeojLivqU6TRw5xgUwc51cJQBOVx2Ad3ua7EBihu3l1xK
PTtdtPf4T+xiuRyotiwoToP6nyyox/+syz0ymqZjBO2qPKYHE5gekwj13z8L
StYSodbN5v+DLCjZSIRas85fKygQpkENHkqDGqxLg2oWHw7qmaOkW6O54i19
+7VoC41ifNxIag4NaqMEB3vLuryWweGbagN9/gcaQg1n0dirvI9A5qGOWzbh
xtAdb0+mtc2IHE//TgsRNQ6W1FBmXsfrDcu1mKqFaNlc/cjHMbkqULACvJJQ
zivmytkgmO6le3944j6g+yW8XHBrPvhbYZHZsfDqUbzDonAMc/KfsAdbujjo
aFnbNVpfMkuUcbUAD9bu/mgICgrkGxvGHMHbBqnwj1ayR3h65VuPgUmEMMmH
YTpC27lRhGw97weLssm6iYQpsfZPWKLsduaOB1Fodoy7vEutKb5W7I+APxwJ
khgJWh8Iao0D7crOBVYQ8XGPmsoaoG66RAiCdDzLCuXBy8UQbYXdn4rTdB3G
HFot5u3xFSa1TuN/DUJZ3Dy0OuxdYUyHvrSVUclaCF3apIuICA9GEwXUCXCB
K29LouxBLmaHl5oIRlCNEDohEciN4Bgje1YRSjSBW7kY3GuhA2iYryCegJvQ
oxUpnpXjPe1vYKLWZXBYXkuVmT0ogKuxrF5ZKWD8PX63Xz+3NXuzZJ6UwlQZ
6YwdlIl8hnk6W3rlWYkmTS4WMgdB0XkyGCpJ+XwSdzEApq64Owf0keWFX6am
iQzlGFFU4fYtQ+Wx6mgFfc4gujFcPoaQhlC6gzpqVXOEaL0xVtsM1u766qmZ
1AE+zAE5WQMNPnWUx3Qerl8JW3gr94h5CXHMR/qQJ+tVwOnAV8UCkwLehlZk
Peaqq9y40AtL7SZ61432AIoS1BhpbTwedUUftG+XTnI+3vdIFok5wJnOYzLI
y7PFggOkiGwiHTqOCfq6B2zYiYzUOKq4cg0HA5QoFVMoc6jHbyvV0yfqN+ag
Y7SfWrnmVXB9xZK1QydsMLeINI6ng+1UQ1nVXiF55OWwYIUhDTfPYpMsaJvz
Bj8nUziREAgWR6rtCkdHnnpWzOH3NtcAgzk0iN3Y4XCLUUhBvAXZiedJYfbW
SbpMuP8CxfxSdt6k2ngDoFytd9MWL+gAK0qocDHClSXh/mEnayvwMeTHhjud
lp3SGfFNA6swp5tqW49Po9Sn11JQoW3LiLe3VgPpJ063lTystkqjdDV8QJzy
hjOO8ZBxr+RCGwV6OwqBA2GwDofQ2Or6QBlaI8iRmi0QWAN60QI70b8usKVD
yLWwu01yDMXWTA6vWPGa2yDLUt1izz3Q3uDCfQE0dUIHMJK3JMEvcLIeD8rP
Y3chBOXC+Ld/IKpCx8rEQKnTt3bTxhrcR85mM+FXKxdqh0NxtL6iQwzge/QO
s0ma/OYRLw6i/ZeaW0jI07fmGKuLp+MyifXuCKfVzaMZCltl2LLFtXPnaoBX
qjca77ziEwQnICu9aeUZRhx/EzqdieaB25z866n7dci/mnMwbFEEsKXQqTx8
zER4oNWZyS+13Vn22/aGsw8tM5aU+lgretnZ9TrdaeuU81Tr2bc8VFt/XS/l
1aHDfrC75Q24++UDYi3R2gH39r0B97/CgC8eGHDfonQY9pW2rAyytGUbMPLi
whGSy4nzz/HoGnI6tfQjeCCU59pRssSTuLokZ47hfl7OB7RqPSWs9/cJOq+e
liAekZawvQ3tLmp8SN5FU3g4YeBurXA2azNzEFyFx8yVoGqbpnjcNNdlX3CJ
HTTcxYa+erfFWLXdzG+agi1ER92cae7gccYCE6+XSY5yhKS5TU3v2B0fel7q
FBrKg8OtU1s8tmkJR3wuMn2aEZ+JTYvMbdHZeEUXSrSCu3qH+EtQWUuuF0ZQ
18vcSMB2gs00nXauobMS/vBMuIT7TS/W0aYycYp01EzFntUfsSC7sB6Xbky1
fhVCihYLcxZmjX1VSTFbK8a8OC6vOB0MTcmo8+Q9ebLG6BW1o8tpLkFzdpVd
EMUdB8hzFp8juBo0KFpmvwPtEDyAWRVtNjoPxsVHjqgIVMaQDjatjJ+1EWXX
VVPokyuIRvTpFdYwWmEs30f8vfXuuzV0PSznX3ppZPbM5HbRjp8elqWaL0pd
VeyA986cNkC5dLv1XNrw37x4UdOB+9T5fWZ63e6zmnxf675hF21bFGRKn5mL
ZIIAOBaS2ey23om/Ob76koRD3/r1qk66lJrSsslja51Mh94Bbu68asPKotR3
4d0nsxmFVhI8I4gyTLphTs0EVjCtnU1HTo3HGrXD4rTPY8dUctVwAodjsPGo
gjZZHiZEmA9152w0FRig7bv0kcClGrS5VMUSVuA9Z5q5zCu+lo+yHvxEm3BD
CZUxz1ffxcjxGX+vrsb3SOsLclHo4gphEhnWReDT1r0so9b0lUx3+6Jdja63
FgehjhFfgcHEuvzVPdnU+SLQ+WK96XTyCFU0aFFFLd3+t9BEFjP72C7URCG0
4gFNhLTsLiMbLT2zBwWwi5/bo5keleknnmByIWcwHmkK0tmCH56YN73wjeEs
024ctlvlneMFZJzGuNN3iYx4mzK+81Km7B8v/D/2njUDG0wHnOKoT9dqZi7V
dkEaiU0qxbZF++VuZSb8q9wC9RYmtFIuJu7ymkrj1CudFnfVDK++0OpUR4Yt
Br2rAAxeDM4CvLjpE26E8R4xHRcTWqlbznpPMyoan1D/uFOicc8px+Y8f80F
CGtZYgQ+1zm+PIsWdY4BejZ5iUJJsOsNDj5+2a+0ZLFb2E2Vrt0VMOdkNCKX
gsePk4KjyxT696L+QXw7QVWalLT2Lci0+IFx6HSVvnyNGrOrP/YuOLDBa658
HuIhjmTSn0dLLg7lzjvD85vNgCQB195daRhqkxdRCjMxi91gK36NuQKgIufB
t7l/zZ6+RtRvjLurLYzlE4kImKfBMEbnmRsp+NJf77rJYN8qKYQ7xPPMUXT3
EyClXgzr0/gmAfTI3JF662pR6IYBOsDGnvCeYDY6DsQ0pS+z40t1yXox2d90
BKK+kdXZm94Z5+YSMdxv4uMe+dpRVNqoVymWG5wAqQcb6aum7dmMYM1rM+TM
P9oSgD/GK9Mv8MLYguUkzeGnw8sfcMMFrA8tm+1RN62iWbqLfQmJrLnM26LL
Cf0mUf/Dh/ar5OkCVwCrIhMKevLBsBkm6PXi/lRwCF+UhkO2jmEvpccLRe1N
x17yyjgMG5Pp79/TXgQnYmamFsHhn/e6ClXWpS3h/hwtVtxJPFZGvtEwtqJB
iAsnWmuU7d+2wVJijrxB+43qHgiY+xZx0LerlghZIHHM4UzFaAZiNF6KVrbV
9POWCwuO+OxO568B9QQl35pc5o+Yj97GtJfCBcB4nPmzhuWXLp+5CALkFxYZ
P2uJ8Yuxtf2pXqV8mJW9M7z4fDSLAImZIXS7tW+YbL6IEDmpuSYvwFP74I9R
o941YoFkFKsFYmA9CQItkE7w3wpg+pltDtaNMJQ8iYmye7ilk92ZCxs0ZY3U
LW50LaqRqdbAPQRhOMM2wfS5W9DwukiGJvH85e6Od5Ot7hEDsbl2uwuCCSmI
6tZrAtVsEwurDcyMKVumYS+ZixeTOYmtRWbLl0nSmzqD3jF4gqWtDbcFTxEu
LjSKZi2WopkLyk1+aw3tOtBmOfSEhXdrC0n1okhM5cPJ8BQ/xwBrDDMp9B2/
egMvoT8oIwElRoxgkzACeMB0uebrI8JbJ2euZpsO1krj5C6JKzD0asqKzDEb
J2TSBxizvFDm0hEDYph6IsCAU7e3aIJgvuYI7z2DdeBdU12MxLkU3pk8thJb
nz0blQIjNxjxMJUEhAwycJNRBQTpHaLElpJGYVTw0lFiCG7z6YLIMq+MEsQ9
NaCJaJYxIu6iZEamWIO+SKAnubgFoxITLfsgUPAaJX34WXyX6COHHJZZDtR7
AusTWJPvT2kGTph6unKDCIMiEGwl5AovC6PxMGUL5Ac2m+RZtSgMsUxSGVcq
NGPobGSjcxkuytxAbhmBdrhNSI3nVUpZhlinZIoR0U6mhHrkX4WFjTr2g8FJ
uipPvQcRljhSoYPdlIpHYId7Y9E1UrTSBhcqdvJRULnFPOLKRT7lGG9pyzRx
GLqUzUmbW2OCyko+NWxJt6XA7DasqQb2ePa0wHsn5yofY2nZsUIVmS9x4+wq
n4AA5kvBDvhjebMEPYOZTWfpmHfXgsU8kGdXN72/DTg/hu6VOtJXz1m+P6hL
V3KSPcTNCOd8FDY1vkBMoLlxru7U7ABVVFyxgIC3Rxnf2oYXC+VYH8cPoaNx
eSCBCIAxvx8j9P1xNueZv66ie5U8dur8tRyCRqLrjtFLOcr63fMybsWB/p4u
q2TylJe43W490AZGdAsUCmceRbBqQtnll1BhjNlc9KXDu9fmdMgvQ9ayAij6
9O/3UwLJoExiEVnT66ET/BqBBEAw2cfm4slaCOfDE7rIDZMl4C2l2ru3Dxxx
HUZRrFlPwyl9/6zg+3Cz4IpbzoJ5qIvcXDRKXQjTBd40ysln7koRNohrUR1X
rWkmC6xojqRxOX2Dm7fX0m7bFPZQma6sUhPtO/nb9fnZ0dnw3wdXb4YnFH4a
nFxfDYYnx/zIXTNHa0NV5FQZqA96Q5M85yI+d9KFK7otAmCum8Do8mJbSdmC
PLSjV9tRutBLn2VeL/CwHTVrP+wrDNBBD722n/anq15BLyFC7WAm4tshojRW
ERea7G5BO/r83zEcMDj2gDTRvhXtePbICpfmCkX/KEzQlRrLmonwGEzRvpA6
amPw33PUkka4d7+x4rTNjS6JVr3MG40rhk9YzliLn6eyaUpINxwloBNHIQ3q
aZeOKbJpMknbdhlzi1fivfBvYtD3qblD+QprxQxIq7Mhv72DNd1DTXquDNU/
aLbloD5Nd+4iI1/WtlciDYwBbqiNH/s01frj05dXzmgOltSH1DV/AhEngrJH
dyaDCEofTZ/6mvWUTyntr+7z2Yo+d1f26a7PXtWn90Nau+VcS1oCKfdWjL7/
FUevHdbpQyDl8972XhOAdq6kgyI9jgxrm8Xn8mXLQZSfyZPiIZ7c3iGmpIGC
W4ZaWFNcmnRdNtU5+OVOAlmiv4unFoCneciOp8+P4gR1wsil/I1og5DOfLAZ
wY4tsf6YArtknbzC64DGWcXnmlGVOfa0ZU62rZ95xccUbtYMJvzTsawpugsF
gX/SyTr1FP4gfPizQmL4ciL8MUKiRRvJxuNGa7nVe97CLI2fF/yfxtGBnbeb
a9mFf1661sFhOg8xW/BjUoQ7w82Wr7a1FAwkoOycbj5qjO1tB6HX+qatteXk
lhMX19uQ9cNFe+5Mv5bDG2nPD3gUxC1zsHw0867Sp32P+DwtdaFrN9t+QsJz
+miVBVR7R62Gr6z90n72ZBshWDSvqSm70VkuZNjo082zHA19c4Mfvum5N0ak
GsuYchxaLZuVg4oVgz5SwIpPNXr40kAzjCwWoKuE9gA4qfxRN6e2G+vi0ca6
jyVfiDkyejQVNQiltUlAQu6+0LZkJ/NDBHQcEpC59Lued85nIbRfScw3yX2R
9hW1ob5ICT9II/qs1BVKeFVt2pdpY/nPrI0fUMd/oDbeJut5rTLeZkO6efOg
5YGHtWn9kkIMF6z82OW4dS5bdS/buw1r15i79evBPjyBpz182qOnJKU/mhNO
+Tpvc+RPKJ8b7CM+j33MMTK0O1MDr9j43MCGWCcrPX2rf9Y6h47EmiJyrXfo
qOtZ491Qp9MpPG9AKVfBibZYKD1bqKB5a7pbZrJddMSloIIktGWubGjtyyJF
OmwHXQruUrBxNOTbJdOY1VAthBR2i+LaOwa78Hnfy8qyesxqqhpL4/Nt/wSh
9QlcDUSGScVecX7jy3XF+g91uyc7a9LlG62TtrzBBwfZpwDlmiy0enuXlVaP
5z041nPZWX2WJbXefum1biQsP9A/pi6vyFxutFybybxpuKKV4ufRO44prSVy
+U9G5Gj/t1e6Nhq2Vb5+au8mDtlG5Q8U3jxqrDbGarR7qC7lUSM1qw0arVqr
Dz6Vu1YsUKPVitJkqwiQhnDDkTZuDseYHwBqdsL5GOLDQZVyxyrWWZ8RHRYI
oJMFOUve6SSHKH0n/6Jub+UQjL+iyqMumDl5AoR3GuW5msGfya9VKn6M0klX
/nUaFVGa3clXWY6p5n9VYLhC01lUQZdR3pUXuOeUyrfJJANxUb3vytdRnkyj
HL47TGGMafQOmk7h1678W5IuAS1/n1Lnf8mmIBzHVRxjxuFfoEcQCxeqykGP
0t5IBhMqgTfzSWQOMa04h7CaTIDzkccpnwImRVulP1SY1AAt8IpX8IZnuM97
gv29XaZgP8MoyRy+SsYAoD4P/yKaqmIKOEHcoFWeJob9E8yynPOmcuzyEM9O
bn7QW9V98Z8XhjIkTawAAA==
<!-- [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.
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. 107 change blocks. 
1587 lines changed or deleted 992 lines changed or added

This html diff was produced by rfcdiff 1.48.