rfc9514xml2.original.xml   rfc9514.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-ietf-idr-bgpls-srv6-ext-14"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<?rfc compact="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-idr-bgpls-srv6-ext-14" number="9514" i pr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs ="true" sortRefs="true" version="3">
<?rfc subcompact="no" ?> <!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="BGP-LS Extensions for SRv6">BGP Link State Extensions for <title abbrev="BGP-LS Extensions for SRv6">Border Gateway Protocol - Link St
SRv6</title> ate (BGP-LS) Extensions for
Segment Routing over IPv6 (SRv6)</title>
<seriesInfo name="RFC" value="9514"/>
<author fullname="Gaurav Dawra" initials="G" surname="Dawra"> <author fullname="Gaurav Dawra" initials="G" surname="Dawra">
<organization>LinkedIn</organization> <organization>LinkedIn</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>gdawra.ietf@gmail.com</email> <email>gdawra.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C" surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Tala
<author fullname="Ketan Talaulikar" initials="K" role="editor" ulikar">
surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<author fullname="Mach Chen" initials="M." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Daniel Bernier " initials="D." surname="Bernier"> <author fullname="Daniel Bernier " initials="D." surname="Bernier">
<organization>Bell Canada</organization> <organization>Bell Canada</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.bernier@bell.ca</email> <email>daniel.bernier@bell.ca</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> <author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<country>France</country> <country>France</country>
</postal> </postal>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<date year="2023" month="November"/>
<date year=""/> <area>rtg</area>
<workgroup>idr</workgroup>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<keyword>SRv6</keyword> <keyword>SRv6</keyword>
<abstract> <abstract>
<t>Segment Routing over IPv6 (SRv6) allows for a flexible definition of <t>Segment Routing over IPv6 (SRv6) allows for a flexible definition of
end-to-end paths within various topologies by encoding paths as end-to-end paths within various topologies by encoding paths as
sequences of topological or functional sub-paths, called "segments". sequences of topological or functional sub-paths called "segments".
These segments are advertised by various protocols such as BGP, IS-IS These segments are advertised by various protocols such as BGP, IS-IS,
and OSPFv3.</t> and OSPFv3.</t>
<t>This document defines extensions to BGP Link-state (BGP-LS) to <t>This document defines extensions to BGP - Link State (BGP-LS) to
advertise SRv6 segments along with their behaviors and other attributes advertise SRv6 segments along with their behaviors and other attributes
via BGP. The BGP-LS address-family solution for SRv6 described in this via BGP. The BGP-LS address-family solution for SRv6 described in this
document is similar to BGP-LS for SR for the MPLS data-plane defined in document is similar to BGP-LS for SR for the MPLS data plane, which is def
a separate document.</t> ined in
RFC 9085.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTROLSSRV6" title="Introduction"> <section anchor="INTROLSSRV6" numbered="true" toc="default">
<t>SRv6 refers to Segment Routing instantiated on the IPv6 data-plane <name>Introduction</name>
<xref target="RFC8402"/>. An SRv6 Segment is often referred to by its <t>SRv6 refers to Segment Routing instantiated on the IPv6 data plane
<xref target="RFC8402" format="default"/>. An SRv6 segment is often referr
ed to by its
SRv6 Segment Identifier (SID).</t> SRv6 Segment Identifier (SID).</t>
<t>The network programming paradigm <xref target="RFC8986" format="default
<t>The network programming paradigm <xref target="RFC8986"/> is central "/> is central
to SRv6. It describes how different behaviors can be bound to SIDs and to SRv6. It describes how different behaviors can be bound to SIDs and
how a network program can be expressed as a combination of SIDs.</t> how a network program can be expressed as a combination of SIDs.</t>
<t>An SRv6-capable node maintains all the SRv6 segments explicitly <t>An SRv6-capable node maintains all the SRv6 segments explicitly
instantiated locally.</t> instantiated locally.</t>
<t>The IS-IS and OSPFv3 link-state routing protocols have been extended <t>The IS-IS and OSPFv3 link-state routing protocols have been extended
to advertise some of these SRv6 SIDs and SRv6-related information <xref to advertise some of these SRv6 SIDs and SRv6-related information <xref ta
target="I-D.ietf-lsr-isis-srv6-extensions"/>, <xref rget="RFC9352" format="default"/> <xref target="RFC9513" format="default"/>. Oth
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>. Other SRv6 SIDs may be er SRv6 SIDs may be
instantiated on a node via other mechanisms for topological or service instantiated on a node via other mechanisms for topological or service
functionalities.</t> functionalities.</t>
<t>The advertisement of SR related information along with the topology <t>The advertisement of SR-related information along with the topology is specif
for the MPLS data-plane instantiation (SR-MPLS) is specified in <xref ied in <xref target="RFC9085" format="default"/>
target="RFC9085"/> and for the BGP Egress Peer Engineering (EPE) is for the MPLS data plane instantiation (SR-MPLS) and in <xref target="RFC90
specified in <xref target="RFC9086"/>. On similar lines, introducing the 86" format="default"/> for BGP Egress Peer Engineering (EPE). On similar lines,
SRv6 related information in BGP-LS allows consumer applications that introducing the
SRv6-related information in BGP-LS allows consumer applications that
require topological visibility to also receive the SRv6 SIDs from nodes require topological visibility to also receive the SRv6 SIDs from nodes
across an IGP domain or even across Autonomous Systems (AS), as across an IGP domain or even across Autonomous Systems (ASes) as
required. This allows applications to leverage the SRv6 capabilities for required. This allows applications to leverage the SRv6 capabilities for
network programming.</t> network programming.</t>
<t>The identifying key of each link-state object, namely a node, link,
<t>The identifying key of each Link-State object, namely a node, link, or prefix, is encoded in the Network Layer Reachability Information
or prefix, is encoded in the Network-Layer Reachability Information (NLRI), and the properties of the object are encoded in the BGP-LS
(NLRI) and the properties of the object are encoded in the BGP-LS Attribute <xref target="RFC7752" format="default"/>.</t>
Attribute <xref target="RFC7752"/>.</t>
<t>This document describes extensions to BGP-LS to advertise the SRv6 <t>This document describes extensions to BGP-LS to advertise the SRv6
SIDs and other SRv6 information from all the SRv6 capable nodes in the SIDs and other SRv6 information from all the SRv6-capable nodes in the
IGP domain when sourced from link-state routing protocols and directly IGP domain when sourced from link-state routing protocols and directly
from individual SRv6 capable nodes (e.g. when sourced from BGP for from individual SRv6-capable nodes (e.g., when sourced from BGP for
EPE).</t> EPE).</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="BGP-LS-SRv6" numbered="true" toc="default">
<section anchor="BGP-LS-SRv6" title="BGP-LS Extensions for SRv6"> <name>BGP-LS Extensions for SRv6</name>
<t>BGP-LS <xref target="RFC7752"/> defines the Node, Link, and Prefix <t>BGP-LS <xref target="RFC7752" format="default"/> defines the Node, Link
Link-State Network Layer Reachability Information (NLRI) types and the , and Prefix
Link-State NLRI types and the
advertisement of their attributes via BGP.</t> advertisement of their attributes via BGP.</t>
<t>When a BGP-LS router advertises topology information that it sources <t>When a BGP-LS router advertises topology information that it sources
from the underlying link-state routing protocol, then it derives the from the underlying link-state routing protocol, it derives the
corresponding SRv6 information from the SRv6 extensions for IS-IS <xref corresponding SRv6 information from the SRv6 extensions for IS-IS <xref ta
target="I-D.ietf-lsr-isis-srv6-extensions"/> or OSPFv3 <xref rget="RFC9352" format="default"/> or OSPFv3 <xref target="RFC9513" format="defau
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>, as applicable. In lt"/> as applicable. In
practice, this derivation comprises a simple copy of the relevant fields practice, this derivation comprises a simple copy of the relevant fields
from the IS-IS/OSPFv3 TLV/sub-TLV into the fields of the corresponding from the IS-IS or OSPFv3 TLV/sub-TLV into the fields of the corresponding
BGP-LS TLV/sub-TLV. When a BGP-LS router advertises topology information BGP-LS TLV/sub-TLV.
from the BGP routing protocol (e.g., for EPE) or when it advertises SRv6
SIDs associated with a node using Direct as the Protocol-ID, then it When a BGP-LS router advertises topology information
from the BGP routing protocol (e.g., for EPE) or advertises SRv6
SIDs associated with a node using Direct as the Protocol-ID, it
derives the SRv6 information from the local node. Such information is derives the SRv6 information from the local node. Such information is
advertised only on behalf of the local router, in contrast to the advertised only on behalf of the local router, in contrast to the
advertisement of information from all nodes of an IGP domain when advertisement of information from all nodes of an IGP domain when
sourced from a link-state routing protocol.</t> sourced from a link-state routing protocol.</t>
<t>The SRv6 information pertaining to a node is advertised via the <t>The SRv6 information pertaining to a node is advertised via the
BGP-LS Node NLRI and using the BGP-LS Attribute TLVs as follows:</t> BGP-LS Node NLRI using the BGP-LS Attribute TLVs as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The SRv6 capabilities of the node are advertised via the SRv6
<t>SRv6 Capabilities of the node are advertised via the SRv6 Capabilities TLV (<xref target="SRCAPATTR" format="default"/>).</li>
Capabilities TLV (<xref target="SRCAPATTR"/>).</t> <li>Maximum SID Depth (MSD) types introduced for SRv6 are advertised
(<xref target="SRNODEMSD" format="default"/>) using the Node MSD TLV s
<t>Maximum SID Depth (MSD) types introduced for SRv6 are advertised pecified in
(<xref target="SRNODEMSD"/>) using the Node MSD TLV specified in <xref target="RFC8814" format="default"/>.</li>
<xref target="RFC8814"/></t> <li>Algorithm support for SRv6 is advertised via the SR-Algorithm TLV
specified in <xref target="RFC9085" format="default"/>.</li>
<t>Algorithm support for SRv6 is advertised via the SR-Algorithm TLV </ul>
specified in <xref target="RFC9085"/>.</t>
</list></t>
<t>The SRv6 information pertaining to a link is advertised via the <t>The SRv6 information pertaining to a link is advertised via the
BGP-LS Link NLRI and using the BGP-LS Attribute TLVs as follows:</t> BGP-LS Link NLRI using the BGP-LS Attribute TLVs as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency
<t>SRv6 SID of the IGP Adjacency SID or the BGP EPE Peer Adjacency SID <xref target="RFC8402" format="default"/> is advertised via the SR
SID <xref target="RFC8402"/> is advertised via the SRv6 End.X SID v6 End.X SID
TLV introduced in this document (<xref target="SRENDXTLV"/>).</t> TLV introduced in this document (<xref target="SRENDXTLV" format="defa
ult"/>).</li>
<t>SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR) <li>The SRv6 SID of the IGP Adjacency SID to a non-Designated Router (DR
or non-Designated Intermediate-System (DIS) <xref target="RFC8402"/> )
or non-Designated Intermediate System (DIS) <xref target="RFC8402" for
mat="default"/>
is advertised via the SRv6 LAN End.X SID TLV introduced in this is advertised via the SRv6 LAN End.X SID TLV introduced in this
document (<xref target="SRLANENDXTLV"/>).</t> document (<xref target="SRLANENDXTLV" format="default"/>).</li>
<li>MSD types introduced for SRv6 are advertised (<xref target="SRLINKMS
<t>MSD types introduced for SRv6 are advertised (<xref D" format="default"/>) using the Link MSD TLV specified in <xref target="RFC8814
target="SRLINKMSD"/>) using the Link MSD TLV specified in <xref " format="default"/>.</li>
target="RFC8814"/>.</t> </ul>
</list></t>
<t>The SRv6 information pertaining to a prefix is advertised via the <t>The SRv6 information pertaining to a prefix is advertised via the
BGP-LS Prefix NLRI and using the BGP-LS Attribute TLVs as follows:</t> BGP-LS Prefix NLRI using the BGP-LS Attribute TLVs as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The SRv6 Locator is advertised via the SRv6 Locator TLV introduced i
<t>SRv6 Locator is advertised via the SRv6 Locator TLV introduced in n
this document (<xref target="SRLOCTLV"/>).</t> this document (<xref target="SRLOCTLV" format="default"/>).</li>
<li>The attributes of the SRv6 Locator are advertised via the Prefix
<t>The attributes of the SRv6 Locator are advertised via the Prefix Attribute Flags TLV specified in <xref target="RFC9085" format="defaul
Attribute Flags TLV specified in <xref target="RFC9085"/>.</t> t"/>.</li>
</list></t> </ul>
<t>The SRv6 SIDs associated with the node are advertised using the <t>The SRv6 SIDs associated with the node are advertised using the
BGP-LS SRv6 SID NLRI introduced in this document (<xref BGP-LS SRv6 SID NLRI introduced in this document (<xref target="SRSIDNLRI"
target="SRSIDNLRI"/>). This enables the BGP-LS encoding to scale to format="default"/>).
This enables the BGP-LS encoding to scale to
cover a potentially large set of SRv6 SIDs instantiated on a node with cover a potentially large set of SRv6 SIDs instantiated on a node with
the granularity of individual SIDs and without affecting the size and the granularity of individual SIDs and without affecting the size and
scalability of the BGP-LS updates. Had the SRv6 SIDs been advertised scalability of the BGP-LS updates.
If the SRv6 SIDs had been advertised
within the BGP-LS Link Attribute associated with the existing Node NLRI, within the BGP-LS Link Attribute associated with the existing Node NLRI,
the BGP-LS update would have grown rather large with the increase in the BGP-LS update would have grown rather large with the increase in
SRv6 SIDs on the node and would have also required a large update SRv6 SIDs on the node and would have also required a large update
message to be generated for any change to even a single SRv6 SID. BGP-LS message to be generated for any change, even a change to a single SRv6 SID
Attribute TLVs for the SRv6 SID NLRI are introduced in this document as . BGP-LS
follows:</t> Attribute TLVs for the SRv6 SID NLRI are introduced in this document as fo
llows:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>The endpoint behavior of the SRv6 SID is advertised via the SRv6 <li>The Endpoint behavior of the SRv6 SID is advertised via the SRv6
Endpoint Behavior TLV (<xref target="SRFUNCTLV"/>).</t> Endpoint Behavior TLV (<xref target="SRFUNCTLV" format="default"/>).</
li>
<t>The BGP EPE Peer Node context for a PeerNode SID, and the Peer <li>The BGP EPE Peer Node context for a PeerNode SID and the Peer
Set context for a PeerSet SID <xref target="RFC8402"/> are Set context for a PeerSet SID <xref target="RFC8402" format="default"/
advertised via the SRv6 BGP EPE Peer Node SID TLV (<xref > are
target="SRPEERTLV"/>),</t> advertised via the SRv6 BGP PeerNode SID TLV (<xref target="SRPEERTLV"
</list></t> format="default"/>).</li>
</ul>
<t>Subsequent sections of this document specify the encoding and usage <t>Subsequent sections of this document specify the encoding and usage
of these extensions. All the TLVs introduced follow the formats and of these extensions. All the TLVs introduced follow the formats and
common field definitions provided in <xref target="RFC7752"/>.</t> common field definitions provided in <xref target="RFC7752" format="defaul t"/>.</t>
</section> </section>
<section anchor="SRNODEATTR" numbered="true" toc="default">
<section anchor="SRNODEATTR" title="SRv6 Node Attributes"> <name>SRv6 Node Attributes</name>
<t>The SRv6 attributes of a node are advertised using the BGP-LS <t>The SRv6 attributes of a node are advertised using the BGP-LS
Attribute TLVs defined in this section and associated with the BGP-LS Attribute TLVs defined in this section and associated with the BGP-LS
Node NLRI.</t> Node NLRI.</t>
<section anchor="SRCAPATTR" numbered="true" toc="default">
<section anchor="SRCAPATTR" title="SRv6 Capabilities TLV"> <name>SRv6 Capabilities TLV</name>
<t>This BGP-LS Attribute TLV is used to announce the SRv6 capabilities <t>This BGP-LS Attribute TLV is used to announce the SRv6 capabilities
of the node along with the BGP-LS Node NLRI and indicates the SRv6 of the node along with the BGP-LS Node NLRI and indicates the SRv6
support by the node. A single instance of this TLV MUST be included in support by the node. A single instance of this TLV <bcp14>MUST</bcp14>
the BGP-LS attribute for each SRv6 capable node. The IS-IS SRv6 be included in the BGP-LS Attribute for each SRv6-capable node. The
Capabilities sub-TLV <xref IS-IS SRv6 Capabilities sub-TLV <xref target="RFC9352"
target="I-D.ietf-lsr-isis-srv6-extensions"/> and the OSPFv3 SRv6 format="default"/> and the OSPFv3 SRv6 Capabilities TLV <xref
Capabilities TLV <xref target="I-D.ietf-lsr-ospfv3-srv6-extensions"/> target="RFC9513" format="default"/> that map to this BGP-LS TLV are
that map to this BGP-LS TLV are specified with the ability to carry specified with the ability to carry optional
optional sub-sub-TLVs/sub-TLVs. However, no such extensions are sub-sub-TLVs and sub-TLVs. However, no such extensions are currently
currently defined. Moreover, the SRv6 Capabilities TLV defined below defined. Moreover, the SRv6 Capabilities TLV defined below is not
is not extensible. As a result, it is expected that any extensions extensible. As a result, it is expected that any extensions will be
will be introduced as top-level TLVs in the BGP-LS Attribute.</t> introduced as top-level TLVs in the BGP-LS Attribute.
The SRv6 Capabilities
<t><figure anchor="SRCAPTLVFIG" title="SRv6 Capabilities TLV Format"> TLV has the following format:</t>
<artwork><![CDATA[ 0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<figure anchor="SRCAPTLVFIG">
<name>SRv6 Capabilities TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> Where:<list style="symbols"> </figure>
<t>Type: 1038</t>
<t>Length : 4.</t>
<t>Flags: 2 octet field. The flags are copied from the IS-IS SRv6 <t>where:</t>
Capabilities sub-TLV (section 2 of <xref
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or from the OSPFv3
SRv6 Capabilities TLV (section 2 of <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of
IS-IS or OSPFv3 respectively.</t>
<t>Reserved: 2 octet that MUST be set to 0 when originated and <dl newline="false" spacing="normal">
ignored on receipt.</t> <dt>Type:</dt> <dd>1038</dd>
</list></t> <dt>Length:</dt> <dd>4</dd>
<dt>Flags:</dt> <dd>2-octet field. The flags are copied from the IS-
IS SRv6
Capabilities sub-TLV (<xref target="RFC9352" sectionFormat="of" sect
ion="2"/>) or from the OSPFv3
SRv6 Capabilities TLV (<xref target="RFC9513" sectionFormat="of" sec
tion="2"/>) in the case of
IS-IS or OSPFv3, respectively.</dd>
<dt>Reserved:</dt><dd>2-octet field that <bcp14>MUST</bcp14> be set to 0 when or
iginated and
ignored on receipt.</dd>
</dl>
</section> </section>
<section anchor="SRNODEMSD" numbered="true" toc="default">
<section anchor="SRNODEMSD" title="SRv6 Node MSD Types"> <name>SRv6 Node MSD Types</name>
<t>The Node MSD TLV <xref target="RFC8814"/> of the BGP-LS Attribute <t>The Node MSD TLV <xref target="RFC8814" format="default"/> of the BGP
-LS Attribute
of the Node NLRI is also used to advertise the limits and the Segment of the Node NLRI is also used to advertise the limits and the Segment
Routing Header (SRH) <xref target="RFC8754"/> operations supported by Routing Header (SRH) <xref target="RFC8754" format="default"/> operation
the SRv6 capable node. The SRv6 MSD Types specified in section 4 of s supported by
<xref target="I-D.ietf-lsr-isis-srv6-extensions"/> are also used with the SRv6-capable node. The SRv6 MSD types specified in
the BGP-LS Node MSD TLV as these code points are shared between IS-IS, <xref target="RFC9352" sectionFormat="of" section="4"/> are also used wi
OSPF and BGP-LS protocols. The description and semantics of these new th
MSD-types for BGP-LS are identical as specified in <xref the BGP-LS Node MSD TLV, as these code points are shared between the IS-
target="I-D.ietf-lsr-isis-srv6-extensions"/>.</t> IS,
OSPF, and BGP-LS protocols. The description and semantics of these new
<t>Each MSD-type is encoded in the BGP-LS Node MSD TLV as a one-octet MSD types for BGP-LS are identical to those specified in <xref target="R
FC9352" format="default"/>.</t>
<t>Each MSD type is encoded in the BGP-LS Node MSD TLV as a one-octet
type followed by a one-octet value as derived from the IS-IS or OSPFv3 type followed by a one-octet value as derived from the IS-IS or OSPFv3
Node MSD advertisements as specified in <xref target="RFC8814"/>.</t> Node MSD advertisements specified in <xref target="RFC8814" format="defa ult"/>.</t>
</section> </section>
</section> </section>
<section anchor="SRLINKATTR" numbered="true" toc="default">
<section anchor="SRLINKATTR" title="SRv6 Link Attributes"> <name>SRv6 Link Attributes</name>
<t>SRv6 attributes and SIDs associated with a link or adjacency are <t>SRv6 attributes and SIDs associated with a link or adjacency are
advertised using the BGP-LS Attribute TLVs defined in this section and advertised using the BGP-LS Attribute TLVs defined in this section and
associated with the BGP-LS Link NLRI.</t> associated with the BGP-LS Link NLRI.</t>
<section anchor="SRENDXTLV" numbered="true" toc="default">
<section anchor="SRENDXTLV" title="SRv6 End.X SID TLV"> <name>SRv6 End.X SID TLV</name>
<t>The SRv6 End.X SID TLV is used to advertise the SRv6 SIDs <t>The SRv6 End.X SID TLV is used to advertise the SRv6 SIDs
associated with an IGP Adjacency SID behavior that correspond to a associated with an IGP Adjacency SID behavior that correspond to a
point-to-point or point-to-multipoint link or adjacency of the node point-to-point or point-to-multipoint link or adjacency of the node
running the IS-IS or OSPFv3 protocols. The information advertised via running the IS-IS or OSPFv3 protocols. The information advertised via
this TLV is derived from the IS-IS SRv6 End.X SID sub-TLV (section 8.1 this TLV is derived from the IS-IS SRv6 End.X SID sub-TLV (<xref target=
of <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 "RFC9352" sectionFormat="of" section="8.1"/>) or the OSPFv3
SRv6 End.X SID sub-TLV (section 9.1 of <xref SRv6 End.X SID sub-TLV (<xref target="RFC9513" sectionFormat="of" sectio
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS n="9.1"/>) in the case of IS-IS
or OSPFv3 respectively. This TLV can also be used to advertise the or OSPFv3, respectively. This TLV can also be used to advertise the
SRv6 SID corresponding to the underlying layer-2 member links for a SRv6 SID corresponding to the underlying Layer 2 member links for a
layer-3 bundle interface as a sub-TLV of the L2 Bundle Member Layer 3 bundle interface as a sub-TLV of the L2 Bundle Member
Attribute TLV <xref target="RFC9085"/>.</t> Attribute TLV <xref target="RFC9085" format="default"/>.</t>
<t>This TLV is also used by BGP-LS to advertise the BGP EPE Peer <t>This TLV is also used by BGP-LS to advertise the BGP EPE Peer
Adjacency SID for SRv6 on the same lines as specified for SR-MPLS in Adjacency SID for SRv6 on the same lines as specified for SR-MPLS in
<xref target="RFC9086"/>. The SRv6 SID for the BGP Peer Adjacency <xref target="RFC9086" format="default"/>. The SRv6 SID for the BGP Peer
using End.X behaviors (viz. End.X, End.X with PSP, End.X with USP, and Adjacency
End.X with PSP &amp; USP) <xref target="RFC8986"/> indicates the using End.X behaviors (viz.&nbsp;End.X, End.X with PSP, End.X with USP,
cross-connect to a specific layer-3 link to the specific BGP session and
End.X with PSP &amp; USP) <xref target="RFC8986" format="default"/> indi
cates the
cross-connect to a specific Layer 3 link to the specific BGP session
peer (neighbor).</t> peer (neighbor).</t>
<t>More than one instance of this TLV (one for each SRv6 End.X SID) can
<t>More than one instance of this TLV can be included in the BGP-LS be included in the BGP-LS
Attribute; one for each SRv6 End.X SID.</t> Attribute.</t>
<t>The TLV has the following format:</t> <t>The TLV has the following format:</t>
<figure anchor="ENDXTLV">
<t><figure anchor="ENDXTLV" title="SRv6 End.X TLV Format"> <name>SRv6 End.X SID TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Algorithm | | Endpoint Behavior | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | Reserved | SID (16 octets) ... | | Weight | Reserved | SID (16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | Sub-TLVs (variable) . . . | SID (cont ...) | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1106</t> </figure>
<t>Length: variable</t>
<t>Endpoint Behavior: 2 octet field. The Endpoint Behavior code
point for this SRv6 SID as defined in section 10.2 of <xref
target="RFC8986"/>.</t>
<t>Flags: 1 octet of flags. The flags are copied from the IS-IS
SRv6 End.X SID sub-TLV (section 8.1 of <xref
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6
End.X SID sub-TLV (section 9.1 of <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of
IS-IS or OSPFv3 respectively. In the case of BGP EPE Peer
Adjacency SID, the flags are as defined in <xref
target="SRPEERTLV"/>.</t>
<t>Algorithm: 1 octet field. Algorithm associated with the <t>where:</t>
SID.</t>
<t>Weight: 1 octet field. The value represents the weight of the <dl newline="false" spacing="normal">
<dt>Type:</dt><dd>1106</dd>
<dt>Length:</dt><dd>variable</dd>
<dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint behavior co
de
point for this SRv6 SID as defined in <xref target="RFC8986" section
Format="of" section="10.2"/>.</dd>
<dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the
IS-IS SRv6 End.X SID sub-TLV (<xref target="RFC9352"
sectionFormat="of" section="8.1"/>) or the OSPFv3 SRv6 End.X SID
sub-TLV (<xref target="RFC9513" sectionFormat="of" section="9.1"/>)
in the case of IS-IS or OSPFv3, respectively. In the case of the BGP E
PE
Peer Adjacency SID, the flags are as defined in <xref
target="SRPEERTLV" format="default"/>.</dd>
<dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
SID.</dd>
<dt>Weight:</dt><dd>1-octet field. The value represents the weight of
the
SID for the purpose of load balancing. The use of the weight is SID for the purpose of load balancing. The use of the weight is
defined in <xref target="RFC8402"/>.</t> defined in <xref target="RFC8402" format="default"/>.</dd>
<dt>Reserved:</dt><dd>1-octet field that <bcp14>MUST</bcp14> be set to
<t>Reserved: 1 octet field that MUST be set to 0 when originated 0 when originated
and ignored on receipt.</t> and ignored on receipt.</dd>
<dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv
<t>SID: 16 octet field. This field encodes the advertised SRv6 SID 6 SID
as 128 bit value.</t> as a 128-bit value.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
<t>Sub-TLVs : Used to advertise sub-TLVs that provide additional al
attributes for the specific SRv6 SID. This document defines one in attributes for the specific SRv6 SID. This document defines one in
<xref target="SRSTRUCTTLV"/>.</t> <xref target="SRSTRUCTTLV" format="default"/>.</dd>
</list></t> </dl>
</section> </section>
<section anchor="SRLANENDXTLV" numbered="true" toc="default">
<name>SRv6 LAN End.X SID TLV</name>
<section anchor="SRLANENDXTLV" title="SRv6 LAN End.X SID TLV ">
<t>For a LAN interface, an IGP node ordinarily announces only its <t>For a LAN interface, an IGP node ordinarily announces only its
adjacency to the IS-IS pseudo-node (or the equivalent OSPF DR). The adjacency to the IS-IS pseudonode (or the equivalent OSPF DR). The
information advertised via this TLV is derived from the IS-IS SRv6 LAN information advertised via this TLV is derived from the IS-IS SRv6 LAN
End.X SID sub-TLV (section 8.2 of <xref End.X SID sub-TLV (<xref target="RFC9352" sectionFormat="of" section="8.
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6 LAN 2"/>) or the OSPFv3 SRv6 LAN
End.X sub-TLV (section 9.2 of <xref End.X SID sub-TLV (<xref target="RFC9513" sectionFormat="of" section="9.
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS 2"/>) in the case of IS-IS
or OSPFv3 respectively. The SRv6 LAN End.X SID TLV allows a node to or OSPFv3, respectively. The SRv6 LAN End.X SID TLV allows a node to
announce the SRv6 SID corresponding to its adjacencies to all other announce the SRv6 SID corresponding to its adjacencies to all other
(i.e., non-DIS or non-DR) nodes attached to the LAN in a single (i.e., non-DIS or non-DR) nodes attached to the LAN in a single
instance of the BGP-LS Link NLRI. Without this TLV, multiple BGP-LS instance of the BGP-LS Link NLRI. Without this TLV, multiple BGP-LS
Link NLRIs would need to be originated, one for each neighbor, to Link NLRIs would need to be originated, one for each neighbor, to
advertise the SRv6 End.X SID TLVs for those non-DIS/non-DR neighbors. advertise the SRv6 End.X SID TLVs for those non-DIS/non-DR neighbors.
The SRv6 SID for these IGP adjacencies using the End.X behaviors (viz. The SRv6 SID for these IGP adjacencies using the End.X behaviors (viz.&n
End.X, End.X with PSP, End.X with USP, and End.X with PSP &amp; USP) bsp;End.X, End.X with PSP, End.X with USP, and End.X with PSP &amp; USP)
<xref target="RFC8986"/> are advertised using the SRv6 LAN End.X SID <xref target="RFC8986" format="default"/> are advertised using the SRv6
LAN End.X SID
TLV.</t> TLV.</t>
<t>More than one instance of this TLV (one for each SRv6 LAN End.X SID)
<t>More than one instance of this TLV can be included in the BGP-LS can be included in the BGP-LS
Attribute; one for each SRv6 LAN End.X SID.</t> Attribute.</t>
<t>The BGP-LS IS-IS SRv6 LAN End.X SID and BGP-LS OSPFv3 SRv6 LAN <t>The BGP-LS IS-IS SRv6 LAN End.X SID and BGP-LS OSPFv3 SRv6 LAN
End.X SID TLVs have the following format:</t> End.X SID TLVs have the following format:</t>
<figure anchor="ENDLXTLV">
<t><figure anchor="ENDLXTLV" title="SRv6 LAN End.X SID TLV Format"> <name>SRv6 LAN End.X SID TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Algorithm | | Endpoint Behavior | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | Reserved | Neighbor ID - | | Weight | Reserved | Neighbor ID - |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IS-IS System-ID (6 octets) or OSPFv3 Router-ID (4 octets) | | IS-IS System-ID (6 octets) or OSPFv3 Router-ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (16 octets) ... | | SID (16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list style="symbols"> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1107 in case of IS-IS and 1108 in case of OSPFv3</t> </figure>
<t>Length: variable</t>
<t>Endpoint Behavior: 2 octet field. The Endpoint Behavior code
point for this SRv6 SID as defined in section 10.2 of <xref
target="RFC8986"/>.</t>
<t>Flags: 1 octet of flags. The flags are copied from the IS-IS
SRv6 LAN End.X SID sub-TLV (section 8.2 of <xref
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6
LAN End.X SID sub-TLV (section 9.2 of <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of
IS-IS or OSPFv3 respectively.</t>
<t>Algorithm: 1 octet field. Algorithm associated with the
SID.</t>
<t>Weight: 1 octet field. The value represents the weight of the
SID for the purpose of load balancing.</t>
<t>Reserved: 1 octet field that MUST be set to 0 when originated
and ignored on receipt.</t>
<t>Neighbor ID : 6 octets of Neighbor System-ID in IS-IS SRv6 LAN
End.X SID TLV or 4 octets of Neighbor Router-id in the OSPFv3 SRv6
LAN End.X SID TLV.</t>
<t>SID: 16 octet field. This field encodes the advertised SRv6 SID <t>where:</t>
as 128 bit value.</t>
<t>Sub-TLVs : Used to advertise sub-TLVs that provide additional <dl newline="false" spacing="normal">
<dt>Type:</dt><dd>1107 for IS-IS and 1108 for OSPFv3</dd>
<dt>Length:</dt><dd>variable</dd>
<dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint behavior co
de
point for this SRv6 SID as defined in <xref target="RFC8986" section
Format="of" section="10.2"/>.</dd>
<dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the IS-
IS
SRv6 LAN End.X SID sub-TLV (<xref target="RFC9352" sectionFormat="of
" section="8.2"/>) or the OSPFv3 SRv6
LAN End.X SID sub-TLV (<xref target="RFC9513" sectionFormat="of" sec
tion="9.2"/>) in the case of
IS-IS or OSPFv3, respectively.</dd>
<dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
SID.</dd>
<dt>Weight:</dt><dd>1-octet field. The value represents the weight of
the
SID for the purpose of load balancing.</dd>
<dt>Reserved:</dt><dd>1-octet field that <bcp14>MUST</bcp14> be set to
0 when originated
and ignored on receipt.</dd>
<dt>Neighbor ID:</dt><dd>6 octets of Neighbor System-ID in the IS-IS S
Rv6 LAN
End.X SID TLV or 4 octets of Neighbor Router-ID in the OSPFv3 SRv6
LAN End.X SID TLV.</dd>
<dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv
6 SID
as a 128-bit value.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
al
attributes for the specific SRv6 SID. This document defines one in attributes for the specific SRv6 SID. This document defines one in
<xref target="SRSTRUCTTLV"/>.</t> <xref target="SRSTRUCTTLV" format="default"/>.</dd>
</list></t> </dl>
</section>
<section anchor="SRLINKMSD" title="SRv6 Link MSD Types"> </section>
<t>The Link MSD TLV <xref target="RFC8814"/> of the BGP-LS Attribute <section anchor="SRLINKMSD" numbered="true" toc="default">
<name>SRv6 Link MSD Types</name>
<t>The Link MSD TLV <xref target="RFC8814" format="default"/> of the BGP
-LS Attribute
of the Link NLRI is also used to advertise the limits and the SRH of the Link NLRI is also used to advertise the limits and the SRH
operations supported on the specific link by the SRv6 capable node. operations supported on the specific link by the SRv6-capable node.
The SRv6 MSD Types specified in section 4 of<xref The SRv6 MSD types specified in <xref target="RFC9352" sectionFormat="of
target="I-D.ietf-lsr-isis-srv6-extensions"> </xref> are also used with " section="4"> </xref> are also used with
the BGP-LS Link MSD TLV as these code points are shared between IS-IS, the BGP-LS Link MSD TLV, as these code points are shared between the IS-
IS,
OSPF, and BGP-LS protocols. The description and semantics of these new OSPF, and BGP-LS protocols. The description and semantics of these new
MSD types for BGP-LS are identical as specified in <xref MSD types for BGP-LS are identical as specified in <xref target="RFC9352
target="I-D.ietf-lsr-isis-srv6-extensions"/>.</t> " format="default"/>.</t>
<t>Each MSD type is encoded in the BGP-LS Link MSD TLV as a one-octet
<t>Each MSD-type is encoded in the BGP-LS Link MSD TLV as a one-octet
type followed by a one-octet value as derived from the IS-IS or OSPFv3 type followed by a one-octet value as derived from the IS-IS or OSPFv3
Link MSD advertisements as specified in <xref target="RFC8814"/>.</t> Link MSD advertisements specified in <xref target="RFC8814" format="defa ult"/>.</t>
</section> </section>
</section> </section>
<section anchor="SRPFXATTR" numbered="true" toc="default">
<section anchor="SRPFXATTR" title="SRv6 Prefix Attributes"> <name>SRv6 Prefix Attributes</name>
<t>SRv6 attributes with an IPv6 prefix are advertised using the BGP-LS <t>SRv6 attributes with an IPv6 prefix are advertised using the BGP-LS
Attribute TLVs defined in this section and associated with the BGP-LS Attribute TLVs defined in this section and associated with the BGP-LS
Prefix NLRI.</t> Prefix NLRI.</t>
<section anchor="SRLOCTLV" numbered="true" toc="default">
<section anchor="SRLOCTLV" title="SRv6 Locator TLV"> <name>SRv6 Locator TLV</name>
<t>As specified in <xref target="RFC8986"/>, an SRv6 SID comprises <t>As specified in <xref target="RFC8986" format="default"/>, an SRv6 SI
Locator, Function and Argument parts.</t> D comprises
locator, function, and argument parts.</t>
<t>A node is provisioned with one or more Locators supported by that <t>A node is provisioned with one or more locators supported by that
node. Locators are covering prefixes for the set of SIDs provisioned node. Locators are covering prefixes for the set of SIDs provisioned
on that node. Each Locator is advertised as a BGP-LS Prefix NLRI on that node. Each locator is advertised as a BGP-LS Prefix NLRI
object along with the SRv6 Locator TLV in its BGP-LS Attribute.</t> object along with the SRv6 Locator TLV in its BGP-LS Attribute.</t>
<t>The information advertised via this TLV is derived from the IS-IS <t>The information advertised via this TLV is derived from the IS-IS
SRv6 Locator TLV (section 7.1 of <xref SRv6 Locator TLV (<xref target="RFC9352" sectionFormat="of" section="7.1
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6 "/>) or the OSPFv3 SRv6
Locator TLV (section 7.1 of <xref Locator TLV (<xref target="RFC9513" sectionFormat="of" section="7.1"/>)
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS in the case of IS-IS
or OSPFv3 respectively.</t> or OSPFv3, respectively.</t>
<t>The IPv6 Prefix matching the locator may also be advertised as
<t>The IPv6 Prefix matching the Locator may be also advertised as
prefix reachability by the underlying routing protocol. In this case, prefix reachability by the underlying routing protocol. In this case,
the Prefix NLRI would be also associated with the Prefix Metric TLV the Prefix NLRI would also be associated with the Prefix Metric TLV
<xref target="RFC7752"/> that carries the routing metric for this <xref target="RFC7752" format="default"/> that carries the routing metri
prefix. A Prefix NLRI, that has been advertised with a SRv6 Locator c for this
TLV, is also considered a normal routing prefix (i.e., prefix prefix. A Prefix NLRI that has been advertised with a SRv6 Locator
reachability) only when there is also an IGP metric TLV (TLV 1095) TLV is also considered a normal routing prefix (i.e., prefix
associated it. Otherwise, it is considered only as an SRv6 Locator reachability) only when there is also an IGP Metric TLV (TLV 1095)
associated it. Otherwise, it is only considered an SRv6 Locator
advertisement.</t> advertisement.</t>
<t>The SRv6 Locator TLV has the following format: </t>
<t>The SRv6 Locator TLV has the following format: <figure <figure anchor="SRV6LOCFIG">
anchor="SRV6LOCFIG" title="SRv6 Locator TLV Format"> <name>SRv6 Locator TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | Reserved | | Flags | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1162</t> </figure>
<t>Length: variable</t>
<t>Flags: 1 octet of flags. The flags are copied from the IS-IS
SRv6 Locator TLV (section 7.1 of <xref
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6
Locator TLV (section 7.1 of <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of
IS-IS or OSPFv3 respectively.</t>
<t>Algorithm: 1 octet field. Algorithm associated with the
SID.</t>
<t>Reserved: 2 octet field. The value MUST be set to 0 when
originated and ignored on receipt.</t>
<t>Metric: 4 octet field. The value of the metric for the Locator <t>where:</t>
copied from the IS-IS SRv6 Locator TLV (section 7.1 of <xref
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6
Locator TLV (section 7.1 of <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of
IS-IS or OSPFv3 respectively.</t>
<t>Sub-TLVs : Used to advertise sub-TLVs that provide additional <dl newline="false">
<dt>Type:</dt><dd>1162</dd>
<dt>Length:</dt><dd>variable</dd>
<dt>Flags:</dt><dd>1 octet of flags. The flags are copied from the IS-
IS
SRv6 Locator TLV (<xref target="RFC9352" sectionFormat="of" section=
"7.1"/>) or the OSPFv3 SRv6
Locator TLV (<xref target="RFC9513" sectionFormat="of" section="7.1"
/>) in the case of
IS-IS or OSPFv3, respectively.</dd>
<dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
SID.</dd>
<dt>Reserved:</dt><dd>2-octet field. The value <bcp14>MUST</bcp14> be
set to 0 when
originated and ignored on receipt.</dd>
<dt>Metric:</dt><dd>4-octet field. The value of the metric for the loc
ator
copied from the IS-IS SRv6 Locator TLV (<xref target="RFC9352" secti
onFormat="of" section="7.1"/>) or the OSPFv3 SRv6
Locator TLV (<xref target="RFC9513" sectionFormat="of" section="7.1"
/>) in the case of
IS-IS or OSPFv3, respectively.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
al
attributes for the given SRv6 Locator. Currently, none are attributes for the given SRv6 Locator. Currently, none are
defined.</t> defined.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="SRSIDNLRI" numbered="true" toc="default">
<section anchor="SRSIDNLRI" title="SRv6 SID NLRI"> <name>SRv6 SID NLRI</name>
<t>The "Link-State NLRI" defined in <xref target="RFC7752"/> is extended <t>The Link-State NLRI defined in <xref target="RFC7752" format="default"/
> is extended
to carry the SRv6 SID information.</t> to carry the SRv6 SID information.</t>
<t>This document defines the following new Link-State NLRI type for SRv6 S
<t>A new "Link-State NLRI Type" is defined for SRv6 SID information as ID information: SRv6 SID NLRI (type 6).
follows:</t> </t>
<t><list style="symbols">
<t>Link-State NLRI Type: SRv6 SID NLRI (value 6).</t>
</list></t>
<t>The SRv6 SIDs associated with the node are advertised using the <t>The SRv6 SIDs associated with the node are advertised using the
BGP-LS SRv6 SID NLRI.</t> BGP-LS SRv6 SID NLRI.</t>
<t>This new NLRI type has the following format:</t>
<t>The format of this new NLRI type is as shown in the following <figure anchor="SRSIDNLRIFIG">
figure:</t> <name>SRv6 SID NLRI Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure anchor="SRSIDNLRIFIG" title="SRv6 SID NLRI Format"> 0 1 2 3
<artwork><![CDATA[ 0 1 2 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
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 | Protocol-ID |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-ID | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (8 octets) |
| Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (8 octets) | | Local Node Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Node Descriptors (variable) // | SRv6 SID Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list style="symbols"> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Protocol-ID: 1-octet field that specifies the information source </figure>
protocol <xref target="RFC7752"/>.</t>
<t>Identifier: 8 octet value as defined in <xref
target="RFC7752"/>.</t>
<t>Local Node Descriptors TLV: set of Node Descriptor TLVs for the <t>where:</t>
local node, as defined in <xref target="RFC7752"/> for IGPs, direct,
and static configuration or as defined in <xref target="RFC9086"/>
for BGP protocol.</t>
<t>SRv6 SID Descriptors: set of SRv6 SID Descriptor TLVs. This field <dl newline="false" spacing="normal">
MUST contain a single SRv6 SID Information TLV (<xref <dt>Protocol-ID:</dt><dd>1-octet field that specifies the information so
target="SRSIDINFO"/>) and MAY contain the Multi-Topology Identifier urce
TLV <xref target="RFC7752"/>.</t> protocol <xref target="RFC7752" format="default"/>.</dd>
</list></t> <dt>Identifier:</dt><dd>8-octet value as defined in <xref target="RFC775
2" format="default"/>.</dd>
<dt>Local Node Descriptors TLV:</dt><dd>Set of Node Descriptor TLVs for
the
local node as defined in <xref target="RFC7752" format="default"/> for
IGPs, the Direct Protocol-ID,
and the Static configuration Protocol-ID or as defined in <xref target="RF
C9086" format="default"/>
for BGP.</dd>
<dt>SRv6 SID Descriptors:</dt><dd>Set of SRv6 SID Descriptor TLVs. This
field
<bcp14>MUST</bcp14> contain a single SRv6 SID Information TLV (<xref t
arget="SRSIDINFO" format="default"/>) and <bcp14>MAY</bcp14> contain the Multi-T
opology Identifier
TLV <xref target="RFC7752" format="default"/>.</dd>
</dl>
<t>New TLVs for advertisement within the BGP-LS Attribute <xref <t>New TLVs for advertisement within the BGP-LS Attribute <xref target="RF
target="RFC7752"/> are defined in <xref target="SRSIDATTR"/> to carry C7752" format="default"/> are defined in <xref target="SRSIDATTR" format="defaul
t"/> to carry
the attributes of an SRv6 SID.</t> the attributes of an SRv6 SID.</t>
<section anchor="SRSIDINFO" numbered="true" toc="default">
<section anchor="SRSIDINFO" title="SRv6 SID Information TLV"> <name>SRv6 SID Information TLV</name>
<t>An SRv6 SID that is associated with the node and advertised using <t>An SRv6 SID that is associated with the node and advertised using
the SRv6 SID NLRI is encoded using the SRv6 SID Information TLV.</t> the SRv6 SID NLRI is encoded using the SRv6 SID Information TLV.</t>
<t>When advertising the SRv6 SIDs from the IGPs, the SID information <t>When advertising the SRv6 SIDs from the IGPs, the SID information
is derived from the IS-IS SRv6 End SID sub-TLV (section 7.2 of <xref is derived from the IS-IS SRv6 End SID sub-TLV (<xref target="RFC9352" s
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6 End ectionFormat="of" section="7.2"/>) or the OSPFv3 SRv6 End
SID sub-TLV (section 8 of <xref SID sub-TLV (<xref target="RFC9513" sectionFormat="of" section="8"/>) in
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS the case of IS-IS
or OSPFv3 respectively.</t> or OSPFv3, respectively.</t>
<t>The TLV carries the SRv6 SIDs corresponding to the BGP PeerNode and <t>The TLV carries the SRv6 SIDs corresponding to the BGP PeerNode and
PeerSet SID <xref target="RFC8402"/> when SRv6 BGP EPE functionality PeerSet SIDs <xref target="RFC8402" format="default"/> when SRv6 BGP EPE functionality
is enabled in BGP.</t> is enabled in BGP.</t>
<t>The TLV has the following format: </t>
<t>The TLV has the following format: <figure anchor="SRV6SIDDESC" <figure anchor="SRV6SIDDESC">
title="SRv6 SID Information TLV Format"> <name>SRv6 SID Information TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (16 octets) ... | | SID (16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (cont ...) | | SID (cont ...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 518</t> </figure>
<t>Length: 16.</t> <t>where:</t>
<dl newline="false" spacing="normal">
<dt>Type:</dt><dd>518</dd>
<dt>Length:</dt><dd>16</dd>
<dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv
6 SID
as a 128-bit value.</dd>
</dl>
<t>SID: 16 octet field. This field encodes the advertised SRv6 SID
as 128 bit value.</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="SRSIDATTR" numbered="true" toc="default">
<section anchor="SRSIDATTR" title="SRv6 SID Attributes"> <name>SRv6 SID Attributes</name>
<t>This section specifies the TLVs to be carried in the BGP Link State <t>This section specifies the TLVs to be carried in the BGP Link State
Attribute associated with the BGP-LS SRv6 SID NLRI.</t> Attribute associated with the BGP-LS SRv6 SID NLRI.</t>
<section anchor="SRFUNCTLV" numbered="true" toc="default">
<section anchor="SRFUNCTLV" title="SRv6 Endpoint Behavior TLV"> <name>SRv6 Endpoint Behavior TLV</name>
<t>Each SRv6 SID instantiated on an SRv6 capable node has specific <t>Each SRv6 SID instantiated on an SRv6-capable node has specific
instructions (called behavior) bound to it. <xref target="RFC8986"/> instructions (called "behavior") bound to it. <xref target="RFC8986" for
mat="default"/>
describes how behaviors are bound to a SID and also defines the describes how behaviors are bound to a SID and also defines the
initial set of well-known behaviors.</t> initial set of well-known behaviors.</t>
<t>The SRv6 Endpoint Behavior TLV is a mandatory TLV that <bcp14>MUST</b
<t>The SRv6 Endpoint Behavior TLV is a mandatory TLV that MUST be cp14> be
included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID
NLRI.</t> NLRI.</t>
<t>When advertising the SRv6 SIDs from the IGPs, the Endpoint <t>When advertising the SRv6 SIDs from the IGPs, the Endpoint
behavior, Flags, and Algorithm are derived from the IS-IS SRv6 End SID behavior, Flags, and Algorithm are derived from the IS-IS SRv6 End SID
sub-TLV (section 7.2 of <xref sub-TLV (<xref target="RFC9352" sectionFormat="of" section="7.2"/>) or t
target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the OSPFv3 SRv6 End he OSPFv3 SRv6 End
SID sub-TLV (section 8 of <xref SID sub-TLV (<xref target="RFC9513" sectionFormat="of" section="8"/>) in
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS the case of IS-IS
or OSPFv3 respectively.</t> or OSPFv3, respectively.</t>
<t>When advertising the SRv6 SIDs corresponding to the BGP EPE <t>When advertising the SRv6 SIDs corresponding to the BGP EPE
functionality, the Endpoint Behavior corresponds to End.X and similar functionality, the Endpoint behavior corresponds to End.X and similar
behaviors. When advertising the SRv6 SIDs that are locally behaviors. When advertising the SRv6 SIDs that are locally
instantiated on the node using Direct as the Protoocl-ID, The Endpoint instantiated on the node using Direct as the Protocol-ID, the Endpoint
Behavior corresponds to any SRv6 Endpoint Behavior associated with the behavior corresponds to any SRv6 Endpoint behavior associated with the
node. Flags are currently not defined. The algorithm value MUST be 0 node. Flags are currently not defined. The algorithm value <bcp14>MUST</
bcp14> be 0
unless an algorithm is associated locally with the SRv6 Locator from unless an algorithm is associated locally with the SRv6 Locator from
which the SID is allocated.</t> which the SID is allocated.</t>
<t>The TLV has the following format:</t> <t>The TLV has the following format:</t>
<figure anchor="SRENDFUNC">
<t><figure anchor="SRENDFUNC" title="SRv6 Endpoint Behavior TLV"> <name>SRv6 Endpoint Behavior TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Algorithm | | Endpoint Behavior | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1250</t> </figure>
<t>Length: 4.</t> <t>where:</t>
<t>Endpoint Behavior: 2 octet field. The Endpoint Behavior code <dl newline="false" spacing="normal">
point for this SRv6 SID. Support values are those from the "SRv6 <dt>Type:</dt><dd>1250</dd>
Endpoint Behaviors" IANA registry (as established via section 10.2 <dt>Length:</dt><dd>4</dd>
of <xref target="RFC8986"/>).</t> <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint behavior co
de
point for this SRv6 SID. Values are from the "SRv6
Endpoint Behaviors" IANA registry (<xref target="RFC8986" sectionFor
mat="of" section="10.2"/>).</dd>
<t>Flags: 1 octet of flags. The flags map to the IS-IS or OSPFv3 <dt>Flags:</dt><dd>1 octet of flags. The flags map to the IS-IS or
encodings when advertising SRv6 SIDs corresponding to IGPs. For OSPFv3 encodings when advertising SRv6 SIDs corresponding to IGPs.
SRv6 SIDs corresponding to BGP EPE and when advertising SRv6 SID No flags are currently defined for SRv6 SIDs corresponding to BGP
using Direct Protocol-ID, none are defined currently and they MUST EPE or for advertisement of a SRv6 SID using Direct as the
be set to 0 when originated and ignored on receipt.</t> Protocol-ID. Undefined flags <bcp14>MUST</bcp14> be set to 0 when or
iginating and ignored on
receipt. </dd>
<dt>Algorithm:</dt><dd>1-octet field. Algorithm associated with the
SID.</dd>
</dl>
<t>Algorithm: 1 octet field. Algorithm associated with the
SID.</t>
</list></t>
</section> </section>
<section anchor="SRPEERTLV" numbered="true" toc="default">
<section anchor="SRPEERTLV" title="SRv6 BGP Peer Node SID TLV"> <name>SRv6 BGP PeerNode SID TLV</name>
<t>The BGP PeerNode SID and PeerSet SID for SR-MPLS are specified in <t>The BGP PeerNode and PeerSet SIDs for SR-MPLS are specified in
<xref target="RFC9086"/>. Similar Peer Node and Peer Set functionality <xref target="RFC9086" format="default"/>. Similar Peer Node and Peer Se
t functionality
can be realized with SRv6 using SIDs with END.X behavior. Refer to can be realized with SRv6 using SIDs with END.X behavior. Refer to
<xref target="BGPEPE"/> for some differences between the signaling of <xref target="BGPEPE" format="default"/> for some differences between th
these SIDs in SR-MPLS and SRv6. The SRv6 BGP Peer Node SID TLV is a e signaling of
these SIDs in SR-MPLS and SRv6. The SRv6 BGP PeerNode SID TLV is a
mandatory TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI mandatory TLV for use in the BGP-LS Attribute for an SRv6 SID NLRI
advertised by BGP for the EPE functionality. This TLV MUST be included advertised by BGP for the EPE functionality. This TLV <bcp14>MUST</bcp14 > be included
along with SRv6 SIDs that are associated with the BGP PeerNode or along with SRv6 SIDs that are associated with the BGP PeerNode or
PeerSet functionality.</t> PeerSet functionality.</t>
<t>The TLV has the following format:</t> <t>The TLV has the following format:</t>
<figure anchor="SRPEERTLVFIG">
<t><figure anchor="SRPEERTLVFIG" <name>SRv6 BGP PeerNode SID TLV Format</name>
title="SRv6 BGP Peer Node SID TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
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 | Length |
| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved |
| Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer AS Number |
| Peer AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer BGP Identifier |
| Peer BGP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list style="symbols"> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1251</t> </figure>
<t>Length: 12</t> <t>where:</t>
<t>Flags: 1 octet of flags with the following definition: <figure <dl newline="false" spacing="normal">
anchor="ENDXBGPFLAGS" title="SRv6 BGP EPE SID Flags Format"> <dt>Type:</dt><dd>1251</dd>
<artwork align="left"><![CDATA[ 0 1 2 3 4 5 6 7 <dt>Length:</dt><dd>12</dd>
+-+-+-+-+-+-+-+-+ <dt>Flags:</dt><dd><t>1 octet of flags with the following definitions:
|B|S|P| | </t>
+-+-+-+-+-+-+-+-+
<figure anchor="ENDXBGPFLAGS">
<name>SRv6 BGP EPE SID Flags Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| |
+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="symbols"> </figure>
<t>B-Flag: Backup Flag. If set, the SID is eligible to be
protected using fast reroute (FRR). The computation of the
backup forwarding path and its association with the forwarding
entry for the Peer BGP Identifier is implementation
specific.</t>
<t>S-Flag: Set Flag. When set, the S-Flag indicates that the <dl newline="false" spacing="normal">
<dt>B-Flag:</dt><dd>Backup Flag. If set, the SID is eligible to
be protected using Fast Reroute (FRR). The computation of the
backup forwarding path and its association with the forwarding
entry for the Peer BGP Identifier are implementation specific.</dd
>
<dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that
the
SID refers to a set of BGP peering sessions (i.e., BGP Peer SID refers to a set of BGP peering sessions (i.e., BGP Peer
Set SID functionality) and therefore MAY be assigned to one or Set SID functionality) and therefore <bcp14>MAY</bcp14> be assig
more End.X SIDs associated with BGP peer sessions.</t> ned to one or
more End.X SIDs associated with BGP peering sessions.</dd>
<t>P-Flag: Persistent Flag: When set, the P-Flag indicates <dt>P-Flag:</dt><dd>Persistent Flag. When set, the P-Flag indicate
s
that the SID is persistently allocated, i.e., the value that the SID is persistently allocated, i.e., the value
remains consistent across router restart and/or session remains consistent across router restart and/or session
flap.</t> flap.</dd>
<dt>Other bits are reserved for future use and
<t>Other bits are reserved for future use and MUST be set to 0 <bcp14>MUST</bcp14> be set to 0 when originated and ignored on
when originated and ignored on receipt.</t> receipt. The flags defined above are also used with the SRv6
</list> The flags defined above are also used with the SRv6 End.X SID TLV when advertising the SRv6 BGP Peer Adjacency SID
End.X SID TLV when advertising SRv6 BGP Peer Adjacency SID (<xref (<xref target="SRENDXTLV" format="default"/>).</dt><dd></dd>
target="SRENDXTLV"/>).</t> </dl></dd>
<t>Weight: 1 octet field. The value represents the weight of the <dt>Weight:</dt><dd>1-octet field. The value represents the weight of the
SID for the purpose of load balancing. The use of the weight is SID for the purpose of load balancing. The use of the weight is
defined in <xref target="RFC8402"/>.</t> defined in <xref target="RFC8402" format="default"/>.</dd>
<dt>Reserved:</dt><dd>2-octet field. The value <bcp14>MUST</bcp14> be
<t>Reserved: 2 octet field. The value MUST be set to 0 when set to 0 when
originated and ignored on receipt.</t> originated and ignored on receipt.</dd>
<dt>Peer AS Number:</dt><dd>4 octets of the BGP AS number of the peer
<t>Peer AS Number : 4 octets of BGP AS number of the peer router.</dd>
router.</t> <dt>Peer BGP Identifier:</dt><dd>4 octets of the BGP Identifier (BGP
Router-ID) of the peer router.</dd>
<t>Peer BGP Identifier : 4 octets of the BGP Identifier (BGP </dl>
Router-ID) of the peer router.</t>
</list></t>
<t>For an SRv6 BGP EPE Peer Node SID, one instance of this TLV is <t>For an SRv6 BGP EPE PeerNode SID, one instance of this TLV is
associated with the SRv6 SID. For SRv6 BGP EPE Peer Set SID, multiple associated with the SRv6 SID. For an SRv6 BGP EPE PeerSet SID, multiple
instances of this TLV (one for each peer in the &ldquo;peer instances of this TLV (one for each peer in the "peer
set&rdquo;) are associated with the SRv6 SID and the S-Flag is set") are associated with the SRv6 SID and the S-Flag is
SET.</t> set.</t>
</section> </section>
</section> </section>
<section anchor="SRSTRUCTTLV" numbered="true" toc="default">
<section anchor="SRSTRUCTTLV" title="SRv6 SID Structure TLV"> <name>SRv6 SID Structure TLV</name>
<t>The SRv6 SID Structure TLV is used to advertise the length of each <t>The SRv6 SID Structure TLV is used to advertise the length of each
individual part of the SRv6 SID as defined in <xref target="RFC8986"/>. individual part of the SRv6 SID as defined in <xref target="RFC8986" forma t="default"/>.
It is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID It is an optional TLV for use in the BGP-LS Attribute for an SRv6 SID
NLRI and as a sub-TLV of the SRv6 End.X SID, IS-IS SRv6 LAN End.X SID, NLRI and as a sub-TLV of the SRv6 End.X SID, IS-IS SRv6 LAN End.X SID,
and OSPFv3 SRv6 LAN End.X SID TLVs.</t> and OSPFv3 SRv6 LAN End.X SID TLVs.</t>
<t>When advertising SRv6 SIDs from the IGPs, the SRv6 SID Structure <t>When advertising SRv6 SIDs from the IGPs, the SRv6 SID Structure
information is derived from the IS-IS SRv6 SID Structure sub-sub-TLV information is derived from the IS-IS SRv6 SID Structure sub-sub-TLV
(section 9 of <xref target="I-D.ietf-lsr-isis-srv6-extensions"/>) or the (<xref target="RFC9352" sectionFormat="of" section="9"/>) or the
OSPFv3 SRv6 SID Structure sub-TLV (section 10 of <xref OSPFv3 SRv6 SID Structure sub-TLV (<xref target="RFC9513" sectionFormat="o
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>) in the case of IS-IS or f" section="10"/>) in the case of IS-IS or
OSPFv3 respectively.</t> OSPFv3, respectively.</t>
<t>When advertising the SRv6 SIDs corresponding to the BGP EPE <t>When advertising the SRv6 SIDs corresponding to the BGP EPE
functionality or for advertising SRv6 SIDs using Direct Protocol-ID, the functionality or for advertising SRv6 SIDs using Direct as the Protocol-ID , the
SRv6 SID Structure information is derived from the locally provisioned SRv6 SID Structure information is derived from the locally provisioned
SRv6 SID.</t> SRv6 SID.</t>
<t>The TLV has the following format:</t> <t>The TLV has the following format:</t>
<figure anchor="SRSIDSTRUCT">
<t><figure anchor="SRSIDSTRUCT" title="SRv6 SID Structure TLV"> <name>SRv6 SID Structure TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length | | LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 1252</t> </figure>
<t>Length: 4</t>
<t>LB Length: 1 octet field. SRv6 SID Locator Block length in
bits.</t>
<t>LN Length: 1 octet field. SRv6 SID Locator Node length in
bits.</t>
<t>Fun. Length: 1 octet field. SRv6 SID Function length in bits.</t> <t>where:</t>
<t>Arg. Length: 1 octet field. SRv6 SID Argument length in bits.</t> <dl newline="false" spacing="normal">
</list></t> <dt>Type:</dt><dd>1252</dd>
<dt>Length:</dt><dd>4</dd>
<dt>LB Length:</dt><dd>1-octet field. SRv6 SID Locator Block length in
bits.</dd>
<dt>LN Length:</dt><dd>1-octet field. SRv6 SID Locator Node length in
bits.</dd>
<dt>Fun. Length:</dt><dd>1-octet field. SRv6 SID Function length in bits
.</dd>
<dt>Arg. Length:</dt><dd>1-octet field. SRv6 SID Argument length in bits
.</dd>
</dl>
<t>The sum of the LB Length, LN Length, Func. Length, and Arg. Length <t>The sum of the LB Length, LN Length, Fun. Length, and Arg. Length
MUST be less than or equal to 128.</t> <bcp14>MUST</bcp14> be less than or equal to 128.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>Per this document, IANA has allocated code points in the "Border
<t>This document requests assigning code points from the IANA "Border Gateway Protocol - Link State (BGP-LS) Parameters" registry group, as
Gateway Protocol - Link State (BGP-LS) Parameters" registry group as
described in the subsections below.</t> described in the subsections below.</t>
<section anchor="NLRITYPES" numbered="true" toc="default">
<section anchor="NLRITYPES" title="BGP-LS NLRI-Types"> <name>BGP-LS NLRI Types</name>
<t>The following code points have been assigned by IANA from the <t>IANA has assigned the following code points in the
registry called "BGP-LS NLRI-Types":</t> "BGP-LS NLRI Types" registry:</t>
<table anchor="IANANLRI">
<t><figure anchor="IANANLRI" title="SRv6 SID NLRI Type Code Point"> <name>Addition to BGP-LS NLRI Types Registry</name>
<artwork><![CDATA[ +------+----------------------------+------------ <thead>
---+ <tr>
| Type | NLRI Type | Reference | <th>Type</th>
+------+----------------------------+---------------+ <th>NLRI Type</th>
| 6 | SRv6 SID NLRI | this document | <th>Reference</th>
+------+----------------------------+---------------+ </tr>
]]></artwork> </thead>
</figure></t> <tbody>
<tr>
<td>6</td>
<td>SRv6 SID NLRI</td>
<td>RFC 9514</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="BGPLSTLVS" numbered="true" toc="default">
<section anchor="BGPLSTLVS" title="BGP-LS TLVs"> <name>BGP-LS NLRI and Attribute TLVs</name>
<t>The following TLV code points have been assigned by IANA from the <t>IANA has assigned the following TLV code points in the "BGP-LS NLRI a
registry called "BGP-LS Node Descriptor, Link Descriptor, Prefix nd Attribute TLVs" registry:</t>
Descriptor, and Attribute TLVs":</t> <table anchor="ATTRTYPES">
<name>Additions to BGP-LS NLRI and Attribute TLVs Registry</name>
<t><figure anchor="ATTRTYPES" <thead>
title="SRv6 BGP-LS Attribute TLV Code Points"> <tr>
<artwork><![CDATA[+----------+-------------------------------------- <th>TLV Code Point</th>
--+---------------+ <th>Description</th>
| TLV Code | Description | Value defined | <th>Reference</th>
| Point | | in | </tr>
+----------+----------------------------------------+---------------+ </thead>
| 518 | SRv6 SID Information | this document | <tbody>
| 1038 | SRv6 Capabilities | this document | <tr>
| 1106 | SRv6 End.X SID | this document | <td>518</td>
| 1107 | IS-IS SRv6 LAN End.X SID | this document | <td>SRv6 SID Information</td>
| 1108 | OSPFv3 SRv6 LAN End.X SID | this document | <td>RFC 9514</td>
| 1162 | SRv6 Locator | this document | </tr>
| 1250 | SRv6 Endpoint Behavior | this document | <tr>
| 1251 | SRv6 BGP Peer Node SID | this document | <td>1038</td>
| 1252 | SRv6 SID Structure | this document | <td>SRv6 Capabilities</td>
+----------+----------------------------------------+---------------+]]></artwor <td>RFC 9514</td>
k> </tr>
</figure></t> <tr>
<td>1106</td>
<td>SRv6 End.X SID</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1107</td>
<td>IS-IS SRv6 LAN End.X SID</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1108</td>
<td>OSPFv3 SRv6 LAN End.X SID</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1162</td>
<td>SRv6 Locator</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1250</td>
<td>SRv6 Endpoint Behavior</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1251</td>
<td>SRv6 BGP PeerNode SID</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1252</td>
<td>SRv6 SID Structure</td>
<td>RFC 9514</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="BGPEPEFLAGS" numbered="true" toc="default">
<section anchor="BGPEPEFLAGS" title="SRv6 BGP EPE SID Flags"> <name>SRv6 BGP EPE SID Flags</name>
<t>This document requests the creation of a new registry called "SRv6 <t>Per this document, IANA has created a new registry called "SRv6
BGP EPE SID Flags" under the "Border Gateway Protocol - Link State BGP EPE SID Flags" under the "Border Gateway Protocol - Link State
(BGP-LS) Parameters" registry group. The allocation policy of this (BGP-LS) Parameters" registry group. The allocation policy of this
registry is "Standards Action" according to <xref registry is "Standards Action" according to <xref target="RFC8126" forma
target="RFC8126"/>.</t> t="default"/>.</t>
<t>The initial contents of the registry are as follows:</t>
<t>The following flags are defined: <figure anchor="EPEFLAGS" <table anchor="EPEFLAGS">
title="SRv6 BGP EPE SID Flags"> <name>New SRv6 BGP EPE SID Flags Registry</name>
<artwork align="center"><![CDATA[ Bit Description <thead>
Reference <tr>
0 Backup Flag (B-Flag) This document <th>Bit</th>
1 Set Flag (S-Flag) This document <th>Description</th>
2 Persistent Flag (P-Flag) This document <th>Reference</th>
3-7 Unassigned ]]></artwork> </tr>
</figure></t> </thead>
<tbody>
<tr>
<td>0</td>
<td>Backup Flag (B-Flag)</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>1</td>
<td>Set Flag (S-Flag)</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>2</td>
<td>Persistent Flag (P-Flag)</td>
<td>RFC 9514</td>
</tr>
<tr>
<td>3-7</td>
<td>Unassigned</td>
<td></td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability Considerations</name>
<t>This section is structured as recommended in <xref <t>This section is structured as recommended in <xref target="RFC5706" for
target="RFC5706"/>.</t> mat="default"/>.</t>
<t>The new protocol extensions introduced in this document augment the <t>The new protocol extensions introduced in this document augment the
existing IGP topology information that is distributed via <xref existing IGP topology information that is distributed via <xref target="RF
target="RFC7752"/>. Procedures and protocol extensions defined in this C7752" format="default"/>. Procedures and protocol extensions defined in this
document do not affect the BGP protocol operations and management other document do not affect the BGP protocol operations and management other
than as discussed in the Manageability Considerations section of <xref than as discussed in Section <xref target="RFC7752" sectionFormat="bare" s
target="RFC7752"/>. Specifically, the malformed attribute tests for ection="6">Manageability Considerations</xref> of <xref target="RFC7752"/>. Spec
syntactic checks in the Fault Management section of <xref ifically, the malformed attribute tests for
target="RFC7752"/> now encompass the new BGP-LS extensions defined in syntactic checks in Section <xref target="RFC7752" sectionFormat="bare" se
ction="6.2.2">Fault Management</xref> of <xref target="RFC7752"/> now encompass
the new BGP-LS extensions defined in
this document. The semantic or content checking for the TLVs specified this document. The semantic or content checking for the TLVs specified
in this document and their association with the BGP-LS NLRI types or in this document and their association with the BGP-LS NLRI types or
their BGP-LS Attribute is left to the consumer of the BGP-LS information their BGP-LS Attribute are left to the consumer of the BGP-LS information
(e.g., an application or a controller) and not the BGP protocol.</t> (e.g., an application or a controller) and not BGP.</t>
<t>The SR information introduced in BGP-LS by this specification may be <t>The SR information introduced in BGP-LS by this specification may be
used by BGP-LS consumer applications like an SR path computation engine used by BGP-LS consumer applications like an SR Path Computation Engine
(PCE) to learn the SRv6 capabilities of the nodes in the topology and (PCE) to learn the SRv6 capabilities of the nodes in the topology and the
the mapping of SRv6 segments to those nodes. This can enable the SR PCE mapping of SRv6 segments to those nodes. This can enable the SR PCE
to perform path computations based on SR for traffic engineering to perform path computations based on SR for traffic-engineering
use-cases and to steer traffic on paths different from the underlying use cases and to steer traffic on paths different from the underlying
IGP based distributed best path computation. Errors in the encoding or IGP-based distributed best path computation. Errors in the encoding or
decoding of the SRv6 information may result in the unavailability of decoding of the SRv6 information may result in the unavailability of
such information to the SR PCE or incorrect information being made such information to the SR PCE or incorrect information being made
available to it. This may result in the SR PCE not being able to perform available to it. This may result in the SR PCE not being able to perform
the desired SR-based optimization functionality or to perform it in an the desired SR-based optimization functionality or performing it in an
unexpected or inconsistent manner. The handling of such errors by unexpected or inconsistent manner. The handling of such errors by
applications like SR PCE may be implementation-specific and out of the applications like SR PCE may be implementation specific and out of the
scope of this document.</t> scope of this document.</t>
<t>The manageability considerations related to BGP EPE functionality are <t>The manageability considerations related to BGP EPE functionality are
discussed in <xref target="RFC9086"/> in the context of SR-MPLS and they discussed in <xref target="RFC9086" format="default"/> in the context of S R-MPLS; they
also apply to this document in the context of SRv6.</t> also apply to this document in the context of SRv6.</t>
<t>The extensions specified in this document do not introduce any new
<t>The extensions, specified in this document, do not introduce any new
configuration or monitoring aspects in BGP or BGP-LS other than as configuration or monitoring aspects in BGP or BGP-LS other than as
discussed in <xref target="RFC7752"/>. The manageability aspects of the discussed in <xref target="RFC7752" format="default"/>. The manageability
underlying SRv6 features are covered by <xref aspects of the
target="I-D.ietf-spring-srv6-yang"/>.</t> underlying SRv6 features are covered by <xref target="I-D.ietf-spring-srv6
-yang" format="default"/>.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The new protocol extensions introduced in this document augment the <t>The new protocol extensions introduced in this document augment the
existing IGP topology information that is distributed via <xref existing IGP topology information that is distributed via <xref
target="RFC7752"/>. The advertisement of the SRv6 link-state information target="RFC7752" format="default"/>. The advertisement of the SRv6
defined in this document presents a similar risk as associated with the link-state information defined in this document presents a similar risk
existing set of link-state information as described in <xref as associated with the existing link-state information as described in
target="RFC7752"/>. The Security Considerations section of <xref <xref target="RFC7752" format="default"/>. Section <xref target="RFC7752"
target="RFC7752"/> also applies to these extensions. The procedures and sectionFormat="bare" section="8">Security Considerations</xref> of <xref t
new TLVs defined in this document, by themselves, do not affect the arget="RFC7752"/> also applies to these extensions. The
BGP-LS security model discussed in <xref target="RFC7752"/>.</t> procedures and new TLVs defined in this document, by themselves, do not
affect the BGP-LS security model discussed in <xref target="RFC7752"
<t>The extensions introduced in this document are used to propagate IGP format="default"/>.</t>
defined information (<xref target="I-D.ietf-lsr-isis-srv6-extensions"/> <t>The extensions introduced in this document are used to propagate
and <xref target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>). These IGP-defined information <xref target="RFC9352" format="default"/> <xref
extensions represent the advertisement of SRv6 information associated target="RFC9513" format="default"/>. These extensions represent the
with the IGP node, link, and prefix. The IGP instances originating these advertisement of SRv6 information associated with the IGP node, link,
TLVs are assumed to support all the required security and authentication and prefix. The IGP instances originating these TLVs are assumed to
mechanisms (as described in <xref support all the required security and authentication mechanisms (as
target="I-D.ietf-lsr-isis-srv6-extensions"/> and <xref described in <xref target="RFC9352" format="default"/> and <xref
target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>).</t> target="RFC9513" format="default"/>).</t>
<t>The security considerations related to BGP EPE functionality are <t>The security considerations related to BGP EPE functionality are
discussed in <xref target="RFC9086"/> in the context of SR-MPLS and they discussed in <xref target="RFC9086" format="default"/> in the context of S R-MPLS, and they
also apply to this document in the context of SRv6.</t> also apply to this document in the context of SRv6.</t>
<t>BGP-LS SRv6 extensions enable traffic-engineering use cases within
<t>BGP-LS SRv6 extensions enable traffic engineering use-cases within the SR domain. SR operates within a trusted domain <xref target="RFC8402"
the Segment Routing domain. SR operates within a trusted domain <xref format="default"/>, and its security considerations also apply to BGP-LS
target="RFC8402"/> and its security considerations also apply to BGP-LS sessions when carrying SR information. The SR traffic-engineering
sessions when carrying SR information. The SR traffic engineering
policies using the SIDs advertised via BGP-LS are expected to be used policies using the SIDs advertised via BGP-LS are expected to be used
entirely within this trusted SR domain (e.g., between multiple AS or IGP entirely within this trusted SR domain (e.g., between multiple AS or IGP
domains within a single provider network). Therefore, precaution is domains within a single provider network). Therefore, precaution is
necessary to ensure that the link-state information (including SRv6 necessary to ensure that the link-state information (including SRv6
information) advertised via BGP-LS sessions is securely limited to information) advertised via BGP-LS sessions is securely limited to
consumers within this trusted SR domain. BGP peering sessions for consumers within this trusted SR domain. BGP peering sessions for
address-families other than Link-State may be set up to routers outside address families other than Link State may be set up to routers outside
the SR domain. The isolation of BGP-LS peering sessions is RECOMMENDED the SR domain. The isolation of BGP-LS peering sessions is <bcp14>RECOMMEN
DED</bcp14>
to ensure that BGP-LS topology information (including the newly added SR to ensure that BGP-LS topology information (including the newly added SR
information) is not advertised to an external BGP peering session information) is not advertised to an external BGP peering session
outside the SR domain.</t> outside the SR domain.</t>
</section> </section>
<section title="Contributors">
<figure>
<artwork><![CDATA[James Uttaro
AT&T
USA
Email: ju1738@att.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Hani Elmalky
Ericsson
USA
Email: hani.elmalky@gmail.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Arjun Sreekantiah
Individual
USA
Email: arjunhrs@gmail.com
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Les Ginsberg
Cisco Systems
USA
Email: ginsberg@cisco.com]]></artwork>
</figure>
<figure>
<artwork><![CDATA[Shunwan Zhuang
Huawei
China
Email: zhuangshunwan@huawei.com]]></artwork>
</figure>
<t/>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Peter Psenak, Arun Babu, Pablo
Camarillo, Francois Clad, Peng Shaofu, Cheng Li, Dhruv Dhody, Tom Petch,
and Dan Romascanu for their review of this document and their comments.
The authors would also like to thank Susan Hares for her shepherd review
and Adrian Farrel for his detailed Routing Directorate review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.8986.xml'?>
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.8174.xml'?>
<?rfc include='reference.I-D.ietf-lsr-isis-srv6-extensions.xml'?> <displayreference target="I-D.ietf-spring-srv6-yang" to="SRV6-YANG"/>
<?rfc include='reference.I-D.ietf-lsr-ospfv3-srv6-extensions.xml'?>
<?rfc include='reference.RFC.7752.xml'?>
<?rfc include='reference.RFC.8402.xml'?>
<?rfc include='reference.RFC.9085.xml'?>
<?rfc include='reference.RFC.9086.xml'?>
<?rfc include='reference.RFC.8126.xml'?>
<?rfc include='reference.RFC.8814.xml'?> <references>
</references> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
352.xml"/>
<references title="Informative References"> <!-- [I-D.ietf-lsr-ospfv3-srv6-extensions] in EDIT state as of 07/07/23; compani
<?rfc include='reference.RFC.8754.xml'?> on document RFC 9513 -->
<reference anchor="RFC9513" target="https://www.rfc-editor.org/info/rfc9513">
<front>
<title>OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)</title>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="Z." surname="Hu" fullname="Zhibo Hu">
<organization>Huawei Technologies</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="edi
tor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9513"/>
<seriesInfo name="DOI" value="10.17487/RFC9513"/>
</reference>
<?rfc include='reference.RFC.5706.xml'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
752.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
085.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
814.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
706.xml"/>
<?rfc include='reference.I-D.ietf-spring-srv6-yang.xml'?> <!-- [I-D.ietf-spring-srv6-yang] IESG state Expired -->
<reference anchor="I-D.ietf-spring-srv6-yang" target="https://datatracker.ietf.o
rg/doc/html/draft-ietf-spring-srv6-yang-02">
<front>
<title>YANG Data Model for SRv6 Base and Static</title>
<author fullname="Syed Raza" initials="S." surname="Raza">
<organization>Cisco Systems</organization>
</author>
<author fullname="Sonal Agarwal" initials="S." surname="Agarwal">
<organization>Cisco Systems</organization>
</author>
<author fullname="Xufeng Liu" initials="X." surname="Liu">
<organization>Volta Networks</organization>
</author>
<author fullname="Zhibo Hu" initials="Z." surname="Hu">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Iftekhar Hussain" initials="I." surname="Hussain">
<organization>Infinera Corporation</organization>
</author>
<author fullname="Himanshu C. Shah" initials="H. C." surname="Shah">
<organization>Ciena Corporation</organization>
</author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization>SoftBank</organization>
</author>
<author fullname="Katsuhiro Horiba" initials="K." surname="Horiba">
<organization>SoftBank</organization>
</author>
<author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
<organization>Cisco Systems</organization>
</author>
<author fullname="Ahmed Abdelsalam" initials="A." surname="Abdelsalam">
<organization>Cisco Systems</organization>
</author>
<date day="23" month="September" year="2022"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-yang-02"/>
</reference>
</references>
</references> </references>
<section anchor="BGPEPE" numbered="true" toc="default">
<section anchor="BGPEPE" title="Differences with BGP-EPE for SR-MPLS"> <name>Differences with BGP-EPE for SR-MPLS</name>
<t>The signaling of SRv6 SIDs corresponding to BGP-EPE functionality as <t>The signaling of SRv6 SIDs corresponding to BGP-EPE functionality as
defined in this document differ from the signaling of SR-MPLS BGP-EPE defined in this document differs from the signaling of SR-MPLS BGP-EPE
SIDs as specified in <xref target="RFC9086"/>. This section provides a SIDs as specified in <xref target="RFC9086" format="default"/>. This secti
on provides a
high-level overview of the same.</t> high-level overview of the same.</t>
<t>There is no difference in the advertisement of the BGP Peer Adjacency <t>There is no difference in the advertisement of the BGP Peer Adjacency
SID in both SR-MPLS and SRv6 and it is advertised as an attribute of the SID in both SR-MPLS and SRv6, and it is advertised as an attribute of the
Link NLRI which identifies a specific Layer 3 interface on the BGP Link NLRI, which identifies a specific Layer 3 interface on the BGP
Speaker. The difference is in the advertisement of the BGP Peer Node and Speaker. The difference is in the advertisement of the BGP PeerNode and
Peer Set SIDs.</t> PeerSet SIDs.</t>
<t>In the case of SR-MPLS, an additional Link NLRI is required to be
<t>In case of SR-MPLS, an additional Link NLRI is required to be advertised corresponding to each BGP peering session on the node. Note
advertised corresponding to each BGP Peering session on the node. Note that this is not the same Link NLRI associated with the actual Layer 3
that, this is not the same Link NLRI associated with the actual layer 3
interface even when the peering is set up using the interface IP interface even when the peering is set up using the interface IP
addresses. These BGP-LS Link NLRIs are not really links in the addresses. These BGP-LS Link NLRIs are not really links in the
conventional link-state routing data model but instead identify BGP conventional link-state routing data model but instead identify BGP
peering sessions. The BGP Peer Node and/or Peer Set SIDs associated with peering sessions. The BGP PeerNode and/or PeerSet SIDs associated with
that peering session are advertised as attributes associated with this that peering session are advertised as attributes associated with this
peering Link NLRI. In the case of SRv6, each BGP Peer Node or Peer Set peering Link NLRI. In the case of SRv6, each BGP PeerNode or PeerSet
SID is considered to be associated with the BGP Speaker node and is SID is considered to be associated with the BGP Speaker Node and is
advertised using the BGP-LS SRv6 SID NLRI while the peering session advertised using the BGP-LS SRv6 SID NLRI, while the peering session
information is advertised as attributes associated with it.</t> information is advertised as attributes associated with it.</t>
<t>The advertisement of the BGP PeerSet SID for SR-MPLS is done by
<t>The advertisement of the BGP Peer Set SID for SR-MPLS is done by
including that SID as an attribute in all the Link NLRIs corresponding including that SID as an attribute in all the Link NLRIs corresponding
to the peering sessions that are part of the "set". The advertisement of to the peering sessions that are part of the "set". The advertisement of
the BGP Peer Set SID for SRv6 is advertised using a single SRv6 SID NLRI the BGP PeerSet SID for SRv6 is advertised using a single SRv6 SID NLRI,
and all the peers associated with that "set" are indicated as attributes and all the peers associated with that "set" are indicated as attributes
associated with the NLRI.</t> associated with the NLRI.</t>
</section>
<t/> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Peter Psenak"/>,
<contact fullname="Arun Babu"/>, <contact fullname="Pablo Camarillo"/>,
<contact fullname="Francois Clad"/>, <contact fullname="Peng Shaofu"/>,
<contact fullname="Cheng Li"/>, <contact fullname="Dhruv Dhody"/>,
<contact fullname="Tom Petch"/>, and <contact fullname="Dan Romascanu"/>
for their review of this document and their comments. The authors would
also like to thank <contact fullname="Susan Hares"/> for her shepherd
review and <contact fullname="Adrian Farrel"/> for his detailed Routing Ar
ea
Directorate review.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="James Uttaro" >
<organization>AT&amp;T</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>ju1738@att.com</email>
</address>
</contact>
<contact fullname="Hani Elmalky">
<organization>Ericsson</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>hani.elmalky@gmail.com</email>
</address>
</contact>
<contact fullname="Arjun Sreekantiah">
<organization>Individual</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>arjunhrs@gmail.com</email>
</address>
</contact>
<contact fullname="Les Ginsberg">
<organization>Cisco Systems</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</contact>
<contact fullname="Shunwan Zhuang">
<organization>Huawei</organization>
<address>
<postal>
<country>China</country>
</postal>
<email>zhuangshunwan@huawei.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 203 change blocks. 
881 lines changed or deleted 1025 lines changed or added

This html diff was produced by rfcdiff 1.48.