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"/>
<date/> <area>RTG</area>
<workgroup>pce</workgroup>
<workgroup>PCE Working Group</workgroup> <keyword>Prefix-SID Algorithm</keyword>
<keyword>Flexible Algorithm</keyword>
<keyword>IGP Algorithm Types</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 <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 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 ers (SIDs) and SR-Algorithms. An SR-Algorithm associated with a SID defines the
path computation algorithm used by Interior Gateway Protocols (IGPs).</t> path computation algorithm used by 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 (PSTs).</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">
<section title="Terminology"> <name>Terminology</name>
<t>This document uses the following terms defined in <xref target="RFC5440" <t>This document uses the following terms defined in <xref target="RFC5440
/>: ERO, LSPA, PCC, " format="default"/>: Explicit Route Object (ERO), Label Switched Path Attribute
PCE, PCEP, PCEP Peer, PCEP speaker, RRO, TED.</t> s (LSPA), Path Computation Client (PCC), Path Computation Element (PCE), Path Co
mputation Element Communication Protocol (PCEP), PCEP peer, PCEP speaker, Record
<t>This document uses the following terms defined in <xref target="RFC5440" Route Object (RRO), and Traffic Engineering Database (TED).</t>
/>: Explicit Route Object (ERO), Label Switched Path Attributes (LSPA), Path Com <t>This document uses the following term defined in <xref target="RFC3031"
putation Client (PCC), Path Computation Element (PCE), Path Computation Element format="default"/>: Label Switched Path (LSP).</t>
Communication Protocol (PCEP), PCEP Peer, PCEP speaker, Record Route Object (RRO <t>This document uses the following term defined in <xref target="RFC9479"
), and Traffic Engineering Database (TED).</t> format="default"/> and <xref target="RFC9492" format="default"/>: Application-S
pecific Link Attributes (ASLA).</t>
<t>This document uses the following term defined in <xref target="RFC3031"/ <t>This document uses the following terms defined in <xref target="RFC8664
>: Label Switched Path (LSP).</t> " format="default"/>: Node or Adjacency Identifier (NAI) and Segment Routing Dat
abase (SR-DB).</t>
<t>This document uses the following term defined in <xref target="RFC9479"/ <t>This document uses the following terms defined in <xref target="RFC9350
> and <xref target="RFC9492"/>: Application-Specific Link Attributes (ASLA).</t> " format="default"/>: Flexible Algorithm Definition (FAD) and winning FAD.</t>
<t> Note that the base PCEP specification <xref target="RFC4655" format="d
<t>This document uses the following terms defined in <xref target="RFC8664" efault"/> originally defined the use of the PCE architecture for MPLS and GMPLS
/>: Node or Adjacency Identifier (NAI) and Segment Routing Database (SR-DB).</t> networks
with LSPs instantiated using the RSVP-TE signaling protocol. Over time, sup
<t>This document uses the following terms defined in <xref target="RFC9350" port for additional PSTs, such as
/>: Flexible Algorithm Definition (FAD) and Winning FAD.</t> SRv6, has been introduced <xref target="RFC9603" format="default"/>. The te
rm "LSP" is used extensively in PCEP specifications and, in the
<t> Note that the base PCEP specification <xref target="RFC4655"/> origina
lly 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"/>. The term "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 IGPs, in
<t>A primary motivation for these extensions is to enable the PCE to lever cluding Flexible Algorithms. Aligning PCE path computation with these IGP algori
age the path computation logic and topological information derived from Interior thms enables network operators to obtain paths that are congruent with the under
Gateway Protocols (IGPs), including Flexible Algorithms. Aligning PCE path comp lying routing behavior, which can result in segment lists with a reduced number
utation with these IGP algorithms enables network operators to obtain paths that of SIDs. The support for SR-Algorithm constraints in PCE path computation simpli
are congruent with the underlying routing behavior, which can result in segment fies the deployment and management of Flexible Algorithm paths in multi-domain n
lists with a reduced number of SIDs. The support for SR-Algorithm constraints i etwork scenarios.</t>
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 IGP domains, each using the same FAD but with d
iffering 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 PST 1 (Segment Routing
prior to the introduction of this extension.</t> ) <xref target="RFC8664" format="default"/>. It does not indicate support for th
</list> ese extensions for other PSTs. If the S flag is set to 0, behavior reverts to th
e procedures defined in existing specifications prior to the introduction of thi
s 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 PST 3 (SRv6) <xref target="RFC9603" format="default
other Path Setup Types. If the S flag is set to 0, behavior reverts to the proce "/>. It does not indicate support for these extensions for other PSTs. If the S
dures defined in existing specifications prior to the introduction of this exten flag is set to 0, behavior reverts to the procedures defined in existing specifi
sion.</t> cations 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">
<t>Unassigned (24 bits): This field is reserved for future use and MUST be set <dt>Unassigned (24 bits):</dt><dd>This field is reserved for future
to zero when sending and ignored when receiving.</t> use and <bcp14>MUST</bcp14> be set to zero when sending and ignored when receivi
ng.</dd>
<t>Algorithm (8 bits): SR-Algorithm value from registry "IGP Algorithm Types" <dt>Algorithm (8 bits):</dt><dd>The SR-Algorithm value from the "IGP
of "Interior Gateway Protocol (IGP) Parameters" IANA registry (see <xref target= Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" r
"IANA-ALGORITHM-TYPES"/>).</t> egistry group (see <xref target="IANA-ALGORITHM-TYPES" format="default"/>).</dd>
</dl>
<t>Future extensions SHOULD first use the Unassigned portion of the initial 4 <t>Future extensions <bcp14>SHOULD</bcp14> first use the Unassigned po
bytes to carry new information. If additional space is needed, the Subobject Ext rtion of the initial 4 bytes to carry new information. If additional space is ne
ension Block may be extended in 4-byte increments. Each such extension must be i eded, the Subobject Extension Block may be extended in 4-byte increments. Each s
ndicated by a dedicated SEBF in the Flags field (similar to the A flag) and must uch extension must be indicated by a dedicated SEBF in the Flags field (similar
be accompanied by capability signaling in an appropriate capability sub-TLV. Th to the A flag) and must be accompanied by capability signaling in an appropriate
e specific sub-TLV to be used is not restricted by this specification and may in capability sub-TLV. The specific sub-TLV to be used is not restricted by this s
clude, for example, the SR-PCE-CAPABILITY Sub-TLV, the SRv6-PCE-CAPABILITY Sub-T pecification and may include, for example, the SR-PCE-CAPABILITY sub-TLV, the SR
LV, or other capability TLVs, depending on the context of the extension. Interop v6-PCE-CAPABILITY sub-TLV, or other capability TLVs, depending on the context of
erability procedures and the precise signaling mechanisms for each new SEBF and the extension. Interoperability procedures and the precise signaling mechanisms
its associated capability will be defined by future specifications or procedures for each new SEBF and its associated capability will be defined by future speci
describing those extensions.</t> fications or procedures describing those extensions.</t>
<t>When receiving a Subobject Extension Block longer than 4 bytes, rec
<t>When receiving a Subobject Extension Block longer than 4 bytes, receivers t eivers that do not recognize or have not negotiated support for additional flags
hat do not recognize or have not negotiated support for additional flags MUST ig <bcp14>MUST</bcp14> ignore the unknown additional bytes beyond those defined in
nore the unknown additional bytes beyond those defined in this document.</t> this document.</t>
</section>
</section> <section anchor="Guidance-Future-Extensions" numbered="true" toc="defaul
t">
<section anchor="Guidance-Future-Extensions" title="Guidance for Future Ex <name>Guidance for Future Extensions</name>
tensions">
<t>Future enhancements extending the Subobject Extension Block must: <t>Future enhancements extending the Subobject Extension Block must:
<list style="symbols"> </t>
<t>Define a new SEBF in the Flags field to indicate the presence of new exte <ul spacing="normal">
nsion, and specify the corresponding capability signaling for that extension.</t <li>
> <t>Define a new SEBF in the Flags field to indicate the presence o
<t>Specify which parts of the reserved/extension block are used and how the f a new extension and specify the corresponding capability signaling for that ex
block length is calculated when their extension is present.</t> tension.</t>
<t>The reserved bits in the initial 4 bytes are used when possible, and the </li>
block is extended only when additional space is necessary.</t> <li>
<t>Future extensions may define additional SEBFs and corresponding fields, a <t>Specify which parts of the reserved/extension block are used an
llowing the block to be increased in size beyond the initial 4 bytes as needed.< d how the block length is calculated when their extension is present.</t>
/t> </li>
</list> <li>
</t> <t>Ensure the reserved bits in the initial 4 bytes are used when p
ossible
<t>Example: Future extension introducing a Z flag and a new Z field (8 bits): and the block is extended only when additional space is necessary.</t>
<list style="symbols"> </li>
<t>If the A flag and/or the Z flag are set, the Subobject Extension Block is <li>
included. The Z field may use 8 bits of the reserved portion. A field is only c <t> Have future extensions define additional SEBFs and correspondi
onsidered valid if its corresponding flag is set. For example, if the Z flag is ng
set to 1 but the A flag is set to 0, the Z field is valid, but the Algorithm fie fields, allowing the block to be increased in size beyond the
ld is ignored.</t> initial 4 bytes as needed.</t>
<t>If space beyond the initial 4 bytes is needed, the extension document spe </li>
cifies the new block layout and total length. To simplify parsing, if a flag for </ul>
such an extension is set, the full extended block is encoded, including the ini <t>Example: Future extension introducing a Z flag and a new Z field (8
tial 4 bytes, even if the A flag is set to 0.</t> bits):
</list> </t>
</t> <ul spacing="normal">
<li>
</section> <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>
<section anchor="SRv6-ERO-Subobject" numbered="true" toc="default">
<section anchor="SRv6-ERO-Subobject" title="SRv6-ERO Subobject"> <name>SRv6-ERO Subobject</name>
<t>This document updates the SRv6-ERO subobject format defined in <t>This document updates the SRv6-ERO subobject format defined in <xref
<xref target="RFC9603" sectionFormat="of" section="4.3.1" /> with Algorithm fiel target="RFC9603" sectionFormat="of" section="4.3.1" format="default"/> with the
d carved out of the Reserved field. Further, a new A flag is defined in the exis Algorithm field carved out of the Reserved field. Further, a new A flag is defin
ting Flags field as shown in <xref target="SRv6-ERO-subobject-format"/>.</t> ed in the existing Flags field as shown in <xref target="SRv6-ERO-subobject-form
<figure anchor="SRv6-ERO-subobject-format" title="SRv6-ERO Subobject Format"><ar at" format="default"/>.</t>
twork align="center"> <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 PST = 1 or 3 for SR-MPLS and SRv6, respe
the first instance of this TLV MUST be processed, subsequent instances MUST be i ctively. Only the first instance of this TLV <bcp14>MUST</bcp14> be processed; s
gnored.</t> ubsequent 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 PST.</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.2019" 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.2019" 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 PSTs other than 1 or 3 for SR-MPLS and SRv6, respectively), if the Gener
</section> ic Metric sub-TLV with the Bandwidth metric type is not advertised for a link, t
<section anchor="P2MP-BANDWIDTH" title="P2MP Path Bandwi he PCE implementation <bcp14>MAY</bcp14> apply a local policy to derive a metric
dth Metric"> value (similar to the procedures in Sections <xref target="RFC9843" sectionForm
<t>The Bandwidth metric type of the METRIC object in PC at="bare" section="4.1.3"/> and <xref target="RFC9843" sectionFormat="bare" sect
EP encodes the Path Bandwidth metric for the destination that observes the worst ion="4.1.4"/> of <xref target="RFC9843" format="default"/>) or the link <bcp14>M
bandwidth metric among all destinations of the P2MP tree.</t> AY</bcp14> be treated as if the metric value is unavailable (e.g., by using a de
<list style="symbols"> fault value). If the Bandwidth metric value is advertised for a link, the PCE <b
<t>The P2P Bandwidth metric of the path to destination cp14>MUST</bcp14> use the advertised value to compute the path metric in accorda
Dest_j is denoted by BM(Dest_j).</t> nce with Sections <xref target="P2P-BANDWIDTH" format="counter"/> and <xref targ
<t>The P2MP Path Bandwidth metric for the P2MP tree T et="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.2019" 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.2019" 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.2019" 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.2019" 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 SR. <xref
the definition of SR-Algorithm in Segment Routing. <xref target="RFC8665"/> and target="RFC8665" format="default"/> and <xref target="RFC8667" format="default"/
<xref target="RFC8667"/> are describing the use of the SR-Algorithm in IGP. Note > describe the use of the SR-Algorithm in IGP. Note that some RFCs refer to SR-A
that some RFCs are referring to SR-Algorithm with different names, for example lgorithm with different names, for example, "Prefix-SID Algorithm" and "SR Algor
"Prefix-SID Algorithm" and "SR Algorithm".</t> ithm".</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">
<section anchor="SR-ALGORITHM-CONSTRAINT" title="SR-Algorithm Constraint"> <name>SR-Algorithm Constraint</name>
<t>To signal a specific SR-Algorithm constraint to the PCE, the headend
<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>
MUST encode the SR-Algorithm TLV inside the LSPA object.</t> <t>If a PCC receives an LSPA object with the SR-Algorithm TLV as part of
PCInitiate or PCUpd messages, then it <bcp14>MUST</bcp14> include an LSPA objec
<t>If a PCC receives an LSPA object with SR-Algorithm TLV as part of PCI t with the SR-Algorithm TLV in a PCRpt message as part of intended-attribute-lis
nitiate, PCUpd messages, then it MUST include LSPA object with SR-Algorithm TLV t.</t>
in 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
<t>If a PCE receives an LSPA object with SR-Algorithm TLV in PCRpt or PC hm TLV in a PCUpd message, or a PCRep message in case of an unsuccessful path co
Req, then it MUST include the LSPA object with SR-Algorithm TLV in PCUpd message mputation based on rules described in <xref target="RFC5440" sectionFormat="of"
, or PCRep message in case of an unsuccessful path computation based on rules de section="7.11" format="default"/>.</t>
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
sub-TLV corresponding to the LSP's PST <bcp14>MUST</bcp14> ignore the SR-Algorit
<t>A PCEP peer that did not advertise the S flag in the Path Setup Type hm TLV on receipt.</t>
Sub-TLV corresponding to the LSP's PST, it MUST ignore the SR-Algorithm TLV on r <t>The PCE <bcp14>MUST NOT</bcp14> use Prefix SIDs associated with an SR
eceipt.</t> -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
<t>The PCE MUST NOT use Prefix SIDs associated with an SR-Algorithm othe that the backup path may fail to forward traffic over parts of the topology tha
r than the one specified in the SR-Algorithm constraint. If a protected Adjacenc t are not included in the specified SR-Algorithm. Consequently, it is <bcp14>NOT
y SID is used without an associated SR-Algorithm, there is a risk that the backu RECOMMENDED</bcp14> to use protected Adjacency SIDs without an explicitly speci
p path may fail to forward traffic over parts of the topology that are not inclu fied SR-Algorithm. If an Adjacency SID has an associated SR-Algorithm, the PCE <
ded in the specified SR-Algorithm. Consequently, it is NOT RECOMMENDED to use pr bcp14>MUST</bcp14> ensure that the SR-Algorithm matches the one specified in the
otected Adjacency SIDs without an explicitly specified SR-Algorithm. If an Adjac SR-Algorithm constraint.</t>
ency SID has an associated SR-Algorithm, the PCE MUST ensure that the SR-Algorit <t>Other SID types, such as BSIDs, are allowed. Furthermore, the inclusi
hm matches the one specified in the SR-Algorithm constraint.</t> on of a path BSID from another policy is permitted only if the path associated w
ith that policy fully satisfies all the constraints of the current path computat
<t>Other SID types, such as Binding SIDs, are allowed. Furthermore, the ion.</t>
inclusion of a path Binding SID (BSID) from another policy is permitted only if <t>The specified SR-Algorithm constraint is applied to the end-to-end SR
the path associated with that policy fully satisfies all the constraints of the Policy path. Using different SR-Algorithm constraints or using winning FAD with
current path computation.</t> 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
<t>The specified SR-Algorithm constraint is applied to the end-to-end SR f this document.</t>
policy path. Using different SR-Algorithm constraints or using winning FAD with <t>If the PCE is unable to find a path with the given SR-Algorithm const
different optimization metric or constraints for same SR-Algorithm in each doma raint, it does not support a combination of specified constraints, or if the FAD
in or part of the topology in single path computation is out of the scope of thi contains constraints, optimization metrics, or other attributes, which the PCE
s document.</t> does not support or recognize, it <bcp14>MUST</bcp14> use an empty ERO in PCInit
iate for LSP instantiation, a PCUpd message if an update is required, or a NO-PA
<t>If the PCE is unable to find a path with the given SR-Algorithm const TH object in PCRep to indicate that it was not able to find the valid path.</t>
raint, it does not support a combination of specified constraints or if the FAD <t>If the Algorithm field value is in the range 128-255, the PCE <bcp14>
contains constraints, optimization metric or other attributes, which the PCE doe MUST</bcp14> perform path computation according to the Flexible Algorithm proced
s not support or recognize, it MUST use an empty ERO in PCInitiate for LSP insta ures outlined in <xref target="FLEX-ALGO-COMPUTATION" format="default"/>. Otherw
ntiation or PCUpd message if an update is required or NO-PATH object in PCRep to ise, the PCE <bcp14>MUST</bcp14> adhere to the path computation procedures with
indicate that it was not able to find the valid path.</t> SID filtering as defined in <xref target="SID-FILTERING-COMPUTATION" format="def
ault"/>.</t>
<t>If the Algorithm field value is in the range 128-255, the PCE MUST pe <t>If the NO-PATH object is included in PCRep, then the PCE <bcp14>MAY</
rform path computation according to the Flexible Algorithm procedures outlined i bcp14> include the SR-Algorithm TLV to indicate constraint, which cannot be sati
n <xref target="FLEX-ALGO-COMPUTATION"/>. Otherwise, the PCE MUST adhere to the sfied as described in <xref target="RFC5440" sectionFormat="of" section="7.5" fo
path computation procedures with SID filtering defined in <xref target="SID-FILT rmat="default"/>.</t>
ERING-COMPUTATION"/>.</t> <t>SR-Algorithm does not replace the objective function defined in <xref
target="RFC5541" format="default"/>.</t>
<t>If the NO-PATH object is included in PCRep, then the PCE MAY include <section anchor="SID-FILTERING-COMPUTATION" numbered="true" toc="default
SR-Algorithm TLV to indicate constraint, which cannot be satisfied as described ">
in <xref target="RFC5440" sectionFormat="of" section="7.5" />.</t> <name>Path Computation for SR-Algorithms 0-127</name>
<t>The SR-Algorithm constraint acts as a filter, restricting which SID
<t>SR-Algorithm does not replace the Objective Function defined in <xref s may be used as a result of the path computation function. Path computation is
target="RFC5541"/>.</t> done based on optimization metric type and constraints specified in the PCEP mes
sage received from the PCC.</t>
<section anchor="SID-FILTERING-COMPUTATION" title="Path Computation for <t>The mechanism described in this section is applicable only to SR-Al
SR-Algorithms 0-127"> gorithm values in the range 0-127. It is not applicable to Flexible Algorithms (
<t>The SR-Algorithm constraint acts as a filter, restricting which SIDs range 128-255), which are handled as described in <xref target="FLEX-ALGO-COMPUT
may be used as a result of the path computation function. Path computation is do ATION" format="default"/>. Within the 0-127 range, currently defined algorithms
ne based on optimization metric type and constraints specified in the PCEP messa are 0 (Shortest Path First (SPF)) and 1 (Strict-SPF), as introduced in <xref tar
ge received from the PCC.</t> get="RFC8402" sectionFormat="of" section="3.1.1" format="default"/>. Future algo
<t>The mechanism described in this section is applicable only to SR-Algo rithms defined within this range that do not require explicit PCEP extensions be
rithm values in the range 0-127. It is not applicable to Flexible Algorithms (ra yond the SR-Algorithm TLV may also utilize this SID filtering approach. If a PCE
nge 128-255), which are handled as described in <xref target="FLEX-ALGO-COMPUTAT implementation receives a request with an SR-Algorithm value in the 0-127 range
ION"/>. Within the 0-127 range, currently defined algorithms are 0 (Shortest Pat that it does not support for path computation, it <bcp14>MUST</bcp14> reject th
h First (SPF)) and 1 (Strict SPF) as introduced in <xref target="RFC8402" sectio e PCEP message and send a PCErr message with Error-Type 19 (Invalid Operation) a
nFormat="of" section="3.1.1" />. Future algorithms defined within this range tha nd Error-value 34 (Unsupported combination of constraints).</t>
t do not require explicit PCEP extensions beyond the SR-Algorithm TLV may also u </section>
tilize this SID filtering approach. If a PCE implementation receives a request w <section anchor="FLEX-ALGO-COMPUTATION" numbered="true" toc="default">
ith an SR-Algorithm value in the 0-127 range that it does not support for path c <name>Path Computation for Flexible Algorithms</name>
omputation, it MUST reject the PCEP message and send a PCErr message with Error- <t>This section is applicable only to the Flexible Algorithms range of
Type 19 (Invalid Operation) and Error-Value TBD4 (Unsupported SR-Algorithm).</t> SR-Algorithm values. The PCE performs Flexible Algorithm path computation based
</section> on topology information stored in its TED <xref target="RFC5440" format="defaul
<section anchor="FLEX-ALGO-COMPUTATION" title="Path Computation for Flex t"/>. The TED is expected to be populated with necessary information, including
ible Algorithms"> Flexible Algorithm Definitions (FADs), node participation, and ASLA-specific lin
<t>This section is applicable only to the Flexible Algorithms range of S k attributes, through standard mechanisms, such as IGPs with Traffic Engineering
R-Algorithm values. The PCE performs Flexible Algorithm path computation based o extensions or BGP - Link State (BGP-LS) <xref target="RFC9552" format="default"
n topology information stored in its TED <xref target="RFC5440"/>. The TED is ex />.</t>
pected to be populated with necessary information, including Flexible Algorithm <t>The PCE must follow the IGP Flexible Algorithm path computation log
Definitions (FADs), node participation, and ASLA-specific link attributes, throu ic as described in <xref target="RFC9350" format="default"/>. This includes perf
gh standard mechanisms such as Interior Gateway Protocols (IGPs) with Traffic En orming the FAD selection as described in <xref target="RFC9350" sectionFormat="o
gineering extensions or BGP-LS <xref target="RFC9552"/>.</t> 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
<t>The PCE must follow the IGP Flexible Algorithm path computation logic ipation (<xref target="RFC9350" sectionFormat="of" section="11" format="default"
as described in <xref target="RFC9350"/>. This includes performing the FAD sele />), using ASLA-specific link attributes (<xref target="RFC9350" sectionFormat="
ction as described in <xref target="RFC9350" sectionFormat="of" section="5.3" /> of" section="12" format="default"/>), and applying other rules for Flexible Algo
and other sections, determining the topology associated with specific Flexible rithm path calculation (<xref target="RFC9350" sectionFormat="of" section="13" f
Algorithm based on the FAD, the node participation <xref target="RFC9350" sectio ormat="default"/>). While <xref target="RFC9350" format="default"/> defines the
nFormat="of" section="11" />, using ASLA-specific link attributes <xref target=" base procedures for IGP Flexible Algorithms, these procedures are further extend
RFC9350" sectionFormat="of" section="12" />, and applying other rules for Flexib ed by other documents, such as <xref target="RFC9843" format="default"/>; a PCE
le Algorithm path calculation <xref target="RFC9350" sectionFormat="of" section= implementation may need to support these IGP extensions to allow use of specific
"13" />. While <xref target="RFC9350"/> defines the base procedures for IGP Flex constraints in FAD. <xref target="RFC9917" format="default"/> created an IANA r
ible Algorithms, these procedures are further extended by other documents such a egistry called "IGP Flex-Algorithm Path Computation Rules" <eref target="https:/
s <xref target="RFC9843"/>, a PCE implementation may need to support these IGP e /www.iana.org/assignments/igp-parameters" brackets="angle"/> within the "Interio
xtensions to allow use of specific constraints in FAD. <xref target="I-D.ietf-ls r Gateway Protocol (IGP) Parameters" registry group with the ordered set of rule
r-igp-flex-algo-reverse-affinity"/> created an IANA registry called "IGP Flex-Al s that <bcp14>MUST</bcp14> be used to prune links from the topology during the F
gorithm Path Computation Rules Registry" within the "Interior Gateway Protocol ( lexible Algorithm path computation.</t>
IGP) Parameters" registry group with the ordered set of rules that MUST be used <t>The PCE <bcp14>MUST</bcp14> optimize the computed path based on the
to prune links from the topology during the Flexible Algorithm path computation. metric type specified in the FAD. The optimization metric type included in PCEP
</t> 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
<t>[Note to RFC Editor: The URL of the "IGP Flex-Algorithm Path Computat ic type is not defined in PCEP or not supported by the PCEP peer. It is allowed
ion Rules Registry" IANA registry to be inserted once it will get created after to use SID types other than Prefix SID (e.g., Adjacency or BSID) but only from n
approval of <xref target="I-D.ietf-lsr-igp-flex-algo-reverse-affinity" />.] </t> odes participating in the specified SR-Algorithm.</t>
<t>There are corresponding metric types in PCEP for IGP and TE metrics
<t>The PCE MUST optimize the computed path based on the metric type spec from FAD introduced in <xref target="RFC9350" format="default"/>, but there wer
ified in the FAD. The optimization metric type included in PCEP messages from th e no corresponding metric types defined for "Min Unidirectional Link Delay" from
e PCC MUST be ignored. The PCE MUST use the metric type from the FAD in messages <xref target="RFC9350" format="default"/> and "Bandwidth metric" and "User-defi
sent to the PCC unless that metric type is not defined in PCEP or not supported ned metric" from <xref target="RFC9843" format="default"/>. <xref target="METRIC
by the PCEP peer. It is allowed to use SID types other than Prefix SID (e.g., A -TYPES" format="default"/> of this document introduces them. Note that the defin
djacency or BSID), but only from nodes participating in the specified SR-Algorit ed "Path Bandwidth metric" is accumulative and is different from the BANDWIDTH o
hm.</t> bject defined in <xref target="RFC5440" format="default"/>.</t>
<t>The PCE <bcp14>MUST</bcp14> use the constraints specified in the FA
<t>There are corresponding metric types in PCEP for IGP and TE metric fr D and also constraints (except optimization metric type) directly included in PC
om FAD introduced in <xref target="RFC9350"/>, but there were no corresponding m EP messages from the PCC. The PCE implementation <bcp14>MAY</bcp14> decide to ig
etric types defined for "Min Unidirectional Link Delay" from <xref target="RFC93 nore specific constraints received from the PCC based on existing processing rul
50"/> and "Bandwidth Metric", "User Defined Metric" from <xref target="RFC9843"/ es for PCEP objects and TLVs, e.g., the P flag described in <xref target="RFC544
>. <xref target="METRIC-TYPES"/> of this document is introducing them. Note that 0" sectionFormat="of" section="7.2" format="default"/> and processing rules desc
the defined "Path Bandwidth Metric" is accumulative and is different from the B ribed in <xref target="RFC9753" format="default"/>. If the PCE does not support
andwidth Object defined in <xref target="RFC5440"/>.</t> 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
<t>The PCE MUST use the constraints specified in the FAD and also constr empty ERO or PCRep with NO-PATH object. The PCC <bcp14>MUST NOT</bcp14> include
aints (except optimization metric type) directly included in PCEP messages from constraints from the FAD in the PCEP message sent to the PCE, as it can result i
the PCC. The PCE implementation MAY decide to ignore specific constraints receiv n undesired behavior in various cases. The PCE <bcp14>SHOULD NOT</bcp14> include
ed from the PCC based on existing processing rules for PCEP Objects and TLVs, e. constraints from the FAD in PCEP messages sent to the PCC.</t>
g. P flag described in <xref target="RFC5440" sectionFormat="of" section="7.2" / <t>The combinations of the constraints specified in the FAD and constr
> and processing rules described in <xref target="RFC9753"/>. If the PCE does no aints directly included in PCEP messages from the PCC may decrease the chance th
t support a specified combination of constraints, it MUST fail path computation at Flexible-Algorithm-specific Prefix SIDs represent an optimal path while satis
and respond with a PCEP message with PCInitiate or PCUpd message with empty ERO fying all specified constraints; as a result, a longer SID list may be required
or PCRep with NO-PATH object. PCC MUST NOT include constraints from FAD in PCEP for the computed path. Adding more constraints on top of the FAD requires compl
message sent to PCE as it can result in undesired behavior in various cases. PCE ex path computation and may reduce the benefit of this scheme.</t>
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
nts directly included in PCEP messages from the PCC may decrease the chance that
Flexible Algorithm specific Prefix SIDs represent an optimal path while satisfy
ing all specified constraints, as a result a longer SID list may be required for
the computed path. Adding more constraints on top of FAD requires complex 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= <t>All manageability requirements and considerations listed in <xref targe
"RFC8664"/> and <xref target="RFC9603"/> apply to the PCEP extensions defined in t="RFC5440" format="default"/>, <xref target="RFC8231" format="default"/>, <xref
this document. In addition, the requirements and considerations listed in this target="RFC8664" format="default"/>, and <xref target="RFC9603" format="default
section apply.</t> "/> apply to the PCEP extensions defined in this document. In addition, the requ
<section title="Control of Function and Policy" numbered="true" toc="defau irements and considerations listed in this section apply.</t>
lt"> <section numbered="true" toc="default">
<t>A PCE or PCC implementation MAY allow the capability of supporting th <name>Control of Function and Policy</name>
e PCEP extensions introduced in this document to be enabled or disabled as part <t>A PCE or PCC implementation <bcp14>MAY</bcp14> allow the capability o
of the global configuration. By default, this capability SHOULD be enabled.</t> 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>This document does not put new requirements but relies on the necessa <t>An implementation <bcp14>SHOULD</bcp14> also allow the operator to vi
ry IGP extensions.</t> ew FADs, which may be used in Flexible Algorithm path computation as defined in
</section> <xref target="FLEX-ALGO-COMPUTATION" format="default"/>.</t>
<section title="Impact On Network Operations" numbered="true" toc="default <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view no
"> des participating in the specified SR-Algorithm.</t>
<t>This document inherits considerations from documents describing IGP F
lexible Algorithm - for example <xref target="RFC9350"/> and <xref target="RFC98
43"/>.</t>
</section> </section>
</section> <section numbered="true" toc="default">
<section title="Operational Considerations" numbered="true" toc="default"> <name>Requirements on Other Protocols and Functional Components</name>
<t>This document inherits operational considerations from documents desc <t>This document does not put new requirements but relies on the necessa
ribing IGP Flexible Algorithm - for example <xref target="RFC9350"/> and <xref t ry IGP extensions.</t>
arget="RFC9843"/>.</t>
</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
working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this
information as they see fit".</t>
<section anchor="Cisco" title="Cisco">
<t><list style="symbols">
<t>Organization: Cisco Systems</t>
<t>Implementation: IOS-XR PCC and PCE.</t>
<t>Description: SR-MPLS part with experimental codepoints.</t>
<t>Maturity Level: Production.</t>
<t>Coverage: Partial.</t>
<t>Contact: ssidor@cisco.com</t>
</list></t>
</section> </section>
<section anchor="Huawei" title="Huawei"> <section numbered="true" toc="default">
<t><list style="symbols"> <name>Impact on Network Operations</name>
<t>Organization: Huawei</t> <t>This document inherits considerations from documents describing IGP F
<t>Implementation: NE Series Routers</t> lexible Algorithm -- for example, <xref target="RFC9350" format="default"/> and
<t>Description: SR Policy with SR Algorithm.</t> <xref target="RFC9843" format="default"/>.</t>
<t>Maturity Level: Production.</t>
<t>Coverage: Partial.</t>
<t>Contact: pengshuping@huawei.com</t>
</list></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations" numbered="true" toc="default"> <name>Operational Considerations</name>
<t>The security considerations described in <xref target="RFC5440"/> <t>This document inherits operational considerations from documents descri
, bing IGP Flexible Algorithm -- for example, <xref target="RFC9350" format="defau
<xref target='RFC8231'/>, <xref target='RFC8253'/>, <xref target='RFC8281' lt"/> and <xref target="RFC9843" format="default"/>.</t>
/>, <xref target="RFC8664"/>, <xref target="RFC9603"/> and <xref target='RFC9350
'/> apply to the extensions described in this document as well.</t>
<t>Note that this specification introduces the possibility of comput
ing paths by the PCE based on Flexible Algorithm related topology attributes and
based on the metric type and constraints from FAD. This creates additional vuln
erabilities, which are already described for the path computation done by IGP li
ke those described in Security Considerations section of <xref target='RFC9350'/
>, but which are also applicable to path computation done by PCE. Hence, securin
g the PCEP session using Transport Layer Security (TLS) <xref target="RFC8253"/>
<xref target='I-D.ietf-pce-pceps-tls13'/> is RECOMMENDED as per the recommendati
ons
and best current practices described in <xref target="RFC9325"/>.</t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="SR-CAPABILITY-FLAG" title="SR Capability Flag"> <t>The security considerations described in <xref target="RFC5440" format=
"default"/>,
<t>IANA maintains a registry, named "SR Capability Flag Field", within t <xref target="RFC8231" format="default"/>, <xref target="RFC8253" format="
he "Path Computation Element Protocol default"/>, <xref target="RFC8281" format="default"/>, <xref target="RFC8664" fo
(PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABI rmat="default"/>, <xref target="RFC9603" format="default"/>, and <xref target="R
LITY TLV. IANA is requested to confirm the following early allocation:</t> FC9350" format="default"/> apply to the extensions described in this document as
well.</t>
<texttable anchor="SR-CAPABILITY-FLAG-value" style="none" suppress-title <t>Note that this specification introduces the possibility of computing pa
="true"> ths by the PCE based on Flexible-Algorithm-related topology attributes and based
<ttcol align="center" width='15%'>Bit</ttcol> on the metric type and constraints from the FAD. This creates additional vulner
<ttcol align="left" width='30%'>Description </ttcol> abilities, which are already described for the path computation done by IGP, lik
<ttcol align="left" width='55%'>Reference </ttcol> e those described in the Security Considerations section of <xref target="RFC935
<c>5</c><c>SR-Algorithm Capability</c><c>This document</c> 0" format="default"/> but which are also applicable to path computation done by
</texttable> 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="SRv6-CAPABILITY-FLAG" numbered="true" toc="default">
<section anchor="SRv6-CAPABILITY-FLAG" title="SRv6 PCE Capability Flag"> <name>SRv6 PCE Capability Flag</name>
<t>IANA maintains a registry named "SRv6 Capability Flag Field" within t
<t>IANA maintains a registry, named "SRv6 Capability Flag Field", within he "Path Computation Element Protocol
the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILI
(PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILI TY sub-TLV. IANA has registered the following:</t>
TY sub-TLV. IANA is requested to <table anchor="SRv6-CAPABILITY-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">13</td>
<td align="left">SR-Algorithm Capability</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="SR-ERO-FLAG" numbered="true" toc="default">
<section anchor="SR-ERO-FLAG" title="SR-ERO Flag"> <name>SR-ERO Flag</name>
<t>IANA maintains a registry named "SR-ERO Flag Field" within the "Path
<t>IANA maintains a registry, named "SR-ERO Flag Field", within the "Pat Computation Element Protocol
h Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobj
(PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobj ect. IANA has registered the following:</t>
ect. IANA is requested to confirm the following early allocation:</t> <table anchor="SR-ERO-FLAG-value" align="center">
<thead>
<texttable anchor="SR-ERO-FLAG-value" style="none" suppress-title="true" <tr>
> <th align="center">Bit</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">7</td>
<td align="left">SR-Algorithm Flag (A)</td>
<td align="left">RFC 9933</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="SRv6-ERO-FLAG" numbered="true" toc="default">
<section anchor="SRv6-ERO-FLAG" title="SRv6-ERO 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-ERO Flag Field", within the "P h Computation Element Protocol
ath 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 the SRv6-ERO subo bject. IANA has registered the following:</t>
bject. IANA is requested to <table anchor="SRv6-ERO-FLAG-value" align="center">
make the following assignment:</t> <thead>
<tr>
<texttable anchor="SRv6-ERO-FLAG-value" style="none" suppress-title="tru <th align="center">Bit</th>
e"> <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>TBD2</c><c>SR-Algorithm Flag (A)</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="TLV-Type" title="PCEP TLV Types"> <name>PCEP TLV Types</name>
<t>IANA maintains a registry named "PCEP TLV Type Indicators" within the
<t>IANA maintains a registry, named "PCEP TLV Type Indicators", within t "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has reg
he "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is re istered the following TLV type for the new LSPA TLV specified in this document.<
quested to confirm the early allocation of a new TLV type for the new LSPA TLV s /t>
pecified in this document.</t> <table anchor="LSPA-TLV-type" align="center">
<thead>
<texttable anchor="LSPA-TLV-type" style="none" suppress-title="true"> <tr>
<ttcol align="center" width='15%'>Type</ttcol> <th align="center">Value</th>
<ttcol align="left" width='30%'>Description </ttcol> <th align="left">Description </th>
<ttcol align="left" width='55%'>Reference </ttcol> <th align="left">Reference </th>
<c>66</c><c>SR-Algorithm</c><c>This document</c> </tr>
</texttable> </thead>
<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">
<section anchor="Metric-Types" title="Metric Types"> <name>Metric Types</name>
<t>IANA maintains a registry named "METRIC Object T Field" within the "P
<t>IANA maintains a registry for "METRIC Object T Field" within the "Pat ath Computation Element Protocol (PCEP) Numbers" registry group. IANA has regist
h Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested ered these codepoints as follows:</t>
to confirm <table anchor="Metric-types" align="center">
the early allocated codepoints as follows:</t> <thead>
<tr>
<texttable anchor="Metric-types" style="none" suppress-title="true"> <th align="center">Value</th>
<ttcol align="center" width='15%'>Type</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>22</c><c>Path Min Delay Metric</c><c>This document</c> </thead>
<c>23</c><c>P2MP Path Min Delay Metric</c><c>This document</c> <tbody>
<c>24</c><c>Path Bandwidth Metric</c><c>This document</c> <tr>
<c>25</c><c>P2MP Path Bandwidth Metric</c><c>This document</c> <td align="center">22</td>
<c>128-255</c><c>User Defined Metric </c><c>This document</c> <td align="left">Path Min Delay metric</td>
</texttable> <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>
<section anchor="PCEP-Error-Object" numbered="true" toc="default">
<section anchor="PCEP-Error-Object" title="PCEP-Error Object"> <name>PCEP-Error Object</name>
<t>IANA has registered the following Error-Types and Error-values within
<t>IANA is requested to allocate new error types and error values within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computatio
the "PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers n Element Protocol (PCEP) Numbers" registry group.</t>
registry for the following errors.</t> <table anchor="PCEP-Error-type" align="center">
<thead>
<texttable anchor="PCEP-Error-type" style="none" suppress-title="true"> <tr>
<ttcol align="center" width='15%'>Error-Type</ttcol> <th align="center">Error-Type</th>
<ttcol align="left" width='30%'>Meaning </ttcol> <th align="left">Meaning </th>
<ttcol align="left" width='55%'>Error-Value </ttcol> <th align="left">Error-value </th>
<ttcol align='left' >Reference</ttcol> <th align="left">Reference</th>
<c>19</c><c>Invalid Operation</c><c>TBD3:Attempted use of SR-Algorithm </tr>
without advertised capability</c><c>This Document</c> </thead>
<c></c><c></c><c>TBD4:Unsupported combination of constraints</c><c>Thi <tbody>
s Document</c> <tr>
</texttable> <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>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<?rfc include="reference.RFC.5440"?> <references>
<?rfc include="reference.RFC.7471"?> <name>Normative References</name>
<?rfc include="reference.RFC.8174"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include="reference.RFC.8231"?> 119.xml"/>
<?rfc include="reference.RFC.8233"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.8253"?> 440.xml"/>
<?rfc include="reference.RFC.8281"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="reference.RFC.8402"?> 471.xml"/>
<?rfc include="reference.RFC.8570"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.8664"?> 174.xml"/>
<?rfc include="reference.RFC.8665"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.8667"?> 231.xml"/>
<?rfc include="reference.RFC.9256"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.9350"?> 233.xml"/>
<?rfc include="reference.RFC.9603"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.9753"?> 253.xml"/>
<?rfc include="reference.RFC.9843"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.I-D.ietf-lsr-igp-flex-algo-reverse-affinity"?> 281.xml"/>
<?rfc include="reference.I-D.ietf-pce-pceps-tls13"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
</references> <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"/>
<references title="Informative References"> <!-- [I-D.ietf-pce-pceps-tls13] -> [RFC9916]
<?rfc include="reference.RFC.9826"?> companion doc RFC9916
<?rfc include="reference.RFC.3031"?> -->
<?rfc include="reference.RFC.4655"?> <reference anchor="RFC9916" target="https://www.rfc-editor.org/info/rfc9916">
<?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> <front>
<title>IEEE Standard for Floating-Point Arithmetic</title> <title>Updates for PCEPS: TLS Connection Establishment Restrictions</title>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4610935"/> <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
<seriesInfo name="IEEE" value="IEEE Std 754-2008"/> <organization>Huawei</organization>
<author>
<organization showOnFrontPage="true">IEEE</organization>
</author> </author>
<date month="August" year="2008"/> <author initials="S." surname="Turner" fullname="Sean Turner">
</front> <organization>sn3rd</organization>
</reference>
<reference anchor="IANA-ALGORITHM-TYPES">
<front>
<title>Interior Gateway Protocol (IGP) Parameters - IGP Algorithm Types</tit
le>
<author>
<organization>IANA</organization>
</author> </author>
<date year="n/a"/> <author initials="R." surname="Housley" fullname="Russ Housley">
<organization>Vigil Security, LLC</organization>
</author>
<date month='February' year='2026'/>
</front> </front>
<seriesInfo name="IANA Registry" value="https://www.iana.org/assignments/igp-p <seriesInfo name="RFC" value="9916"/>
arameters/igp-parameters.xhtml#algorithm-type"/> <seriesInfo name="DOI" value="10.17487/RFC9916"/>
</reference> </reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
826.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
031.xml"/>
<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"/>
<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> </references>
<section anchor="Acknowledgement" title="Acknowledgement"> <section anchor="Acknowledgements" numbered="false" toc="default">
<t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the document and <name>Acknowledgements</name>
for his contributions and suggestions.</t> <t>Thanks to <contact fullname="Dhruv Dhody"/> for shepherding the
<t> document and for their contributions and suggestions.</t>
Would like to thank Adrian Farrel, Aijun Wang, Alexey Melnikov, Boris Khasanov, <t>The authors would like to thank <contact fullname="Adrian Farrel"/>, <c
Deb Cooley, Eric Vyncke, Gunter Van de Velde, Jie Dong, Ketan Talaulikar, Mahesh ontact
Jethanandani, Marina Fizgeer, Mike Bishop, Mohamed Boucadair, Nagendra Nainar, fullname="Aijun Wang"/>, <contact fullname="Alexey Melnikov"/>, <contact
Rakesh Gandhi, Russ White, Shraddha Hegde for review and suggestions. fullname="Boris Khasanov"/>, <contact fullname="Deb Cooley"/>, <contact
</t> fullname="Éric Vyncke"/>, <contact fullname="Gunter Van de Velde"/>,
</section> <!-- Acknowledgement --> <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 title="Contributors"> <section numbered="false" toc="default">
<name>Contributors</name>
<t><figure><artwork> <contact fullname="Mike Koldychev">
Mike Koldychev <organization>Ciena Corporation</organization>
Ciena Corporation <address>
Email: mkoldych@proton.me <email>mkoldych@proton.me</email>
</address>
</contact>
Zafar Ali <contact fullname="Zafar Ali">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
Email: zali@cisco.com <address>
<email>zali@cisco.com</email>
</address>
</contact>
Stephane Litkowski <contact fullname="Stephane Litkowski">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
Email: slitkows.ietf@gmail.com <address>
<email>slitkows.ietf@gmail.com</email>
</address>
</contact>
Siva Sivabalan <contact fullname="Siva Sivabalan">
Ciena <organization>Ciena</organization>
Email: msiva282@gmail.com <address>
<email>msiva282@gmail.com</email>
</address>
</contact>
Tarek Saad <contact fullname="Tarek Saad">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
Email: tsaad.net@gmail.com <address>
<email>tsaad.net@gmail.com</email>
</address>
</contact>
Mahendra Singh Negi <contact fullname="Mahendra Singh Negi">
RtBrick Inc <organization>RtBrick Inc</organization>
Email: mahend.ietf@gmail.com <address>
<email>mahend.ietf@gmail.com</email>
</address>
</contact>
Tom Petch <contact fullname="Tom Petch">
Email: ietfc@btconnect.com <address>
</artwork></figure></t> <email>ietfc@btconnect.com</email>
</address>
</contact>
</section> <!-- Contributors --> </section>
</back> </back>
<!-- [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)
.
-->
</rfc> </rfc>
 End of changes. 80 change blocks. 
1148 lines changed or deleted 1328 lines changed or added

This html diff was produced by rfcdiff 1.48.