rfc9604xml2.original.xml   rfc9604.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="4"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes" ?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="no"?> ]>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-binding-
<?rfc compact="yes" ?> label-sid-16" number="9604" ipr="trust200902" obsoletes="" updates="" submission
<?rfc iprnotified="Yes" ?> Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocD
<?rfc strict="no" ?> epth="4" symRefs="true" sortRefs="true" version="3">
<rfc category="std" docName="draft-ietf-pce-binding-label-sid-15"
ipr="trust200902">
<front>
<title abbrev="Binding Label/SID">Carrying Binding Label/Segment
Identifier (SID) in PCE-based Networks.</title>
<front>
<title abbrev="Binding Label/SID">Carrying Binding Label/SID in Path Computa
tion Element (PCE) Networks</title>
<seriesInfo name="RFC" value="9604"/>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>msiva282@gmail.com</email> <email>msiva282@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Pegasus Parc</street> <extaddr>Pegasus Parc</extaddr>
<street>De Kleetlaan 6a</street>
<city>De kleetlaan 6a</city> <city>Brabant</city>
<code>1831</code>
<region>DIEGEM</region> <country>Belgium</country>
<code>BRABANT 1831</code>
<country>BELGIUM</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Microsoft Corporation</organization> <organization>Nvidia</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<!--<author fullname="Jonathan Hardwick" initials="J." surname="Hardwick">
<organization>Metaswitch Networks</organization>
<address>
<postal>
<street>100 Church Street</street>
<city>Enfield</city>
<region>Middlesex</region>
<country>UK</country>
</postal>
<email>Jonathan.Hardwick@metaswitch.com</email>
</address>
</author>-->
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="李呈" asciiFullname="Cheng Li" role="editor">
<!--<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization ascii="Huawei Technologies" showOnFrontPage="true">华为技术有限公司</o
<organization>Huawei Technologies</organization> rganization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka 560066</region>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>-->
<author fullname="Cheng Li (editor)" initials="C." surname="Li, Ed.">
<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 ascii="Beijing">北京</city>
<city>Beijing</city>
<region/>
<code>100095</code> <code>100095</code>
<country ascii="China">中国</country>
<country>China</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>c.l@huawei.com</email> <email>c.l@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<date month="July" year="2024"/>
<area>rtg</area>
<workgroup>pce</workgroup>
<date day="20" month="March" year="2022"/> <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search.
<area>Routing Area</area> -->
<workgroup>PCE Working Group</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<!-- [rfced] Note that we updated the abbreviations and expansions in the abstra
ct to
introduce the abbreviations upon first occurrence and use them the abbreviations
for the
remainder of the section. Please review and let us know if any updates are desi
red.
-->
<t>In order to provide greater scalability, network confidentiality, and <t>In order to provide greater scalability, network confidentiality, and
service independence, Segment Routing (SR) utilizes a Binding Segment service independence, Segment Routing (SR) utilizes a Binding SID (BSID),
Identifier (SID) (called BSID) as described in RFC 8402. It is possible as described in RFC 8402. It is possible to associate a BSID to an
to associate a BSID to an RSVP-TE-signaled Traffic Engineering Label RSVP-TE-signaled Traffic Engineering (TE) Label Switched Path (LSP) or
Switched Path or an SR Traffic Engineering path. The BSID can be used by an SR TE path. The BSID can be used by an upstream node for steering
an upstream node for steering traffic into the appropriate TE path to traffic into the appropriate TE path to enforce SR policies. This
enforce SR policies. This document specifies the concept of binding document specifies the concept of binding value, which can be either an
value, which can be either an MPLS label or Segment Identifier. It MPLS label or SID. It further specifies an extension to Path Computation
further specifies an extension to Path Computation Element (PCE) Element Communication Protocol (PCEP) for reporting the binding value by
communication Protocol(PCEP) for reporting the binding value by a Path a Path Computation Client (PCC) to the Path Computation Element (PCE) to
Computation Client (PCC) to the PCE to support PCE-based Traffic support PCE-based TE policies.</t>
Engineering policies.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t>A Path Computation Element (PCE) can compute Traffic Engineering <name>Introduction</name>
paths (TE paths) through a network where those paths are subject to <t>A Path Computation Element (PCE) can compute Traffic Engineering (TE)
paths through a network where those paths are subject to
various constraints. Currently, TE paths are set up using either the various constraints. Currently, TE paths are set up using either the
RSVP-TE signaling protocol or Segment Routing (SR). We refer to such RSVP-TE signaling protocol or Segment Routing (SR). We refer to such
paths as RSVP-TE paths and SR-TE paths respectively in this paths as "RSVP-TE paths" and "SR-TE paths", respectively, in this
document.</t> document.</t>
<t>As per <xref target="RFC8402" format="default"/>, SR allows a
<t>As per <xref target="RFC8402"/> SR allows a head-end node to steer a head-end node to steer a packet flow along a given path via an SR
packet flow along a given path via a Segment Routing Policy (SR Policy). Policy. As per <xref target="RFC9256" format="default"/>, an SR Policy
As per <xref target="I-D.ietf-spring-segment-routing-policy"/>, an SR is a framework that enables the instantiation of an ordered list of
Policy is a framework that enables the instantiation of an ordered list segments on a node for implementing a source routing policy with a
of segments on a node for implementing a source routing policy with a
specific intent for traffic steering from that node.</t> specific intent for traffic steering from that node.</t>
<t>As described in <xref target="RFC8402" format="default"/>, a Binding
<t>As described in <xref target="RFC8402"/>, a Binding Segment SID (BSID) is bound to an SR Policy, instantiation of
Identifier (BSID) is bound to a Segment Routing (SR) Policy, which may involve a list of Segment Identifiers (SIDs). Any packets
instantiation of which may involve a list of Segment Identifiers (SIDs). received with an active segment equal to a BSID are steered onto the
Any packets received with an active segment equal to a BSID are steered bound SR Policy. A BSID may be either a local (SR Local Block (SRLB)) or
onto the bound SR Policy. A BSID may be either a local (SR Local Block a global (SR Global Block (SRGB)) SID. As per <xref target="RFC9256"
(SRLB)) or a global (SR Global Block (SRGB)) SID. As per Section 6.4 of sectionFormat="of" section="6.4"/>, a BSID can also be associated with
<xref target="I-D.ietf-spring-segment-routing-policy"/> a BSID can also any type of interface or tunnel to enable the use of a non-SR interface
be associated with any type of interface or tunnel to enable the use of or tunnel as a segment in a SID list. In this document, the term
a non-SR interface or tunnel as a segment in a SID list. In this "binding label/SID" is used to generalize the allocation of a binding
document, the term 'binding label/SID' is used to generalize the value for both SR and non-SR paths.</t>
allocation of binding value for both SR and non-SR paths.</t>
<!--<t>Similar to assigning label to a Forwarding Equivalence Class (FEC) via Label Distribution Protocol (LDP), a binding label can be assigned to a RSVP -TE LSP. If the topmost label of an incoming packet is the binding label, the pa cket is steered onto the RSVP-TE LSP. <!--<t>Similar to assigning label to a Forwarding Equivalence Class (FEC) via Label Distribution Protocol (LDP), a binding label can be assigned to a RSVP -TE LSP. If the topmost label of an incoming packet is the binding label, the pa cket is steered onto the RSVP-TE LSP.
As such, any upstream node can use binding labels to steer the packets that it originates to appropriate TE LSPs to enforce TE/SR policy. Similarly, a binding SID, see <xref target="I-D.ietf-isis-segment-routing-extensions"/>, <xref targe t="I-D.ietf-idr-segment-routing-te-policy"/> As such, any upstream node can use binding labels to steer the packets that it originates to appropriate TE LSPs to enforce TE/SR policy. Similarly, a binding SID, see <xref target="I-D.ietf-isis-segment-routing-extensions"/>, <xref targe t="I-D.ietf-idr-segment-routing-te-policy"/>
and <xref target="RFC8402"/> can be used to enforce SR policy with SR-TE path. N ote that if an SR-TE path is represented as a forwarding-adjacency (FA), then th e corresponding adjacency SID can be used as the binding SID. In such case, the path is advertised using the routing protocols as described in <xref target="RFC 4206"/>. The binding SID provides an alternate mechanism without additional over head on routing protocols.</t>--> and <xref target="RFC8402"/> can be used to enforce SR policy with SR-TE path. N ote that if an SR-TE path is represented as a forwarding-adjacency (FA), then th e corresponding adjacency SID can be used as the binding SID. In such case, the path is advertised using the routing protocols as described in <xref target="RFC 4206"/>. The binding SID provides an alternate mechanism without additional over head on routing protocols.</t>-->
<t><xref target="RFC5440"/> describes the PCEP for communication between <t><xref target="RFC5440" format="default"/> describes the PCEP for commun ication between
a Path Computation Client (PCC) and a PCE or between a pair of PCEs as a Path Computation Client (PCC) and a PCE or between a pair of PCEs as
per <xref target="RFC4655"/>. <xref target="RFC8231"/> specifies per <xref target="RFC4655" format="default"/>. <xref target="RFC8231" form at="default"/> specifies
extensions to PCEP that allow a PCC to delegate its Label Switched Paths extensions to PCEP that allow a PCC to delegate its Label Switched Paths
(LSPs) to a stateful PCE. A stateful PCE can then update the state of (LSPs) to a stateful PCE. A stateful PCE can then update the state of
LSPs delegated to it. <xref target="RFC8281"/> specifies a mechanism LSPs delegated to it. <xref target="RFC8281" format="default"/> specifies a mechanism
allowing a PCE to dynamically instantiate an LSP on a PCC by sending the allowing a PCE to dynamically instantiate an LSP on a PCC by sending the
path and characteristics. This document specifies an extension to PCEP path and characteristics. This document specifies an extension to PCEP
to manage the binding of label/SID that can be applied to SR, RSVP-TE, to manage the binding of label/SID that can be applied to SR, RSVP-TE,
and other path setup types.</t> and other path setup types.</t>
<t><xref target="RFC8664" format="default"/> provides a mechanism for a PC
<t><xref target="RFC8664"/> provides a mechanism for a PCE (acting as a E (acting as a
network controller) to instantiate SR-TE paths (candidate paths) for an network controller) to instantiate SR-TE paths (candidate paths) for an
SR Policy onto a head-end node (acting as a PCC) using PCEP. For more SR Policy onto a head-end node (acting as a PCC) using PCEP. For more
information on the SR Policy Architecture, see <xref information on the SR Policy Architecture, see <xref target="RFC9256" form
target="I-D.ietf-spring-segment-routing-policy"/>.</t> at="default"/>.</t>
<section anchor="Motivation" numbered="true" toc="default">
<section anchor="Motivation" title="Motivation and Example"> <name>Motivation and Example</name>
<t>A binding label/SID has local significance to the ingress node of <t>A binding label/SID has local significance to the ingress node of
the corresponding TE path. When a stateful PCE is deployed for setting the corresponding TE path. When a stateful PCE is deployed for setting
up TE paths, a binding label/SID reported from the PCC to the stateful up TE paths, a binding label/SID reported from the PCC to the stateful
PCE is useful for the purpose of enforcing end-to-end TE/SR policy. A PCE is useful for enforcing an end-to-end TE/SR policy. A
sample Data Center (DC) and IP/MPLS WAN use-case is illustrated in sample Data Center (DC) and IP/MPLS WAN use case is illustrated in
<xref target="figure1"/> with a multi-domain PCE. In the IP/MPLS WAN, <xref target="figure1" format="default"/> with a multi-domain PCE. In th
e IP/MPLS WAN,
an SR-TE LSP is set up using the PCE. The list of SIDs of the SR-TE an SR-TE LSP is set up using the PCE. The list of SIDs of the SR-TE
LSP is {A, B, C, D}. The gateway node 1 (which is the PCC) allocates a LSP is {A, B, C, D}. The gateway Node-1 (which is the PCC) allocates a
binding SID X and reports it to the PCE. In the MPLS DC network, an binding SID X and reports it to the PCE. In the MPLS DC network, an
end-to-end SR-TE LSP is established. In order for the access node to end-to-end SR-TE LSP is established. In order for the access node to
steer the traffic towards Node-1 and over the SR-TE path in WAN, the steer the traffic towards Node-1 and over the SR-TE path in WAN, the
PCE passes the SID stack {Y, X} where Y is the node SID of the gateway PCE passes the SID stack {Y, X} where Y is the node SID of the gateway
node-1 to the access node and X is the BSID. In the absence of the Node-1 to the access node and X is the BSID. In the absence of the
BSID X, the PCE would need to pass the SID stack {Y, A, B, C, D} to BSID X, the PCE would need to pass the SID stack {Y, A, B, C, D} to
the access node. This example also illustrates the additional benefit the access node. This example also illustrates the additional benefit
of using the binding label/SID to reduce the number of SIDs imposed by of using the binding label/SID to reduce the number of SIDs imposed by
the access nodes with a limited forwarding capacity.</t> the access nodes with a limited forwarding capacity.</t>
<figure anchor="figure1">
<figure anchor="figure1" title="A Sample Use-case of Binding SID"> <name>A Sample Use Case of Binding SID</name>
<artwork align="center"><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
SID stack SID stack
{Y, X} +--------------+ {Y, X} +--------------+
| Multi-domain | | Multi-domain |
_ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE |
| +--------------+ | +--------------+
| ^ | ^
| | Binding | | Binding
| .-----. | SID (X) .-----. | .-----. | SID (X) .-----.
| ( ) | ( ) | ( ) | ( )
V .--( )--. | .--( )--. V .--( )--. | .--( )--.
skipping to change at line 269 skipping to change at line 172
V .--( )--. | .--( )--. V .--( )--. | .--( )--.
+------+ ( ) +-------+ ( ) +-------+ +------+ ( ) +-------+ ( ) +-------+
|Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway|
| Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 |
+------+ ( SR-TE path ) +-------+ ( SR-TE path ) +-------+ +------+ ( SR-TE path ) +-------+ ( SR-TE path ) +-------+
'--( )--' Node '--( )--' '--( )--' Node '--( )--'
( ) SID of ( ) ( ) SID of ( )
'-----' Node-1 '-----' '-----' Node-1 '-----'
is Y SIDs for SR-TE LSP: is Y SIDs for SR-TE LSP:
{A, B, C, D} {A, B, C, D}
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Using the extension defined in this document, a PCC could report to <t>Using the extension defined in this document, a PCC could report to
the stateful PCE the binding label/SID it allocated via a Path the stateful PCE the binding label/SID it allocated via a Path
Computation LSP State Report (PCRpt) message. It is also possible for Computation LSP State Report (PCRpt) message. It is also possible for
a stateful PCE to request a PCC to allocate a specific binding a stateful PCE to request a PCC to allocate a specific binding
label/SID by sending a Path Computation LSP Update Request (PCUpd) label/SID by sending a Path Computation LSP Update Request (PCUpd)
message. If the PCC can successfully allocate the specified binding message. If the PCC can successfully allocate the specified binding
value, it reports the binding value to the PCE. Otherwise, the PCC value, it reports the binding value to the PCE. Otherwise, the PCC
sends an error message to the PCE indicating the cause of the failure. sends an error message to the PCE indicating the cause of the failure.
A local policy or configuration at the PCC SHOULD dictate if the A local policy or configuration at the PCC <bcp14>SHOULD</bcp14> dictate if the
binding label/SID needs to be assigned.</t> binding label/SID needs to be assigned.</t>
</section> </section>
<section anchor="Summary" numbered="true" toc="default">
<section anchor="Summary" title="Summary of the Extension"> <name>Summary of the Extension</name>
<t>To implement the needed changes to PCEP, in this document, we <t>To implement the needed changes to PCEP, this document
introduce a new OPTIONAL TLV that a PCC can use in order to report the introduces a new <bcp14>OPTIONAL</bcp14> TLV that allows a PCC to report
binding label/SID associated with a TE LSP, or a PCE to request a PCC the
binding label/SID associated with a TE LSP or a PCE to request a PCC
to allocate any or a specific binding label/SID value. This TLV is to allocate any or a specific binding label/SID value. This TLV is
intended for TE LSPs established using RSVP-TE, SR-TE, or any other intended for TE LSPs established using RSVP-TE, SR-TE, or any other
future method. In the case of SR-TE LSPs, the TLV can carry a binding future method. In the case of SR-TE LSPs, the TLV can carry a binding
label (for SR-TE path with MPLS data-plane) or a binding IPv6 SID label (for SR-TE paths with the MPLS data plane) or a binding IPv6 SID
(e.g., IPv6 address for SR-TE paths with IPv6 data-plane). Throughout (e.g., IPv6 address for SR-TE paths with the IPv6 data plane). Throughou
t
this document, the term "binding value" means either an MPLS label or this document, the term "binding value" means either an MPLS label or
a SID.</t> a SID.</t>
<t>As another way to use the extension specified in this document, to <t>As another way to use the extension specified in this document, to
support the PCE-based central controller <xref target="RFC8283"/> support the PCE-based central controller <xref target="RFC8283" format=" default"/>
operation where the PCE would take responsibility for managing some operation where the PCE would take responsibility for managing some
part of the MPLS label space for each of the routers that it controls, part of the MPLS label space for each of the routers that it controls,
the PCE could directly make the binding label/SID allocation and the PCE could directly make the binding label/SID allocation and
inform the PCC. See <xref target="PCECC"/> for details.</t> inform the PCC. See <xref target="PCECC" format="default"/> for details.
</t>
<t>In addition to specifying a new TLV, this document specifies how <t>In addition to specifying a new TLV, this document specifies how
and when a PCC and PCE can use this TLV, how they can allocate a and when a PCC and PCE can use this TLV, how they can allocate a
binding label/SID, and associated error handling.</t> binding label/SID, and the associated error handling.</t>
</section> </section>
</section> </section>
<!-- Introduction --> <!-- Introduction -->
<section title="Requirements Language"> <section numbered="true" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Language</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
they appear in all capitals, as shown here.</t> ",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The following terminologies are used in this document: <list <t>The following terminologies are used in this document: </t>
style="hanging"> <dl newline="false" spacing="normal">
<t hangText="BSID:">Binding Segment Identifier.</t> <dt>BSID:</dt>
<dd>Binding SID</dd>
<t hangText="binding label/SID:">a generic term used for the binding <dt>binding label/SID:</dt>
segment for both SR and non-SR paths.</t> <dd>a generic term used for the binding segment for both SR and non-SR
paths</dd>
<t hangText="binding value:">a generic term used for the binding <dt>binding value:</dt>
segment as it can be encoded in various formats (as per the binding <dd>a generic term used for the binding segment as it can be encoded
type(BT)).</t> in various formats (as per the binding type (BT))</dd>
<!--<t hangText="LER:">Label Edge Router.</t>-->
<!--<t hangText="LER:">Label Edge Router.</t>--> <dt>LSP:</dt>
<dd>Label Switched Path</dd>
<t hangText="LSP:">Label Switched Path.</t> <!--<t hangText="LSR:">Label Switching Router.</t>-->
<dt>PCC:</dt>
<!--<t hangText="LSR:">Label Switching Router.</t>--> <dd>Path Computation Client</dd>
<dt>PCEP:</dt>
<t hangText="PCC:">Path Computation Client.</t> <dd>Path Computation Element Communication Protocol</dd>
<dt>RSVP-TE:</dt>
<t hangText="PCEP:">Path Computation Element communication <dd>Resource ReserVation Protocol Traffic Engineering </dd>
Protocol.</t> <dt>SID:</dt>
<dd>Segment Identifier</dd>
<t hangText="RSVP-TE:">Resource ReserVation Protocol-Traffic <dt>SR:</dt>
Engineering.</t> <dd>Segment Routing</dd>
<!--<t hangText="SRGB:">Segment Routing Global Block.</t>-->
<t hangText="SID:">Segment Identifier.</t>
<t hangText="SR:">Segment Routing.</t>
<!--<t hangText="SRGB:">Segment Routing Global Block.</t>-->
<!--<t hangText="SRLB:">Segment Routing Local Block.</t>--> <!--<t hangText="SRLB:">Segment Routing Local Block.</t>-->
</list></t> </dl>
</section> </section>
<!-- Terminology --> <section anchor="TE-PATH-BINDING-TLV" numbered="true" toc="default">
<name>Path Binding TLV</name>
<section anchor="TE-PATH-BINDING-TLV" title="Path Binding TLV"> <t>The new optional TLV called "TE-PATH-BINDING TLV" (the format is
<t>The new optional TLV called "TE-PATH-BINDING TLV" (whose format is shown in <xref target="BINDING-LABEL-TLV-FORMAT" format="default"/>) is de
shown in <xref target="BINDING-LABEL-TLV-FORMAT"/>) is defined to carry fined to carry
the binding label/SID for a TE path. This TLV is associated with the LSP the binding label/SID for a TE path. This TLV is associated with the LSP
object specified in <xref target="RFC8231"/>. This TLV can also be object specified in <xref target="RFC8231" format="default"/>. This TLV ca
carried in the PCEP-ERROR object <xref target="RFC5440"/> in case of n also be
error. Multiple instances of TE-PATH-BINDING TLVs MAY be present in the carried in the PCEP-ERROR object <xref target="RFC5440" format="default"/>
LSP and PCEP-ERROR object. The type of this TLV is 55 (early allocated in case of
by IANA). The length is variable.</t> error. Multiple instances of TE-PATH-BINDING TLVs <bcp14>MAY</bcp14> be pr
esent in the
<t>[Note to RFC Editor: Please remove "(early allocated by IANA)" before LSP and PCEP-ERROR object. The type of this TLV is 55. The length is varia
publication]</t> ble.</t>
<figure anchor="BINDING-LABEL-TLV-FORMAT" title="TE-PATH-BINDING TLV">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 55 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> <figure anchor="BINDING-LABEL-TLV-FORMAT">
<name>TE-PATH-BINDING TLV</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 55 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Binding Value (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<t>The TE-PATH-BINDING TLV is a generic TLV such that it is able to carry
<t>TE-PATH-BINDING TLV is a generic TLV such that it is able to carry binding label/SID (i.e., MPLS label or SRv6 SID). It is formatted
binding label/SID (i.e. MPLS label or SRv6 SID). It is formatted according to the rules specified in <xref target="RFC5440" format="default
according to the rules specified in <xref target="RFC5440"/>. The value "/>. The value
portion of the TLV comprises:</t> portion of the TLV comprises:</t>
<t>Binding Type (BT): A one-octet field that identifies the type of <t>Binding Type (BT): A one-octet field that identifies the type of
binding included in the TLV. This document specifies the following BT binding included in the TLV. This document specifies the following BT
values: <list style="symbols"> values:</t>
<t>BT = 0: The binding value is a 20-bit MPLS label value. The TLV <ul spacing="normal">
is padded to 4-bytes alignment. The Length MUST be set to 7 (the <li>BT = 0: The binding value is a 20-bit MPLS label value. The TLV is
padding is not included in the length, as per <xref padded to 4-bytes alignment. The Length <bcp14>MUST</bcp14> be set to
target="RFC5440"/> Section 7.1) and the first 20 bits are used to 7 (the padding is not included in the length, as per <xref
encode the MPLS label value.</t> target="RFC5440" sectionFormat="comma" section="7.1"/>), and the first
20 bits are used to encode the MPLS label value.</li>
<t>BT = 1: The binding value is a 32-bit MPLS label stack entry as <li>BT = 1: The binding value is a 32-bit MPLS Label Stack Entry as
per <xref target="RFC3032"/> with Label, TC <xref per <xref target="RFC3032" format="default"/> with Label, Traffic
target="RFC5462"/>, S, and TTL values encoded. Note that the Class (TC) <xref target="RFC5462" format="default"/>, S, and TTL
receiver MAY choose to override TC, S, and TTL values according to values encoded. Note that the receiver <bcp14>MAY</bcp14> choose to
its local policy. The Length MUST be set to 8.</t> override TC, S, and TTL values according to its local policy. The
Length <bcp14>MUST</bcp14> be set to 8.</li>
<t>BT = 2: The binding value is an SRv6 SID with the format of a <li>BT = 2: The binding value is an SRv6 SID with the format of a
16-octet IPv6 address, representing the binding SID for SRv6. The 16-octet IPv6 address, representing the binding SID for SRv6. The
Length MUST be set to 20.</t> Length <bcp14>MUST</bcp14> be set to 20.</li>
<li>BT = 3: The binding value is a 24-octet field, defined in <xref
<t>BT = 3: The binding value is a 24 octet field, defined in <xref target="Behavior-Structure" format="default"/>, that contains the SRv6
target="Behavior-Structure"/>, that contains the SRv6 SID as well as SID as well as its Behavior and Structure. The Length
its Behavior and Structure. The Length MUST be set to 28.</t> <bcp14>MUST</bcp14> be set to 28.</li>
</list></t> </ul>
<t><xref target="IANA-TLV" format="default"/> defines the IANA registry us
<t><xref target="IANA-TLV"/> defines the IANA registry used to maintain ed to maintain
all these binding types as well as any future ones. Note that multiple these binding types as well as any future ones. Note that multiple
TE-PATH-BINDING TLVs with same or different Binding Types MAY be present TE-PATH-BINDING TLVs with the same or different binding types <bcp14>MAY</
bcp14> be present
for the same LSP. A PCEP speaker could allocate multiple TE-PATH-BINDING for the same LSP. A PCEP speaker could allocate multiple TE-PATH-BINDING
TLVs (of the same BT), and use different binding values in different TLVs (of the same BT) and use different binding values in different
domains or use-cases based on a local policy.</t> domains or use cases based on a local policy.</t>
<t>Flags: 1 octet of flags. The following flag is defined in the new <t>Flags: 1 octet of flags. The following flag is defined in the new
registry "TE-PATH-BINDING TLV Flag field" as described in <xref "TE-PATH-BINDING TLV Flag field" registry as described in <xref target="IA
target="IANA-TLV"/>:</t> NA-TLV" format="default"/>:</t>
<figure anchor="BINDING-LABEL-FLAGS">
<figure anchor="BINDING-LABEL-FLAGS" suppress-title="false" <name>Flags</name>
title="Flags"> <artwork align="left" name="" type="" alt=""><![CDATA[
<artwork align="left"><![CDATA[ 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 |R| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R| | ]]></artwork>
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> </figure>
<t>Where: </t>
<t>where: <list style="symbols"> <ul spacing="normal">
<t>R (Removal - 1 bit): When set, the requesting PCEP peer requires <li>R (Removal - 1 bit): When set, the requesting PCEP peer requires
the removal of the binding value for the LSP. When unset, the PCEP the removal of the binding value for the LSP. When unset, the PCEP
peer indicates that the binding value is added or retained for the peer indicates that the binding value is added or retained for the
LSP. This flag is used in the PCRpt and PCUpd messages. It is LSP. This flag is used in the PCRpt and PCUpd messages. It is ignored
ignored in other PCEP messages.</t> in other PCEP messages.</li>
<li>The unassigned flags <bcp14>MUST</bcp14> be set to 0 while sending
<t>The unassigned flags MUST be set to 0 while sending and ignored and ignored on receipt.</li>
on receipt.</t> </ul>
</list></t>
<!--Currently no flags are defined. </t>--> <!--Currently no flags are defined. </t>-->
<!--Following flags are defined in the new <!--Following flags are defined in the new
registry "TE-PATH-BINDING TLV Flag field" as described in <xref registry "TE-PATH-BINDING TLV Flag field" as described in <xref
target="IANA-TLV"/>:</t> target="IANA-TLV"/>:</t>
<figure anchor="BINDING-LABEL-FLAGS" suppress-title="false" title="Flags"> <figure anchor="BINDING-LABEL-FLAGS" suppress-title="false" title="Flags">
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at line 479 skipping to change at line 363
target="I-D.ietf-spring-segment-routing-policy"/>.</t> target="I-D.ietf-spring-segment-routing-policy"/>.</t>
<t>I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is <t>I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It is
used as described in Section 8.2 of <xref used as described in Section 8.2 of <xref
target="I-D.ietf-spring-segment-routing-policy"/>.</t> target="I-D.ietf-spring-segment-routing-policy"/>.</t>
<t>Unassigned bits MUST be set to 0 while sending and ignored on <t>Unassigned bits MUST be set to 0 while sending and ignored on
receipt.</t> receipt.</t>
</list></t>--> </list></t>-->
<t>Reserved: MUST be set to 0 while sending and ignored on receipt.</t> <t>Reserved: <bcp14>MUST</bcp14> be set to 0 while sending and ignored on
receipt.</t>
<t>Binding Value: A variable-length field, padded with trailing zeros to <t>Binding value: A variable-length field, padded with trailing zeros to
a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS a 4-octet boundary. When the BT is 0, the 20 bits represent the MPLS
label. When the BT is 1, the 32 bits represent the MPLS label stack label. When the BT is 1, the 32 bits represent the MPLS label stack
entry as per <xref target="RFC3032"/>. When the BT is 2, the 128 bits entry as per <xref target="RFC3032" format="default"/>. When the BT is 2,
represent the SRv6 SID. When the BT is 3, the Binding Value also the 128 bits
contains the SRv6 Endpoint Behavior and SID Structure, defined in <xref represent the SRv6 SID. When the BT is 3, the binding value also
target="Behavior-Structure"/>. In this document, the TE-PATH-BINDING TLV contains the SRv6 Endpoint Behavior and SID Structure, defined in <xref ta
is considered to be empty if no Binding Value is present. Note that the rget="Behavior-Structure" format="default"/>. In this document, the TE-PATH-BIND
ING TLV
is considered to be empty if no binding value is present. Note that the
length of the TLV would be 4 in such a case.</t> length of the TLV would be 4 in such a case.</t>
<section anchor="Behavior-Structure" numbered="true" toc="default">
<section anchor="Behavior-Structure" <name>SRv6 Endpoint Behavior and SID Structure</name>
title="SRv6 Endpoint Behavior and SID Structure"> <t>This section specifies the format of the binding value in the
<t>This section specifies the format of the Binding Value in the
TE-PATH-BINDING TLV when the BT is set to 3 for the SRv6 Binding SIDs TE-PATH-BINDING TLV when the BT is set to 3 for the SRv6 Binding SIDs
<xref target="RFC8986"/>. The format is shown in <xref <xref target="RFC8986" format="default"/>. The format is shown in <xref
target="SID-BEHAVIOR-AND-STRUCTURE"/>.</t> target="SID-BEHAVIOR-AND-STRUCTURE" format="default"/>.</t>
<figure anchor="SID-BEHAVIOR-AND-STRUCTURE">
<figure anchor="SID-BEHAVIOR-AND-STRUCTURE" <name>SRv6 Endpoint Behavior and SID Structure</name>
title="SRv6 Endpoint Behavior and SID Structure"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | SRv6 Binding SID (16 octets) |
| SRv6 Binding SID (16 octets) | | |
| | | |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Endpoint Behavior |
| Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LB Length | LN Length | Fun. Length | Arg. Length |
| LB Length | LN Length | Fun. Length | Arg. Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
]]></artwork>
</figure> </figure>
<t>The Binding Value consists of:</t>
<ul spacing="normal">
<li>SRv6 Binding SID: 16 octets. The 128-bit IPv6 address,
representing the binding SID for SRv6.</li>
<li>Reserved: 2 octets. It <bcp14>MUST</bcp14> be set to 0 on
transmit and ignored on receipt.</li>
<li>Endpoint Behavior: 2 octets. The Endpoint Behavior code point
for this SRv6 SID as defined by the "SRv6 Endpoint
Behaviors" registry <xref target="RFC8986"
format="default"/>. When the field is set with the value 0, the
endpoint behavior is considered unknown.</li>
<!-- [rfced] Please verify that this statement is correct, as the "SRv6 Endpoint
Behaviors" registry indicates value 0 is Reserved:
<t>The Binding Value consists of:<list style="symbols"> Original:
<t>SRv6 Binding SID: 16 octets. The 128-bit IPv6 address, When the field is set with the
representing the binding SID for SRv6.</t> value 0, the endpoint behavior is considered unknown.
<t>Reserved: 2 octets. It MUST be set to 0 on transmit and ignored
on receipt.</t>
<t>Endpoint Behavior: 2 octets. The Endpoint Behavior code point
for this SRv6 SID as per the IANA subregistry called "SRv6
Endpoint Behaviors", created by <xref target="RFC8986"/>. When the
field is set with the value 0, the endpoint behavior is considered
unknown.</t>
<t><xref target="RFC8986"/> defines an SRv6 SID as consisting of See https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-
LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most endpoint-behaviors
significant bits of the SID, followed by F bits of function -->
(FUNCT) and A bits of arguments (ARG). A locator may be <li>
represented as B:N where B is the SRv6 SID locator block (IPv6 <t><xref target="RFC8986" format="default"/> defines an SRv6 SID
as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded
in the L most significant bits of the SID, followed by F bits of
function (FUNCT) and A bits of arguments (ARG). A locator may be
represented as B:N, where B is the SRv6 SID locator block (IPv6
prefix allocated for SRv6 SIDs by the operator) and N is the prefix allocated for SRv6 SIDs by the operator) and N is the
identifier of the parent node instantiating the SID called locator identifier of the parent node instantiating the SID, called "locator
node. The following fields are used to advertise the length of node". The following fields are used to advertise the length of
each individual part of the SRv6 SID as defined in :<list each individual part of the SRv6 SID:</t>
style="symbols">
<t>LB Length: 1 octet. SRv6 SID Locator Block length in
bits.</t>
<t>LN Length: 1 octet. SRv6 SID Locator Node length in
bits.</t>
<t>Function Length: 1 octet. SRv6 SID Function length in <!-- [rfced] Figure 4 uses "Arg. Length". Following the figure, "Argument Lengt
bits.</t> h" (singular) is defined as "SRv6 SID Arguments length" (plural) and ARG is intr
oduced as "arguments". Please consider whether these should be consistent (i.e.
, Argument or Arguments). If yes, please indicate whether singular or plural is
correct.
<t>Argument Length: 1 octet. SRv6 SID Arguments length in Note that the plural form is used in RFC 9603.
bits.</t> -->
</list></t>
</list></t>
<ul spacing="normal">
<li>LB Length: 1 octet. SRv6 SID Locator Block length in
bits.</li>
<li>LN Length: 1 octet. SRv6 SID Locator Node length in
bits.</li>
<li>Function Length: 1 octet. SRv6 SID Function length in
bits.</li>
<li>Argument Length: 1 octet. SRv6 SID Arguments length in
bits.</li>
</ul>
</li>
</ul>
<t>The total of the locator block, locator node, function, and <t>The total of the locator block, locator node, function, and
argument lengths MUST be lower or equal to 128 bits. If this condition argument lengths <bcp14>MUST</bcp14> be less than or equal to 128 bits. If this condition
is not met, the corresponding TE-PATH-BINDING TLV is considered is not met, the corresponding TE-PATH-BINDING TLV is considered
invalid. Also, if the Endpoint Behavior is found to be unknown or invalid. Also, if the Endpoint Behavior is found to be unknown or
inconsistent, it is considered invalid. A PCErr message with inconsistent, it is considered invalid. A PCErr message with
Error-Type = 10 ("Reception of an invalid object") and Error-Value = Error-Type = 10 ("Reception of an invalid object") and Error-value =
37 ("Invalid SRv6 SID Structure") MUST be sent in such cases.</t> 37 ("Invalid SRv6 SID Structure") <bcp14>MUST</bcp14> be sent in such ca
ses.</t>
<t>The SRv6 SID Structure could be used by the PCE for ease of <t>The SRv6 SID Structure could be used by the PCE for ease of
operations and monitoring. For example, this information could be used operations and monitoring. For example, this information could be used
for validation of SRv6 SIDs being instantiated in the network and for validation of SRv6 SIDs being instantiated in the network and
checked for conformance to the SRv6 SID allocation scheme chosen by checked for conformance to the SRv6 SID allocation scheme chosen by
the operator as described in Section 3.2 of <xref target="RFC8986"/>. the operator as described in <xref target="RFC8986" sectionFormat="of" s
In the future, PCE could also be used for verification and the ection="3.2"/>.
automation for securing the SRv6 domain by provisioning filtering In the future, PCE could also be used for verification and for
rules at SR domain boundaries as described in Section 5 of <xref automatically securing the SRv6 domain by provisioning filtering
target="RFC8754"/>. The details of these potential applications are rules at SR domain boundaries as described in <xref target="RFC8754" sec
tionFormat="of" section="5"/>. The details of these potential applications are
outside the scope of this document.</t> outside the scope of this document.</t>
</section> </section>
</section> </section>
<!-- Path-setup-type-tlv --> <!-- Path-setup-type-tlv -->
<section anchor="Operation" title="Operation"> <section anchor="Operation" numbered="true" toc="default">
<name>Operation</name>
<t>The binding value is usually allocated by the PCC and reported to a <t>The binding value is usually allocated by the PCC and reported to a
PCE via a PCRpt message (see <xref target="PCECC"/> where PCE does the PCE via a PCRpt message (see <xref target="PCECC" format="default"/> where PCE performs the
allocation). If a PCE does not recognize the TE-PATH-BINDING TLV, it allocation). If a PCE does not recognize the TE-PATH-BINDING TLV, it
would ignore the TLV in accordance with <xref target="RFC5440"/>. If a would ignore the TLV in accordance with <xref target="RFC5440" format="def
PCE recognizes the TLV but does not support the TLV, it MUST send a ault"/>. If a
PCErr with Error-Type = 2 (Capability not supported).</t> PCE recognizes the TLV but does not support the TLV, it <bcp14>MUST</bcp14
> send a
PCErr with Error-Type = 2 ("Capability not supported").</t>
<t>Multiple TE-PATH-BINDING TLVs are allowed to be present in the same <t>Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
LSP object. This signifies the presence of multiple binding SIDs for the LSP object. This signifies the presence of multiple binding SIDs for the
given LSP. In the case of multiple TE-PATH-BINDING TLVs, the existing given LSP. In the case of multiple TE-PATH-BINDING TLVs, the existing
instances of TE-PATH-BINDING TLVs MAY be included in the LSP object. In instances of TE-PATH-BINDING TLVs <bcp14>MAY</bcp14> be included in the LS
case of an error condition, the whole message is rejected and the P object. In
resulting PCErr message MAY include the offending TE-PATH-BINDING TLV in case of an error condition, the whole message is rejected, and the
resulting PCErr message <bcp14>MAY</bcp14> include the offending TE-PATH-B
INDING TLV in
the PCEP-ERROR object.</t> the PCEP-ERROR object.</t>
<t>If a PCE recognizes an invalid binding value (e.g., label value from <t>If a PCE recognizes an invalid binding value (e.g., label value from
the reserved MPLS label space), it MUST send a PCErr message with the reserved MPLS label space), it <bcp14>MUST</bcp14> send a PCErr messag
Error-Type = 10 ("Reception of an invalid object") and Error Value = 2 e with
("Bad label value") as specified in <xref target="RFC8664"/>.</t> Error-Type = 10 ("Reception of an invalid object") and Error-value = 2
("Bad label value") as specified in <xref target="RFC8664" format="default
<t>For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the "/>.</t>
<t>For SRv6 BSIDs, it is <bcp14>RECOMMENDED</bcp14> to always explicitly s
pecify the
SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV by SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV by
setting the BT (Binding Type) to 3. This can enable the sender to have setting BT to 3. This can enable the sender to have
control of the SRv6 Endpoint Behavior and SID Structure. A sender MAY control of the SRv6 Endpoint Behavior and SID Structure. A sender <bcp14>M
AY</bcp14>
choose to set the BT to 2, in which case the receiving implementation choose to set the BT to 2, in which case the receiving implementation
chooses how to interpret the SRv6 Endpoint Behavior and SID Structure chooses how to interpret the SRv6 Endpoint Behavior and SID Structure
according to local policy.</t> according to local policy.</t>
<t>If a PCC wishes to withdraw a previously reported binding value, it <t>If a PCC wishes to withdraw a previously reported binding value, it
MUST send a PCRpt message with the specific TE-PATH-BINDING TLV with R <bcp14>MUST</bcp14> send a PCRpt message with the specific TE-PATH-BINDING TLV with R
flag set to 1. If a PCC wishes to modify a previously reported binding, flag set to 1. If a PCC wishes to modify a previously reported binding,
it MUST withdraw the former binding value (with R flag set in the former it <bcp14>MUST</bcp14> withdraw the former binding value (with R flag set in the former
TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing TE-PATH-BINDING TLV) and include a new TE-PATH-BINDING TLV containing
the new binding value. Note that other instances of TE-PATH-BINDING TLVs the new binding value. Note that other instances of TE-PATH-BINDING TLVs
that are unchanged MAY also be included. If the unchanged instances are that are unchanged <bcp14>MAY</bcp14> also be included. If the unchanged i nstances are
not included, they will remain associated with the LSP.</t> not included, they will remain associated with the LSP.</t>
<t>If a PCE requires a PCC to allocate one (or several) specific binding
<t>If a PCE requires a PCC to allocate a (or several) specific binding
value(s), it may do so by sending a PCUpd or PCInitiate message value(s), it may do so by sending a PCUpd or PCInitiate message
containing a TE-PATH-BINDING TLV(s). If the value(s) can be successfully containing one or more TE-PATH-BINDING TLVs. If the values can be successf
allocated, the PCC reports the binding value(s) to the PCE. If the PCC ully
considers the binding value specified by the PCE invalid, it MUST send a allocated, the PCC reports the binding values to the PCE. If the PCC
PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and considers the binding value specified by the PCE invalid, it <bcp14>MUST</
Error Value = TBD3 ("Invalid SID"). If the binding value is valid, but bcp14> send a
the PCC is unable to allocate the binding value, it MUST send a PCErr PCErr message with Error-Type = 32 ("Binding label/SID failure") and
message with Error-Type = TBD2 ("Binding label/SID failure") and Error Error-value = 1 ("Invalid SID"). If the binding value is valid but
Value = TBD4 ("Unable to allocate the specified binding value"). Note the PCC is unable to allocate the binding value, it <bcp14>MUST</bcp14> se
nd a PCErr
message with Error-Type = 32 ("Binding label/SID failure") and Error-value
= 2 ("Unable to allocate the specified binding value"). Note
that, in case of an error, the PCC rejects the PCUpd or PCInitiate that, in case of an error, the PCC rejects the PCUpd or PCInitiate
message in its entirety and can include the offending TE-PATH-BINDING message in its entirety and can include the offending TE-PATH-BINDING
TLV in the PCEP-ERROR object.</t> TLV in the PCEP-ERROR object.</t>
<t>If a PCE wishes to request the withdrawal of a previously reported <t>If a PCE wishes to request the withdrawal of a previously reported
binding value, it MUST send a PCUpd message with the specific binding value, it <bcp14>MUST</bcp14> send a PCUpd message with the specif ic
TE-PATH-BINDING TLV with R flag set to 1. If a PCE wishes to modify a TE-PATH-BINDING TLV with R flag set to 1. If a PCE wishes to modify a
previously requested binding value, it MUST request the withdrawal of previously requested binding value, it <bcp14>MUST</bcp14> request the wit hdrawal of
the former binding value (with R flag set in the former TE-PATH-BINDING the former binding value (with R flag set in the former TE-PATH-BINDING
TLV) and include a new TE-PATH-BINDING TLV containing the new binding TLV) and include a new TE-PATH-BINDING TLV containing the new binding
value. If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where value. If a PCC receives a PCUpd message with TE-PATH-BINDING TLV where
the R flag is set to 1, but either the binding value is missing (empty the R flag is set to 1, but either the binding value is missing (empty
TE-PATH-BINDING TLV) or the binding value is incorrect, it MUST send a TE-PATH-BINDING TLV) or the binding value is incorrect, it <bcp14>MUST</bc
PCErr message with Error-Type = TBD2 ("Binding label/SID failure") and p14> send a
Error Value = TBD6 ("Unable to remove the binding value").</t> PCErr message with Error-Type = 32 ("Binding label/SID failure") and
Error-value = 4 ("Unable to remove the binding value").</t>
<!--<t>If a PCC wishes to withdraw all previously reported binding values, it <!--<t>If a PCC wishes to withdraw all previously reported binding values, it
MUST send a PCRpt message without any TE-PATH-BINDING TLV. If a MUST send a PCRpt message without any TE-PATH-BINDING TLV. If a
PCC wishes to modify any or all previously reported binding values, it PCC wishes to modify any or all previously reported binding values, it
MUST send a PCRpt message containing TE-PATH-BINDING TLVs MUST send a PCRpt message containing TE-PATH-BINDING TLVs
containing all the binding values that apply from that point on.</t> containing all the binding values that apply from that point on.</t>
<t>If a PCE wishes to modify a previously requested binding value, it <t>If a PCE wishes to modify a previously requested binding value, it
MUST send a PCUpd message with TE-PATH-BINDING TLVs containing MUST send a PCUpd message with TE-PATH-BINDING TLVs containing
all the binding values that apply from that point on. The absence of all the binding values that apply from that point on. The absence of
TE-PATH-BINDING TLV in PCUpd message means that the PCE does TE-PATH-BINDING TLV in PCUpd message means that the PCE does
skipping to change at line 663 skipping to change at line 540
<!--<t>The absence of TE-PATH-BINDING TLV in PCUpd message means <!--<t>The absence of TE-PATH-BINDING TLV in PCUpd message means
that the PCE does not specify a binding value in which case any previous a llocated binding values are withdraw.</t>--> that the PCE does not specify a binding value in which case any previous a llocated binding values are withdraw.</t>-->
<!--<t>If a PCC receives a new valid binding value from the PCE, it MUST t ry to allocate the new binding value. <!--<t>If a PCC receives a new valid binding value from the PCE, it MUST t ry to allocate the new binding value.
If a PCC does not receive an former binding value for the PCE, it MUST w ithdraw the former binding value. If a PCC does not receive an former binding value for the PCE, it MUST w ithdraw the former binding value.
If the new binding value is successfully allocated, the PCC MUST report If the new binding value is successfully allocated, the PCC MUST report
the new value to the PCE. Otherwise, it MUST send a PCErr message with the new value to the PCE. Otherwise, it MUST send a PCErr message with
Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD4 Error-Type = TBD2 ("Binding label/SID failure") and Error Value = TBD4
("Unable to allocate the specified binding value"). Note that, all instanc es of TE-PATH-BINDING TLV that remains unchanged are always included in the LSP object and the offending TE-PATH-BINDING TLV is included in the PCEP-ERROR objec t.</t>--> ("Unable to allocate the specified binding value"). Note that, all instanc es of TE-PATH-BINDING TLV that remains unchanged are always included in the LSP object and the offending TE-PATH-BINDING TLV is included in the PCEP-ERROR objec t.</t>-->
<!-- [rfced] For readability, may we update this text as follows?
Original:
Only one such instance of empty TE-
PATH-BINDING TLV, per BT, SHOULD be included in the LSP object and
others ignored on receipt.
Perhaps:
Only one such instance of empty TE-
PATH-BINDING TLV, per BT, SHOULD be included in the LSP object;
others should be ignored on receipt.
-->
<t>In some cases, a stateful PCE may want to request that the PCC <t>In some cases, a stateful PCE may want to request that the PCC
allocate a binding value of the PCC's own choosing. It instructs the PCC allocate a binding value of the PCC's own choosing. It instructs the PCC
by sending a PCUpd message containing an empty TE-PATH-BINDING TLV, by sending a PCUpd message containing an empty TE-PATH-BINDING TLV,
i.e., no binding value is specified (bringing the Length field of the i.e., no binding value is specified (bringing the Length field of the
TLV to 4). A PCE can also request a PCC to allocate a binding value at TLV to 4). A PCE can also request that a PCC allocate a binding value at
the time of initiation by sending a PCInitiate message with an empty the time of initiation by sending a PCInitiate message with an empty
TE-PATH-BINDING TLV. Only one such instance of empty TE-PATH-BINDING TE-PATH-BINDING TLV. Only one such instance of empty TE-PATH-BINDING
TLV, per BT, SHOULD be included in the LSP object and others ignored on TLV, per BT, <bcp14>SHOULD</bcp14> be included in the LSP object and other s ignored on
receipt. If the PCC is unable to allocate a new binding value as per the receipt. If the PCC is unable to allocate a new binding value as per the
specified BT, it MUST send a PCErr message with Error-Type = TBD2 specified BT, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type
("Binding label/SID failure") and Error-Value = TBD5 ("Unable to = 32
("Binding label/SID failure") and Error-value = 3 ("Unable to
allocate a new binding label/SID").</t> allocate a new binding label/SID").</t>
<t>As previously noted, if a message contains an invalid TE-PATH-BINDING <t>As previously noted, if a message contains an invalid TE-PATH-BINDING
TLV that leads to an error condition, the whole message is rejected TLV that leads to an error condition, the whole message is rejected
including any other valid instances of TE-PATH-BINDING TLVs, if any. The including any other valid instances of TE-PATH-BINDING TLVs, if any. The
resulting error message MAY include the offending TE-PATH-BINDING TLV in resulting error message <bcp14>MAY</bcp14> include the offending TE-PATH-B INDING TLV in
the PCEP-ERROR object.</t> the PCEP-ERROR object.</t>
<t>If a PCC receives a TE-PATH-BINDING TLV in any message other than <t>If a PCC receives a TE-PATH-BINDING TLV in any message other than
PCUpd or PCInitiate, it MUST close the corresponding PCEP session with PCUpd or PCInitiate, it <bcp14>MUST</bcp14> close the corresponding PCEP s
the reason "Reception of a malformed PCEP message" (according to <xref ession with
target="RFC5440"/>). Similarly, if a PCE receives a TE-PATH-BINDING TLV the reason "Reception of a malformed PCEP message" (according to <xref tar
get="RFC5440" format="default"/>). Similarly, if a PCE receives a TE-PATH-BINDIN
G TLV
in any message other than a PCRpt or if the TE-PATH-BINDING TLV is in any message other than a PCRpt or if the TE-PATH-BINDING TLV is
associated with any object other than an LSP or PCEP-ERROR object, the associated with any object other than an LSP or PCEP-ERROR object, the
PCE MUST close the corresponding PCEP session with the reason "Reception PCE <bcp14>MUST</bcp14> close the corresponding PCEP session with the reas
of a malformed PCEP message" (according to <xref on "Reception
target="RFC5440"/>).</t> of a malformed PCEP message" (according to <xref target="RFC5440" format="
default"/>).</t>
<t>If a TE-PATH-BINDING TLV is absent in the PCRpt message and no <t>If a TE-PATH-BINDING TLV is absent in the PCRpt message and no
binding values were reported before, the PCE MUST assume that the binding values were previously reported, the PCE <bcp14>MUST</bcp14> assum e that the
corresponding LSP does not have any binding. Similarly, if corresponding LSP does not have any binding. Similarly, if
TE-PATH-BINDING TLV is absent in the PCUpd message and no binding values TE-PATH-BINDING TLV is absent in the PCUpd message and no binding values
were reported before, the PCC's local policy dictates how the binding were previously reported, the PCC's local policy dictates how the binding
allocations are made for a given LSP.</t> allocations are made for a given LSP.</t>
<t>Note that some binding types have similar information but different <t>Note that some binding types have similar information but different
binding value formats. For example, BT=(2 or 3) is used for the SRv6 SID binding value formats. For example, BT=(2 or 3) is used for the SRv6 SID,
and BT=(0 or 1) is used for the MPLS Label. In case a PCEP speaker and BT=(0 or 1) is used for the MPLS Label. In case a PCEP speaker
receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS receives multiple TE-PATH-BINDING TLVs with the same SRv6 SID or MPLS
Label but different BT values, it MUST send a PCErr message with Label but different BT values, it <bcp14>MUST</bcp14> send a PCErr message
Error-Type = TBD2 ("Binding label/SID failure") and Error-Value = TBD7 with
Error-Type = 32 ("Binding label/SID failure") and Error-value = 5
("Inconsistent binding types").</t> ("Inconsistent binding types").</t>
</section> </section>
<section anchor="SR-ERO" numbered="true" toc="default">
<section anchor="SR-ERO" title="Binding SID in SR-ERO"> <name>Binding SID in SR-ERO</name>
<t>In PCEP messages, LSP route information is carried in the Explicit <t>In PCEP messages, LSP route information is carried in the Explicit
Route Object (ERO), which consists of a sequence of subobjects. <xref Route Object (ERO), which consists of a sequence of subobjects. <xref
target="RFC8664"/> defines the "SR-ERO subobject" capable of carrying a target="RFC8664" format="default"/> defines the "SR-ERO subobject"
SID as well as the identity of the node/adjacency (NAI) represented by capable of carrying a SID as well as the identity of the Node or
the SID. The NAI Type (NT) field indicates the type and format of the Adjacency Identifier (NAI) represented by the SID. The NAI Type (NT)
NAI contained in the SR-ERO. In case of binding SID, the NAI MUST NOT be field indicates the type and format of the NAI contained in the
included and NT MUST be set to zero. <xref target="RFC8664"/> Section SR-ERO. In case of binding SID, the NAI <bcp14>MUST NOT</bcp14> be
5.2.1 specifies bit settings and error handling in the case when NT=0. included and NT <bcp14>MUST</bcp14> be set to zero. <xref
target="RFC8664" sectionFormat="of" section="5.2.1"/> specifies bit
settings and error handling in the case when NT=0.
<!--So as per <!--So as per
Section 5.2.1 of <xref target="RFC8664"/>, for NT=0, the F bit is set to Section 5.2.1 of <xref target="RFC8664"/>, for NT=0, the F bit is set to
1, the S bit needs to be zero and the Length is 8. Further, the M bit is 1, the S bit needs to be zero and the Length is 8. Further, the M bit is
set. If these conditions are not met, the entire ERO MUST be considered set. If these conditions are not met, the entire ERO MUST be considered
invalid and a PCErr message is sent by the PCC with Error-Type = 10 invalid and a PCErr message is sent by the PCC with Error-Type = 10
("Reception of an invalid object") and Error-Value = 11 ("Malformed ("Reception of an invalid object") and Error-Value = 11 ("Malformed
object").--></t> object").-->
</t>
</section> </section>
<section anchor="SRv6-ERO" numbered="true" toc="default">
<section anchor="SRv6-ERO" title="Binding SID in SRv6-ERO"> <name>Binding SID in SRv6-ERO</name>
<!--<t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> defines a new ER <!--<t><xref target="RFCYYY1"/> defines a new ERO
O
subobject "SRv6-ERO subobject" for an SRv6 SID. As stated in <xref subobject "SRv6-ERO subobject" for an SRv6 SID. As stated in <xref
target="SR-ERO"/>, in case of binding SID, the NAI is not included and target="SR-ERO"/>, in case of binding SID, the NAI is not included and
NT is set to zero i.e., NT=0, the F bit is set to 1, the S bit needs to NT is set to zero i.e., NT=0, the F bit is set to 1, the S bit needs to
be zero and the Length is 24 <xref be zero and the Length is 24 <xref
target="I-D.ietf-pce-segment-routing-ipv6"/>. As per <xref target="I-D.ietf-pce-segment-routing-ipv6"/>. As per <xref
target="RFC8664"/>, if these conditions are not met, the entire ERO is target="RFC8664"/>, if these conditions are not met, the entire ERO is
considered invalid and a PCErr message is sent by the PCC with considered invalid and a PCErr message is sent by the PCC with
Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11 Error-Type = 10 ("Reception of an invalid object") and Error-Value = 11
("Malformed object").</t>--> ("Malformed object").</t>-->
<t><xref target="I-D.ietf-pce-segment-routing-ipv6"/> defines the <t><xref target="RFC9603" format="default"/> defines the "SRv6-ERO
"SRv6-ERO subobject" for an SRv6 SID. Similarly to SR-ERO (<xref subobject" for an SRv6 SID. Similarly to SR-ERO (<xref target="SR-ERO"
target="SR-ERO"/>), the NAI MUST NOT be included and the NT MUST be set format="default"/>), the NAI <bcp14>MUST NOT</bcp14> be included and
to zero. <xref target="RFC8664"/> Section 5.2.1 specifies bit settings the NT <bcp14>MUST</bcp14> be set to zero. <xref target="RFC8664"
and error handling in the case when NT=0.</t> sectionFormat="of" section="5.2.1"/> specifies bit settings and error
handling in the case when NT=0.</t>
</section> </section>
<section anchor="PCECC" toc="default" numbered="true">
<section anchor="PCECC" title="PCE Allocation of Binding label/SID" <name>PCE Allocation of Binding label/SID</name>
toc="default"> <t><xref target="Operation" format="default"/> already includes the scenar
<t><xref target="Operation"/> already includes the scenario where a PCE io where a PCE
requires a PCC to allocate a specified binding value by sending a PCUpd requires a PCC to allocate a specified binding value by sending a PCUpd
or PCInitiate message containing a TE-PATH-BINDING TLV. This section or PCInitiate message containing a TE-PATH-BINDING TLV. This section
specifies an OPTIONAL feature for the PCE to allocate the binding specifies an <bcp14>OPTIONAL</bcp14> feature for the PCE to allocate the b inding
label/SID of its own accord in the case where the PCE also controls the label/SID of its own accord in the case where the PCE also controls the
label space of the PCC and can make the label allocation on its own as label space of the PCC and can make the label allocation on its own as
described in <xref target="RFC8283"/>. Note that the act of requesting a described in <xref target="RFC8283" format="default"/>. Note that the act
specific binding value (<xref target="Operation"/>) is different from of requesting a
specific binding value (<xref target="Operation" format="default"/>) is di
fferent from
the act of allocating a binding label/SID as described in this the act of allocating a binding label/SID as described in this
section.</t> section.</t>
<t><xref target="RFC8283" format="default"/> introduces the architecture f
<t><xref target="RFC8283"/> introduces the architecture for PCE as a or PCE as a
central controller as an extension of the architecture described in central controller as an extension of the architecture described in
<xref target="RFC4655"/> and assumes the continued use of PCEP as the <xref target="RFC4655" format="default"/> and assumes the continued use of
protocol used between PCE and PCC. <xref target="RFC9050"/> specifies PCEP as the
protocol used between PCE and PCC. <xref target="RFC9050" format="default"
/> specifies
the procedures and PCEP extensions for using the PCE as the central the procedures and PCEP extensions for using the PCE as the central
controller. It assumes that the exclusive label range to be used by a controller. It assumes that the exclusive label range to be used by a
PCE is known and set on both PCEP peers. A future extension could add PCE is known and set on both PCEP peers. A future extension could add
the capability to advertise this range via a possible PCEP extension as the capability to advertise this range via a possible PCEP extension as
well (see <xref target="I-D.li-pce-controlled-id-space"/>).</t> well (see <xref target="I-D.ietf-pce-controlled-id-space" format="default"
/>).</t>
<t>When PCECC operations are supported as per <xref target="RFC9050"/>, <t>When PCE as a Central Controller (PCECC) operations are supported as pe
the binding label/SID MAY also be allocated by the PCE itself. Both r <xref target="RFC9050" format="default"/>,
peers need to exchange the PCECC capability as described in <xref the binding label/SID <bcp14>MAY</bcp14> also be allocated by the PCE itse
target="RFC9050"/> before the PCE can allocate the binding label/SID on lf. Both
peers need to exchange the PCECC capability as described in <xref target="
RFC9050" format="default"/> before the PCE can allocate the binding label/SID on
its own.</t> its own.</t>
<t>A new P flag in the LSP object <xref target="RFC8231" format="default"/
<t>A new P flag in the LSP object <xref target="RFC8231"/> is introduced > is introduced
to indicate that the allocation needs to be made by the PCE. Note that to indicate that the allocation needs to be made by the PCE. Note that
the P flag could be used for other types of allocations (such as path the P flag could be used for other types of allocations (such as path
segments <xref target="I-D.ietf-pce-sr-path-segment"/>) in future. <list segments <xref target="I-D.ietf-pce-sr-path-segment" format="default"/>) i
style="symbols"> n the future. </t>
<t>P (PCE-allocation): If the bit is set to 1, it indicates that the
PCC requests PCE to make allocations for this LSP. The
TE-PATH-BINDING TLV in the LSP object identifies that the allocation
is for a binding label/SID. A PCC MUST set this bit to 1 and include
a TE-PATH-BINDING TLV in the LSP object if it wishes to request for
allocation of binding label/SID by the PCE in the PCEP message. A
PCE MUST also set this bit to 1 and include a TE-PATH-BINDING TLV to
indicate that the binding label/SID is allocated by PCE and encoded
in the PCEP message towards the PCC. Further, if the binding
label/SID is allocated by the PCC, the PCE MUST set this bit to 0
and follow the procedure described in <xref
target="Operation"/>.</t>
</list></t>
<t>Note that - <list style="symbols"> <t indent="3">P (PCE-allocation): If the bit is set to 1, it indicates
<t>A PCE could allocate the binding label/SID of its own accord for that the PCC requests that the PCE make allocations for this LSP. The
a PCE-initiated or delegated LSP, and inform the PCC in the TE-PATH-BINDING TLV in the LSP object identifies that the allocation
is for a binding label/SID. A PCC <bcp14>MUST</bcp14> set this bit to
1 and include a TE-PATH-BINDING TLV in the LSP object if it wishes to
request an allocation for a binding label/SID by the PCE in the PCEP
message. A PCE <bcp14>MUST</bcp14> also set this bit to 1 and include
a TE-PATH-BINDING TLV to indicate that the binding label/SID is
allocated by PCE and encoded in the PCEP message towards the
PCC. Further, if the binding label/SID is allocated by the PCC, the
PCE <bcp14>MUST</bcp14> set this bit to 0 and follow the procedure
described in <xref target="Operation" format="default"/>.</t>
<t>Note that: </t>
<ul spacing="normal">
<li>A PCE could allocate the binding label/SID of its own accord for
a PCE-initiated or PCE-delegated LSP and inform the PCC in the
PCInitiate message or PCUpd message by setting P=1 and including PCInitiate message or PCUpd message by setting P=1 and including
TE-PATH-BINDING TLV in the LSP object.</t> TE-PATH-BINDING TLV in the LSP object.</li>
<li>To let the PCC allocate the binding label/SID, a PCE <bcp14>MUST</bc
p14> set P=0
and include an empty TE-PATH-BINDING TLV (i.e., no binding value is
specified) in the LSP object in the PCInitiate/PCUpd message.</li>
<li>To request that the PCE allocate the binding label/SID, a PCC
<bcp14>MUST</bcp14> set P=1, D=1, and include an empty TE-PATH-BINDING
TLV in the PCRpt
message.
<t>To let the PCC allocate the binding label/SID, a PCE MUST set P=0 <!-- [rfced] We're having trouble understanding "respond to the PCC with
and include an empty TE-PATH-BINDING TLV ( i.e., no binding value is PCUpd message". Please let us know if either of the following help
specified) in the LSP object in PCInitiate/PCUpd message.</t> clarify or if there's another way to clarify this sentence.
<t>To request that the PCE allocate the binding label/SID, a PCC Also, may we update "P=1, D=1" to "P=1 and D=1" for clarity?
MUST set P=1, D=1, and include an empty TE-PATH-BINDING TLV in PCRpt
message. The PCE will attempt to allocate it and respond to the PCC Original:
The PCE will attempt to allocate it and respond to the
PCC with PCUpd message including the allocated binding label/SID
in the TE-PATH-BINDING TLV and P=1, D=1 in the LSP object.
Perhaps (adding "a" before "PCUpd message"):
The PCE will attempt to allocate it and respond to the
PCC with a PCUpd message that includes the allocated binding label/SID
in the TE-PATH-BINDING TLV and P=1 and D=1 in the LSP object.
-->
The PCE will attempt to allocate it and respond to the PCC
with PCUpd message including the allocated binding label/SID in the with PCUpd message including the allocated binding label/SID in the
TE-PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is TE-PATH-BINDING TLV and P=1, D=1 in the LSP object. If the PCE is
unable to allocate, it MUST send a PCErr message with Error-Type = unable to allocate the binding label/SID, it <bcp14>MUST</bcp14> send
TBD2 ("Binding label/SID failure") and Error-Value = TBD5 ("Unable a PCErr message with Error-Type =
to allocate a new binding label/SID").</t> 32 ("Binding label/SID failure") and Error-value = 3 ("Unable
to allocate a new binding label/SID").</li>
<li>
<t>If one or both speakers (PCE and PCC) have not indicated support <t>If one or both speakers (PCE and PCC) have not indicated support
and willingness to use the PCEP extensions for the PCECC as per and willingness to use the PCEP extensions for the PCECC as per
<xref target="RFC9050"/> and a PCEP peer receives P=1 in the LSP <xref target="RFC9050" format="default"/> and a PCEP peer receives P=1
object, it MUST: <list style="symbols"> in the LSP
<t>send a PCErr message with Error-Type=19 (Invalid Operation) object, they <bcp14>MUST</bcp14>: </t>
and Error-value=16 (Attempted PCECC operations when PCECC <ul spacing="normal">
capability was not advertised) and</t> <li>send a PCErr message with Error-Type = 19 ("Invalid Operation")
and Error-value = 16 ("Attempted PCECC operations when PCECC
<t>terminate the PCEP session.</t> capability was not advertised") and</li>
</list></t> <li>terminate the PCEP session.</li>
</ul>
<t>A legacy PCEP speaker that does not recognize the P flag in the </li>
LSP object would ignore it in accordance with <xref <li>A legacy PCEP speaker that does not recognize the P flag in the
target="RFC8231"/>.</t> LSP object would ignore it in accordance with <xref target="RFC8231" f
</list></t> ormat="default"/>.</li>
</ul>
<t>It is assumed that the label range to be used by a PCE is known and <t>It is assumed that the label range to be used by a PCE is known and
set on both PCEP peers. The exact mechanism is out of the scope of <xref set on both PCEP peers. The exact mechanism is out of the scope of <xref t
target="RFC9050"/> or this document. Note that the specific BSID could arget="RFC9050" format="default"/> and this document. Note that the specific BSI
D could
be from the PCE-controlled or the PCC-controlled label space. The PCE be from the PCE-controlled or the PCC-controlled label space. The PCE
can directly allocate the label from the PCE-controlled label space can directly allocate the label from the PCE-controlled label space
using P=1 as described above, whereas the PCE can request the allocation using P=1 as described above, whereas the PCE can request the allocation
of a specific BSID from the PCC-controlled label space with P=0 as of a specific BSID from the PCC-controlled label space with P=0 as
described in <xref target="Operation"/>.</t> described in <xref target="Operation" format="default"/>.</t>
<!--<t>A PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV <x ref target="I-D.ietf-pce-binding-label-sid"/> in the LSP object) to request for <!--<t>A PCC would set this bit to 1 (and carry the TE-PATH-BINDING TLV <x ref target="I-D.ietf-pce-binding-label-sid"/> in the LSP object) to request for
allocation of the binding label by the PCE in the PCReq or PCRpt allocation of the binding label by the PCE in the PCReq or PCRpt
message. A PCE would also set this bit to 1 to indicate that the message. A PCE would also set this bit to 1 to indicate that the
binding label is allocated by PCE and encoded in the PCRep, binding label is allocated by PCE and encoded in the PCRep,
PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is present in PCUpd, or PCInitiate message (the TE-PATH-BINDING TLV is present in
LSP object). Further, a PCE would set this bit to 0 to indicate LSP object). Further, a PCE would set this bit to 0 to indicate
that the allocation is done by the PCC instead.</t>--> that the allocation is done by the PCC instead.</t>-->
<!--<t>The ingress PCC could request the binding label to be allocated by the PCE <!--<t>The ingress PCC could request the binding label to be allocated by the PCE
via a PCRpt message as per <xref target="RFC8231"/>. The delegate flag (D-fl ag) MUST via a PCRpt message as per <xref target="RFC8231"/>. The delegate flag (D-fl ag) MUST
skipping to change at line 860 skipping to change at line 757
TE-PATH-BINDING TLV in an LSP object. The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t>--> TE-PATH-BINDING TLV in an LSP object. The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t>-->
<!--<t>The PCE could allocate the binding label on its own accord for a PC E- <!--<t>The PCE could allocate the binding label on its own accord for a PC E-
Initiated (or delegated) LSP. The allocated binding label needs to be Initiated (or delegated) LSP. The allocated binding label needs to be
informed to the PCC. The PCE would use the informed to the PCC. The PCE would use the
PCInitiate message <xref target="RFC8281"/> or PCUpd message <xref target="RF C8231"/> towards the PCInitiate message <xref target="RFC8281"/> or PCUpd message <xref target="RF C8231"/> towards the
PCC and MUST include the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t> --> PCC and MUST include the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t> -->
<!--<t>Before a PCE can allocate a binding label the PCECC capability MUST be exchanged on the PCEP session. Note that the CCI object is not used for bind ing allocation; this is done to maintain consistency with the rest of the bindin g label/SID procedures as per <xref target="I-D.ietf-pce-binding-label-sid"/>.</ t>--> <!--<t>Before a PCE can allocate a binding label the PCECC capability MUST be exchanged on the PCEP session. Note that the CCI object is not used for bind ing allocation; this is done to maintain consistency with the rest of the bindin g label/SID procedures as per <xref target="I-D.ietf-pce-binding-label-sid"/>.</ t>-->
<t>Note that, the P-Flag in the LSP object SHOULD NOT be set to 1 <t>Note that the P flag in the LSP object <bcp14>SHOULD NOT</bcp14> be set to 1
without the presence of TE-PATH-BINDING TLV or any other future TLV without the presence of TE-PATH-BINDING TLV or any other future TLV
defined for PCE allocation. On receipt of such an LSP object, the P-Flag defined for PCE allocation. On receipt of such an LSP object, the P flag
is ignored. The presence of TE-PATH-BINDING TLV with P=1 indicates the is ignored. The presence of TE-PATH-BINDING TLV with P=1 indicates the
allocation is for the binding label/SID. In the future, some other TLV allocation is for the binding label/SID. In the future, some other TLV
(such as one defined in <xref target="I-D.ietf-pce-sr-path-segment"/>) (such as one defined in <xref target="I-D.ietf-pce-sr-path-segment" format ="default"/>)
could also be used alongside P=1 to indicate allocation of a different could also be used alongside P=1 to indicate allocation of a different
attribute. A future document should not attempt to assign semantics to attribute. A future document should not attempt to assign semantics to
P=1 without limiting its scope that both PCEP peers could agree on.</t> P=1 without limiting the scope to one that both PCEP peers can agree on.</
</section> t>
<section anchor="Imp" title="Implementation Status">
<t>[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]</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="Huawei" title="Huawei">
<t><list style="symbols">
<t>Organization: Huawei</t>
<t>Implementation: Huawei's Router and Controller</t>
<t>Description: An experimental code-point is used and will be
modified to the value allocated in this document.</t>
<t>Maturity Level: Production</t>
<t>Coverage: Full</t>
<t>Contact: c.l@huawei.com</t>
</list></t>
</section>
<section anchor="Cisco" title="Cisco">
<t><list style="symbols">
<t>Organization: Cisco Systems</t>
<t>Implementation: Head-end and controller.</t>
<t>Description: An experimental code-point is used and will be
modified to the value allocated in this document.</t>
<t>Maturity Level: Production</t>
<t>Coverage: Full</t>
<t>Contact: mkoldych@cisco.com</t>
</list></t>
</section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<t>The security considerations described in <xref target="RFC5440"/>, <name>Security Considerations</name>
<xref target="RFC8231"/>, <xref target="RFC8281"/>, <xref <t>The security considerations described in <xref target="RFC5440" format=
target="RFC8664"/>, and <xref target="RFC9050"/> are applicable to this "default"/>,
<xref target="RFC8231" format="default"/>, <xref target="RFC8281" format="
default"/>, <xref target="RFC8664" format="default"/>, and <xref target="RFC9050
" format="default"/> are applicable to this
specification. No additional security measure is required.</t> specification. No additional security measure is required.</t>
<t>As described in <xref target="RFC8402" format="default"/> and <xref tar
<t>As described in <xref target="RFC8402"/> and <xref get="RFC8664" format="default"/>, SR intrinsically involves an entity (whether
target="RFC8664"/>, SR intrinsically involves an entity (whether
head-end or a central network controller) controlling and instantiating head-end or a central network controller) controlling and instantiating
paths in the network without the involvement of (other) nodes along paths in the network without the involvement of (other) nodes along
those paths. Binding SIDs are in effect shorthand aliases for longer those paths. Binding SIDs are in effect shorthand aliases for longer
path representations, and the alias expansion is in principle known only path representations, and the alias expansion is in principle known only
by the node that acts on it. In this document, the expansion of the by the node that acts on it. In this document, the expansion of the
alias is shared between PCC and PCE, and rogue actions by either PCC or alias is shared between PCC and PCE, and rogue actions by either PCC or
PCE could result in shifting or misdirecting traffic in ways that are PCE could result in shifting or misdirecting traffic in ways that are
hard for other nodes to detect. In particular, when a PCE propagates hard for other nodes to detect. In particular, when a PCE propagates
paths of the form {A, B, BSID} to other entities, the BSID values are paths of the form {A, B, BSID} to other entities, the BSID values are
opaque, and a rogue PCE can substitute a BSID from a different LSP in opaque, and a rogue PCE can substitute a BSID from a different LSP in
skipping to change at line 950 skipping to change at line 786
those paths. Binding SIDs are in effect shorthand aliases for longer those paths. Binding SIDs are in effect shorthand aliases for longer
path representations, and the alias expansion is in principle known only path representations, and the alias expansion is in principle known only
by the node that acts on it. In this document, the expansion of the by the node that acts on it. In this document, the expansion of the
alias is shared between PCC and PCE, and rogue actions by either PCC or alias is shared between PCC and PCE, and rogue actions by either PCC or
PCE could result in shifting or misdirecting traffic in ways that are PCE could result in shifting or misdirecting traffic in ways that are
hard for other nodes to detect. In particular, when a PCE propagates hard for other nodes to detect. In particular, when a PCE propagates
paths of the form {A, B, BSID} to other entities, the BSID values are paths of the form {A, B, BSID} to other entities, the BSID values are
opaque, and a rogue PCE can substitute a BSID from a different LSP in opaque, and a rogue PCE can substitute a BSID from a different LSP in
such paths to move traffic without the recipient of the path knowing the such paths to move traffic without the recipient of the path knowing the
ultimate destination.</t> ultimate destination.</t>
<!--<t>As described in <xref target="RFC8664"/>, SR allows a network <!--<t>As described in <xref target="RFC8664"/>, SR allows a network
controller to instantiate and control paths in the network. A rogue PCE controller to instantiate and control paths in the network. A rogue PCE
can manipulate binding SID allocations to move traffic around for some can manipulate binding SID allocations to move traffic around for some
other LSP that uses BSID in its SR-ERO. Note that path {A, B, BSID} can other LSP that uses BSID in its SR-ERO. Note that path {A, B, BSID} can
be misdirected just by assigning the BSID value to a different LSP be misdirected just by assigning the BSID value to a different LSP
making it a lot easier to misdirect traffic (and harder to detect).</t>--> making it a lot easier to misdirect traffic (and harder to detect).</t>-->
<t>The case of BT=3 provides additional opportunities for malfeasance, <t>The case of BT=3 provides additional opportunities for malfeasance,
as it purports to convey information about internal SRv6 SID structure. as it purports to convey information about internal SRv6 SID Structure.
There is no mechanism defined to validate this internal structure There is no mechanism defined to validate this internal structure
information, and mischaracterizing the division of bits into locator information, and mischaracterizing the division of bits into locator
block, locator node, function, and argument can result in different block, locator node, function, and argument can result in different
interpretation of the bits by PCC and PCE. Most notably, shifting bits interpretation of the bits by PCC and PCE. Most notably, shifting bits
into or out of the "argument" is a direct vector for affecting into or out of the "argument" is a direct vector for affecting
processing, but other attacks are also possible.</t> processing, but other attacks are also possible.</t>
<!--<t>Note that in case of BT as 3, the manipulation of SID structure cou ld <!--<t>Note that in case of BT as 3, the manipulation of SID structure cou ld
be exploited by falsifying the various length values.</t>--> be exploited by falsifying the various length values.</t>-->
<t>Thus, as per <xref target="RFC8231"/>, it is RECOMMENDED that these <t>Thus, as per <xref target="RFC8231" format="default"/>, it is
PCEP extensions only be activated on authenticated and encrypted <bcp14>RECOMMENDED</bcp14> that these PCEP extensions only be activated
sessions across PCEs and PCCs belonging to the same administrative on authenticated and encrypted sessions across PCEs and PCCs belonging
authority, using Transport Layer Security (TLS) <xref to the same administrative authority, using Transport Layer Security
target="RFC8253"/>, as per the recommendations and best current (TLS) <xref target="RFC8253" format="default"/>, as per the
practices in BCP195 <xref target="RFC7525"/> (unless explicitly set recommendations and best current practices in BCP 195 <xref
aside in <xref target="RFC8253"/>).</t> target="RFC9325" format="default"/> (unless explicitly set aside in
<xref target="RFC8253" format="default"/>).</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Manageability Considerations" toc="default"> <name>Manageability Considerations</name>
<t>All manageability requirements and considerations listed in <xref <t>All manageability requirements and considerations listed in <xref forma
format="default" pageno="false" target="RFC5440"/>, <xref t="default" target="RFC5440"/>, <xref format="default" target="RFC8231"/>, and <
format="default" pageno="false" target="RFC8231"/>, and <xref xref target="RFC8664" format="default"/> apply to PCEP protocol extensions defin
target="RFC8664"/> apply to PCEP protocol extensions defined in this ed in this
document. In addition, requirements and considerations listed in this document. In addition, requirements and considerations listed in this
section apply.</t> section apply.</t>
<section toc="default" numbered="true">
<section title="Control of Function and Policy" toc="default"> <name>Control of Function and Policy</name>
<t>A PCC implementation SHOULD allow the operator to configure the <t>A PCC implementation <bcp14>SHOULD</bcp14> allow the operator to conf
igure the
policy the PCC needs to apply when allocating the binding policy the PCC needs to apply when allocating the binding
label/SID.</t> label/SID.</t>
<t>If BT is set to 2, the operator needs to have local policy set to <t>If BT is set to 2, the operator needs to have local policy set to
decide the SID structure and the SRv6 Endpoint Behavior of the decide the SID structure and the SRv6 Endpoint Behavior of the
BSID.</t> BSID.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Information and Data Models" toc="default"> <name>Information and Data Models</name>
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> will <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="de
fault"/> will
be extended to include policy configuration for binding label/SID be extended to include policy configuration for binding label/SID
allocation.</t> allocation.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Liveness Detection and Monitoring" toc="default"> <name>Liveness Detection and Monitoring</name>
<t>The mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
liveness detection and monitoring requirements in addition to those liveness detection and monitoring requirements in addition to those
already listed in <xref format="default" pageno="false" already listed in <xref format="default" target="RFC5440"/>.</t>
target="RFC5440"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Verify Correct Operations" toc="default"> <name>Verify Correct Operations</name>
<t>The mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
operation verification requirements in addition to those already operation verification requirements in addition to those already
listed in <xref format="default" pageno="false" target="RFC5440"/>, listed in <xref format="default" target="RFC5440"/>,
<xref format="default" pageno="false" target="RFC8231"/>, and <xref <xref format="default" target="RFC8231"/>, and <xref target="RFC8664" fo
target="RFC8664"/>.</t> rmat="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Requirements On Other Protocols" toc="default"> <name>Requirements on Other Protocols</name>
<t>The mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Impact On Network Operations" toc="default"> <name>Impact on Network Operations</name>
<t>The mechanisms defined in <xref format="default" pageno="false" <t>The mechanisms defined in <xref format="default" target="RFC5440"/>,
target="RFC5440"/>, <xref format="default" pageno="false" <xref format="default" target="RFC8231"/>, and <xref target="RFC8664" format="de
target="RFC8231"/>, and <xref target="RFC8664"/> also apply to the fault"/> also apply to the
PCEP extensions defined in this document.</t> PCEP extensions defined in this document.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has allocated code points for the protocol elements described in t
his document in the "Path Computation Element Protocol (PCEP) Numbers" registry
group.</t>
<section anchor="TLV" numbered="true" toc="default">
<name>PCEP TLV Type Indicators</name>
<t>This document defines a new PCEP TLV. IANA has allocated the followin
g in the "PCEP TLV Type Indicators" registry within the PCEP Numbers registry g
roup:</t>
<table anchor="TLV-Type" align="center">
<thead>
<tr>
<th align="center">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">55</td>
<td align="left">TE-PATH-BINDING</td>
<td align="left">RFC 9604</td>
</tr>
</tbody>
</table>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA-TLV" numbered="true" toc="default">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" <name>TE-PATH-BINDING TLV</name>
registry. This document requests IANA actions to allocate code points <t>IANA has created the "TE-PATH-BINDING TLV BT Field" registry
for the protocol elements defined in this document.</t> to manage the values of the binding type field in the
TE-PATH-BINDING TLV. Initial values are shown
<section anchor="TLV" title="PCEP TLV Type Indicators"> below. New values are assigned by Standards Action <xref target="RFC81
<t>This document defines a new PCEP TLV; IANA is requested to confirm 26" format="default"/>.</t>
the following early allocations from the "PCEP TLV Type Indicators" <table anchor="BT" align="center">
subregistry of the PCEP Numbers registry, as follows:</t> <thead>
<tr>
<texttable anchor="TLV-Type" style="none" suppress-title="true"> <th align="center">Value</th>
<ttcol align="center" width="15%">Value</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol align="left" width="30%">Description</ttcol> </tr>
</thead>
<ttcol align="left" width="55%">Reference</ttcol> <tbody>
<tr>
<c/> <td align="center">0</td>
<td align="left">MPLS Label</td>
<c>&nbsp;</c> <td align="left">RFC 9604</td>
</tr>
<c/> <tr>
<td align="center">1</td>
<c>55</c> <td align="left">MPLS Label Stack Entry</td>
<td align="left">RFC 9604</td>
<c>TE-PATH-BINDING</c> </tr>
<tr>
<c>This document</c> <td align="center">2</td>
</texttable> <td align="left">SRv6 SID</td>
<td align="left">RFC 9604</td>
<section anchor="IANA-TLV" title="TE-PATH-BINDING TLV "> </tr>
<t>IANA is requested to create a new subregistry "TE-PATH-BINDING <tr>
TLV BT field" to manage the value of the Binding Type field in the <td align="center">3</td>
TE-PATH-BINDING TLV. Initial values for the subregistry are given <td align="left">SRv6 SID with Behavior and Structure</td>
below. New values are assigned by Standards Action <xref <td align="left">RFC 9604</td>
target="RFC8126"/>.</t> </tr>
<tr>
<texttable anchor="BT" style="none" suppress-title="true"> <td align="center">4-255</td>
<ttcol align="center" width="15%">Value</ttcol> <td align="left">Unassigned</td>
<td align="left"></td>
<ttcol align="left" width="30%">Description</ttcol> </tr>
</tbody>
<ttcol align="left" width="55%">Reference</ttcol> </table>
<t>IANA has created a new "TE-PATH-BINDING
<c/> TLV Flag Field" registry to manage the Flag field in the TE-PATH-BINDI
NG TLV.
<c>&nbsp;</c>
<c/>
<c>0</c>
<c>MPLS Label</c>
<c>This document</c>
<c>1</c>
<c>MPLS Label Stack Entry</c>
<c>This document</c>
<c>2</c>
<c>SRv6 SID</c>
<c>This document</c>
<c>3</c>
<c>SRv6 SID with Behavior and Structure</c>
<c>This document</c>
<c>4-255</c>
<c>Unassigned</c>
<c>This document</c>
</texttable>
<t>IANA is requested to create a new subregistry "TE-PATH-BINDING
TLV Flag field" to manage the Flag field in the TE-PATH-BINDING TLV.
New values are to be assigned by Standards Action <xref New values are to be assigned by Standards Action <xref
target="RFC8126"/>. Each bit should be tracked with the following target="RFC8126" format="default"/>. Each bit should be tracked with
qualities:</t> the following qualities:</t>
<ul spacing="compact">
<t><list style="symbols"> <li>Bit number (count from 0 as the most significant bit)</li>
<t>Bit number (count from 0 as the most significant bit)</t> <li>Description</li>
<li>Reference</li>
<t>Description</t> </ul>
<table anchor="BF" align="center">
<t>Reference</t> <thead>
</list></t> <tr>
<th align="center">Bit</th>
<texttable anchor="BF" style="none" suppress-title="true"> <th align="left">Description</th>
<ttcol align="center" width="15%">Bit</ttcol> <th align="left">Reference</th>
</tr>
<ttcol align="left" width="30%">Description</ttcol> </thead>
<tbody>
<ttcol align="left" width="55%">Reference</ttcol> <tr>
<td align="center">0</td>
<c/> <td align="left">R (Removal)</td>
<td align="left">RFC 9604</td>
<c>&nbsp;</c> </tr>
<tr>
<c/> <td align="center">1-7</td>
<td align="left">Unassigned</td>
<!--<c>7</c> <td align="left"></td>
</tr>
<c>Specified-BSID-Only Flag (S-Flag)</c> </tbody>
</table>
<c>This document</c>
<c>6</c>
<c>Drop Upon Invalid Flag (I-Flag)</c>
<c>This document</c>-->
<c>0</c>
<c>R (Removal)</c>
<c>This document</c>
<c>1-7</c>
<c>Unassigned</c>
<c>This document</c>
</texttable>
</section> </section>
</section> </section>
<section anchor="LSP" numbered="true" toc="default">
<section anchor="LSP" title="LSP Object"> <name>LSP Object</name>
<t>IANA is requested to confirm the early allocation for a new <t>IANA has allocated a
code-point in the "LSP Object Flag Field" sub-registry for the new P code point in the "LSP Object Flag Field" registry for the new P
flag as follows:</t> flag as follows:</t>
<table anchor="LSP-Flag" align="center">
<texttable anchor="LSP-Flag" style="none" suppress-title="true"> <thead>
<ttcol align="center" width="15%">Bit</ttcol> <tr>
<th align="center">Bit</th>
<ttcol align="left" width="30%">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol align="left" width="55%">Reference</ttcol> </tr>
</thead>
<c/> <tbody>
<tr>
<c>&nbsp;</c> <td align="center">0</td>
<td align="left">PCE-allocation</td>
<c/> <td align="left">RFC 9604</td>
</tr>
<c>0</c> </tbody>
</table>
<c>PCE-allocation</c>
<c>This document</c>
</texttable>
</section> </section>
<section anchor="Error-Type" numbered="true" toc="default">
<name>PCEP Error Type and Value</name>
<t>This document defines a new Error-Type and associated Error-values
for the PCErr message. IANA has allocated a new Error-Type
and Error-values within the "PCEP-ERROR Object Error Types and Values"
registry of the PCEP Numbers registry group, as follows:</t>
<table anchor="Error">
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="6">32</td>
<td rowspan="6">Binding label/SID failure</td>
<td>0: Unassigned</td>
</tr>
<tr><td>1: Invalid SID</td></tr>
<tr><td>2: Unable to allocate the specified binding value</td></tr
>
<tr><td>3: Unable to allocate a new binding label/SID</td></tr>
<tr><td>4: Unable to remove the binding value</td></tr>
<tr><td>5: Inconsistent binding types</td></tr>
<section anchor="Error-Type" title="PCEP Error Type and Value"> </tbody>
<t>This document defines a new Error-type and associated Error-Values </table>
for the PCErr message. IANA is requested to allocate new error-type
and error-values within the "PCEP-ERROR Object Error Types and Values"
subregistry of the PCEP Numbers registry, as follows:</t>
<texttable anchor="Error" style="none" suppress-title="true">
<ttcol align="center" width="10%">Error-Type</ttcol>
<ttcol align="left" width="30%">Meaning</ttcol>
<ttcol align="left" width="50%">Error-value</ttcol>
<ttcol align="left" width="10%">Reference</ttcol>
<c/>
<c>&nbsp;</c>
<c/>
<c/>
<c>TBD2</c>
<c>Binding label/SID failure</c>
<c>&nbsp;0: Unassigned</c>
<c>This document</c>
<c>&nbsp;</c>
<c>&nbsp;</c>
<c>TBD3: Invalid SID</c>
<c>This document</c>
<c>&nbsp;</c>
<c>&nbsp;</c>
<c>TBD4: Unable to allocate the specified binding value</c>
<c>This document</c>
<c>&nbsp;</c>
<c>&nbsp;</c>
<c>TBD5: Unable to allocate a new binding label/SID</c>
<c>This document</c>
<c>&nbsp;</c>
<c>&nbsp;</c>
<c>TBD6: Unable to remove the binding value</c>
<c>This document</c>
<c>&nbsp;</c>
<c>&nbsp;</c>
<c>TBD7: Inconsistent binding types</c>
<c>This document</c>
</texttable>
</section> </section>
</section> </section>
<section anchor="Acknowledgement" title="Acknowledgements">
<t>We would like to thank Milos Fabian, Mrinmoy Das, Andrew Stone, Tom
Petch, Aijun Wang, Olivier Dugeon, and Adrian Farrel for their valuable
comments.</t>
<t>Thanks to Julien Meuric for shepherding. Thanks to John Scudder for
the AD review.</t>
<t>Thanks to Theresa Enghardt for the GENART review.</t>
<t>Thanks to Martin Vigoureux, Benjamin Kaduk, Eric Vyncke, Lars Eggert,
Murray Kucherawy, and Erik Kline for the IESG reviews.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.303 <displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
2.xml"?> <displayreference target="I-D.ietf-pce-controlled-id-space" to="PCE-ID-SPACE
"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.544 <displayreference target="I-D.ietf-pce-sr-path-segment" to="PCEP-SR"/>
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.546
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.752
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.794
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.823
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.825
3.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828
1.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.840
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.866
4.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.812
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.898
6.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.905
0.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie
tf-pce-segment-routing-ipv6"?>
</references>
<references title="Informative References">
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4206.xml"?>-->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.465
5.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.828
3.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.875 <references>
4.xml"?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
462.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
050.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
603.xml"/>
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC </references>
.8669.xml"?>--> <references>
<name>Informative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
tf-spring-segment-routing-policy"?> 655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
283.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I- D.ietf-idr-segment-routing-te-policy"?>--> <!-- [I-D.ietf-pce-pcep-yang] IESG state Publication Requested as of 06/10/24 -- >
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I- D.ietf-isis-segment-routing-extensions"?>--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i etf-pce-pcep-yang.xml"/>
<!--<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I- <!-- rfced] FYI - I-D.li-pce-controlled-id-space was replaced by
D.ietf-pce-pcep-extension-for-pce-controller"?>--> I-D.ietf-pce-controlled-id-space, so we have update to the replaced draft
string. Please let us know if there is any objection.
-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
etf-pce-controlled-id-space.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie tf-pce-pcep-yang"?> <!-- [I-D.ietf-pce-sr-path-segment] IESG state I-D Exists as of 06/10/24 -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.li -pce-controlled-id-space"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-pce-sr-path-segment.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie tf-pce-sr-path-segment"?> </references>
</references> </references>
<!--<section anchor="sec_pcecc" title="PCE based Central Controller"> <!--<section anchor="sec_pcecc" title="PCE based Central Controller">
<t><xref target="RFC8283"/> introduces the architecture for PCE as a central c ontroller <t><xref target="RFC8283"/> introduces the architecture for PCE as a central c ontroller
as an extension of the architecture described in <xref target="RFC4655"/> and as an extension of the architecture described in <xref target="RFC4655"/> and
assumes the continued use of PCEP as the protocol used between PCE assumes the continued use of PCEP as the protocol used between PCE
and PCC. <xref target="RFC8283"/> further examines the motivations and and PCC. <xref target="RFC8283"/> further examines the motivations and
applicability for PCEP as a Southbound Interface (SBI), and applicability for PCEP as a Southbound Interface (SBI), and
introduces the implications for the protocol.</t> introduces the implications for the protocol.</t>
<t>As per <xref target="RFC8283"/>, PCE as a central controller can allocate and <t>As per <xref target="RFC8283"/>, PCE as a central controller can allocate and
provision the node/prefix/adjacency label (SID) via PCEP. It can also be used to allocate the binding SID as described in this section.</t> provision the node/prefix/adjacency label (SID) via PCEP. It can also be used to allocate the binding SID as described in this section.</t>
skipping to change at line 1365 skipping to change at line 1084
<t>A P flag in LSP object is introduced in <xref target="I-D.li-pce-sr-path-s egment"/> to indicate the allocation needs to be made by the PCE. The same flag is also set for the binding SID allocation request. A PCC would set this bit to 1 to request for <t>A P flag in LSP object is introduced in <xref target="I-D.li-pce-sr-path-s egment"/> to indicate the allocation needs to be made by the PCE. The same flag is also set for the binding SID allocation request. A PCC would set this bit to 1 to request for
allocation of the binding label/SID by the PCE in the PCReq or PCRpt allocation of the binding label/SID by the PCE in the PCReq or PCRpt
message. A PCE would also set this bit to 1 to indicate that the message. A PCE would also set this bit to 1 to indicate that the
binding label/SID is allocated by PCE and encoded in the PCRep, binding label/SID is allocated by PCE and encoded in the PCRep,
PCUpd or PCInitiate message (the TE-PATH-BINDING TLV is present in PCUpd or PCInitiate message (the TE-PATH-BINDING TLV is present in
LSP object). Further, a PCE would set this bit to 0 to indicate LSP object). Further, a PCE would set this bit to 0 to indicate
that the path identifier is allocated by the PCC as described above.</t> that the path identifier is allocated by the PCC as described above.</t>
<t>The ingress PCC could request the binding label/SID to be allocated by the PCE <t>The ingress PCC could request the binding label/SID to be allocated by the PCE
via PCRpt message as per <xref target="RFC8231"/>. The delegate flag (D-flag via PCRpt message as per <xref target="RFC8231"/>. The delegate flag (D-flag
) MUST ) <bcp14>MUST</bcp14>
also be set for this LSP. The TE-PATH-BINDING TLV MAY be included with no Bi also be set for this LSP. The TE-PATH-BINDING TLV <bcp14>MAY</bcp14> be incl
nding uded with no binding
Value. The PCECC would allocated the binding label/SID and further respond to value. The PCECC would allocated the binding label/SID and further respond to
Ingress PCC with PCUpd message as per <xref target="RFC8231"/> and MUST inclu Ingress PCC with PCUpd message as per <xref target="RFC8231"/> and <bcp14>MUS
de the T</bcp14> include the
TE-PATH-BINDING TLV in a LSP object. The P flag in the LSP object would be s et to 1 to indicate that the allocation is made by the PCE.</t> TE-PATH-BINDING TLV in a LSP object. The P flag in the LSP object would be s et to 1 to indicate that the allocation is made by the PCE.</t>
<t>The PCE could allocate the binding label/SID on its own accord for a PCE- <t>The PCE could allocate the binding label/SID on its own accord for a PCE-
Initiated (or delegated LSP). The allocated binding label/SID needs to be Initiated (or delegated LSP). The allocated binding label/SID needs to be
informed to the PCC. The PCE would use the informed to the PCC. The PCE would use the
PCInitiate message <xref target="RFC8281"/> or PCUpd message <xref target="RF C8231"/> towards the PCInitiate message <xref target="RFC8281"/> or PCUpd message <xref target="RF C8231"/> towards the
PCC and MUST include the TE-PATH-BINDING TLV in the LSP object. The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t> PCC and <bcp14>MUST</bcp14> include the TE-PATH-BINDING TLV in the LSP object . The P flag in the LSP object would be set to 1 to indicate that the allocation is made by the PCE.</t>
</section> --> </section> -->
<section title="Contributor Addresses" toc="default"> <section anchor="Acknowledgement" numbered="false" toc="default">
<t><figure align="left" alt="" height="" suppress-title="false" title="" <name>Acknowledgements</name>
width=""> <t>We would like to thank <contact fullname="Milos Fabian"/>, <contact
<artwork align="left" alt="" height="" name="" type="" width="" fullname="Mrinmoy Das"/>, <contact fullname="Andrew Stone"/>, <contact
xml:space="preserve"><![CDATA[ fullname="Tom Petch"/>, <contact fullname="Aijun Wang"/>, <contact
Jonathan Hardwick fullname="Olivier Dugeon"/>, and <contact fullname="Adrian Farrel"/> for
Microsoft their valuable comments.</t>
United Kingdom <t>Thanks to <contact fullname="Julien Meuric"/> for shepherding. Thanks
to <contact fullname="John Scudder"/> for the AD review.</t>
EMail: jonhardwick@microsoft.com <t>Thanks to <contact fullname="Theresa Enghardt"/> for the GENART review.
</t>
Dhruv Dhody <t>Thanks to <contact fullname="Martin Vigoureux"/>, <contact
Huawei Technologies fullname="Benjamin Kaduk"/>, <contact fullname="Eric Vyncke"/>, <contact
Divyashree Techno Park, Whitefield fullname="Lars Eggert"/>, <contact fullname="Murray Kucherawy"/>, and
Bangalore, Karnataka 560066 <contact fullname="Erik Kline"/> for the IESG reviews.</t>
India </section>
EMail: dhruv.ietf@gmail.com <section toc="default" numbered="false">
<name>Contributors</name>
Mahendra Singh Negi <contact fullname="Jonathan Hardwick">
RtBrick India <organization>Microsoft</organization>
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 <address>
Bangalore, Karnataka 560102 <postal>
India <country>United Kingdom</country>
</postal>
<email>jonhardwick@microsoft.com</email>
</address>
</contact>
EMail: mahend.ietf@gmail.com <contact fullname="Dhruv Dhody">
<organization>Huawei Technologies </organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city><region>Karnataka</region>
<country>India</country>
<code>560066</code>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
Mike Koldychev <contact fullname="Mahendra Singh Negi">
Cisco Systems, Inc. <organization>RtBrick India</organization>
2000 Innovation Drive <address>
Kanata, Ontario K2K 3E8 <postal>
Canada <street>N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3</street>
<city>Bangalore</city><region>Karnataka</region>
<country>India</country>
<code>560102</code>
</postal>
<email>mahend.ietf@gmail.com</email>
</address>
</contact>
Email: mkoldych@cisco.com <contact fullname="Mike Koldychev">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2000 Innovation Drive</street>
<city>Kanata</city><region>Ontario</region><code>K2K 3E8</code>
<country>Canada</country>
</postal>
<email>mkoldych@cisco.com</email>
</address>
</contact>
Zafar Ali <contact fullname="Zafar Ali">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
Email: zali@cisco.com
]]></artwork>
</figure></t>
</section> </section>
</back> </back>
<!-- [rfced] We had some questions about capitalization of terms:
Throughout the text, the following term may be used inconsistently. It seems as
though the intent is to use the lowercase form generally and initial capitalizat
ion when referring to the registered values or field names. Please review the f
ollowing for consistency and let us know if any updates are needed.
MPLS Label vs MPLS label
MPLS Label Stack Entry vs MPLS label stack entry
Endpoint Behavior vs endpoint behavior
Length vs length
Binding Value vs binding value
-->
<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically res
ult in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 181 change blocks. 
996 lines changed or deleted 874 lines changed or added

This html diff was produced by rfcdiff 1.48.