rfc9933xml2.original.xml   rfc9933.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="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<?rfc compact="yes"?> docName="draft-ietf-pce-sid-algo-29" number="9933" ipr="trust200902" updates="86
<?rfc subcompact="no"?> 64, 9603" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" toc
<rfc category="std" docName="draft-ietf-pce-sid-algo-29" ipr="trust200902" updat Depth="3" symRefs="true" sortRefs="true" version="3">
es="8664 9603">
<front> <front>
<title abbrev="SR-Algorithm in PCEP"> <title abbrev="SR-Algorithm in PCEP">
Carrying SR-Algorithm in Path Computation Element Communication Protocol (PC EP) Carrying SR-Algorithm in Path Computation Element Communication Protocol (PC EP)
</title> </title>
<seriesInfo name="RFC" value="9933"/>
<author fullname="Samuel Sidor" initials="S." surname="Sidor"> <author fullname="Samuel Sidor" initials="S." surname="Sidor">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Eurovea Central 3.</street> <street>Eurovea Central 3.</street>
<street>Pribinova 10</street> <street>Pribinova 10</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>811 09</code> <code>811 09</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
skipping to change at line 32 skipping to change at line 30
<postal> <postal>
<street>Eurovea Central 3.</street> <street>Eurovea Central 3.</street>
<street>Pribinova 10</street> <street>Pribinova 10</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>811 09</code> <code>811 09</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ssidor@cisco.com</email> <email>ssidor@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Zoey Rose" initials="Z." surname="Rose"> <author fullname="Zoey Rose" initials="Z." surname="Rose">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2300 East President George</street> <street>2300 East President George</street>
<city>Richardson</city> <city>Richardson</city>
<code>TX 75082</code> <region>TX</region>
<code>75082</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>atokar@cisco.com</email> <email>atokar@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Shaofu Peng" initials="S." surname="Peng"> <author fullname="Shaofu Peng" initials="S." surname="Peng">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street>No.50 Software Avenue</street> <street>No.50 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
skipping to change at line 59 skipping to change at line 56
<postal> <postal>
<street>No.50 Software Avenue</street> <street>No.50 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>peng.shaofu@zte.com.cn</email> <email>peng.shaofu@zte.com.cn</email>
</address> </address>
</author> </author>
<author fullname="Shuping Peng" initials="S." surname="Peng"> <author fullname="Shuping Peng" initials="S." surname="Peng">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <code>100095</code>
<code>100095</code> <country>China</country>
<country>China</country>
</postal> </postal>
<phone/> <email>pengshuping@huawei.com</email>
<facsimile/>
<email>pengshuping@huawei.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Andrew Stone" initials="A." surname="Stone"> <author fullname="Andrew Stone" initials="A." surname="Stone">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>andrew.stone@nokia.com</email> <email>andrew.stone@nokia.com</email>
</address> </address>
</author> </author>
<date month="February" year="2026"/>
<area>RTG</area>
<workgroup>pce</workgroup>
<date/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<workgroup>PCE Working Group</workgroup> <keyword>example</keyword>
<abstract> <abstract>
<t>This document specifies extensions to the Path Computation Element Comm
<t>This document specifies extensions to the Path Computation Element Comm unication Protocol (PCEP) to enhance support for Segment Routing (SR) with a foc
unication Protocol (PCEP) to enhance support for Segment Routing (SR) with a foc us on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Enginee
us on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Enginee ring (TE). The SR-Algorithm associated with a SID defines the path computation a
ring (TE). The SR-Algorithm associated with a SID defines the path computation a lgorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for
lgorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal the SR-Algorithm associated with SIDs by encoding this inf
PCEP peers to signal SR-Algorithm associated with SIDs by encoding this informa ormation in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects
tion in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, en , enables SR-Algorithm constraints for path computation, and defines new metric
ables SR-Algorithm constraints for path computation, and defines new metric type types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allo
s for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow su w such extensions.</t>
ch extensions.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t><xref target="RFC5440"/> describes the Path Computation Element Communi <t><xref target="RFC5440" format="default"/> describes the Path Computatio
cation Protocol (PCEP) for communication between a Path Computation Client (PCC) n Element Communication Protocol (PCEP) for communication between a Path Computa
and a Path Computation Element (PCE) or between a pair of PCEs. <xref target="R tion Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs
FC8664"/> and <xref target="RFC9603"/> specify PCEP extensions to support Segmen . <xref target="RFC8664" format="default"/> and <xref target="RFC9603" format="d
t Routing (SR) over MPLS and IPv6 dataplanes respectively.</t> efault"/> specify PCEP extensions to support Segment Routing (SR) over MPLS and
IPv6 data planes, respectively.</t>
<t>This document specifies extensions to PCEP to enhance support for SR T raffic Engineering (TE). Specifically, it focuses on the use of Segment Identifi ers (SIDs) and SR-Algorithms. An SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs).</t> <t>This document specifies extensions to PCEP to enhance support for SR T raffic Engineering (TE). Specifically, it focuses on the use of Segment Identifi ers (SIDs) and SR-Algorithms. An SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs).</t>
<t>The PCEP extensions specified in this document are as follows: <t>The PCEP extensions specified in this document are as follows:
<list style="hanging"> </t>
<t hangText="Signaling SR-Algorithm in ERO and RRO:"> Mechanisms a <dl newline="false" spacing="normal">
re introduced for PCEP peers <dt>Signaling SR-Algorithm in ERO and RRO:</dt>
<dd> Mechanisms are introduced for PCEP peers
to exchange information about the SR-Algorithm associate d with each SID. This includes to exchange information about the SR-Algorithm associate d with each SID. This includes
extending SR-ERO, SR-RRO and SRv6-ERO, SRv6-RRO subobjec extending SR-ERO, SR-RRO, SRv6-ERO, and SRv6-RRO subobje
ts to carry an Algorithm field. cts to carry an Algorithm field.
This document updates <xref target="RFC8664"/> and <xref This document updates <xref target="RFC8664" format="def
target="RFC9603"/> to enable ault"/> and <xref target="RFC9603" format="default"/> to enable
such encoding.</t> such encoding.</dd>
<t hangText="SR-Algorithm Constraint for Path Computation:"> Mecha <dt>SR-Algorithm Constraint for Path Computation:</dt>
nisms are defined for signaling <dd> Mechanisms are defined for signaling
a specific SR-Algorithm as a constraint to the PCE for p ath computation. This includes a specific SR-Algorithm as a constraint to the PCE for p ath computation. This includes
a new SR-Algorithm TLV carried in the Label Switched Pat a new SR-Algorithm TLV carried in the Label Switched Pat
h Attributes (LSPA) Object.</t> h Attributes (LSPA) Object.</dd>
<t hangText="Extensions to METRIC Object:">Several new metric type <dt>Extensions to METRIC Object:</dt>
s are introduced for the METRIC <dd>Several new metric types are introduced for the METRIC
Object to support optimization metrics derived from FADs Object to support optimization metrics derived from Flex
during Flexible Algorithm path ible Algorithm Definitions (FADs) during Flexible Algorithm path
computation, their application is not restricted to Flex computation; their application is not restricted to Flex
ible Algorithms and they may be ible Algorithms, and they may be
used with LSPs setup using different Path Setup Types.</ used with Label Switched Paths (LSPs) set up using diffe
t> rent Path Setup Types.</dd>
</list> </dl>
</t> <section anchor="Language" numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="Language" title="Requirements Language"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> 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>
<section numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology"> <!--[rfced] FYI - We removed the first paragraph in Section 2 as it
<t>This document uses the following terms defined in <xref target="RFC5440" repeats the same information in the second paragraph. Please let us
/>: ERO, LSPA, PCC, know of any objections.
PCE, PCEP, PCEP Peer, PCEP speaker, RRO, TED.</t>
<t>This document uses the following terms defined in <xref target="RFC5440"
/>: Explicit Route Object (ERO), Label Switched Path Attributes (LSPA), Path Com
putation Client (PCC), Path Computation Element (PCE), Path Computation Element
Communication Protocol (PCEP), PCEP Peer, PCEP speaker, Record Route Object (RRO
), and Traffic Engineering Database (TED).</t>
<t>This document uses the following term defined in <xref target="RFC3031"/
>: Label Switched Path (LSP).</t>
<t>This document uses the following term defined in <xref target="RFC9479"/
> and <xref target="RFC9492"/>: Application-Specific Link Attributes (ASLA).</t>
<t>This document uses the following terms defined in <xref target="RFC8664" Original:
/>: Node or Adjacency Identifier (NAI) and Segment Routing Database (SR-DB).</t> This document uses the following terms defined in [RFC5440]: ERO,
LSPA, PCC, PCE, PCEP, PCEP Peer, PCEP speaker, RRO, TED.
<t>This document uses the following terms defined in <xref target="RFC9350" This document uses the following terms defined in [RFC5440]: Explicit
/>: Flexible Algorithm Definition (FAD) and Winning FAD.</t> Route Object (ERO), Label Switched Path Attributes (LSPA), Path
Computation Client (PCC), Path Computation Element (PCE), Path
Computation Element Communication Protocol (PCEP), PCEP Peer, PCEP
speaker, Record Route Object (RRO), and Traffic Engineering Database
(TED).
-->
<t> Note that the base PCEP specification <xref target="RFC4655"/> origina <t>This document uses the following terms defined in <xref target="RFC5440
lly defined the use of the PCE architecture for MPLS and GMPLS networks " format="default"/>: Explicit Route Object (ERO), Label Switched Path Attribute
with LSPs instantiated using the RSVP-TE signaling protocol. Over time, sup s (LSPA), Path Computation Client (PCC), Path Computation Element (PCE), Path Co
port for additional path setup types, such as mputation Element Communication Protocol (PCEP), PCEP peer, PCEP speaker, Record
SRv6, has been introduced <xref target="RFC9603"/>. The term "LSP" is used Route Object (RRO), and Traffic Engineering Database (TED).</t>
extensively in PCEP specifications and, in the <t>This document uses the following term defined in <xref target="RFC3031"
format="default"/>: Label Switched Path (LSP).</t>
<t>This document uses the following term defined in <xref target="RFC9479"
format="default"/> and <xref target="RFC9492" format="default"/>: Application-S
pecific Link Attributes (ASLA).</t>
<t>This document uses the following terms defined in <xref target="RFC8664
" format="default"/>: Node or Adjacency Identifier (NAI) and Segment Routing Dat
abase (SR-DB).</t>
<t>This document uses the following terms defined in <xref target="RFC9350
" format="default"/>: Flexible Algorithm Definition (FAD) and winning FAD.</t>
<t> Note that the base PCEP specification <xref target="RFC4655" format="d
efault"/> originally defined the use of the PCE architecture for MPLS and GMPLS
networks
with LSPs instantiated using the RSVP-TE signaling protocol. Over time, sup
port for additional Path Setup Types, such as
SRv6, has been introduced <xref target="RFC9603" format="default"/>. The te
rm "LSP" is used extensively in PCEP specifications and, in the
context of this document, refers to a Candidate Path within an SR Policy, w hich may be an SRv6 path (still represented context of this document, refers to a Candidate Path within an SR Policy, w hich may be an SRv6 path (still represented
using the LSP Object as specified in <xref target="RFC8231"/>).</t> using the LSP Object as specified in <xref target="RFC8231" format="default
"/>).</t>
<t>The term extension block is used in this document to identify the additi <t>The term "extension block" is used in this document to identify the add
onal bytes appended to a PCEP Object, which may exist depending on the inclusion itional bytes appended to a PCEP Object, which may exist depending on the inclus
of a flag in that object</t> ion of a flag in that object</t>
<t>The following terminologies are used in this document:
<t>The following terminologies are used in this document:
<list style="hanging">
<t hangText="P2MP:"> Point-to-Multipoint</t>
<t hangText="Subobject Extension Block:"> Optional, variable-length ex
tension block for SR-ERO and SR-RRO subobjects defined in <xref target="Subobjec
t-Extension-Block"/> of this document.</t>
<t hangText="Subobject Extension Block Flag (SEBF):"> Any flag in Flag
s field of SR-ERO or SR-RRO subobjects that is used to signal that the correspon
ding field is encoded in the Subobject Extension Block.</t>
</list>
</t> </t>
<dl newline="false" spacing="normal">
<dt>P2MP:</dt>
<dd> Point-to-Multipoint</dd>
<dt>Subobject Extension Block:</dt>
<dd> Optional, variable-length extension block for SR-ERO and SR-RRO sub
objects defined in <xref target="Subobject-Extension-Block" format="default"/> o
f this document.</dd>
<dt>Subobject Extension Block Flag (SEBF):</dt>
<dd> Any flag in the Flags field of SR-ERO or SR-RRO subobjects that is
used to signal that the corresponding field is encoded in the Subobject Extensio
n Block.</dd>
</dl>
</section> </section>
<section anchor="Motivation" numbered="true" toc="default">
<section anchor="Motivation" title="Motivation"> <name>Motivation</name>
<t>Existing PCEP specifications lack mechanisms to explicitly signal and n
<t>Existing PCEP specifications lack mechanisms to explicitly signal and n egotiate SR-Algorithm capabilities and constraints. This limits the ability of P
egotiate SR-Algorithm capabilities and constraints. This limits the ability of P CEs to make informed path computation decisions based on the specific SR-Algorit
CEs to make informed path computation decisions based on the specific SR-Algorit hms supported and desired within the network. The absence of an explicit SR-Algo
hms supported and desired within the network. The absence of an explicit SR-Algo rithm specification in PCEP messages implied no specific constraint on the SR-Al
rithm specification in PCEP messages implied no specific constraint on the SR-Al gorithm to be used for path computation, effectively allowing the use of SIDs wi
gorithm to be used for path computation, effectively allowing the use of SIDs wi th any SR-Algorithm.</t>
th any SR-algorithm.</t>
<t>A primary motivation for these extensions is to enable the PCE to lever age the path computation logic and topological information derived from Interior Gateway Protocols (IGPs), including Flexible Algorithms. Aligning PCE path comp utation with these IGP algorithms enables network operators to obtain paths that are congruent with the underlying routing behavior, which can result in segment lists with a reduced number of SIDs. The support for SR-Algorithm constraints i n PCE path computation simplifies the deployment and management of Flexible Algo rithm paths in multi-domain network scenarios.</t> <t>A primary motivation for these extensions is to enable the PCE to lever age the path computation logic and topological information derived from Interior Gateway Protocols (IGPs), including Flexible Algorithms. Aligning PCE path comp utation with these IGP algorithms enables network operators to obtain paths that are congruent with the underlying routing behavior, which can result in segment lists with a reduced number of SIDs. The support for SR-Algorithm constraints i n PCE path computation simplifies the deployment and management of Flexible Algo rithm paths in multi-domain network scenarios.</t>
<t>The PCE and the PCC may independently compute SR-TE paths with differen t SR-Algorithms. This information needs to be exchanged between PCEP peers for p urposes such as network monitoring and troubleshooting. In scenarios involving m ultiple PCEs, when a PCC receives a path from the primary PCE, it needs to be ab le to report the complete path information, including the SR-Algorithm, to a bac kup PCE. This is essential for high availability (HA) scenarios, ensuring that t he backup PCE can correctly verify Prefix SIDs.</t> <t>The PCE and the PCC may independently compute SR-TE paths with differen t SR-Algorithms. This information needs to be exchanged between PCEP peers for p urposes such as network monitoring and troubleshooting. In scenarios involving m ultiple PCEs, when a PCC receives a path from the primary PCE, it needs to be ab le to report the complete path information, including the SR-Algorithm, to a bac kup PCE. This is essential for high availability (HA) scenarios, ensuring that t he backup PCE can correctly verify Prefix SIDs.</t>
<t>The introduction of an SR-Algorithm TLV within the LSPA object allows o perators to specify SR-Algorithm constraints directly, thereby refining path com putations to meet specific needs, such as low-latency paths.</t> <t>The introduction of an SR-Algorithm TLV within the LSPA object allows o perators to specify SR-Algorithm constraints directly, thereby refining path com putations to meet specific needs, such as low-latency paths.</t>
<t>The ability to specify an SR-Algorithm per SID in ERO and RRO is crucia l for multiple reasons, for example:</t> <t>The ability to specify an SR-Algorithm per SID in ERO and RRO is crucia l for multiple reasons, for example:</t>
<list style="symbols"> <ul spacing="normal">
<t>SID types without algorithm specified - Certain SID types, such <li>
as Binding SIDs (BSIDs) <xref target="RFC8402"/>, may not have an SR-algorithm <t>SID types without algorithm specified - Certain SID types, such as
specified. It may be inaccurate to state that an entire end-to-end path adheres Binding SIDs (BSIDs) <xref target="RFC8402" format="default"/>, may not have an
to a specific algorithm if it includes a BSID from another policy. Note: In SRv6 SR-Algorithm specified. It may be inaccurate to state that an entire end-to-end
, the BSID can be allocated from an algo-specific SRv6 Locator which will result path adheres to a specific algorithm if it includes a BSID from another policy.
in the path to that BSID PCC node following that algo-specific path. However, t Note: In SRv6, the BSID can be allocated from an algorithm-specific SRv6 Locator
he implicit algorithm of BSID is independent of SR algorithm used for the SR Pol , which will result in the path to that BSID PCC node following that algorithm-s
icy associated with that BSID.</t> pecific path. However, the implicit algorithm of BSID is independent of the SR-A
<t>Topologies with two Interior Gateway Protocol (IGP) domains, ea lgorithm used for the SR Policy associated with that BSID.</t>
ch using the same FAD but with differing algorithm numbers.</t> </li>
</list> <li>
<t>Topologies with two Interior Gateway Protocol (IGP) domains, each u
sing the same FAD but with differing algorithm numbers.</t>
</li>
</ul>
</section> </section>
<section anchor="OBJECT-FORMATS" numbered="true" toc="default">
<section anchor="OBJECT-FORMATS" title="Object Formats"> <name>Object Formats</name>
<section anchor="THE-OPEN-SUBOBJECT" title="OPEN Object"> <section anchor="THE-OPEN-SUBOBJECT" numbered="true" toc="default">
<section anchor="SR-CAP-FLAG" title="SR PCE Capability Sub-TLV"> <name>OPEN Object</name>
<t>The SR-PCE-CAPABILITY Sub-TLV is defined in <xref target="RFC8664" sectionFor <section anchor="SR-CAP-FLAG" numbered="true" toc="default">
mat="of" section="4.1.2" /> to be included in the PATH-SETUP-TYPE-CAPABILITY TLV <name>SR PCE Capability Sub-TLV</name>
.</t> <t>The SR-PCE-CAPABILITY sub-TLV is defined in <xref target="RFC8664"
<t>This document defines the following flag in the SR-PCE-CAPABILITY Sub-TLV Fla sectionFormat="of" section="4.1.2" format="default"/> to be included in the PATH
gs field:</t> -SETUP-TYPE-CAPABILITY TLV.</t>
<list style="symbols"> <t>This document defines the following flag in the SR-PCE-CAPABILITY S
<t>S (SR-Algorithm Capability) - bit 5: If the S flag is set to 1, a PCEP speak ub-TLV Flags field:</t>
er indicates support for the Algorithm field and the Subobject Extension Block i <dl spacing="normal" newline="false">
n the SR-ERO subobject described in <xref target="SR-ERO-Subobject"/> and the SR <dt>S (SR-Algorithm Capability) - bit 5:</dt><dd>If the S flag is se
-Algorithm TLV described in <xref target="SR-Algorithm-TLV"/> for LSPs setup usi t to 1, a PCEP speaker indicates support for the Algorithm field and the Subobje
ng Path Setup Type 1 (Segment Routing) <xref target="RFC8664"/>. It does not ind ct Extension Block in the SR-ERO subobject described in <xref target="SR-ERO-Sub
icate support for these extensions for other Path Setup Types. If the S flag is object" format="default"/> and the SR-Algorithm TLV described in <xref target="S
set to 0, behavior reverts to the procedures defined in existing specifications R-Algorithm-TLV" format="default"/> for LSPs set up using Path Setup Type 1 (Seg
prior to the introduction of this extension.</t> ment Routing) <xref target="RFC8664" format="default"/>. It does not indicate su
</list> pport for these extensions for other Path Setup Types. If the S flag is set to 0
, behavior reverts to the procedures defined in existing specifications prior to
the introduction of this extension.</dd>
</dl>
</section> </section>
<section anchor="SRv6-CAP-FLAG" title="SRv6 PCE Capability sub-TLV"> <section anchor="SRv6-CAP-FLAG" numbered="true" toc="default">
<name>SRv6 PCE Capability Sub-TLV</name>
<t>The SRv6-PCE-CAPABILITY sub-TLV is defined in <xref target="RFC9603" sectionF <t>The SRv6-PCE-CAPABILITY sub-TLV is defined in <xref target="RFC9603
ormat="of" section="4.1.1" /> to be included in the PATH-SETUP-TYPE-CAPABILITY T " sectionFormat="of" section="4.1.1" format="default"/> to be included in the PA
LV.</t> TH-SETUP-TYPE-CAPABILITY TLV.</t>
<t>This document defines the following flag in the SRv6-PCE-CAPABILITY sub-TLV F <t>This document defines the following flag in the SRv6-PCE-CAPABILITY
lags field:</t> Sub-TLV Flags field:</t>
<list style="symbols"> <dl spacing="normal" newline="false">
<t>SR-Algorithm Capability (S) - bit TBD1: If the S flag is set to 1, a PCEP spe <dt>SR-Algorithm Capability (S) - bit 13:</dt><dd>If the S flag is s
aker indicates support for the Algorithm field in the SRv6-ERO subobject describ et to 1, a PCEP speaker indicates support for the Algorithm field in the SRv6-ER
ed in <xref target="SRv6-ERO-Subobject"/> and the SR-Algorithm TLV described in O subobject described in <xref target="SRv6-ERO-Subobject" format="default"/> an
<xref target="SR-Algorithm-TLV"/> for LSPs setup using Path Setup Type 3 (SRv6) d the SR-Algorithm TLV described in <xref target="SR-Algorithm-TLV" format="defa
<xref target="RFC9603"/>. It does not indicate support for these extensions for ult"/> for LSPs set up using Path Setup Type 3 (SRv6) <xref target="RFC9603" for
other Path Setup Types. If the S flag is set to 0, behavior reverts to the proce mat="default"/>. It does not indicate support for these extensions for other Pat
dures defined in existing specifications prior to the introduction of this exten h Setup Types. If the S flag is set to 0, behavior reverts to the procedures def
sion.</t> ined in existing specifications prior to the introduction of this extension.</dd
</list> >
</dl>
</section> </section>
</section> </section>
<section anchor="SR-ERO-Subobject" title="SR-ERO Subobject"> <section anchor="SR-ERO-Subobject" numbered="true" toc="default">
<t>This document updates the SR-ERO subobject format defined in <xref ta <name>SR-ERO Subobject</name>
rget="RFC8664" sectionFormat="of" section="4.3.1" /> with a new optional, variab <t>This document updates the SR-ERO subobject format defined in <xref ta
le-length Subobject Extension Block field. The block is used to convey additiona rget="RFC8664" sectionFormat="of" section="4.3.1" format="default"/> with a new
l information, such as the Algorithm field, and is designed to allow future exte optional, variable-length Subobject Extension Block field. The block is used to
nsibility. Further, a new A flag in Flags field is introduced as shown in <xref convey additional information, such as the Algorithm field, and is designed to a
target="SR-ERO-subobject-format"/>.</t> llow future extensibility. Further, a new A flag in the Flags field is introduce
<figure anchor="SR-ERO-subobject-format" title="SR-ERO Subobject Format"><artwor d as shown in <xref target="SR-ERO-subobject-format" format="default"/>.</t>
k align="center"> <figure anchor="SR-ERO-subobject-format">
<name>SR-ERO Subobject Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=36 | Length | NT | Flags |A|F|S|C|M| |L| Type=36 | Length | NT | Flags |A|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional) | | SID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) // // NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Subobject Extension Block (variable, optional) // // Subobject Extension Block (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork></f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
igure> </figure>
<t>A new flag in the Flags field:
<t>A new flag in the Flags field:
<list style="symbols">
<t>A (SR-Algorithm Flag): If set by a PCEP speaker, the Subobject Extension Blo
ck MUST be included in the SR-ERO subobject as shown in <xref target="SR-ERO-sub
object-format"/> along with the specified algorithm. The length of this block is
variable and determined by subtracting the size of the fixed fields and any opt
ional SID or NAI fields from the total subobject Length. The length of the Subob
ject Extension Block MUST always be a multiple of 4 bytes.
If this flag is set to 0, then either:
<list style="symbols">
<t>the Subobject Extension Block is not included and processing described in
<xref target="RFC8664" sectionFormat="of" section="5.2.1" /> applies, or</t>
<t>the Subobject Extension Block is included (due to an SEBF in a future spe
cifications) and the Algorithm field MUST be ignored.</t>
</list>
</t>
</list>
</t> </t>
<dl spacing="normal" newline="false">
<dt>A (SR-Algorithm Flag):</dt><dd><t>If set by a PCEP speaker, the Su
bobject Extension Block <bcp14>MUST</bcp14> be included in the SR-ERO subobject,
as shown in <xref target="SR-ERO-subobject-format" format="default"/>, along wi
th the specified algorithm. The length of this block is variable and determined
by subtracting the size of the fixed fields and any optional SID or NAI fields f
rom the total subobject Length. The length of the Subobject Extension Block <bcp
14>MUST</bcp14> always be a multiple of 4 bytes.
If this flag is set to 0, then either:</t>
<ul spacing="normal">
<li>the Subobject Extension Block is not included and processing d
escribed in <xref target="RFC8664" sectionFormat="of" section="5.2.1" format="de
fault"/> applies or</li>
<li>the Subobject Extension Block is included (due to an SEBF in a
future specifications) and the Algorithm field <bcp14>MUST</bcp14> be ignored.<
/li>
</ul>
</dd>
</dl>
<t>This document updates the SR-ERO subobject validation defined in <xre
f target="RFC8664" sectionFormat="of" section="5.2.1" format="default"/> by exte
nding existing validation to include the Subobject Extension Block and the A fla
g, as follows.</t>
<t>On receiving an SR-ERO subobject, a PCC <bcp14>MUST</bcp14> validate
that the Length field, S bit, F bit, A bit, NT field, and any present SEBFs are
consistent, as follows:</t>
<ul spacing="normal">
<li>
<t>If the Subobject Extension Block is included (i.e., if any SEBF,
such as A or a future flag, is set to 1), the length of the subobject <bcp14>MUS
T</bcp14> include the size of the entire Subobject Extension Block as determined
by the set of SEBFs.
</t>
<ul spacing="normal">
<li>The minimum size of the Subobject Extension Block is 4 bytes w
hen only a single SEBF (such as A) is set and may be longer (in multiples of 4 b
ytes) if additional SEBFs are set and require more space.</li>
<li>The total subobject Length is the sum of the sizes of the fixe
d and optional fields (SID, NAI, etc.) and the total size of the Subobject Exten
sion Block required by the set of SEBFs.</li>
<li>
<t>The exact calculation of Length for each NT, S, F, and set of
SEBFs is as follows:
</t>
<ul spacing="normal">
<li>If NT=0, the F bit <bcp14>MUST</bcp14> be 1, the S bit <bc
p14>MUST</bcp14> be 0, and the Length <bcp14>MUST</bcp14> be 8 + the size of the
Subobject Extension Block.</li>
<li>
<t>If NT=1, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 8
+ the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 1
2 + the size of the Subobject Extension Block.</li>
</ul>
</li>
<li>
<t>If NT=2, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 2
0 + the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 2
4 + the size of the Subobject Extension Block.</li>
</ul>
</li>
<li>
<t>If NT=3, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 1
2 + the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 1
6 + the size of the Subobject Extension Block.</li>
</ul>
</li>
<li>
<t>If NT=4, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 3
6 + the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 4
0 + the size of the Subobject Extension Block.</li>
</ul>
</li>
<li>
<t>If NT=5, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 2
0 + the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 2
4 + the size of the Subobject Extension Block.</li>
</ul>
</li>
<li>
<t>If NT=6, the F bit <bcp14>MUST</bcp14> be 0.
</t>
<ul spacing="normal">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 4
4 + the size of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 4
8 + the size of the Subobject Extension Block.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>If no SEBF (including the A flag defined in this document) is set,
the Length value <bcp14>MUST</bcp14> follow the requirements defined in <xref t
arget="RFC8664" sectionFormat="of" section="5.2.1" format="default"/>.</li>
</ul>
<section anchor="Subobject-Extension-Block" numbered="true" toc="default
">
<name>Subobject Extension Block</name>
<t>The Subobject Extension Block is an optional, extensible field in t
he SR-ERO subobject. Its presence is indicated by the setting of any SEBF in the
subobject's Flags field (e.g., the A flag defined in this document or flags def
ined by future specifications).</t>
<t>This document updates the SR-ERO subobject validation defined in <xref target <dl spacing="normal" newline="true">
="RFC8664" sectionFormat="of" section="5.2.1" /> by extending existing validatio <dt>Block length and presence:</dt>
n to include the Subobject Extension Block and the A flag as follows.</t> <dd>
<t>On receiving an SR-ERO subobject, a PCC MUST validate that the Length field <ul spacing="normal">
, S bit, F bit, A bit, NT field, and any present SEBFs are consistent, as follow <li>
s:</t> <t>If the A flag is set, and no other SEBF is set, the block lengt
<ul spacing="normal" bare="false" empty="false"> h <bcp14>MUST</bcp14> be 4.</t>
<li>If the Subobject Extension Block is included (i.e., if any SEBF, such as </li>
A or a future flag, is set to 1), the length of the subobject MUST include the <li>
size of the entire Subobject Extension Block as determined by the set of SEBFs. <t>The block length is at least 4 bytes when present.</t>
<ul spacing="normal" bare="false" empty="false"> </li>
<li>The minimum size of the Subobject Extension Block is 4 bytes when only <li>
a single SEBF (such as A) is set, and may be longer (in multiples of 4 bytes) i <t>The block length <bcp14>MUST</bcp14> always be a multiple of 4
f additional SEBFs are set and require more space.</li> bytes.</t>
<li>The total subobject Length is the sum of the sizes of the fixed and op </li>
tional fields (SID, NAI, etc.) and the total size of the Subobject Extension Blo <li>
ck required by the set of SEBFs.</li> <t>The block <bcp14>MUST</bcp14> be included if any SEBF is set in
<li>The exact calculation of Length for each NT, S, F, and set of SEBFs is the Flags field.</t>
as follows: </li>
<ul spacing="normal" bare="false" empty="false"> <li>
<li>If NT=0, the F bit <bcp14>MUST</bcp14> be 1, the S bit <bcp14>MUST</ <t>Future extensions may define additional SEBFs and corresponding
bcp14> be zero, and the Length <bcp14>MUST</bcp14> be 8 + the size of the Subobj fields, allowing the block to be increased in size beyond the initial 4 bytes a
ect Extension Block.</li> s needed.</t>
<li>If NT=1, the F bit <bcp14>MUST</bcp14> be zero. </li>
<ul spacing="normal" bare="false" empty="false"> </ul>
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 8 + the size </dd>
of the Subobject Extension Block.</li> </dl>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 12 + the siz <t>The first 4 bytes of the Subobject Extension Block are described in
e of the Subobject Extension Block.</li> <xref target="Subobject-extension-format" format="default"/>.</t>
</ul> <figure anchor="Subobject-extension-format">
</li> <name>Subobject Extension Block Format</name>
<li>If NT=2, the F bit <bcp14>MUST</bcp14> be zero. <artwork align="center" name="" type="" alt=""><![CDATA[
<ul spacing="normal" bare="false" empty="false">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 20 + the siz
e of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 24 + the siz
e of the Subobject Extension Block.</li>
</ul>
</li>
<li>If NT=3, the F bit <bcp14>MUST</bcp14> be zero.
<ul spacing="normal" bare="false" empty="false">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 12 + the siz
e of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 16 + the siz
e of the Subobject Extension Block.</li>
</ul>
</li>
<li>If NT=4, the F bit <bcp14>MUST</bcp14> be zero.
<ul spacing="normal" bare="false" empty="false">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 36 + the siz
e of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 40 + the siz
e of the Subobject Extension Block.</li>
</ul>
</li>
<li>If NT=5, the F bit <bcp14>MUST</bcp14> be zero.
<ul spacing="normal" bare="false" empty="false">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 20 + the siz
e of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 24 + the siz
e of the Subobject Extension Block.</li>
</ul>
</li>
<li>If NT=6, the F bit <bcp14>MUST</bcp14> be zero.
<ul spacing="normal" bare="false" empty="false">
<li>If the S bit is 1, the Length <bcp14>MUST</bcp14> be 44 + the siz
e of the Subobject Extension Block.</li>
<li>If the S bit is 0, the Length <bcp14>MUST</bcp14> be 48 + the siz
e of the Subobject Extension Block.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>If no SEBF (including the A flag defined in this document) is set, the L
ength value MUST follow the requirements defined in <xref target="RFC8664" secti
onFormat="of" section="5.2.1" /> applies.</li>
</ul>
<section anchor="Subobject-Extension-Block" title="Subobject Extension Block">
<t>The Subobject Extension Block is an optional, extensible field in the SR-ER
O subobject. Its presence is indicated by the setting of any SEBF in the subobje
ct's Flags field (e.g., the A flag defined in this document, or flags defined by
future specifications).</t>
<t>Block Length and Presence:
<list style="symbols">
<t>If the A flag is set, and no other SEBF is set, the block Length MUST be
4.</t>
<t>The block length is at least 4 bytes when present.</t>
<t>The block length MUST always be a multiple of 4 bytes</t>
<t>The block MUST be included if any SEBF is set in the Flags field.</t>
<t>Future extensions may define additional SEBFs and corresponding fields, a
llowing the block to be increased in size beyond the initial 4 bytes as needed.<
/t>
</list>
</t>
<t>The first 4 bytes of the Subobject Extension Block are described in <xref tar
get="Subobject-extension-format"/>.</t>
<figure anchor="Subobject-extension-format" title="Subobject Extension Block For
mat"><artwork align="center">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unassigned | Algorithm | | Unassigned | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork></f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
igure> </figure>
<dl spacing="normal" newline="true">
<dt>Unassigned (24 bits):</dt><dd>This field is reserved for future
use and <bcp14>MUST</bcp14> be set to zero when sending and ignored when receivi
ng.</dd>
<dt>Algorithm (8 bits):</dt><dd>The SR-Algorithm value from the "IGP
Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" r
egistry group (see <xref target="IANA-ALGORITHM-TYPES" format="default"/>).</dd>
</dl>
<t>Future extensions <bcp14>SHOULD</bcp14> first use the Unassigned po
rtion of the initial 4 bytes to carry new information. If additional space is ne
eded, the Subobject Extension Block may be extended in 4-byte increments. Each s
uch extension must be indicated by a dedicated SEBF in the Flags field (similar
to the A flag) and must be accompanied by capability signaling in an appropriate
capability sub-TLV. The specific sub-TLV to be used is not restricted by this s
pecification and may include, for example, the SR-PCE-CAPABILITY sub-TLV, the SR
v6-PCE-CAPABILITY sub-TLV, or other capability TLVs, depending on the context of
the extension. Interoperability procedures and the precise signaling mechanisms
for each new SEBF and its associated capability will be defined by future speci
fications or procedures describing those extensions.</t>
<t>When receiving a Subobject Extension Block longer than 4 bytes, rec
eivers that do not recognize or have not negotiated support for additional flags
<bcp14>MUST</bcp14> ignore the unknown additional bytes beyond those defined in
this document.</t>
</section>
<section anchor="Guidance-Future-Extensions" numbered="true" toc="defaul
t">
<name>Guidance for Future Extensions</name>
<t>Future enhancements extending the Subobject Extension Block must:
</t>
<t>Unassigned (24 bits): This field is reserved for future use and MUST be set <!--[rfced] To parallel the structure of the first two bullet items, may
to zero when sending and ignored when receiving.</t> we update the latter two bullet items as follows?
<t>Algorithm (8 bits): SR-Algorithm value from registry "IGP Algorithm Types" Original:
of "Interior Gateway Protocol (IGP) Parameters" IANA registry (see <xref target= * Define a new SEBF in the Flags field to indicate the presence of
"IANA-ALGORITHM-TYPES"/>).</t> new extension, and specify the corresponding capability signaling
for that extension.
<t>Future extensions SHOULD first use the Unassigned portion of the initial 4 * Specify which parts of the reserved/extension block are used and
bytes to carry new information. If additional space is needed, the Subobject Ext how the block length is calculated when their extension is
ension Block may be extended in 4-byte increments. Each such extension must be i present.
ndicated by a dedicated SEBF in the Flags field (similar to the A flag) and must
be accompanied by capability signaling in an appropriate capability sub-TLV. Th
e specific sub-TLV to be used is not restricted by this specification and may in
clude, for example, the SR-PCE-CAPABILITY Sub-TLV, the SRv6-PCE-CAPABILITY Sub-T
LV, or other capability TLVs, depending on the context of the extension. Interop
erability procedures and the precise signaling mechanisms for each new SEBF and
its associated capability will be defined by future specifications or procedures
describing those extensions.</t>
<t>When receiving a Subobject Extension Block longer than 4 bytes, receivers t * The reserved bits in the initial 4 bytes are used when possible,
hat do not recognize or have not negotiated support for additional flags MUST ig and the block is extended only when additional space is necessary.
nore the unknown additional bytes beyond those defined in this document.</t>
</section> * Future extensions may define additional SEBFs and corresponding
fields, allowing the block to be increased in size beyond the
initial 4 bytes as needed.
<section anchor="Guidance-Future-Extensions" title="Guidance for Future Ex Perhaps:
tensions"> * Define a new SEBF in the Flags field to indicate the presence of
a new extension and specify the corresponding capability signaling
for that extension.
<t>Future enhancements extending the Subobject Extension Block must: * Specify which parts of the reserved/extension block are used and
<list style="symbols"> how the block length is calculated when their extension is
<t>Define a new SEBF in the Flags field to indicate the presence of new exte present.
nsion, and specify the corresponding capability signaling for that extension.</t
>
<t>Specify which parts of the reserved/extension block are used and how the
block length is calculated when their extension is present.</t>
<t>The reserved bits in the initial 4 bytes are used when possible, and the
block is extended only when additional space is necessary.</t>
<t>Future extensions may define additional SEBFs and corresponding fields, a
llowing the block to be increased in size beyond the initial 4 bytes as needed.<
/t>
</list>
</t>
<t>Example: Future extension introducing a Z flag and a new Z field (8 bits): * Ensure the reserved bits in the initial 4 bytes are used when possible
<list style="symbols"> and the block is extended only when additional space is necessary.
<t>If the A flag and/or the Z flag are set, the Subobject Extension Block is
included. The Z field may use 8 bits of the reserved portion. A field is only c
onsidered valid if its corresponding flag is set. For example, if the Z flag is
set to 1 but the A flag is set to 0, the Z field is valid, but the Algorithm fie
ld is ignored.</t>
<t>If space beyond the initial 4 bytes is needed, the extension document spe
cifies the new block layout and total length. To simplify parsing, if a flag for
such an extension is set, the full extended block is encoded, including the ini
tial 4 bytes, even if the A flag is set to 0.</t>
</list>
</t>
</section> * Have future extensions define additional SEBFs and corresponding
</section> fields, allowing the block to be increased in size beyond the
initial 4 bytes as needed.
-->
<section anchor="SRv6-ERO-Subobject" title="SRv6-ERO Subobject"> <ul spacing="normal">
<t>This document updates the SRv6-ERO subobject format defined in <li>
<xref target="RFC9603" sectionFormat="of" section="4.3.1" /> with Algorithm fiel <t>Define a new SEBF in the Flags field to indicate the presence o
d carved out of the Reserved field. Further, a new A flag is defined in the exis f a new extension and specify the corresponding capability signaling for that ex
ting Flags field as shown in <xref target="SRv6-ERO-subobject-format"/>.</t> tension.</t>
<figure anchor="SRv6-ERO-subobject-format" title="SRv6-ERO Subobject Format"><ar </li>
twork align="center"> <li>
<t>Specify which parts of the reserved/extension block are used an
d how the block length is calculated when their extension is present.</t>
</li>
<li>
<t>The reserved bits in the initial 4 bytes are used when possible
, and the block is extended only when additional space is necessary.</t>
</li>
<li>
<t>Future extensions may define additional SEBFs and corresponding
fields, allowing the block to be increased in size beyond the initial 4 bytes a
s needed.</t>
</li>
</ul>
<t>Example: Future extension introducing a Z flag and a new Z field (8
bits):
</t>
<ul spacing="normal">
<li>
<t>If the A flag and/or the Z flag are set, the Subobject Extensio
n Block is included. The Z field may use 8 bits of the reserved portion. A field
is only considered valid if its corresponding flag is set. For example, if the
Z flag is set to 1 but the A flag is set to 0, the Z field is valid but the Algo
rithm field is ignored.</t>
</li>
<li>
<t>If space beyond the initial 4 bytes is needed, the extension do
cument specifies the new block layout and total length. To simplify parsing, if
a flag for such an extension is set, the full extended block is encoded, includi
ng the initial 4 bytes, even if the A flag is set to 0.</t>
</li>
</ul>
</section>
</section>
<section anchor="SRv6-ERO-Subobject" numbered="true" toc="default">
<name>SRv6-ERO Subobject</name>
<t>This document updates the SRv6-ERO subobject format defined in <xref
target="RFC9603" sectionFormat="of" section="4.3.1" format="default"/> with the
Algorithm field carved out of the Reserved field. Further, a new A flag is defin
ed in the existing Flags field as shown in <xref target="SRv6-ERO-subobject-form
at" format="default"/>.</t>
<figure anchor="SRv6-ERO-subobject-format">
<name>SRv6-ERO Subobject Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type=40 | Length | NT | Flags |A|V|T|F|S| |L| Type=40 | Length | NT | Flags |A|V|T|F|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Algorithm | Endpoint Behavior | | Reserved | Algorithm | Endpoint Behavior |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SRv6 SID (optional) | | SRv6 SID (optional) |
| (128-bit) | | (128-bit) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NAI (variable, optional) // // NAI (variable, optional) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID Structure (optional) | | SID Structure (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork></f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
igure> </figure>
<dl spacing="normal" newline="true">
<t>Flags field:</t> <dt>Flags field:</dt>
<dd>A (SR-Algorithm Flag): If set by a PCEP speaker, the Algorithm fie
<t>A (SR-Algorithm Flag): If set by a PCEP speaker, the Algorithm field is inc ld is included in the SRv6-ERO subobject as specified in <xref target="SRv6-ERO-
luded in SRv6-ERO subobject as specified in <xref target="SRv6-ERO-subobject-for subobject-format" format="default"/>.
mat"/>. If this flag is set to 0, then the Algorithm field is absent and processing desc
If this flag is set to 0, then the Algorithm field is absent and processing desc ribed in <xref target="RFC9603" sectionFormat="of" section="5.2.1" format="defau
ribed in <xref target="RFC9603" sectionFormat="of" section="5.2.1" /> applies. lt"/> applies.
</t> </dd>
<dt>Reserved (8 bits):</dt><dd>It <bcp14>MUST</bcp14> be set to 0 while
<t>Reserved (8 bits): It MUST be set to zero while sending and ignored on sending and ignored on
receipt.</t> receipt.</dd>
<dt>Algorithm (8 bits):</dt><dd>The SR-Algorithm value from the "IGP Alg
<t>Algorithm (8 bits): SR-Algorithm value from registry "IGP Algorithm Types" of orithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" regis
"Interior Gateway Protocol (IGP) Parameters" IANA registry.</t> try group.</dd>
</dl>
<t>Note: The Subobject Extension Block is applicable to SRv6-ERO subobject, but <t>Note: The Subobject Extension Block is applicable to the SRv6-ERO sub
is not required by this specific specification as existing reserved space is use object but is not required by this specific specification as existing reserved s
d. When additional space is needed in the SRv6-ERO subobject, the future extensi pace is used. When additional space is needed in the SRv6-ERO subobject, the fut
ons SHOULD specify the usage of the Subobject Extension Block for the SRv6-ERO s ure extensions <bcp14>SHOULD</bcp14> specify the usage of the Subobject Extensio
ubobject.</t> n Block for the SRv6-ERO subobject.</t>
</section> </section>
<section anchor="SR-Algorithm-TLV" numbered="true" toc="default">
<section anchor="SR-Algorithm-TLV" title="SR-Algorithm TLV"> <name>SR-Algorithm TLV</name>
<t>A new TLV for the LSPA Object is introduced to carry the SR-Algorithm <t>A new TLV for the LSPA Object is introduced to carry the SR-Algorithm
constraint (<xref target="SR-ALGORITHM-CONSTRAINT"/>). This TLV MUST only be us constraint (<xref target="SR-ALGORITHM-CONSTRAINT" format="default"/>). This TL
ed when PST (Path Setup type) = 1 or 3 for SR-MPLS and SRv6, respectively. Only V <bcp14>MUST</bcp14> only be used when Path Setup Type (PST) = 1 or 3 for SR-MP
the first instance of this TLV MUST be processed, subsequent instances MUST be i LS and SRv6, respectively. Only the first instance of this TLV <bcp14>MUST</bcp1
gnored.</t> 4> be processed; subsequent instances <bcp14>MUST</bcp14> be ignored.</t>
<t>The format of the SR-Algorithm TLV is as follows:</t> <t>The format of the SR-Algorithm TLV is as follows:</t>
<figure anchor="SR-ALGORITHM-TLV-FMT" title="SR-Algorithm TLV Format"> <figure anchor="SR-ALGORITHM-TLV-FMT">
<artwork align="center"><![CDATA[ <name>SR-Algorithm TLV Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=66 | Length=4 | | Type=66 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S| Algorithm | | Reserved | Flags |S| Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl spacing="normal" newline="false">
<t>Type (16 bits): 66.</t> <dt>Type (16 bits):</dt><dd>66</dd>
<t>Length (16 bits): 4.</t> <dt>Length (16 bits):</dt><dd>4</dd>
</dl>
<t>The 32-bit value is formatted as follows. <t>The 32-bit value is formatted as follows.</t>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Reserved (16 bits):"> MUST be set to zero by the sender <dt>Reserved (16 bits):</dt>
and MUST be ignored by the receiver.</t> <dd> <bcp14>MUST</bcp14> be set to 0 by the sender and <bcp14>MUST</bc
<t hangText="Flags (8 bits):"> This document defines the following f p14> be ignored by the receiver.</dd>
lag. The other flags <dt>Flags (8 bits):</dt>
MUST be set to zero by the sender and MUST be ignored by the recei <dd>
ver. <t> This document defines the following flag. The other flags
<list style="symbols"> <bcp14>MUST</bcp14> be set to 0 by the sender and <bcp14>MUST</bcp
<t>S (Strict): If set, the path computation at the PCE MUST fail 14> be ignored by the receiver.
if the specified SR-Algorithm constraint cannot be satisfied. If the S (Strict)
bit is unset and the PCE is unable to compute a path that satisfies the specifi
ed SR-Algorithm constraint, the PCE MUST attempt to compute a path as if no SR-A
lgorithm constraint had been requested. This means the PCE may use any available
SR-Algorithm for the computation, consistent with the default behavior in the a
bsence of SR-Algorithm constraint.</t>
</list>
</t> </t>
<t hangText="Algorithm (8 bits):"> SR-Algorithm to be used during pa <dl spacing="normal" newline="false">
th computation (see <xref target="SR-ALGORITHM-CONSTRAINT"/>).</t> <dt>S (Strict):</dt><dd>If set, the path computation at the PCE
</list> <bcp14>MUST</bcp14> fail if the specified SR-Algorithm
</t> constraint cannot be satisfied. If the S (Strict) bit is unset
and the PCE is unable to compute a path that satisfies the
specified SR-Algorithm constraint, the PCE <bcp14>MUST</bcp14>
attempt to compute a path as if no SR-Algorithm constraint had
been requested. This means the PCE may use any available
SR-Algorithm for the computation, consistent with the default
behavior in the absence of SR-Algorithm constraint.</dd>
</dl>
</dd>
<dt>Algorithm (8 bits):</dt>
<dd>The SR-Algorithm to be used during path computation (see <xref tar
get="SR-ALGORITHM-CONSTRAINT" format="default"/>).</dd>
</dl>
</section> </section>
<section anchor="METRIC-TYPES" title="Extensions to METRIC Object"> <section anchor="METRIC-TYPES" numbered="true" toc="default">
<t>The METRIC object is defined in <xref target="RFC5440" sectionFormat <name>Extensions to METRIC Object</name>
="of" section="7.8" />. This document specifies additional types for the METRIC <t>The METRIC object is defined in <xref target="RFC5440" sectionFormat=
object to enable the encoding of optimization metric types derived from the FAD "of" section="7.8" format="default"/>. This document specifies additional types
during Flexible Algorithm path computation (see <xref target="FLEX-ALGO-COMPUTAT for the METRIC object to enable the encoding of optimization metric types derive
ION"/>). While these new metric types are defined to support this specific use c d from the FAD during Flexible Algorithm path computation (see <xref target="FLE
ase, their use is not restricted to Flexible Algorithm path computation or to an X-ALGO-COMPUTATION" format="default"/>). While these new metric types are define
y specific Path Setup Type.</t> d to support this specific use case, their use is not restricted to Flexible Alg
<list style="symbols"> orithm path computation or to any specific Path Setup Type.</t>
<t> T=22: Path Min Delay metric (<xref target="P2P-MIN-DELAY"/>) </ <ul spacing="normal">
t> <li>
<t> T=23: P2MP Path Min Delay metric (<xref target="P2MP-MIN-DELAY" <t> T=22: Path Min Delay Metric (<xref target="P2P-MIN-DELAY" format
/>) </t> ="default"/>) </t>
<t> T=24: Path Bandwidth Metric (<xref target="P2P-BANDWIDTH"/>) </ </li>
t> <li>
<t> T=25: P2MP Path Bandwidth Metric (<xref target="P2MP-BANDWIDTH" <t> T=23: P2MP Path Min Delay Metric (<xref target="P2MP-MIN-DELAY"
/>) </t> format="default"/>) </t>
<t> T=128-255: User-defined metric (<xref target="USER-DEFINED-METR </li>
IC"/>) </t> <li>
</list> <t> T=24: Path Bandwidth Metric (<xref target="P2P-BANDWIDTH" format
<t>The following terminology is used and expanded along the way.</t> ="default"/>) </t>
<list style="symbols"> </li>
<t>A network comprises of a set of N links {Li, (i=1...N)}.</t> <li>
<t>A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,( <t> T=25: P2MP Path Bandwidth Metric (<xref target="P2MP-BANDWIDTH"
i=1...K)}.</t> format="default"/>) </t>
<t>A P2MP tree T comprises a set of M destinations {Dest_j,(j=1...M)} </li>
.</t> <li>
</list> <t> T=128-255: User-Defined Metric (<xref target="USER-DEFINED-METRI
<section anchor="MIN-DELAY-VALUE" title="Path Min Delay Metric"> C" format="default"/>) </t>
<t><xref target="RFC7471"/> and <xref target="RFC8570"/> define "Min/ </li>
Max Unidirectional Link Delay Sub-TLV" to advertise the link minimum and maximum </ul>
delay in microseconds in a 24-bit field.</t> <t>The following terminology is used and expanded along the way.</t>
<t><xref target="RFC5440"/> defines the METRIC object with a 32-bit m <ul spacing="normal">
etric value encoded in IEEE floating point format (see <xref target="IEEE.754.20 <li>
08"/>).</t> <t>A network comprises a set of N links {Li, (i=1...N)}.</t>
<t>The encoding for the Path Min Delay metric value is quantified in </li>
units of microseconds and encoded in IEEE floating point format.</t> <li>
<t>For use in the PCEP METRIC object, the 24-bit unsigned integer del <t>A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,
ay value is converted to a 32-bit IEEE floating point value. This conversion fol (i=1...K)}.</t>
lows the procedure specified in <xref target="IEEE.754.2008"/>.</t> </li>
<li>
<section anchor="P2P-MIN-DELAY" title="P2P Path Min Del <t>A P2MP tree T comprises a set of M destinations {Dest_j,(j=1...M)
ay Metric"> }.</t>
<t>The minimum Link Delay metric is defined in <xref ta </li>
rget="RFC7471"/> and <xref target="RFC8570"/> as "Min Unidirectional Link Delay" </ul>
. The Path Min Link Delay metric represents measured minimum link delay value ov <section anchor="MIN-DELAY-VALUE" numbered="true" toc="default">
er a configurable interval.</t> <name>Path Min Delay Metric</name>
<t>The Path Min Delay metric type of the METRIC object <t><xref target="RFC7471" format="default"/> and <xref target="RFC8570
in PCEP represents the sum of the Min Link Delay metric of all links along a P2P " format="default"/> define the "Min/Max Unidirectional Link Delay" sub-TLV to a
path. </t> dvertise the link minimum and maximum delay in microseconds in a 24-bit field.</
t>
<list style="symbols"> <t><xref target="RFC5440" format="default"/> defines the METRIC object
<t>A Min Link Delay metric of link L is denoted D(L).< with a 32-bit metric value encoded in IEEE floating point format (see <xref tar
/t> get="IEEE.754.2008" format="default"/>).</t>
<t>A Path Min Delay metric for the P2P path P = Sum {D <t>The encoding for the Path Min Delay metric value is quantified in u
(Lpi), (i=1...K)}.</t> nits of microseconds and encoded in IEEE floating point format.</t>
</list> <t>For use in the PCEP METRIC object, the 24-bit unsigned integer dela
</section> y value is converted to a 32-bit IEEE floating point value. This conversion foll
<section anchor="P2MP-MIN-DELAY" title="P2MP Path Min De ows the procedure specified in <xref target="IEEE.754.2008" format="default"/>.<
lay Metric"> /t>
<t>The P2MP Path Min Delay metric type of the METRIC ob <section anchor="P2P-MIN-DELAY" numbered="true" toc="default">
ject in PCEP encodes the Path Min Delay metric for the destination that observes <name>P2P Path Min Delay Metric</name>
the worst (i.e., highest value) delay metric among all destinations of the P2MP <t>The minimum Link Delay metric is defined in <xref target="RFC7471
tree.</t> " format="default"/> and <xref target="RFC8570" format="default"/> as "Min Unidi
<list style="symbols"> rectional Link Delay". The Path Min Link Delay metric represents the measured mi
<t>The P2P Path Min Delay metric of the path to destin nimum link delay value over a configurable interval.</t>
ation Dest_j is denoted by PMDM(Dest_j).</t> <t>The Path Min Delay metric type of the METRIC object in PCEP repre
<t>The P2MP Path Min Delay metric for the P2MP tree T sents the sum of the Min Link Delay metric of all links along a P2P path. </t>
= Maximum{PMDM(Dest_j), (j=1...M)}.</t> <ul spacing="normal">
</list> <li>
</section> <t>A Min Link Delay metric of link L is denoted by D(L).</t>
</section> </li>
<section anchor="BANDWIDTH-VALUE" title="Path Bandwidth Metric"> <li>
<t><xref target="RFC9843" sectionFormat="of" section="4" /> defines a <t>A Path Min Delay metric for the P2P path P = Sum {D(Lpi), (i=
new metric type "Bandwidth Metric", which may be advertised in their link metric 1...K)}.</t>
advertisements.</t> </li>
<t>When performing Flexible Algorithm path computation as described in </ul>
<xref target="FLEX-ALGO-COMPUTATION"/>, procedures described in sections 4.1 an </section>
d 5 from <xref target="RFC9843"/> MUST be followed with automatic metric calcula <section anchor="P2MP-MIN-DELAY" numbered="true" toc="default">
tion.</t> <name>P2MP Path Min Delay Metric</name>
<t>For path computations in contexts other than Flexible Algorithm (in <t>The P2MP Path Min Delay metric type of the METRIC object in PCEP
cluding Path Setup Types other than 1 or 3 for SR-MPLS and SRv6), if the Generic encodes the Path Min Delay metric for the destination that observes the worst (i
Metric sub-TLV with Bandwidth metric type is not advertised for a link, the PCE .e., highest value) delay metric among all destinations of the P2MP tree.</t>
implementation MAY apply a local policy to derive a metric value (similar to th <ul spacing="normal">
e procedures in Sections 4.1.3 and 4.1.4 of <xref target="RFC9843"/>) or the lin <li>
k MAY be treated as if the metric value is unavailable (e.g. by using a default <t>The P2P Path Min Delay metric of the path to destination Dest
value). If the Bandwidth metric value is advertised for a link, the PCE MUST use _j is denoted by PMDM(Dest_j).</t>
the advertised value to compute the path metric in accordance with <xref target </li>
="P2P-BANDWIDTH"/> and <xref target="P2MP-BANDWIDTH"/>.</t> <li>
<t>The Path Bandwidth metric value is encoded in IEEE floating point f <t>The P2MP Path Min Delay metric for the P2MP tree T = Maximum{
ormat (see <xref target="IEEE.754.2008"/>).</t> PMDM(Dest_j), (j=1...M)}.</t>
<t>For use in the PCEP METRIC object, the 24-bit unsigned integer dela </li>
y value is converted to a 32-bit IEEE floating point value. This conversion foll </ul>
ows the procedure specified in <xref target="IEEE.754.2008"/>. </t> </section>
</section>
<section anchor="P2P-BANDWIDTH" title="P2P Path Bandwidt <section anchor="BANDWIDTH-VALUE" numbered="true" toc="default">
h Metric"> <name>Path Bandwidth Metric</name>
<t>The Path Bandwidth metric type of the METRIC object <t><xref target="RFC9843" sectionFormat="of" section="4" format="defau
in PCEP represents the sum of the Bandwidth Metric of all links along a P2P path lt"/> defines a new metric type, "Bandwidth Metric", which may be advertised in
. Note: the link Bandwidth Metric utilized in the formula may be the original me their link metric advertisements.</t>
tric advertised on the link, which may have a value inversely proportional to th <t>When performing Flexible Algorithm path computation as described in
e link capacity.</t> <xref target="FLEX-ALGO-COMPUTATION" format="default"/>, procedures described i
n Sections <xref target="RFC9843" sectionFormat="bare" section="4.1"/> and <xref
<list style="symbols"> target="RFC9843" sectionFormat="bare" section="5"/> from <xref target="RFC9843"
<t>A Bandwidth Metric of link L is denoted B(L).</t> format="default"/> <bcp14>MUST</bcp14> be followed with automatic metric calcul
<t>A Path Bandwidth metric for the P2P path P = Sum {B ation.</t>
(Lpi), (i=1...K)}.</t> <t>For path computations in contexts other than Flexible Algorithm (in
</list> cluding Path Setup Types other than 1 or 3 for SR-MPLS and SRv6, respectively),
</section> if the Generic Metric sub-TLV with the Bandwidth metric type is not advertised f
<section anchor="P2MP-BANDWIDTH" title="P2MP Path Bandwi or a link, the PCE implementation <bcp14>MAY</bcp14> apply a local policy to der
dth Metric"> ive a metric value (similar to the procedures in Sections <xref target="RFC9843"
<t>The Bandwidth metric type of the METRIC object in PC sectionFormat="bare" section="4.1.3"/> and <xref target="RFC9843" sectionFormat
EP encodes the Path Bandwidth metric for the destination that observes the worst ="bare" section="4.1.4"/> of <xref target="RFC9843" format="default"/>) or the l
bandwidth metric among all destinations of the P2MP tree.</t> ink <bcp14>MAY</bcp14> be treated as if the metric value is unavailable (e.g., b
<list style="symbols"> y using a default value). If the Bandwidth metric value is advertised for a link
<t>The P2P Bandwidth metric of the path to destination , the PCE <bcp14>MUST</bcp14> use the advertised value to compute the path metri
Dest_j is denoted by BM(Dest_j).</t> c in accordance with Sections <xref target="P2P-BANDWIDTH" format="counter"/> an
<t>The P2MP Path Bandwidth metric for the P2MP tree T d <xref target="P2MP-BANDWIDTH" format="counter"/>.</t>
= Maximum{BM(Dest_j), (j=1...M)}.</t> <t>The Path Bandwidth metric value is encoded in IEEE floating point f
</list> ormat (see <xref target="IEEE.754.2008" format="default"/>).</t>
</section> <t>For use in the PCEP METRIC object, the 24-bit unsigned integer dela
</section> y value is converted to a 32-bit IEEE floating point value. This conversion foll
ows the procedure specified in <xref target="IEEE.754.2008" format="default"/>.
<section anchor="USER-DEFINED-METRIC" title="User Defined Metric"> </t>
<t><xref target="RFC9843" sectionFormat="of" section="2" /> defined a <section anchor="P2P-BANDWIDTH" numbered="true" toc="default">
new metric type range for "User defined metric", which may be advertised in thei <name>P2P Path Bandwidth Metric</name>
r link metric advertisements. These are user defined and can be assigned by an o <t>The Path Bandwidth metric type of the METRIC object in PCEP repre
perator for local use.</t> sents the sum of the Bandwidth Metric of all links along a P2P path. Note: The l
<t>User Defined metric values are encoded using the IEEE floating poin ink Bandwidth Metric utilized in the formula may be the original metric advertis
t format (see <xref target="IEEE.754.2008"/>).</t> ed on the link, which may have a value inversely proportional to the link capaci
<t>For use in the PCEP METRIC object, the 24-bit unsigned integer dela ty.</t>
y value is converted to a 32-bit IEEE floating point value. This conversion foll <ul spacing="normal">
ows the procedure specified in <xref target="IEEE.754.2008"/>.</t> <li>
<t>The metric type range was chosen to allow mapping with values assig <t>A Bandwidth Metric of link L is denoted by B(L).</t>
ned in the "IGP Metric-Type Registry". For example, the User Defined metric type </li>
130 of the METRIC object in PCEP can represent the sum of the User Defined Metr <li>
ic 130 of all links along a P2P.</t> <t>A Path Bandwidth metric for the P2P path P = Sum {B(Lpi), (i=
<t>User Defined Metrics are equally applicable to P2P and P2MP paths.< 1...K)}.</t>
/t> </li>
</section> </ul>
</section>
<section anchor="P2MP-BANDWIDTH" numbered="true" toc="default">
<name>P2MP Path Bandwidth Metric</name>
<t>The Bandwidth metric type of the METRIC object in PCEP encodes th
e Path Bandwidth metric for the destination that observes the worst bandwidth me
tric among all destinations of the P2MP tree.</t>
<ul spacing="normal">
<li>
<t>The P2P Bandwidth metric of the path to destination Dest_j is
denoted by BM(Dest_j).</t>
</li>
<li>
<t>The P2MP Path Bandwidth metric for the P2MP tree T = Maximum{
BM(Dest_j), (j=1...M)}.</t>
</li>
</ul>
</section>
</section>
<section anchor="USER-DEFINED-METRIC" numbered="true" toc="default">
<name>User-Defined Metric</name>
<t><xref target="RFC9843" sectionFormat="of" section="2" format="defau
lt"/> defined a new metric type range for "user-defined metric", which may be ad
vertised in their link metric advertisements. These are user defined and can be
assigned by an operator for local use.</t>
<t>User-defined metric values are encoded using the IEEE floating poin
t format (see <xref target="IEEE.754.2008" format="default"/>).</t>
<t>For use in the PCEP METRIC object, the 24-bit unsigned integer dela
y value is converted to a 32-bit IEEE floating point value. This conversion foll
ows the procedure specified in <xref target="IEEE.754.2008" format="default"/>.<
/t>
<t>The metric type range was chosen to allow mapping with values assig
ned in the "IGP Metric-Type" registry. For example, the user-defined metric type
130 of the METRIC object in PCEP can represent the sum of the user-defined metr
ic 130 of all links along a P2P path.</t>
<t>User-defined metrics are equally applicable to P2P and P2MP paths.<
/t>
</section>
</section> </section>
</section> </section>
<section anchor="Operation" numbered="true" toc="default">
<section anchor="Operation" title="Operation"> <name>Operation</name>
<t>The PCEP extensions defined in Sections <xref target="ERO-ENCODING" for
<t>The PCEP extensions defined in <xref target="ERO-ENCODING"/> and <xre mat="counter"/> and <xref target="SR-ALGORITHM-CONSTRAINT" format="counter"/> of
f target="SR-ALGORITHM-CONSTRAINT"/> of this document MUST NOT be used unless bo this document <bcp14>MUST NOT</bcp14> be used unless both PCEP speakers have in
th PCEP speakers have indicated support by setting the S flag in the Path Setup dicated support by setting the S flag in the Path Setup Type sub-TLV correspondi
Type Sub-TLV corresponding to the PST of the LSP. If this condition is not met, ng to the PST of the LSP. If this condition is not met, the receiving PCEP speak
the receiving PCEP speaker MUST respond with a PCErr message with Error-Type 19 er <bcp14>MUST</bcp14> respond with a PCErr message with Error-Type 19 (Invalid
(Invalid Operation) and Error-Value TBD3 (Attempted use of SR-Algorithm without Operation) and Error-value 33 (Attempted use of SR-Algorithm without advertised
advertised capability).</t> capability).</t>
<t>The SR-Algorithm used in this document refers to a complete range of SR
<t>The SR-Algorithm used in this document refers to a complete range of -Algorithm values (0-255) if a specific section does not specify otherwise. Vali
SR-Algorithm values (0-255) if a specific section does not specify otherwise. Va d SR-Algorithm values are defined in the "IGP Algorithm Types" registry of the "
lid SR-Algorithm values are defined in the registry "IGP Algorithm Types" of "In Interior Gateway Protocol (IGP) Parameters" registry group. Refer to <xref targe
terior Gateway Protocol (IGP) Parameters" IANA registry. Refer to <xref target=" t="RFC8402" sectionFormat="of" section="3.1.1" format="default"/> and <xref targ
RFC8402" sectionFormat="of" section="3.1.1" /> and <xref target="RFC9256"/> for et="RFC9256" format="default"/> for the definition of SR-Algorithm in Segment Ro
the definition of SR-Algorithm in Segment Routing. <xref target="RFC8665"/> and uting. <xref target="RFC8665" format="default"/> and <xref target="RFC8667" form
<xref target="RFC8667"/> are describing the use of the SR-Algorithm in IGP. Note at="default"/> describe the use of the SR-Algorithm in IGP. Note that some RFCs
that some RFCs are referring to SR-Algorithm with different names, for example refer to SR-Algorithm with different names, for example, "Prefix-SID Algorithm"
"Prefix-SID Algorithm" and "SR Algorithm".</t> and "SR Algorithm".</t>
<section anchor="ERO-ENCODING" numbered="true" toc="default">
<section anchor="ERO-ENCODING" title="ERO and RRO Subobjects"> <name>ERO and RRO Subobjects</name>
<t>If a PCC receives the Algorithm field in the ERO subobject within PCI
<t>If a PCC receives the Algorithm field in the ERO subobject within PCIni nitiate, PCUpd, or PCRep messages and the path received from those messages is b
tiate, PCUpd, or PCRep messages and the path received from those messages is bei eing included in the ERO of PCRpt message, then the PCC <bcp14>MUST</bcp14> incl
ng included in the ERO of PCRpt message, then the PCC MUST include the Algorithm ude the Algorithm field in the encoded subobjects with the received SR-Algorithm
field in the encoded subobjects with the received SR-Algorithm value.</t> value.</t>
<t>As per <xref target="RFC8664" format="default"/>, the format of the S
<t>As per <xref target="RFC8664"/>, the format of the SR-RRO subobject is R-RRO subobject is the same as that of the SR-ERO subobject but without the L fl
the same as that of the SR-ERO subobject, but without the L flag, therefore SR-R ag; therefore, the SR-RRO subobject may also carry the A flag and Algorithm fiel
RO subobject may also carry the A flag and Algorithm field in the Subobject Exte d in the Subobject Extension Block. Similarly, as per <xref target="RFC9603" for
nsion Block. Similarly, as per <xref target="RFC9603"/>, the format of the SRv6- mat="default"/>, the format of the SRv6-RRO subobject is the same as that of the
RRO subobject is the same as that of the SRv6-ERO subobject but without the L fl SRv6-ERO subobject but without the L flag; therefore, the SRv6-RRO subobject ma
ag, therefore SRv6-RRO subobject may also carry the A flag and Algorithm field.< y also carry the A flag and Algorithm field.</t>
/t> <section anchor="SR-ERO-ENCODING" numbered="true" toc="default">
<name>SR-ERO</name>
<section anchor="SR-ERO-ENCODING" title="SR-ERO"> <t>A PCEP speaker <bcp14>MAY</bcp14> set the A flag and include the Al
gorithm field as part of the Subobject Extension Block in an SR-ERO subobject if
<t>A PCEP speaker MAY set the A flag and include the Algorithm field as pa the S flag has been advertised in the SR-PCE-CAPABILITY sub-TLV by both PCEP sp
rt of the Subobject Extension Block in an SR-ERO subobject if the S flag has bee eakers.</t>
n advertised in SR-PCE-CAPABILITY Sub-TLV by both PCEP speakers.</t> <t>If the PCEP peer receives an SR-ERO subobject with the A flag set b
ut the S flag was not advertised in SR-PCE-CAPABILITY sub-TLV, then it <bcp14>MU
<t>If the PCEP peer receives an SR-ERO subobject with the A flag set, but ST</bcp14> consider the entire ERO as invalid, as described in <xref target="RFC
the S flag was not advertised in SR-PCE-CAPABILITY Sub-TLV, then it MUST conside 8664" sectionFormat="of" section="5.2.1" format="default"/>.</t>
r the entire ERO as invalid as described in <xref target="RFC8664" sectionFormat <t>The Subobject Extension Block field in the SR-ERO subobject <bcp14>
="of" section="5.2.1" />.</t> MUST</bcp14> be included after the optional SID, NAI, or SID structure, and the
length of the SR-ERO subobject <bcp14>MUST</bcp14> be increased by the size of t
<t>The Subobject Extension Block field in the SR-ERO subobject MUST be inc he Subobject Extension Block, as determined by the set of SEBFs.</t>
luded after the optional SID, NAI, or SID structure and the length of the SR-ERO <t>If the length and the A flag are not consistent, as specified in <x
subobject MUST be increased by the size of the Subobject Extension Block, as de ref target="SR-ERO-Subobject" format="default"/>, the PCEP peer <bcp14>MUST</bcp
termined by the set of SEBFs.</t> 14> consider the entire ERO invalid and <bcp14>MUST</bcp14> send a PCErr message
with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("
<t>If the length and the A flag are not consistent as specified in <xref t Malformed object").</t>
arget="SR-ERO-Subobject"/>, PCEP peer MUST consider the entire ERO invalid and M <t>If the SID value is absent (S flag is set to 1), the NAI value is p
UST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") resent (F flag is set to 0), and the Algorithm field is set (the A flag is set t
and Error-value = 11 ("Malformed object").</t> o 1), the PCC is responsible for choosing the SRv6-SID value based on values spe
cified in the NAI and Algorithm fields. If the PCC cannot find a SID index in th
<t>If the SID value is absent (S flag is set to 1), the NAI value is prese e SR-DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Rece
nt (F flag is set to 0) and the Algorithm field is set (the A flag is set to 1), ption of an invalid object") and Error-value = 14 ("Unknown SID").</t>
the PCC is responsible for choosing the SRv6-SID value based on values specifie </section>
d in NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, <section anchor="SRv6-ERO-ENCODING" numbered="true" toc="default">
it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid obje <name>SRv6-ERO</name>
ct") and Error-value = 14 ("Unknown SID").</t> <t>A PCEP speaker <bcp14>MAY</bcp14> set the A flag and include the Al
gorithm field in an SRv6-ERO subobject if the S flag has been advertised in SRv6
</section> -PCE-CAPABILITY sub-TLV by both PCEP speakers.</t>
<t>If the PCEP peer receives an SRv6-ERO subobject with the A flag set
<section anchor="SRv6-ERO-ENCODING" title="SRv6-ERO"> or with the SR-Algorithm included, but the S flag was not advertised in SRv6-PC
E-CAPABILITY sub-TLV, then it <bcp14>MUST</bcp14> consider the entire ERO as inv
<t>A PCEP speaker MAY set the A-flag and include the Algorithm field in an alid, as described in <xref target="RFC8664" sectionFormat="of" section="5.2.1"
SRv6-ERO subobject if the S flag has been advertised in SRv6-PCE-CAPABILITY sub format="default"/>.</t>
-TLV by both PCEP speakers.</t> <t>The Algorithm field in the SRv6-ERO subobject <bcp14>MUST</bcp14> b
e included in the position specified in <xref target="SRv6-ERO-Subobject" format
<t>If the PCEP peer receives SRv6-ERO subobject with the A flag set or wit ="default"/>; the length of the SRv6-ERO subobject is not impacted by the inclus
h the SR-Algorithm included, but the S flag was not advertised in SRv6-PCE-CAPAB ion of the Algorithm field.</t>
ILITY Sub-TLV, then it MUST consider the entire ERO as invalid as described in < <t>If the SRv6-SID value is absent (S flag is set to 1), the NAI value
xref target="RFC8664" sectionFormat="of" section="5.2.1" />.</t> is present (F flag is n), and the Algorithm field is set (the A flag is set to
1), the PCC is responsible for choosing the SRv6-SID value based on values speci
<t>The Algorithm field in the SRv6-ERO subobject MUST be included in the p fied in the NAI and Algorithm fields. If the PCC cannot find a SID index in the
osition specified in <xref target="SRv6-ERO-Subobject"/>, the length of the SRv6 SR-DB, it <bcp14>MUST</bcp14> send a PCErr message with Error-Type = 10 ("Recept
-ERO subobject is not impacted by the inclusion of the Algorithm field.</t> ion of an invalid object") and Error-value = 14 ("Unknown SID").</t>
</section>
<t>If the SRv6-SID value is absent (S flag is set to 1), the NAI value is
present (F flag is n) and the Algorithm field is set (the A flag is set to 1), t
he PCC is responsible for choosing the SRv6-SID value based on values specified
in NAI and Algorithm fields. If the PCC cannot find a SID index in the SR-DB, it
MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object
") and Error-value = 14 ("Unknown SID").</t>
</section>
</section> </section>
<section anchor="SR-ALGORITHM-CONSTRAINT" numbered="true" toc="default">
<name>SR-Algorithm Constraint</name>
<t>To signal a specific SR-Algorithm constraint to the PCE, the headend
<bcp14>MUST</bcp14> encode the SR-Algorithm TLV inside the LSPA object.</t>
<section anchor="SR-ALGORITHM-CONSTRAINT" title="SR-Algorithm Constraint"> <!--[rfced] For clarity, may we update "PCInitiate, PCUpd messages" to
"PCInitiate or PCUpd messages"?
<t>To signal a specific SR-Algorithm constraint to the PCE, the headend
MUST encode the SR-Algorithm TLV inside the LSPA object.</t>
<t>If a PCC receives an LSPA object with SR-Algorithm TLV as part of PCI
nitiate, PCUpd messages, then it MUST include LSPA object with SR-Algorithm TLV
in PCRpt message as part of intended-attribute-list.</t>
<t>If a PCE receives an LSPA object with SR-Algorithm TLV in PCRpt or PC
Req, then it MUST include the LSPA object with SR-Algorithm TLV in PCUpd message
, or PCRep message in case of an unsuccessful path computation based on rules de
scribed in <xref target="RFC5440" sectionFormat="of" section="7.11" />.</t>
<t>A PCEP peer that did not advertise the S flag in the Path Setup Type Original:
Sub-TLV corresponding to the LSP's PST, it MUST ignore the SR-Algorithm TLV on r If a PCC receives an LSPA object with SR-Algorithm TLV as part of
eceipt.</t> PCInitiate, PCUpd messages, then it MUST include LSPA object with SR-
Algorithm TLV in PCRpt message as part of intended-attribute-list.
<t>The PCE MUST NOT use Prefix SIDs associated with an SR-Algorithm othe Perhaps:
r than the one specified in the SR-Algorithm constraint. If a protected Adjacenc If a PCC receives an LSPA object with SR-Algorithm TLV as part of
y SID is used without an associated SR-Algorithm, there is a risk that the backu PCInitiate or PCUpd messages, then it MUST include LSPA object with SR-
p path may fail to forward traffic over parts of the topology that are not inclu Algorithm TLV in PCRpt message as part of intended-attribute-list.
ded in the specified SR-Algorithm. Consequently, it is NOT RECOMMENDED to use pr -->
otected Adjacency SIDs without an explicitly specified SR-Algorithm. If an Adjac
ency SID has an associated SR-Algorithm, the PCE MUST ensure that the SR-Algorit
hm matches the one specified in the SR-Algorithm constraint.</t>
<t>If a PCC receives an LSPA object with the SR-Algorithm TLV as part of
PCInitiate, PCUpd messages, then it <bcp14>MUST</bcp14> include an LSPA object
with the SR-Algorithm TLV in a PCRpt message as part of intended-attribute-list.
</t>
<t>If a PCE receives an LSPA object with the SR-Algorithm TLV in PCRpt o
r PCReq, then it <bcp14>MUST</bcp14> include the LSPA object with the SR-Algorit
hm TLV in a PCUpd message, or a PCRep message in case of an unsuccessful path co
mputation based on rules described in <xref target="RFC5440" sectionFormat="of"
section="7.11" format="default"/>.</t>
<t>A PCEP peer that did not advertise the S flag in the Path Setup Type
sub-TLV corresponding to the LSP's PST <bcp14>MUST</bcp14> ignore the SR-Algorit
hm TLV on receipt.</t>
<t>The PCE <bcp14>MUST NOT</bcp14> use Prefix SIDs associated with an SR
-Algorithm other than the one specified in the SR-Algorithm constraint. If a pro
tected Adjacency SID is used without an associated SR-Algorithm, there is a risk
that the backup path may fail to forward traffic over parts of the topology tha
t are not included in the specified SR-Algorithm. Consequently, it is <bcp14>NOT
RECOMMENDED</bcp14> to use protected Adjacency SIDs without an explicitly speci
fied SR-Algorithm. If an Adjacency SID has an associated SR-Algorithm, the PCE <
bcp14>MUST</bcp14> ensure that the SR-Algorithm matches the one specified in the
SR-Algorithm constraint.</t>
<t>Other SID types, such as Binding SIDs, are allowed. Furthermore, the inclusion of a path Binding SID (BSID) from another policy is permitted only if the path associated with that policy fully satisfies all the constraints of the current path computation.</t> <t>Other SID types, such as Binding SIDs, are allowed. Furthermore, the inclusion of a path Binding SID (BSID) from another policy is permitted only if the path associated with that policy fully satisfies all the constraints of the current path computation.</t>
<t>The specified SR-Algorithm constraint is applied to the end-to-end SR Policy path. Using different SR-Algorithm constraints or using winning FAD with different optimization metrics or constraints for the same SR-Algorithm in each domain or part of the topology in single path computation is out of the scope o f this document.</t>
<t>The specified SR-Algorithm constraint is applied to the end-to-end SR <!--[rfced] May we update the punctuation in the latter part of this
policy path. Using different SR-Algorithm constraints or using winning FAD with sentence to clarify that it is a list of what is used?
different optimization metric or constraints for same SR-Algorithm in each doma
in or part of the topology in single path computation is out of the scope of thi
s document.</t>
<t>If the PCE is unable to find a path with the given SR-Algorithm const
raint, it does not support a combination of specified constraints or if the FAD
contains constraints, optimization metric or other attributes, which the PCE doe
s not support or recognize, it MUST use an empty ERO in PCInitiate for LSP insta
ntiation or PCUpd message if an update is required or NO-PATH object in PCRep to
indicate that it was not able to find the valid path.</t>
<t>If the Algorithm field value is in the range 128-255, the PCE MUST pe
rform path computation according to the Flexible Algorithm procedures outlined i
n <xref target="FLEX-ALGO-COMPUTATION"/>. Otherwise, the PCE MUST adhere to the
path computation procedures with SID filtering defined in <xref target="SID-FILT
ERING-COMPUTATION"/>.</t>
<t>If the NO-PATH object is included in PCRep, then the PCE MAY include Original:
SR-Algorithm TLV to indicate constraint, which cannot be satisfied as described If the PCE is unable to find a path with the given SR-Algorithm
in <xref target="RFC5440" sectionFormat="of" section="7.5" />.</t> constraint, it does not support a combination of specified
constraints or if the FAD contains constraints, optimization metric
or other attributes, which the PCE does not support or recognize, it
MUST use an empty ERO in PCInitiate for LSP instantiation or PCUpd
message if an update is required or NO-PATH object in PCRep to
indicate that it was not able to find the valid path.
<t>SR-Algorithm does not replace the Objective Function defined in <xref Perhaps:
target="RFC5541"/>.</t> If the PCE is unable to find a path with the given SR-Algorithm
constraint, it does not support a combination of specified
constraints or if the FAD contains constraints, optimization metrics,
or other attributes, which the PCE does not support or recognize, it
MUST use an empty ERO in PCInitiate for LSP instantiation, a PCUpd
message if an update is required, or a NO-PATH object in PCRep to
indicate that it was not able to find the valid path.
-->
<section anchor="SID-FILTERING-COMPUTATION" title="Path Computation for <t>If the PCE is unable to find a path with the given SR-Algorithm const
SR-Algorithms 0-127"> raint, it does not support a combination of specified constraints, or if the FAD
<t>The SR-Algorithm constraint acts as a filter, restricting which SIDs contains constraints, optimization metrics, or other attributes, which the PCE
may be used as a result of the path computation function. Path computation is do does not support or recognize, it <bcp14>MUST</bcp14> use an empty ERO in PCInit
ne based on optimization metric type and constraints specified in the PCEP messa iate for LSP instantiation or PCUpd message if an update is required or NO-PATH
ge received from the PCC.</t> object in PCRep to indicate that it was not able to find the valid path.</t>
<t>The mechanism described in this section is applicable only to SR-Algo <t>If the Algorithm field value is in the range 128-255, the PCE <bcp14>
rithm values in the range 0-127. It is not applicable to Flexible Algorithms (ra MUST</bcp14> perform path computation according to the Flexible Algorithm proced
nge 128-255), which are handled as described in <xref target="FLEX-ALGO-COMPUTAT ures outlined in <xref target="FLEX-ALGO-COMPUTATION" format="default"/>. Otherw
ION"/>. Within the 0-127 range, currently defined algorithms are 0 (Shortest Pat ise, the PCE <bcp14>MUST</bcp14> adhere to the path computation procedures with
h First (SPF)) and 1 (Strict SPF) as introduced in <xref target="RFC8402" sectio SID filtering as defined in <xref target="SID-FILTERING-COMPUTATION" format="def
nFormat="of" section="3.1.1" />. Future algorithms defined within this range tha ault"/>.</t>
t do not require explicit PCEP extensions beyond the SR-Algorithm TLV may also u <t>If the NO-PATH object is included in PCRep, then the PCE <bcp14>MAY</
tilize this SID filtering approach. If a PCE implementation receives a request w bcp14> include the SR-Algorithm TLV to indicate constraint, which cannot be sati
ith an SR-Algorithm value in the 0-127 range that it does not support for path c sfied as described in <xref target="RFC5440" sectionFormat="of" section="7.5" fo
omputation, it MUST reject the PCEP message and send a PCErr message with Error- rmat="default"/>.</t>
Type 19 (Invalid Operation) and Error-Value TBD4 (Unsupported SR-Algorithm).</t> <t>SR-Algorithm does not replace the objective function defined in <xref
</section> target="RFC5541" format="default"/>.</t>
<section anchor="FLEX-ALGO-COMPUTATION" title="Path Computation for Flex <section anchor="SID-FILTERING-COMPUTATION" numbered="true" toc="default
ible Algorithms"> ">
<t>This section is applicable only to the Flexible Algorithms range of S <name>Path Computation for SR-Algorithms 0-127</name>
R-Algorithm values. The PCE performs Flexible Algorithm path computation based o <t>The SR-Algorithm constraint acts as a filter, restricting which SID
n topology information stored in its TED <xref target="RFC5440"/>. The TED is ex s may be used as a result of the path computation function. Path computation is
pected to be populated with necessary information, including Flexible Algorithm done based on optimization metric type and constraints specified in the PCEP mes
Definitions (FADs), node participation, and ASLA-specific link attributes, throu sage received from the PCC.</t>
gh standard mechanisms such as Interior Gateway Protocols (IGPs) with Traffic En <t>The mechanism described in this section is applicable only to SR-Al
gineering extensions or BGP-LS <xref target="RFC9552"/>.</t> gorithm values in the range 0-127. It is not applicable to Flexible Algorithms (
range 128-255), which are handled as described in <xref target="FLEX-ALGO-COMPUT
ATION" format="default"/>. Within the 0-127 range, currently defined algorithms
are 0 (Shortest Path First (SPF)) and 1 (Strict-SPF), as introduced in <xref tar
get="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>. Future algo
rithms defined within this range that do not require explicit PCEP extensions be
yond the SR-Algorithm TLV may also utilize this SID filtering approach. If a PCE
implementation receives a request with an SR-Algorithm value in the 0-127 range
that it does not support for path computation, it <bcp14>MUST</bcp14> reject th
e PCEP message and send a PCErr message with Error-Type 19 (Invalid Operation) a
nd Error-value 34 (Unsupported combination of constraints).</t>
</section>
<section anchor="FLEX-ALGO-COMPUTATION" numbered="true" toc="default">
<name>Path Computation for Flexible Algorithms</name>
<t>This section is applicable only to the Flexible Algorithms range of
SR-Algorithm values. The PCE performs Flexible Algorithm path computation based
on topology information stored in its TED <xref target="RFC5440" format="defaul
t"/>. The TED is expected to be populated with necessary information, including
Flexible Algorithm Definitions (FADs), node participation, and ASLA-specific lin
k attributes, through standard mechanisms, such as Interior Gateway Protocols (I
GPs) with Traffic Engineering extensions or BGP - Link State (BGP-LS) <xref targ
et="RFC9552" format="default"/>.</t>
<t>The PCE must follow the IGP Flexible Algorithm path computation logic as described in <xref target="RFC9350"/>. This includes performing the FAD sele ction as described in <xref target="RFC9350" sectionFormat="of" section="5.3" /> and other sections, determining the topology associated with specific Flexible Algorithm based on the FAD, the node participation <xref target="RFC9350" sectio nFormat="of" section="11" />, using ASLA-specific link attributes <xref target=" RFC9350" sectionFormat="of" section="12" />, and applying other rules for Flexib le Algorithm path calculation <xref target="RFC9350" sectionFormat="of" section= "13" />. While <xref target="RFC9350"/> defines the base procedures for IGP Flex ible Algorithms, these procedures are further extended by other documents such a s <xref target="RFC9843"/>, a PCE implementation may need to support these IGP e xtensions to allow use of specific constraints in FAD. <xref target="I-D.ietf-ls r-igp-flex-algo-reverse-affinity"/> created an IANA registry called "IGP Flex-Al gorithm Path Computation Rules Registry" within the "Interior Gateway Protocol ( IGP) Parameters" registry group with the ordered set of rules that MUST be used to prune links from the topology during the Flexible Algorithm path computation. </t> <!--[rfced] This note was left in the document:
<t>[Note to RFC Editor: The URL of the "IGP Flex-Algorithm Path Computat [Note to RFC Editor: The URL of the "IGP Flex-Algorithm Path
ion Rules Registry" IANA registry to be inserted once it will get created after Computation Rules Registry" IANA registry to be inserted once it will
approval of <xref target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity" />.] </t> get created after approval of
[I-D.ietf-lsr-igp-flex-algo-reverse-affinity].]
<t>The PCE MUST optimize the computed path based on the metric type spec Would you like an informative reference or an inline URL to be added
ified in the FAD. The optimization metric type included in PCEP messages from th for the "IGP Flex-Algorithm Path Computation Rules" registry
e PCC MUST be ignored. The PCE MUST use the metric type from the FAD in messages
sent to the PCC unless that metric type is not defined in PCEP or not supported
by the PCEP peer. It is allowed to use SID types other than Prefix SID (e.g., A
djacency or BSID), but only from nodes participating in the specified SR-Algorit
hm.</t>
<t>There are corresponding metric types in PCEP for IGP and TE metric fr Original:
om FAD introduced in <xref target="RFC9350"/>, but there were no corresponding m [I-D.ietf-lsr-igp-flex-algo-reverse-affinity] created an IANA
etric types defined for "Min Unidirectional Link Delay" from <xref target="RFC93 registry called "IGP Flex-Algorithm Path Computation Rules Registry"
50"/> and "Bandwidth Metric", "User Defined Metric" from <xref target="RFC9843"/ within the "Interior Gateway Protocol (IGP) Parameters" registry
>. <xref target="METRIC-TYPES"/> of this document is introducing them. Note that group with the ordered set of rules that MUST be used to prune links
the defined "Path Bandwidth Metric" is accumulative and is different from the B from the topology during the Flexible Algorithm path computation.
andwidth Object defined in <xref target="RFC5440"/>.</t>
<t>The PCE MUST use the constraints specified in the FAD and also constr Perhaps A (with an informative reference):
aints (except optimization metric type) directly included in PCEP messages from [RFC9917] created an IANA
the PCC. The PCE implementation MAY decide to ignore specific constraints receiv registry called "IGP Flex-Algorithm Path Computation Rules" [IANA-IGP-RULES]
ed from the PCC based on existing processing rules for PCEP Objects and TLVs, e. within the "Interior Gateway Protocol (IGP) Parameters" registry
g. P flag described in <xref target="RFC5440" sectionFormat="of" section="7.2" / group with the ordered set of rules that MUST be used to prune links
> and processing rules described in <xref target="RFC9753"/>. If the PCE does no from the topology during the Flexible Algorithm path computation.
t support a specified combination of constraints, it MUST fail path computation ...
and respond with a PCEP message with PCInitiate or PCUpd message with empty ERO [IANA-IGP-Rules]
or PCRep with NO-PATH object. PCC MUST NOT include constraints from FAD in PCEP IANA, "IGP Flex-Algorithm Path Computation Rules",
message sent to PCE as it can result in undesired behavior in various cases. PCE <https://www.iana.org/assignments/igp-parameters>.
SHOULD NOT include constraints from FAD in PCEP messages sent to PCC.</t>
<t>The combinations of the constraints specified in the FAD and constrai Perhaps B (with inline URL):
nts directly included in PCEP messages from the PCC may decrease the chance that [RFC9917] created an IANA
Flexible Algorithm specific Prefix SIDs represent an optimal path while satisfy registry called "IGP Flex-Algorithm Path Computation Rules"
ing all specified constraints, as a result a longer SID list may be required for <https://www.iana.org/assignments/igp-parameters> within the "Interior
the computed path. Adding more constraints on top of FAD requires complex path Gateway Protocol (IGP) Parameters" registry group with the ordered set
computation and may reduce the benefit of this scheme.</t> of rules that MUST be used to prune links from the topology during the
Flexible Algorithm path computation.
-->
<t>The PCE must follow the IGP Flexible Algorithm path computation log
ic as described in <xref target="RFC9350" format="default"/>. This includes perf
orming the FAD selection as described in <xref target="RFC9350" sectionFormat="o
f" section="5.3" format="default"/> and other sections, determining the topology
associated with specific a Flexible Algorithm based on the FAD, the node partic
ipation (<xref target="RFC9350" sectionFormat="of" section="11" format="default"
/>), using ASLA-specific link attributes (<xref target="RFC9350" sectionFormat="
of" section="12" format="default"/>), and applying other rules for Flexible Algo
rithm path calculation (<xref target="RFC9350" sectionFormat="of" section="13" f
ormat="default"/>). While <xref target="RFC9350" format="default"/> defines the
base procedures for IGP Flexible Algorithms, these procedures are further extend
ed by other documents, such as <xref target="RFC9843" format="default"/>; a PCE
implementation may need to support these IGP extensions to allow use of specific
constraints in FAD. <xref target="RFC9917" format="default"/> created an IANA r
egistry called "IGP Flex-Algorithm Path Computation Rules" within the "Interior
Gateway Protocol (IGP) Parameters" registry group with the ordered set of rules
that <bcp14>MUST</bcp14> be used to prune links from the topology during the Fle
xible Algorithm path computation.</t>
<t>The PCE <bcp14>MUST</bcp14> optimize the computed path based on the
metric type specified in the FAD. The optimization metric type included in PCEP
messages from the PCC <bcp14>MUST</bcp14> be ignored. The PCE <bcp14>MUST</bcp1
4> use the metric type from the FAD in messages sent to the PCC unless that metr
ic type is not defined in PCEP or not supported by the PCEP peer. It is allowed
to use SID types other than Prefix SID (e.g., Adjacency or BSID) but only from n
odes participating in the specified SR-Algorithm.</t>
<t>There are corresponding metric types in PCEP for IGP and TE metrics
from FAD introduced in <xref target="RFC9350" format="default"/>, but there wer
e no corresponding metric types defined for "Min Unidirectional Link Delay" from
<xref target="RFC9350" format="default"/> and "Bandwidth Metric" and "User-Defi
ned Metric" from <xref target="RFC9843" format="default"/>. <xref target="METRIC
-TYPES" format="default"/> of this document introduces them. Note that the defin
ed "Path Bandwidth Metric" is accumulative and is different from the BANDWIDTH O
bject defined in <xref target="RFC5440" format="default"/>.</t>
<t>The PCE <bcp14>MUST</bcp14> use the constraints specified in the FA
D and also constraints (except optimization metric type) directly included in PC
EP messages from the PCC. The PCE implementation <bcp14>MAY</bcp14> decide to ig
nore specific constraints received from the PCC based on existing processing rul
es for PCEP Objects and TLVs, e.g., the P flag described in <xref target="RFC544
0" sectionFormat="of" section="7.2" format="default"/> and processing rules desc
ribed in <xref target="RFC9753" format="default"/>. If the PCE does not support
a specified combination of constraints, it <bcp14>MUST</bcp14> fail path computa
tion and respond with a PCEP message with a PCInitiate or PCUpd message with an
empty ERO or PCRep with NO-PATH object. The PCC <bcp14>MUST NOT</bcp14> include
constraints from the FAD in the PCEP message sent to the PCE, as it can result i
n undesired behavior in various cases. The PCE <bcp14>SHOULD NOT</bcp14> include
constraints from the FAD in PCEP messages sent to the PCC.</t>
<t>The combinations of the constraints specified in the FAD and constr
aints directly included in PCEP messages from the PCC may decrease the chance th
at Flexible-Algorithm-specific Prefix SIDs represent an optimal path while satis
fying all specified constraints; as a result, a longer SID list may be required
for the computed path. Adding more constraints on top of the FAD requires compl
ex path computation and may reduce the benefit of this scheme.</t>
</section> </section>
</section> </section>
<section anchor="NEW-METRIC-TYPES" title="Metric types"> <section anchor="NEW-METRIC-TYPES" numbered="true" toc="default">
<t>All the rules of processing the METRIC object as explained in <xref t <name>Metric Types</name>
arget="RFC5440"/> and <xref target="RFC8233"/> are applicable to the metric type <t>All the rules of processing the METRIC object as explained in <xref t
s defined in this document.</t> arget="RFC5440" format="default"/> and <xref target="RFC8233" format="default"/>
are applicable to the metric types defined in this document.</t>
</section> </section>
</section> </section>
<section title="Manageability Considerations" numbered="true" toc="default"> <section numbered="true" toc="default">
<t>All manageability requirements and considerations listed in <xref targe <name>Manageability Considerations</name>
t="RFC5440"/>, <xref target="RFC8231"/>, <xref target="RFC8281"/>, <xref target=
"RFC8664"/> and <xref target="RFC9603"/> apply to the PCEP extensions defined in <!--[rfced] We note that RFC 8281 does not list any "manageability
this document. In addition, the requirements and considerations listed in this requirements and considerations". All other RFCs in this sentence
section apply.</t> have a specific section about that topic. May we remove RFC 8281
<section title="Control of Function and Policy" numbered="true" toc="defau from the list?
lt">
<t>A PCE or PCC implementation MAY allow the capability of supporting th Original:
e PCEP extensions introduced in this document to be enabled or disabled as part All manageability requirements and considerations listed in
of the global configuration. By default, this capability SHOULD be enabled.</t> [RFC5440], [RFC8231], [RFC8281], [RFC8664] and [RFC9603] apply to the
PCEP extensions defined in this document.
-->
<t>All manageability requirements and considerations listed in <xref targe
t="RFC5440" format="default"/>, <xref target="RFC8231" format="default"/>, <xref
target="RFC8281" format="default"/>, <xref target="RFC8664" format="default"/>,
and <xref target="RFC9603" format="default"/> apply to the PCEP extensions defi
ned in this document. In addition, the requirements and considerations listed in
this section apply.</t>
<section numbered="true" toc="default">
<name>Control of Function and Policy</name>
<t>A PCE or PCC implementation <bcp14>MAY</bcp14> allow the capability o
f supporting the PCEP extensions introduced in this document to be enabled or di
sabled as part of the global configuration. By default, this capability <bcp14>S
HOULD</bcp14> be enabled.</t>
</section> </section>
<section title="Information and Data Models" numbered="true" toc="default" <section numbered="true" toc="default">
> <name>Information and Data Models</name>
<t>An implementation SHOULD allow the operator to view the capability de <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view th
fined in this document. Sections <xref target="RFC9826" sectionFormat="bare" sec e capability defined in this document. Sections <xref target="RFC9826" sectionFo
tion="4.1"/> and <xref target="RFC9826" sectionFormat="bare" section="4.1.1"/> o rmat="bare" section="4.1" format="default"/> and <xref target="RFC9826" sectionF
f <xref target="RFC9826"/> should be extended to include the capabilities introd ormat="bare" section="4.1.1" format="default"/> of <xref target="RFC9826" format
uced in Sections <xref target="SR-CAP-FLAG" sectionFormat="bare"/> and <xref tar ="default"/> should be extended to include the capabilities introduced in Sectio
get="SRv6-CAP-FLAG" sectionFormat="bare"/> for the PCEP peer.</t> ns <xref target="SR-CAP-FLAG" format="counter"/> and <xref target="SRv6-CAP-FLAG
</section> " format="counter"/> for the PCEP peer.</t>
<section title="Liveness Detection and Monitoring" numbered="true" toc=" </section>
default"> <section numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<t>This document does not define any new mechanism that impacts the live ness detection and monitoring of PCEP.</t> <t>This document does not define any new mechanism that impacts the live ness detection and monitoring of PCEP.</t>
</section>
<section title="Verify Correct Operations" numbered="true" toc="default">
<t>An implementation SHOULD also allow the operator to view FADs, which
may be used in Flexible Algorithm path computation defined in <xref target="FLEX
-ALGO-COMPUTATION"/>.</t>
<t>An implementation SHOULD allow the operator to view nodes participati
ng in the specified SR-Algorithm.</t>
</section> </section>
<section title="Requirements on Other Protocols and Functional Com <section numbered="true" toc="default">
ponents" numbered="true" toc="default"> <name>Verify Correct Operations</name>
<t>An implementation <bcp14>SHOULD</bcp14> also allow the operator to vi
ew FADs, which may be used in Flexible Algorithm path computation as defined in
<xref target="FLEX-ALGO-COMPUTATION" format="default"/>.</t>
<t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view no
des participating in the specified SR-Algorithm.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements on Other Protocols and Functional Components</name>
<t>This document does not put new requirements but relies on the necessa ry IGP extensions.</t> <t>This document does not put new requirements but relies on the necessa ry IGP extensions.</t>
</section> </section>
<section title="Impact On Network Operations" numbered="true" toc="default <section numbered="true" toc="default">
"> <name>Impact on Network Operations</name>
<t>This document inherits considerations from documents describing IGP F <t>This document inherits considerations from documents describing IGP F
lexible Algorithm - for example <xref target="RFC9350"/> and <xref target="RFC98 lexible Algorithm -- for example, <xref target="RFC9350" format="default"/> and
43"/>.</t> <xref target="RFC9843" format="default"/>.</t>
</section> </section>
</section> </section>
<section title="Operational Considerations" numbered="true" toc="default"> <section numbered="true" toc="default">
<t>This document inherits operational considerations from documents desc <name>Operational Considerations</name>
ribing IGP Flexible Algorithm - for example <xref target="RFC9350"/> and <xref t <t>This document inherits operational considerations from documents descri
arget="RFC9843"/>.</t> bing IGP Flexible Algorithm -- for example, <xref target="RFC9350" format="defau
lt"/> and <xref target="RFC9843" format="default"/>.</t>
</section> </section>
<section 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 <section numbered="true" toc="default">
working groups to assign due consideration to documents that have the <name>Security Considerations</name>
benefit of running code, which may serve as evidence of valuable <t>The security considerations described in <xref target="RFC5440" format=
experimentation and feedback that have made the implemented protocols "default"/>,
more mature. It is up to the individual working groups to use this <xref target="RFC8231" format="default"/>, <xref target="RFC8253" format="
information as they see fit".</t> default"/>, <xref target="RFC8281" format="default"/>, <xref target="RFC8664" fo
<section anchor="Cisco" title="Cisco"> rmat="default"/>, <xref target="RFC9603" format="default"/>, and <xref target="R
<t><list style="symbols"> FC9350" format="default"/> apply to the extensions described in this document as
<t>Organization: Cisco Systems</t> well.</t>
<t>Implementation: IOS-XR PCC and PCE.</t> <t>Note that this specification introduces the possibility of computing pa
<t>Description: SR-MPLS part with experimental codepoints.</t> ths by the PCE based on Flexible-Algorithm-related topology attributes and based
<t>Maturity Level: Production.</t> on the metric type and constraints from the FAD. This creates additional vulner
<t>Coverage: Partial.</t> abilities, which are already described for the path computation done by IGP, lik
<t>Contact: ssidor@cisco.com</t> e those described in the Security Considerations section of <xref target="RFC935
</list></t> 0" format="default"/> but which are also applicable to path computation done by
the PCE. Hence, securing the PCEP session using Transport Layer Security (TLS) <
xref target="RFC8253" format="default"/> <xref target="RFC9916" format="default"
/> is <bcp14>RECOMMENDED</bcp14> as per the recommendations
and best current practices described in <xref target="RFC9325" format="defaul
t"/>.</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="SR-CAPABILITY-FLAG" numbered="true" toc="default">
<name>SR Capability Flag</name>
<t>IANA maintains a registry named "SR Capability Flag Field" within the
"Path Computation Element Protocol
(PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABI
LITY sub-TLV. IANA has registered the following:</t>
<table anchor="SR-CAPABILITY-FLAG-value" align="center">
<thead>
<tr>
<th align="center">Bit</th>
<th align="left">Description </th>
<th align="left">Reference </th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">5</td>
<td align="left">SR-Algorithm Capability</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Huawei" title="Huawei"> <section anchor="SRv6-CAPABILITY-FLAG" numbered="true" toc="default">
<t><list style="symbols"> <name>SRv6 PCE Capability Flag</name>
<t>Organization: Huawei</t> <t>IANA maintains a registry named "SRv6 Capability Flag Field" within t
<t>Implementation: NE Series Routers</t> he "Path Computation Element Protocol
<t>Description: SR Policy with SR Algorithm.</t> (PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILI
<t>Maturity Level: Production.</t> TY sub-TLV. IANA has registered the following:</t>
<t>Coverage: Partial.</t> <table anchor="SRv6-CAPABILITY-FLAG-value" align="center">
<t>Contact: pengshuping@huawei.com</t> <thead>
</list></t> <tr>
<th align="center">Bit</th>
<th align="left">Description </th>
<th align="left">Reference </th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">13</td>
<td align="left">SR-Algorithm Capability</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
</section> <section anchor="SR-ERO-FLAG" numbered="true" toc="default">
<name>SR-ERO Flag</name>
<section title="Security Considerations" numbered="true" toc="default"> <t>IANA maintains a registry named "SR-ERO Flag Field" within the "Path
<t>The security considerations described in <xref target="RFC5440"/> Computation Element Protocol
, (PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobj
<xref target='RFC8231'/>, <xref target='RFC8253'/>, <xref target='RFC8281' ect. IANA has registered the following:</t>
/>, <xref target="RFC8664"/>, <xref target="RFC9603"/> and <xref target='RFC9350 <table anchor="SR-ERO-FLAG-value" align="center">
'/> apply to the extensions described in this document as well.</t> <thead>
<t>Note that this specification introduces the possibility of comput <tr>
ing paths by the PCE based on Flexible Algorithm related topology attributes and <th align="center">Bit</th>
based on the metric type and constraints from FAD. This creates additional vuln <th align="left">Description </th>
erabilities, which are already described for the path computation done by IGP li <th align="left">Reference </th>
ke those described in Security Considerations section of <xref target='RFC9350'/ </tr>
>, but which are also applicable to path computation done by PCE. Hence, securin </thead>
g the PCEP session using Transport Layer Security (TLS) <xref target="RFC8253"/> <tbody>
<xref target='I-D.ietf-pce-pceps-tls13'/> is RECOMMENDED as per the recommendati <tr>
ons <td align="center">7</td>
and best current practices described in <xref target="RFC9325"/>.</t> <td align="left">SR-Algorithm Flag (A)</td>
</section> <td align="left">RFC 9933</td>
</tr>
<section anchor="IANA" title="IANA Considerations"> </tbody>
</table>
<section anchor="SR-CAPABILITY-FLAG" title="SR Capability Flag">
<t>IANA maintains a registry, named "SR Capability Flag Field", within t
he "Path Computation Element Protocol
(PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABI
LITY TLV. IANA is requested to confirm the following early allocation:</t>
<texttable anchor="SR-CAPABILITY-FLAG-value" style="none" suppress-title
="true">
<ttcol align="center" width='15%'>Bit</ttcol>
<ttcol align="left" width='30%'>Description </ttcol>
<ttcol align="left" width='55%'>Reference </ttcol>
<c>5</c><c>SR-Algorithm Capability</c><c>This document</c>
</texttable>
</section> </section>
<section anchor="SRv6-ERO-FLAG" numbered="true" toc="default">
<section anchor="SRv6-CAPABILITY-FLAG" title="SRv6 PCE Capability Flag"> <name>SRv6-ERO Flag</name>
<t>IANA maintains a registry named "SRv6-ERO Flag Field" within the "Pat
<t>IANA maintains a registry, named "SRv6 Capability Flag Field", within h Computation Element Protocol
the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SRv6-ERO subo
(PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILI bject. IANA has registered the following:</t>
TY sub-TLV. IANA is requested to <table anchor="SRv6-ERO-FLAG-value" align="center">
make the following assignment:</t> <thead>
<tr>
<texttable anchor="SRv6-CAPABILITY-FLAG-value" style="none" suppress-tit <th align="center">Bit</th>
le="true"> <th align="left">Description </th>
<ttcol align="center" width='15%'>Bit</ttcol> <th align="left">Reference </th>
<ttcol align="left" width='30%'>Description </ttcol> </tr>
<ttcol align="left" width='55%'>Reference </ttcol> </thead>
<c>TBD1</c><c>SR-Algorithm Capability</c><c>This document</c> <tbody>
</texttable> <tr>
<td align="center">7</td>
<td align="left">SR-Algorithm Flag (A)</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="TLV-Type" numbered="true" toc="default">
<section anchor="SR-ERO-FLAG" title="SR-ERO Flag"> <name>PCEP TLV Types</name>
<t>IANA maintains a registry named "PCEP TLV Type Indicators" within the
<t>IANA maintains a registry, named "SR-ERO Flag Field", within the "Pat "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has reg
h Computation Element Protocol istered the following TLV type for the new LSPA TLV specified in this document.<
(PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobj /t>
ect. IANA is requested to confirm the following early allocation:</t> <table anchor="LSPA-TLV-type" align="center">
<thead>
<texttable anchor="SR-ERO-FLAG-value" style="none" suppress-title="true" <tr>
> <th align="center">Value</th>
<ttcol align="center" width='15%'>Bit</ttcol> <th align="left">Description </th>
<ttcol align="left" width='30%'>Description </ttcol> <th align="left">Reference </th>
<ttcol align="left" width='55%'>Reference </ttcol> </tr>
<c>7</c><c>SR-Algorithm Flag (A)</c><c>This document</c> </thead>
</texttable> <tbody>
<tr>
<td align="center">66</td>
<td align="left">SR-Algorithm</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Metric-Types" numbered="true" toc="default">
<name>Metric Types</name>
<t>IANA maintains a registry named "METRIC Object T Field" within the "P
ath Computation Element Protocol (PCEP) Numbers" registry group. IANA has regist
ered these codepoints as follows:</t>
<table anchor="Metric-types" 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">22</td>
<td align="left">Path Min Delay Metric</td>
<td align="left">RFC 9933</td>
</tr>
<tr>
<td align="center">23</td>
<td align="left">P2MP Path Min Delay Metric</td>
<td align="left">RFC 9933</td>
</tr>
<tr>
<td align="center">24</td>
<td align="left">Path Bandwidth Metric</td>
<td align="left">RFC 9933</td>
</tr>
<tr>
<td align="center">25</td>
<td align="left">P2MP Path Bandwidth Metric</td>
<td align="left">RFC 9933</td>
</tr>
<tr>
<td align="center">128-255</td>
<td align="left">User-Defined Metric </td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section>
<section anchor="PCEP-Error-Object" numbered="true" toc="default">
<name>PCEP-Error Object</name>
<t>IANA has registered the following Error-Types and Error-values within
the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computatio
n Element Protocol (PCEP) Numbers" registry group.</t>
<table anchor="PCEP-Error-type" align="center">
<thead>
<tr>
<th align="center">Error-Type</th>
<th align="left">Meaning </th>
<th align="left">Error-value </th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">19</td>
<td align="left">Invalid Operation</td>
<td align="left">33: Attempted use of SR-Algorithm without adverti
sed capability</td>
<td align="left">RFC 9933</td>
</tr>
<tr>
<td align="center"/>
<td align="left"/>
<td align="left">34: Unsupported combination of constraints</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle>
<back>
<references>
<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.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
471.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
233.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
570.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
665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
667.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
603.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
753.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
843.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
917.xml"/>
<section anchor="SRv6-ERO-FLAG" title="SRv6-ERO Flag"> <!-- [I-D.ietf-pce-pceps-tls13] -> [RFC9916]
companion doc RFC9916
<t>IANA maintains a registry, named "SRv6-ERO Flag Field", within the "P -->
ath Computation Element Protocol <reference anchor="RFC9916" target="https://www.rfc-editor.org/info/rfc9916">
(PCEP) Numbers" registry group to manage the Flags field of the SRv6-ERO subo <front>
bject. IANA is requested to <title>Updates for PCEPS: TLS Connection Establishment Restrictions</title>
make the following assignment:</t> <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<organization>Huawei</organization>
</author>
<author initials="S." surname="Turner" fullname="Sean Turner">
<organization>sn3rd</organization>
</author>
<author initials="R." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC</organization>
</author>
<date month='February' year='2026'/>
</front>
<seriesInfo name="RFC" value="9916"/>
<seriesInfo name="DOI" value="10.17487/RFC9916"/>
</reference>
<texttable anchor="SRv6-ERO-FLAG-value" style="none" suppress-title="tru </references>
e"> <references>
<ttcol align="center" width='15%'>Bit</ttcol> <name>Informative References</name>
<ttcol align="left" width='30%'>Description </ttcol> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<ttcol align="left" width='55%'>Reference </ttcol> 826.xml"/>
<c>TBD2</c><c>SR-Algorithm Flag (A)</c><c>This document</c> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</texttable> 031.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
541.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.9
479.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
492.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<section anchor="TLV-Type" title="PCEP TLV Types"> <!-- [rfced] Regarding [IEEE.754.2008], this IEEE Standard has been
superseded by a newer version published in 2019
(https://ieeexplore.ieee.org/document/8766229). Would you like us to
update this reference to point to the most current version?
<t>IANA maintains a registry, named "PCEP TLV Type Indicators", within t Current:
he "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is re [IEEE.754.2008]
quested to confirm the early allocation of a new TLV type for the new LSPA TLV s IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
pecified in this document.</t> Std 754-2008, DOI 10.1109/IEEESTD.2008.4610935, August
2008, <https://doi.org/10.1109/IEEESTD.2008.4610935>.
Perhaps:
[IEEE.754.2019]
IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
<https://doi.org/10.1109/IEEESTD.2019.8766229>.
-->
<reference anchor="IEEE.754.2008" quoteTitle="true" target="https://doi.
org/10.1109/IEEESTD.2008.4610935" derivedAnchor="IEEE.754.2008">
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="August" year="2008"/>
</front>
<seriesInfo name="IEEE Std" value="754-2008"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4610935"/>
</reference>
<!-- Note to PE: XML for most current version of [IEEE.754.2008]
<reference anchor="IEEE.754.2019">
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="July" year="2019"/>
</front>
<seriesInfo name="IEEE Std" value="754-2019"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2019.8766229"/>
</reference>
-->
<reference anchor="IANA-ALGORITHM-TYPES" target="https://www.iana.org/as
signments/igp-parameters">
<front>
<title>IGP Algorithm Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references>
<texttable anchor="LSPA-TLV-type" style="none" suppress-title="true"> <section anchor="Acknowledgements" numbered="false" toc="default">
<ttcol align="center" width='15%'>Type</ttcol> <name>Acknowledgements</name>
<ttcol align="left" width='30%'>Description </ttcol> <t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the
<ttcol align="left" width='55%'>Reference </ttcol> document and for their contributions and suggestions.</t>
<c>66</c><c>SR-Algorithm</c><c>This document</c> <t>The authors would like to thank <contact fullname="Adrian Farrel"/>, <c
</texttable> ontact
fullname="Aijun Wang"/>, <contact fullname="Alexey Melnikov"/>, <contact
fullname="Boris Khasanov"/>, <contact fullname="Deb Cooley"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Gunter Van de Velde"/>,
<contact fullname="Jie Dong"/>, <contact fullname="Ketan Talaulikar"/>,
<contact fullname="Mahesh Jethanandani"/>, <contact fullname="Marina
Fizgeer"/>, <contact fullname="Mike Bishop"/>, <contact
fullname="Mohamed Boucadair"/>, <contact fullname="Nagendra Nainar"/>,
<contact fullname="Rakesh Gandhi"/>, <contact fullname="Russ White"/>,
and <contact fullname="Shraddha Hegde"/> for review and suggestions.</t>
</section>
</section> <section numbered="false" toc="default">
<name>Contributors</name>
<section anchor="Metric-Types" title="Metric Types"> <contact fullname="Mike Koldychev">
<organization>Ciena Corporation</organization>
<address>
<email>mkoldych@proton.me</email>
</address>
</contact>
<t>IANA maintains a registry for "METRIC Object T Field" within the "Pat <contact fullname="Zafar Ali">
h Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested <organization>Cisco Systems, Inc.</organization>
to confirm <address>
the early allocated codepoints as follows:</t> <email>zali@cisco.com</email>
</address>
</contact>
<texttable anchor="Metric-types" style="none" suppress-title="true"> <contact fullname="Stephane Litkowski">
<ttcol align="center" width='15%'>Type</ttcol> <organization>Cisco Systems, Inc.</organization>
<ttcol align="left" width='30%'>Description </ttcol> <address>
<ttcol align="left" width='55%'>Reference </ttcol> <email>slitkows.ietf@gmail.com</email>
<c>22</c><c>Path Min Delay Metric</c><c>This document</c> </address>
<c>23</c><c>P2MP Path Min Delay Metric</c><c>This document</c> </contact>
<c>24</c><c>Path Bandwidth Metric</c><c>This document</c>
<c>25</c><c>P2MP Path Bandwidth Metric</c><c>This document</c>
<c>128-255</c><c>User Defined Metric </c><c>This document</c>
</texttable>
</section>
<section anchor="PCEP-Error-Object" title="PCEP-Error Object"> <contact fullname="Siva Sivabalan">
<organization>Ciena</organization>
<address>
<email>msiva282@gmail.com</email>
</address>
</contact>
<t>IANA is requested to allocate new error types and error values within <contact fullname="Tarek Saad">
the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers <organization>Cisco Systems, Inc.</organization>
registry for the following errors.</t> <address>
<email>tsaad.net@gmail.com</email>
</address>
</contact>
<texttable anchor="PCEP-Error-type" style="none" suppress-title="true"> <contact fullname="Mahendra Singh Negi">
<ttcol align="center" width='15%'>Error-Type</ttcol> <organization>RtBrick Inc</organization>
<ttcol align="left" width='30%'>Meaning </ttcol> <address>
<ttcol align="left" width='55%'>Error-Value </ttcol> <email>mahend.ietf@gmail.com</email>
<ttcol align='left' >Reference</ttcol> </address>
<c>19</c><c>Invalid Operation</c><c>TBD3:Attempted use of SR-Algorithm </contact>
without advertised capability</c><c>This Document</c>
<c></c><c></c><c>TBD4:Unsupported combination of constraints</c><c>Thi
s Document</c>
</texttable>
</section> <contact fullname="Tom Petch">
<address>
<email>ietfc@btconnect.com</email>
</address>
</contact>
</section> </section>
</middle> </back>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5440"?>
<?rfc include="reference.RFC.7471"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8231"?>
<?rfc include="reference.RFC.8233"?>
<?rfc include="reference.RFC.8253"?>
<?rfc include="reference.RFC.8281"?>
<?rfc include="reference.RFC.8402"?>
<?rfc include="reference.RFC.8570"?>
<?rfc include="reference.RFC.8664"?>
<?rfc include="reference.RFC.8665"?>
<?rfc include="reference.RFC.8667"?>
<?rfc include="reference.RFC.9256"?>
<?rfc include="reference.RFC.9350"?>
<?rfc include="reference.RFC.9603"?>
<?rfc include="reference.RFC.9753"?>
<?rfc include="reference.RFC.9843"?>
<?rfc include="reference.I-D.ietf-lsr-igp-flex-algo-reverse-affinity"?>
<?rfc include="reference.I-D.ietf-pce-pceps-tls13"?>
</references> <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<references title="Informative References"> <!--[rfced] Terminology
<?rfc include="reference.RFC.9826"?>
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.4655"?>
<?rfc include="reference.RFC.5541"?>
<?rfc include="reference.RFC.7942"?>
<?rfc include="reference.RFC.9325"?>
<?rfc include="reference.RFC.9479"?>
<?rfc include="reference.RFC.9492"?>
<?rfc include="reference.RFC.9552"?>
<reference anchor="IEEE.754.2008" quoteTitle="true" target="https://doi.org/10.1
109/IEEESTD.2008.4610935" derivedAnchor="IEEE.754.2008">
<front>
<title>IEEE Standard for Floating-Point Arithmetic</title>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4610935"/>
<seriesInfo name="IEEE" value="IEEE Std 754-2008"/>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author>
<date month="August" year="2008"/>
</front>
</reference>
<reference anchor="IANA-ALGORITHM-TYPES">
<front>
<title>Interior Gateway Protocol (IGP) Parameters - IGP Algorithm Types</tit
le>
<author>
<organization>IANA</organization>
</author>
<date year="n/a"/>
</front>
<seriesInfo name="IANA Registry" value="https://www.iana.org/assignments/igp-p
arameters/igp-parameters.xhtml#algorithm-type"/>
</reference>
</references>
<section anchor="Acknowledgement" title="Acknowledgement"> a) We note that "object" and "Object" are both used throughout the document.
<t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the document and Please review the terms below and let us know if/how this capitalization should
for his contributions and suggestions.</t> be made consistent.
<t>
Would like to thank Adrian Farrel, Aijun Wang, Alexey Melnikov, Boris Khasanov,
Deb Cooley, Eric Vyncke, Gunter Van de Velde, Jie Dong, Ketan Talaulikar, Mahesh
Jethanandani, Marina Fizgeer, Mike Bishop, Mohamed Boucadair, Nagendra Nainar,
Rakesh Gandhi, Russ White, Shraddha Hegde for review and suggestions.
</t>
</section> <!-- Acknowledgement -->
<section title="Contributors"> METRIC object vs. METRIC Object
LSPA Object vs. LSPA object
PCEP Object
LSP Object
NO-PATH object
BANDWIDTH Object (FYI - We capitalized "Bandwidth" to reflect usage in RFC 5440
.)
<t><figure><artwork> b) Similar to above, we note that "metric" and "Metric" are both used throughout
Mike Koldychev the document. Please review the terms below and let us know if/how this
Ciena Corporation capitalization should be made consistent.
Email: mkoldych@proton.me
Zafar Ali Path Min Delay metric vs. Path Min Delay Metric
Cisco Systems, Inc. P2MP Path Min Delay metric vs. P2MP Path Min Delay Metric
Email: zali@cisco.com Path Bandwidth Metric vs. Path Bandwidth metric
P2MP Path Bandwidth Metric vs. P2MP Path Bandwidth metric
User-defined metric vs. User Defined metric vs. User Defined Metric
Link Delay metric
Path Min Link Delay metric
Min Link Delay metric
P2P Path Min Delay metric
Bandwidth Metric vs. Bandwidth metric vs. bandwidth metric
P2P Bandwidth metric
-->
Stephane Litkowski <!--[rfced] Abbreviations
Cisco Systems, Inc.
Email: slitkows.ietf@gmail.com
Siva Sivabalan a) Both the expansion and the acronym for the following terms are used
Ciena throughout the document. Would you like to update to using the expansion
Email: msiva282@gmail.com upon first usage and the acronym for the rest of the document for
consistency?
Tarek Saad Binding SID (BSID)
Cisco Systems, Inc. Interior Gateway Protocol (IGP)
Email: tsaad.net@gmail.com Path Setup Type (PST)
Segment Routing (SR)
Mahendra Singh Negi b) FYI - We have expanded the following abbreviation per Section 3.6 of
RtBrick Inc RFC 7322 ("RFC Style Guide"). Please review each expansion in the document
Email: mahend.ietf@gmail.com carefully to ensure correctness.
Tom Petch BGP - Link State (BGP-LS)
Email: ietfc@btconnect.com -->
</artwork></figure></t>
</section> <!-- Contributors --> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
</back> 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. 117 change blocks. 
1081 lines changed or deleted 1505 lines changed or added

This html diff was produced by rfcdiff 1.48.