rfc9085xml2.original.xml   rfc9085.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" number="9085"
<?rfc tocdepth="3"?> docName="draft-ietf-idr-bgp-ls-segment-routing-ext-18" ipr="trust200902"
<?rfc tocindent="yes"?> consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en
<?rfc symrefs="yes"?> "
<?rfc sortrefs="yes"?> tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true"
<?rfc comments="yes"?> version="3">
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-segment-routing-ext-16"
ipr="trust200902">
<front> <front>
<title abbrev="BGP LS extensions for Segment Routing">BGP Link-State
extensions for Segment Routing</title>
<title abbrev="BGP-LS Extensions for Segment Routing">Border Gateway Protoco
l - Link State (BGP-LS) Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="9085"/>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Rome</city> <city>Rome</city>
<code/>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
<author fullname="Ketan Talaulikar" initials="K." role="editor" aulikar">
surname="Talaulikar">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant@cisco.com</email> <email>ketant@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Brussels</city> <city>Brussels</city>
<code/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler"> <author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>RtBrick Inc.</organization> <organization>RtBrick Inc.</organization>
<address> <address>
<postal> <postal/>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</author> </author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Building, No. 156 Beiqing Rd.</street> <street>Huawei Building, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<date month="August" year="2021"/>
<date year=""/>
<area>Routing</area> <area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup> <workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<keyword>SID</keyword> <keyword>SID</keyword>
<keyword>MPLS</keyword> <keyword>MPLS</keyword>
<keyword>Label advertisement</keyword> <keyword>Label advertisement</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>OSPFv3</keyword> <keyword>OSPFv3</keyword>
<abstract> <abstract>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end <t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths by encoding paths as sequences of topological sub-paths, called paths by encoding paths as sequences of topological subpaths, called
"segments". These segments are advertised by routing protocols e.g. by "segments". These segments are advertised by routing protocols, e.g., by
the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP
topologies.</t> topologies.</t>
<t>This document defines extensions to the BGP Link-state address-family <t>This document defines extensions to the Border Gateway Protocol - Link
in order to carry segment routing information via BGP.</t> State (BGP-LS) address family
in order to carry SR information via BGP.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end <t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths by combining sub-paths called "segments". A segment can represent paths by combining subpaths called "segments". A segment can represent
any instruction: topological or service-based. A segment can have a any instruction: topological or service based. A segment can have a
local semantic to an SR node or global semantic within a domain. Within local semantic to an SR node or global semantic within a domain. Within
IGP topologies, an SR path is encoded as a sequence of topological IGP topologies, an SR path is encoded as a sequence of topological
sub-paths, called "IGP segments". These segments are advertised by the subpaths, called "IGP segments". These segments are advertised by the
link-state routing protocols (IS-IS, OSPFv2 and OSPFv3).</t> link-state routing protocols (IS-IS, OSPFv2, and OSPFv3).</t>
<t><xref target="RFC8402"/> defines the Link-State IGP segments - <t><xref target="RFC8402" format="default"/> defines the link-state IGP se
Prefix, Node, Anycast and Adjacency segments. Prefix segments, by gments --
prefix, node, anycast, and adjacency segments. Prefix segments, by
default, represent an ECMP-aware shortest-path to a prefix, as per the default, represent an ECMP-aware shortest-path to a prefix, as per the
state of the IGP topology. Adjacency segments represent a hop over a state of the IGP topology. Adjacency segments represent a hop over a
specific adjacency between two nodes in the IGP. A prefix segment is specific adjacency between two nodes in the IGP. A prefix segment is
typically a multi-hop path while an adjacency segment, in most of the typically a multi-hop path while an adjacency segment, in most of the
cases, is a one-hop path. Node and anycast segments are variations of cases, is a one-hop path. Node and anycast segments are variations of
the prefix segment with their specific characteristics.</t> the prefix segment with their specific characteristics.</t>
<t>When Segment Routing is enabled in an IGP domain, segments are <t>When SR is enabled in an IGP domain, segments are
advertised in the form of Segment Identifiers (SIDs). The IGP link-state advertised in the form of Segment Identifiers (SIDs). The IGP link-state
routing protocols have been extended to advertise SIDs and other routing protocols have been extended to advertise SIDs and other
SR-related information. IGP extensions are described for: <xref SR-related information. IGP extensions are described for: <xref target="RF
target="I-D.ietf-isis-segment-routing-extensions">IS-IS</xref>, <xref C8667" format="default">IS-IS</xref>, <xref target="RFC8665" format="default">OS
target="I-D.ietf-ospf-segment-routing-extensions">OSPFv2</xref> and PFv2</xref>, and
<xref <xref target="RFC8666" format="default">OSPFv3</xref>.
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions">OSPFv3</xref>. Using these extensions, SR can be enabled within an IGP
Using these extensions, Segment Routing can be enabled within an IGP
domain.</t> domain.</t>
<t>Segment Routing (SR) allows advertisement of single or multi-hop <t>SR allows advertisement of single or multi-hop
paths. The flooding scope for the IGP extensions for Segment routing is paths. The flooding scope for the IGP extensions for SR is
IGP area-wide. Consequently, the contents of a Link State Database IGP area-wide. Consequently, the contents of a Link-State Database
(LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP
area and therefore, by using the IGP alone it is not enough to construct area; therefore, by using the IGP alone, it is not enough to construct
segments across multiple IGP Area or AS boundaries.</t> segments across multiple IGP area or Autonomous
System (AS) boundaries.</t>
<t>In order to address the need for applications that require <t>In order to address the need for applications that require
topological visibility across IGP areas, or even across Autonomous topological visibility across IGP areas, or even across ASes,
Systems (AS), the BGP-LS address-family/sub-address-family have been the BGP-LS address family / subaddress family have been
defined to allow BGP to carry Link-State information. The BGP Network defined to allow BGP to carry link-state information.
The BGP Network
Layer Reachability Information (NLRI) encoding format for BGP-LS and a Layer Reachability Information (NLRI) encoding format for BGP-LS and a
new BGP Path Attribute called the BGP-LS attribute are defined in <xref new BGP Path Attribute called the "BGP-LS Attribute" are defined in <xref
target="RFC7752"/>. The identifying key of each Link-State object, target="RFC7752" format="default"/>. The identifying key of each link-state obje
namely a node, link, or prefix, is encoded in the NLRI and the ct,
properties of the object are encoded in the BGP-LS attribute.</t> namely a node, link, or prefix, is encoded in the NLRI, and the
properties of the object are encoded in the BGP-LS Attribute.</t>
<t><figure anchor="MECHANISM-CONSUMER-PRODUCER" <figure anchor="MECHANISM-CONSUMER-PRODUCER">
title="Link State info collection"> <name>Link-State Information Collection</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+------------+ +------------+
| Consumer | | Consumer |
+------------+ +------------+
^ ^
| |
v v
+-------------------+ +-------------------+
| BGP Speaker | +-----------+ | BGP Speaker | +-----------+
| (Route-Reflector) | | Consumer | | (Route Reflector) | | Consumer |
+-------------------+ +-----------+ +-------------------+ +-----------+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
+---------------+ | +-------------------+ | +---------------+ | +-------------------+ |
| | | | | | | |
v v v v v v v v
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP | | BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker | | Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
^ ^ ^ ^ ^ ^
| | | | | |
IGP IGP IGP IGP IGP IGP
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t><xref target="MECHANISM-CONSUMER-PRODUCER" format="default"/> denotes a
<t><xref target="MECHANISM-CONSUMER-PRODUCER"/> denotes a typical typical
deployment scenario. In each IGP area, one or more nodes are configured deployment scenario. In each IGP area, one or more nodes are configured
with BGP-LS. These BGP speakers form an IBGP mesh by connecting to one with BGP-LS. These BGP speakers form an Internal BGP (IBGP) mesh by connec
or more route-reflectors. This way, all BGP speakers (specifically the ting to one
route-reflectors) obtain Link-State information from all IGP areas (and or more route reflectors. This way, all BGP speakers (specifically the
from other ASes from EBGP peers). An external component connects to the route reflectors) obtain link-state information from all IGP areas (and
route-reflector to obtain this information (perhaps moderated by a from other ASes from External BGP (EBGP) peers). An external component con
nects to the
route reflector to obtain this information (perhaps moderated by a
policy regarding what information is or isn't advertised to the external policy regarding what information is or isn't advertised to the external
component) as described in <xref target="RFC7752"/>.</t> component) as described in <xref target="RFC7752" format="default"/>.</t>
<t>This document describes extensions to BGP-LS to advertise the SR <t>This document describes extensions to BGP-LS to advertise the SR
information. An external component (e.g., a controller) can collect SR information. An external component (e.g., a controller) can collect SR
information from across an SR domain (as described in <xref information from across an SR domain (as described in <xref target="RFC840
target="RFC8402"/>) and construct the end-to-end path (with its 2" format="default"/>) and construct the end-to-end path (with its
associated SIDs) that need to be applied to an incoming packet to associated SIDs) that needs to be applied to an incoming packet to
achieve the desired end-to-end forwarding. SR operates within a trusted achieve the desired end-to-end forwarding. SR operates within a trusted
domain consisting of a single or multiple ASes managed by the same domain consisting of a single AS or multiple ASes managed by the same
administrative entity e.g. within a single provider network.</t> administrative entity, e.g., within a single provider network.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
/bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as descri
bed in BCP 14
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d
efault"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section> </section>
</section>
<section title="BGP-LS Extensions for Segment Routing"> <section numbered="true" toc="default">
<name>BGP-LS Extensions for Segment Routing</name>
<t>This document defines SR extensions to BGP-LS and specifies the TLVs <t>This document defines SR extensions to BGP-LS and specifies the TLVs
and sub-TLVs for advertising SR information within the BGP-LS Attribute. and sub-TLVs for advertising SR information within the BGP-LS Attribute.
<xref target="ISISTLV"/> and <xref target="OSPFTLV"/> lists the Sections <xref target="ISISTLV" format="counter"/> and <xref target="OSPF
equivalent TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols.</t> TLV" format="counter"/> list the
equivalent TLVs and sub-TLVs in the IS-IS, OSPFv2, and OSPFv3 protocols.</
t>
<t><xref target="RFC7752">BGP-LS</xref> defines the BGP-LS NLRI that can <t><xref target="RFC7752" format="default">BGP-LS</xref> defines the BGP-L
be a Node NLRI, a Link NLRI or a Prefix NLRI. <xref S NLRI that can
target="RFC7752">BGP-LS</xref> defines the TLVs that map link-state be a Node NLRI, a Link NLRI, or a Prefix NLRI, and it defines the TLVs tha
t map link-state
information to BGP-LS NLRI within the BGP-LS Attribute. This document information to BGP-LS NLRI within the BGP-LS Attribute. This document
adds additional BGP-LS Attribute TLVs in order to encode SR information. adds additional BGP-LS Attribute TLVs in order to encode SR information.
It does not introduce any changes to the encoding of the BGP-LS It does not introduce any changes to the encoding of the BGP-LS
NLRIs.</t> NLRIs.</t>
<section anchor="NODE" numbered="true" toc="default">
<section anchor="NODE" title="Node Attributes TLVs"> <name>Node Attribute TLVs</name>
<t>The following Node Attribute TLVs are defined:</t> <t>The following Node Attribute TLVs are defined:</t>
<table anchor="node-attribute_tlv" align="center">
<texttable anchor="node-attribute_tlv" title="Node Attribute TLVs"> <name>Node Attribute TLVs</name>
<ttcol align="center">Type</ttcol> <thead>
<tr>
<ttcol align="left">Description</ttcol> <th align="left">Type</th>
<th align="left">Description</th>
<ttcol align="right">Section</ttcol> <th align="left">Section</th>
</tr>
<c>1161</c> </thead>
<tbody>
<c>SID/Label</c> <tr>
<td align="center">1161</td>
<c><xref target="SIDLABELTLV"/></c> <td align="left">SID/Label</td>
<td align="right">
<c>1034</c> <xref target="SIDLABELTLV" format="default"/></td>
</tr>
<c>SR Capabilities</c> <tr>
<td align="center">1034</td>
<c><xref target="SRCAPTLV"/></c> <td align="left">SR Capabilities</td>
<td align="right">
<c>1035</c> <xref target="SRCAPTLV" format="default"/></td>
</tr>
<c>SR Algorithm</c> <tr>
<td align="center">1035</td>
<c><xref target="SRALGOTLV"/></c> <td align="left">SR Algorithm</td>
<td align="right">
<c>1036</c> <xref target="SRALGOTLV" format="default"/></td>
</tr>
<c>SR Local Block</c> <tr>
<td align="center">1036</td>
<c><xref target="SRLB"/></c> <td align="left">SR Local Block</td>
<td align="right">
<c>1037</c> <xref target="SRLB" format="default"/></td>
</tr>
<c>SRMS Preference</c> <tr>
<td align="center">1037</td>
<c><xref target="SRMSPREF"/></c> <td align="left">SRMS Preference</td>
</texttable> <td align="right">
<xref target="SRMSPREF" format="default"/></td>
</tr>
</tbody>
</table>
<t>These TLVs should only be added to the BGP-LS Attribute associated <t>These TLVs should only be added to the BGP-LS Attribute associated
with the Node NLRI describing the IGP node that is originating the with the Node NLRI that describes the IGP node that is originating the
corresponding IGP TLV/sub-TLV described below.</t> corresponding IGP TLV/sub-TLV described below.</t>
<section anchor="SIDLABELTLV" numbered="true" toc="default">
<section anchor="SIDLABELTLV" title="SID/Label TLV"> <name>SID/Label TLV</name>
<t>The SID/Label TLV is used as a sub-TLV by the SR Capabilities <t>The SID/Label TLV is used as a sub-TLV by the SR Capabilities
(<xref target="SRCAPTLV"/>) and Segment Routing Local Block (SRLB) (<xref target="SRCAPTLV" format="default"/>) and Segment Routing Local
(<xref target="SRLB"/>) TLVs. This information is derived from the Block (SRLB)
protocol specific advertisements. <list style="symbols"> (<xref target="SRLB" format="default"/>) TLVs. This information is der
<t>IS-IS, as defined by the SID/Label sub-TLV in section 2.3 of ived from the
<xref target="I-D.ietf-isis-segment-routing-extensions"/>.</t> protocol-specific advertisements. </t>
<ul spacing="normal">
<t>OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in section <li>IS-IS, as defined by the SID/Label Sub-TLV in
2.1 of <xref target="I-D.ietf-ospf-segment-routing-extensions"/> <xref target="RFC8667" section="2.3" sectionFormat="of"/>.</li>
and section 3.1 of <xref <li>OSPFv2/OSPFv3, as defined by the SID/Label Sub-TLV in <xref targ
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> et="RFC8665" section="2.1" sectionFormat="of"/>
</list></t> and <xref target="RFC8666" section="3.1" sectionFormat="of"/>.</li
>
<t>The TLV has the following format: <figure anchor="SIDLTLVFIG" </ul>
title="SID/Label TLV Format"> <t>The TLV has the following format: </t>
<artwork><![CDATA[ <figure anchor="SIDLTLVFIG">
<name>SID/Label TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) // | SID/Label (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging"> <dl newline="false">
<t>Type: 1161</t>
<t>Length: Variable. Either 3 or 4 depending whether the value <dt>Type:</dt><dd> 1161</dd>
is encoded as a label or as an index/SID.</t> <dt>Length:</dt><dd> Variable. Either 3 or 4 octets depending on whe
ther the value
is encoded as a label or as an index/SID.</dd>
<t>SID/Label: If length is set to 3, then the 20 rightmost bits <dt>SID/Label:</dt><dd> If the length is set to 3, then the 20 right
represent a label (the total TLV size is 7) and the 4 leftmost most bits
bits are set to 0. If length is set to 4, then the value represent a label (the total TLV size is 7), and the 4 leftmost
represents a 32 bit SID (the total TLV size is 8).</t> bits are set to 0. If the length is set to 4, then the value
</list></t> represents a 32-bit SID (the total TLV size is 8).</dd>
</dl>
</section> </section>
<section anchor="SRCAPTLV" numbered="true" toc="default">
<section anchor="SRCAPTLV" title="SR Capabilities TLV"> <name>SR Capabilities TLV</name>
<t>The SR Capabilities TLV is used in order to advertise the node's <t>The SR Capabilities TLV is used in order to advertise the node's
SR Capabilities including its Segment Routing Global Base (SRGB) SR capabilities including its Segment Routing Global Base (SRGB)
range(s). In the case of IS-IS, the capabilities also include the range(s). In the case of IS-IS, the capabilities also include the
IPv4 and IPv6 support for the SR-MPLS forwarding plane. This IPv4 and IPv6 support for the SR-MPLS forwarding plane. This
information is derived from the protocol specific advertisements. information is derived from the protocol-specific advertisements.
<list style="symbols"> </t>
<t>IS-IS, as defined by the SR Capabilities sub-TLV in section <ul spacing="normal">
3.1 of <xref <li>IS-IS, as defined by the SR-Capabilities Sub-TLV in <xref target
target="I-D.ietf-isis-segment-routing-extensions"/>.</t> ="RFC8667" section="3.1" sectionFormat="of"/>.</li>
<li>OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in
<t>OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in <xref target="RFC8665" section="3.2" sectionFormat="of"/>. OSPFv3
section 3.2 of <xref leverages the same TLV as defined for OSPFv2.</li>
target="I-D.ietf-ospf-segment-routing-extensions"/>. OSPFv3 </ul>
leverages the same TLV as defined for OSPFv2.</t> <t>The SR Capabilities TLV has the following format: </t>
</list></t> <figure anchor="SRCAPTLVFIG">
<name>SR Capabilities TLV Format</name>
<t>The SR Capabilities TLV has the following format: <figure <artwork name="" type="" align="left" alt=""><![CDATA[
anchor="SRCAPTLVFIG" title="SR Capabilities TLV Format">
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size 1 | | Range Size 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV 1 // | SID/Label Sub-TLV 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size N | | Range Size N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV N // | SID/Label Sub-TLV N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:<list style="hanging"> <t>Where:</t>
<t>Type: 1034</t>
<t>Length: Variable. Minimum length is 12.</t> <dl spacing="normal">
<t>Flags: 1 octet of flags as defined in section 3.1 of <xref <dt>Type:</dt> <dd>1034</dd>
target="I-D.ietf-isis-segment-routing-extensions"/> for IS-IS.
The flags are not currently defined for OSPFv2 and OSPFv3 and
MUST be set to 0 and ignored on receipt.</t>
<t>Reserved: 1 octet that MUST be set to 0 and ignored on <dt>Length:</dt><dd>Variable. The minimum length is 12 octets.</dd>
receipt.</t>
<t>One or more entries, each of which have the following <dt>Flags:</dt><dd> 1 octet of flags as defined in
format:<list style="hanging"> <xref
<t>Range Size: 3 octet with a non-zero value indicating the target="RFC8667" section="3.1"
number of labels in the range.</t> sectionFormat="of"/> for IS-IS. The flags are not currently
defined for OSPFv2 and OSPFv3 and <bcp14>MUST</bcp14> be
set to 0 and ignored on receipt.</dd>
<t>SID/Label TLV (as defined in <xref <dt>Reserved:</dt><dd> 1 octet that <bcp14>MUST</bcp14> be set to 0
target="SIDLABELTLV"/>) used as sub-TLV which encodes the and ignored on
receipt.</dd>
<dt>One or more entries, each of which have the following
format:</dt>
<dd>
<t><br/></t>
<dl>
<dt>Range Size:</dt><dd> 3 octets with a non-zero value
indicating the number of labels in the range.</dd>
<dt>SID/Label TLV:</dt><dd>(as defined in <xref target="SIDLABEL
TLV" format="default"/>) used as a sub-TLV, which encodes the
first label in the range. Since the SID/Label TLV is used to first label in the range. Since the SID/Label TLV is used to
indicate the first label of the SRGB range, only label indicate the first label of the SRGB range, only label
encoding is valid under the SR Capabilities TLV.</t> encoding is valid under the SR Capabilities TLV.</dd>
</list></t>
</list></t>
</section>
<section anchor="SRALGOTLV" title="SR Algorithm TLV"> </dl>
<t>The SR Algorithm TLV is used in order to advertise the SR </dd>
Algorithms supported by the node. This information is derived from </dl>
the protocol specific advertisements. <list style="symbols">
<t>IS-IS, as defined by the SR-Algorithm sub-TLV in section 3.2
of <xref
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in section </section>
3.1 of <xref
target="I-D.ietf-ospf-segment-routing-extensions"/>. OSPFv3 <section anchor="SRALGOTLV" numbered="true" toc="default">
leverages the same TLV as defined for OSPFv2.</t> <name>SR-Algorithm TLV</name>
</list>The SR Algorithm TLV has the following format: <figure <t>The SR-Algorithm TLV is used in order to advertise the SR algorithm
anchor="SRALGTLVFIG" title="SR Algorithm TLV Format"> s
<artwork><![CDATA[ supported by the node. This information is derived from
the protocol-specific advertisements. </t>
<ul spacing="normal">
<li>IS-IS, as defined by the SR-Algorithm Sub-TLV in
<xref target="RFC8667" section="3.2" sectionFormat="of"/>.</li>
<li>OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in
<xref target="RFC8665" section="3.1" sectionFormat="of"/>. OSPFv3
leverages the same TLV as defined for OSPFv2.</li>
</ul>
<t>The SR-Algorithm TLV has the following format: </t>
<figure anchor="SRALGTLVFIG">
<name>SR-Algorithm TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm N | | Algorithm 1 | Algorithm... | Algorithm N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
<dl newline="false" spacing="normal">
]]></artwork> <dt>Type:</dt><dd> 1035</dd>
</figure></t>
<t>Where:<list style="hanging"> <dt>Length:</dt><dd> Variable. The minimum length is 1 octet and the
<t>Type: 1035</t> maximum can be
256.</dd>
<t>Length: Variable. Minimum length is 1 and maximum can be <dt>Algorithm:</dt><dd> One or more fields of 1 octet each that iden
256.</t> tifies the
algorithm.</dd>
</dl>
<t>Algorithm: One or more fields of 1 octet each identifying the
algorithm.</t>
</list></t>
</section> </section>
<section anchor="SRLB" numbered="true" toc="default">
<section anchor="SRLB" title="SR Local Block TLV"> <name>SR Local Block TLV</name>
<t>The SR Local Block (SRLB) TLV contains the range(s) of labels the <t>The SRLB TLV contains the range(s) of labels the
node has reserved for local SIDs. Local SIDs are used, e.g., in IGP node has reserved for local SIDs. Local SIDs are used, e.g., in IGP
(IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by (IS-IS, OSPF) for Adjacency SIDs and may also be allocated by
components other than IGP protocols. As an example, an application components other than IGP protocols. As an example, an application
or a controller may instruct a node to allocate a specific local or a controller may instruct a node to allocate a specific local
SID. Therefore, in order for such applications or controllers to SID. Therefore, in order for such applications or controllers to
know the range of local SIDs available, it is required that the node know the range of local SIDs available, the node is required to
advertises its SRLB.</t> advertise its SRLB.</t>
<t>This information is derived from the protocol-specific
<t>This information is derived from the protocol specific advertisements. </t>
advertisements. <list style="symbols"> <ul spacing="normal">
<t>IS-IS, as defined by the SR Local Block sub-TLV in section <li>IS-IS, as defined by the SRLB Sub-TLV in
3.3 of <xref <xref target="RFC8667" section="3.3" sectionFormat="of"/>.</li>
target="I-D.ietf-isis-segment-routing-extensions"/>.</t> <li>OSPFv2/OSPFv3, as defined by the SR Local Block TLV in
<xref target="RFC8665" section="3.3" sectionFormat="of"/>. OSPFv3
<t>OSPFv2/OSPFv3, as defined by the SR Local Block TLV in leverages the same TLV as defined for OSPFv2.</li>
section 3.3. of <xref </ul>
target="I-D.ietf-ospf-segment-routing-extensions"/>. OSPFv3 <t>The SRLB TLV has the following format: </t>
leverages the same TLV as defined for OSPFv2.</t> <figure anchor="SRLBTLVFIG">
</list></t> <name>SRLB TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
<t>The SRLB TLV has the following format: <figure 1 2 3
anchor="SRLBTLVFIG" title="SRLB TLV Format">
<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 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 | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Range Size 1 | | Sub-Range Size 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV 1 // | SID/Label Sub-TLV 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Range Size N | | Sub-Range Size N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV N // | SID/Label Sub-TLV N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging"> <dl newline="false" spacing="normal">
<t>Type: 1036</t>
<t>Length: Variable. Minimum length is 12.</t> <dt>Type:</dt><dd> 1036</dd>
<t>Flags: 1 octet of flags. The flags are as defined in section <dt>Length:</dt><dd> Variable. The minimum length is 12 octets.</dd>
3.3 of <xref target="I-D.ietf-isis-segment-routing-extensions"/>
<dt>Flags:</dt><dd> 1 octet of flags. The flags are as defined in
<xref target="RFC8667" section="3.3" sectionFormat="of"/>
for IS-IS. The flags are not currently defined for OSPFv2 and for IS-IS. The flags are not currently defined for OSPFv2 and
OSPFv3 and MUST be set to 0 and ignored on receipt.</t> OSPFv3 and <bcp14>MUST</bcp14> be set to 0 and ignored on receipt. </dd>
<t>Reserved: 1 octet that MUST be set to 0 and ignored on <dt>Reserved:</dt><dd> 1 octet that <bcp14>MUST</bcp14> be set to 0
receipt.</t> and ignored on
receipt.</dd>
<t>One or more entries corresponding to sub-range(s), each of <dt>One or more entries corresponding to a sub-range(s), each of
which have the following format:<list style="hanging"> which have the following format:</dt>
<t>Range Size: 3 octet value indicating the number of labels <dd>
in the range.</t>
<t>SID/Label TLV (as defined in <xref <t><br/></t>
target="SIDLABELTLV"/>) used as sub-TLV which encodes the <dl>
<dt>Range Size:</dt><dd> 3-octet value indicating the number of
labels
in the range.</dd>
<dt>SID/Label TLV:</dt><dd>(as defined in <xref target="SIDLABEL
TLV" format="default"/>) used as a sub-TLV, which encodes the
first label in the sub-range. Since the SID/Label TLV is first label in the sub-range. Since the SID/Label TLV is
used to indicate the first label of the SRLB sub-range, only used to indicate the first label of the SRLB sub-range, only
label encoding is valid under the SR Local Block TLV.</t> label encoding is valid under the SR Local Block TLV.</dd>
</list></t> </dl>
</list></t> </dd>
</section> </dl>
<section anchor="SRMSPREF" title="SRMS Preference TLV"> </section>
<section anchor="SRMSPREF" numbered="true" toc="default">
<name>SRMS Preference TLV</name>
<t>The Segment Routing Mapping Server (SRMS) Preference TLV is used <t>The Segment Routing Mapping Server (SRMS) Preference TLV is used
in order to associate a preference with SRMS advertisements from a in order to associate a preference with SRMS advertisements from a
particular source. <xref particular source. <xref target="RFC8661" format="default"/> specifies
target="I-D.ietf-spring-segment-routing-ldp-interop"/> specifies the the
SRMS functionality along with SRMS preference of the node SRMS functionality along with the SRMS preference of the node
advertising the SRMS Prefix-to-SID Mapping ranges.</t> advertising the SRMS Prefix-to-SID mapping ranges.</t>
<t>This information is derived from the protocol-specific
<t>This information is derived from the protocol specific advertisements. </t>
advertisements. <list style="symbols"> <ul spacing="normal">
<t>IS-IS, as defined by the SRMS Preference sub-TLV in section <li>IS-IS, as defined by the SRMS Preference Sub-TLV in
3.4 of <xref <xref target="RFC8667" section="3.4" sectionFormat="of"/>.</li>
target="I-D.ietf-isis-segment-routing-extensions"/>.</t> <li>OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in
<xref target="RFC8665" section="3.4" sectionFormat="of"/>. OSPFv3
<t>OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in leverages the same TLV as defined for OSPFv2.</li>
section 3.4 of <xref </ul>
target="I-D.ietf-ospf-segment-routing-extensions"/>. OSPFv3 <t>The SRMS Preference TLV has the following format: </t>
leverages the same TLV as defined for OSPFv2.</t> <figure anchor="SRMSTLVFIG">
</list></t> <name>SRMS Preference TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0
<t>The SRMS Preference TLV has the following format: <figure 1 2 3
anchor="SRMSTLVFIG" title="SRMS Preference TLV Format">
<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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | Preference |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:<list style="hanging">
<t>Type: 1037</t>
<t>Length: 1.</t>
<t>Preference: 1 octet carrying an unsigned 8 bit SRMS
preference.</t>
</list></t>
</section>
</section>
<section anchor="LINK" title="Link Attribute TLVs">
<t>The following Link Attribute TLVs are are defined:</t>
<texttable anchor="link-attribute_tlv" title="Link Attribute TLVs">
<ttcol align="center">Type</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="right">Section</ttcol>
<c>1099</c>
<c>Adjacency SID TLV</c>
<c><xref target="ADJSIDTLV"/></c>
<c>1100</c>
<c>LAN Adjacency SID TLV</c> <t>Where:</t>
<c><xref target="LANADJSIDTLV"/></c> <dl newline="false" spacing="normal">
<c>1172</c> <dt>Type:</dt><dd> 1037</dd>
<c>L2 Bundle Member TLV</c> <dt>Length:</dt><dd> 1 octet</dd>
<c><xref target="L2BUNDLETLV"/></c> <dt>Preference:</dt><dd> 1 octet carrying an unsigned 8-bit SRMS
</texttable> preference.</dd>
</dl>
</section>
</section>
<section anchor="LINK" numbered="true" toc="default">
<name>Link Attribute TLVs</name>
<t>The following Link Attribute TLVs are defined:</t>
<table anchor="link-attribute_tlv" align="center">
<name>Link Attribute TLVs</name>
<thead>
<tr>
<th align="left">Type</th>
<th align="left">Description</th>
<th align="left">Section</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1099</td>
<td align="left">Adjacency SID TLV</td>
<td align="right">
<xref target="ADJSIDTLV" format="default"/></td>
</tr>
<tr>
<td align="center">1100</td>
<td align="left">LAN Adjacency SID TLV</td>
<td align="right">
<xref target="LANADJSIDTLV" format="default"/></td>
</tr>
<tr>
<td align="center">1172</td>
<td align="left">L2 Bundle Member Attributes TLV</td>
<td align="right">
<xref target="L2BUNDLETLV" format="default"/></td>
</tr>
</tbody>
</table>
<t>These TLVs should only be added to the BGP-LS Attribute associated <t>These TLVs should only be added to the BGP-LS Attribute associated
with the Link NLRI describing the link of the IGP node that is with the Link NLRI that describes the link of the IGP node that is
originating the corresponding IGP TLV/sub-TLV described below.</t> originating the corresponding IGP TLV/sub-TLV described below.</t>
<section anchor="ADJSIDTLV" numbered="true" toc="default">
<section anchor="ADJSIDTLV" title="Adjacency SID TLV"> <name>Adjacency SID TLV</name>
<t>The Adjacency SID TLV is used in order to advertise information <t>The Adjacency SID TLV is used in order to advertise information
related to an Adjacency SID. This information is derived from related to an Adjacency SID. This information is derived from
Adj-SID sub-TLV of IS-IS (section 2.2.1 of <xref the Adj-SID Sub-TLV of IS-IS (<xref target="RFC8667" section="2.2.1" s
target="I-D.ietf-isis-segment-routing-extensions"/>), OSPFv2 ectionFormat="of"/>), OSPFv2
(section 6.1 of <xref (<xref target="RFC8665" section="6.1" sectionFormat="of"/>), and OSPFv
target="I-D.ietf-ospf-segment-routing-extensions"/>) and OSPFv3 3
(section 7.1 of <xref (<xref target="RFC8666" section="7.1" sectionFormat="of"/>).</t>
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t> <t>The Adjacency SID TLV has the following format: </t>
<figure anchor="ADJSIDTLVFIG">
<t>The Adjacency SID TLV has the following format: <figure <name>Adjacency SID TLV Format</name>
anchor="ADJSIDTLVFIG" title="Adjacency SID TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) // | SID/Label/Index (variable) //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging"> <dl newline="false" spacing="normal">
<t>Type: 1099</t>
<t>Length: Variable. Either 7 or 8 depending on Label or Index
encoding of the SID</t>
<t>Flags. 1 octet value which should be set as: <list
style="symbols">
<t>IS-IS Adj-SID flags are defined in section 2.2.1 of <xref
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2 Adj-SID flags are defined in section 6.1 of <xref <dt>Type:</dt><dd>1099</dd>
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
<t>OSPFv3 Adj-SID flags are defined in section 7.1 of <xref <dt>Length:</dt><dd> Variable. Either 7 or 8 octets depending on the
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t label or index
> encoding of the SID.</dd>
</list></t>
<t>Weight: 1 octet carrying the weight used for load-balancing <dt>Flags:</dt><dd><t> 1-octet value that should be set as: </t>
purposes. The use of weight is described in section 3.4 of <xref <ul spacing="normal">
target="RFC8402"/>.</t> <li>IS-IS Adj-SID flags as defined in <xref target="RFC8667" sec
tion="2.2.1" sectionFormat="of"/>.</li>
<li>OSPFv2 Adj-SID flags as defined in <xref target="RFC8665" se
ction="6.1" sectionFormat="of"/>.</li>
<li>OSPFv3 Adj-SID flags as defined in <xref target="RFC8666" se
ction="7.1" sectionFormat="of"/>.</li>
</ul>
</dd>
<t>Reserved: 2 octets that MUST be set to 0 and ignored on <dt>Weight:</dt><dd> 1 octet carrying the weight used for load-balan
receipt.</t> cing
purposes. The use of weight is described in <xref target="RFC8402"
section="3.4" sectionFormat="of"/>.</dd>
<t>SID/Index/Label: <list style="symbols"> <dt>Reserved:</dt><dd> 2 octets that <bcp14>MUST</bcp14> be set to 0
<t>IS-IS: Label or index value as defined in section 2.2.1 and ignored on
of <xref receipt.</dd>
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2: Label or index value as defined in section 6.1 of <dt>SID/Index/Label: </dt>
<xref
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
<t>OSPFv3: Label or index value as defined in section 7.1 of <dd><t><br/></t>
<xref <dl spacing="normal">
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t <dt>IS-IS:</dt><dd> Label or index value as defined in
> <xref target="RFC8667" section="2.2.1" sectionFormat="of"/>.</d
</list></t> d>
</list></t> <dt>OSPFv2:</dt><dd> Label or index value as defined in
<xref target="RFC8665" section="6.1" sectionFormat="of"/>.</dd
>
<dt>OSPFv3:</dt><dd> Label or index value as defined in
<xref target="RFC8666" section="7.1" sectionFormat="of"/>.</dd
>
</dl>
</dd>
</dl>
<t>The Flags and, as an extension, the SID/Index/Label fields of <t>The Flags and, as an extension, the SID/Index/Label fields of
this TLV are interpreted according to the respective underlying this TLV are interpreted according to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link
NLRI is used to determine the underlying protocol specification for NLRI is used to determine the underlying protocol specification for
parsing these fields.</t> parsing these fields.</t>
</section> </section>
<section anchor="LANADJSIDTLV" numbered="true" toc="default">
<name>LAN Adjacency SID TLV</name>
<section anchor="LANADJSIDTLV" title="LAN Adjacency SID TLV">
<t>For a LAN, normally a node only announces its adjacency to the <t>For a LAN, normally a node only announces its adjacency to the
IS-IS pseudo-node (or the equivalent OSPF Designated and Backup IS-IS pseudonode (or the equivalent OSPF Designated and Backup
Designated Routers). The LAN Adjacency Segment TLV allows a node to Designated Routers). The LAN Adjacency SID TLV allows a node to
announce adjacencies to all other nodes attached to the LAN in a announce adjacencies to all other nodes attached to the LAN in a
single instance of the BGP-LS Link NLRI. Without this TLV, the single instance of the BGP-LS Link NLRI. Without this TLV, the
corresponding BGP-LS link NLRI would need to be originated for each corresponding BGP-LS Link NLRI would need to be originated for each
additional adjacency in order to advertise the SR TLVs for these additional adjacency in order to advertise the SR TLVs for these
neighbor adjacencies.</t> neighbor adjacencies.</t>
<t>This information is derived from LAN-Adj-SID sub-TLV of IS-IS <t>This information is derived from the LAN-Adj-SID Sub-TLV of
(section 2.2.2 of <xref IS-IS (<xref target="RFC8667" sectionFormat="of" section="2.2.2"/>), t
target="I-D.ietf-isis-segment-routing-extensions"/>) and LAN Adj-SID he LAN Adj-SID Sub-TLV of OSPFv2
sub-TLV of OSPFv2 (section 6.2 of <xref (<xref target="RFC8665" sectionFormat="of" section="6.2"/>), and the L
target="I-D.ietf-ospf-segment-routing-extensions"/>) and OSPFv3 AN Adj-SID Sub-TLV of OSPFv3 (<xref
(section 7.2 of <xref target="RFC8666" sectionFormat="of" section="7.2"/>).</t>
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t> <t>The LAN Adjacency SID TLV has the following format: </t>
<figure anchor="LADJSIDTLVFIG">
<t>The LAN Adjacency SID TLV has the following format: <figure <name>LAN Adjacency SID TLV Format</name>
anchor="LADJSIDTLVFIG" title="LAN Adjacency SID TLV Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Neighbor ID / IS-IS System-ID | | OSPF Neighbor ID / IS-IS System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) // | SID/Label/Index (variable) //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging"> <dl newline="false" spacing="normal">
<t>Type: 1100</t>
<t>Length: Variable. For IS-IS it would be 13 or 14 depending on <dt>Type:</dt> <dd>1100</dd>
Label or Index encoding of the SID. For OSPF it would be 11 or
12 depending on Label or Index encoding of the SID.</t>
<t>Flags. 1 octet value which should be set as: <list <dt>Length:</dt><dd> Variable. For IS-IS, it would be 13 or 14 octet
style="symbols"> s depending on
<t>IS-IS LAN Adj-SID flags are defined in section 2.2.2 of the label or index encoding of the SID. For OSPF, it would be 11 o
<xref r
target="I-D.ietf-isis-segment-routing-extensions"/>.</t> 12 octets depending on the label or index encoding of the SID.</dd
>
<t>OSPFv2 LAN Adj-SID flags are defined in section 6.2 of <dt>Flags:</dt><dd><t> 1-octet value that should be set as: </t>
<xref
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
<t>OSPFv3 LAN Adj-SID flags are defined in section 7.2 of <ul spacing="normal">
<xref <li>IS-IS LAN Adj-SID flags as defined in
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <xref target="RFC8667" section="2.2.2" sectionFormat="of"/>.</
</list></t> li>
<li>OSPFv2 LAN Adj-SID flags as defined in
<xref target="RFC8665" section="6.2" sectionFormat="of"/>.</li
>
<t>Weight: 1 octet carrying the weight used for load-balancing <li>OSPFv3 LAN Adj-SID flags as defined in
purposes. The use of weight is described in section 3.4 of <xref <xref target="RFC8666" section="7.2" sectionFormat="of"/>.</li
target="RFC8402"/>.</t> >
</ul>
</dd>
<t>Reserved: 2 octets that MUST be set to 0 and ignored on <dt>Weight:</dt><dd> 1 octet carrying the weight used for load-balan
receipt.</t> cing
purposes. The use of weight is described in <xref target="RFC8402"
section="3.4" sectionFormat="of"/>.</dd>
<t>Neighbor ID: 6 octets for IS-IS for the System-ID and 4 <dt>Reserved:</dt><dd> 2 octets that <bcp14>MUST</bcp14> be set to 0
octets for OSPF for the OSPF Router-ID of the neighbor.</t> and ignored on
receipt.</dd>
<t>SID/Index/Label: <list style="symbols"> <dt>Neighbor ID:</dt><dd> 6 octets for IS-IS for the System ID, and
<t>IS-IS: Label or index value as defined in section 2.2.2 4
of <xref octets for OSPF for the OSPF Router-ID of the neighbor.</dd>
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2: Label or index value as defined in section 6.2 of <dt>SID/Index/Label: </dt>
<xref
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
<t>OSPFv3: Label or index value as defined in section 7.2 of <dd><t><br/></t>
<xref <dl spacing="normal">
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t <dt>IS-IS:</dt><dd> Label or index value as defined in
> <xref target="RFC8667" section="2.2.2" sectionFormat="of"/>.</
</list></t> dd>
</list></t> <dt>OSPFv2:</dt><dd> Label or index value as defined in
<xref target="RFC8665" section="6.2" sectionFormat="of"/>.</dd
>
<dt>OSPFv3:</dt><dd> Label or index value as defined in
<xref target="RFC8666" section="7.2" sectionFormat="of"/>.</dd
>
</dl>
</dd>
</dl>
<t>The Neighbor ID, Flags and, as an extension, the SID/Index/Label <t>The Neighbor ID, Flags, and, as an extension, the SID/Index/Label
fields of this TLV are interpreted according to the respective fields of this TLV are interpreted according to the respective
underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the underlying IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the
BGP-LS Link NLRI is used to determine the underlying protocol BGP-LS Link NLRI is used to determine the underlying protocol
specification for parsing these fields.</t> specification for parsing these fields.</t>
</section> </section>
<section anchor="L2BUNDLETLV" numbered="true" toc="default">
<section anchor="L2BUNDLETLV" title="L2 Bundle Member Attribute TLV"> <name>L2 Bundle Member Attributes TLV</name>
<t>The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member <t>The L2 Bundle Member Attributes TLV identifies an L2 Bundle Member
link which in turn is associated with a parent L3 link. The L3 link link, which in turn is associated with a parent L3 link. The L3 link
is described by the Link NLRI defined in <xref target="RFC7752"/> is described by the Link NLRI defined in <xref target="RFC7752" format
and the L2 Bundle Member Attribute TLV is associated with the Link ="default"/>,
NLRI. The TLV MAY include sub-TLVs which describe attributes and the L2 Bundle Member Attributes TLV is associated with the Link
NLRI. The TLV <bcp14>MAY</bcp14> include sub-TLVs that describe attrib
utes
associated with the bundle member. The identified bundle member associated with the bundle member. The identified bundle member
represents a unidirectional path from the originating router to the represents a unidirectional path from the originating router to the
neighbor specified in the parent L3 Link. Multiple L2 Bundle Member neighbor specified in the parent L3 link. Multiple L2 Bundle Member
Attribute TLVs MAY be associated with a Link NLRI.</t> Attributes TLVs <bcp14>MAY</bcp14> be associated with a Link NLRI.</t>
<t>This information is derived from L2 Bundle Member Attributes TLV <t>This information is derived from L2 Bundle Member Attributes TLV
of IS-IS (section 2 of <xref target="I-D.ietf-isis-l2bundles"/>). of IS-IS (<xref target="RFC8668" section="2" sectionFormat="of"/>).
The equivalent functionality has not been specified as yet for The equivalent functionality has not been specified as yet for
OSPF.</t> OSPF.</t>
<t>The L2 Bundle Member Attributes TLV has the following format:
<t>The L2 Bundle Member Attribute TLV has the following format: </t>
<figure anchor="L2BTLVFIG" <figure anchor="L2BTLVFIG">
title="L2 Bundle Member Attributes TLV Format"> <name>L2 Bundle Member Attributes TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[ 0
3 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2 Bundle Member Descriptor | | L2 Bundle Member Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link attribute sub-TLVs(variable) // | Link Attribute Sub-TLVs(variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging"> <dl newline="false" spacing="normal">
<t>Type: 1172</t>
<t>Length: Variable.</t> <dt>Type:</dt><dd> 1172</dd>
<t>L2 Bundle Member Descriptor: 4 octets field that carries a <dt>Length:</dt><dd> Variable.</dd>
Link Local Identifier as defined in <xref
target="RFC4202"/>.</t>
</list></t>
<t>Link attributes for L2 Bundle Member Links are advertised as <dt>L2 Bundle Member Descriptor:</dt><dd> 4-octet field that carries
sub-TLVs of the L2 Bundle Member Attribute TLV. The sub-TLVs are a
link-local identifier as defined in <xref target="RFC4202" format=
"default"/>.</dd>
</dl>
<t>Link attributes for L2 Bundle Member links are advertised as
sub-TLVs of the L2 Bundle Member Attributes TLV. The sub-TLVs are
identical to existing BGP-LS TLVs as identified in the table identical to existing BGP-LS TLVs as identified in the table
below.</t> below.</t>
<table anchor="l2subtlvs" align="center">
<texttable anchor="l2subtlvs" <name>BGP-LS Attribute TLVs are also used as sub-TLVs of the L2 Bund
title="BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bu le Member Attributes TLV</name>
ndle Member Attribute TLV"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference Document</th>
<ttcol align="left">Reference Document</ttcol> </tr>
</thead>
<c>1088</c> <tbody>
<tr>
<c>Administrative group (color)</c> <td align="center">1088</td>
<td align="left">Administrative group (color)</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1089</c> </tr>
<tr>
<c>Maximum link bandwidth</c> <td align="center">1089</td>
<td align="left">Maximum link bandwidth</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1090</c> </tr>
<tr>
<c>Max. reservable link bandwidth</c> <td align="center">1090</td>
<td align="left">Max. reservable link bandwidth</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1091</c> </tr>
<tr>
<c>Unreserved bandwidth</c> <td align="center">1091</td>
<td align="left">Unreserved bandwidth</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1092</c> </tr>
<tr>
<c>TE default metric</c> <td align="center">1092</td>
<td align="left">TE default metric</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1093</c> </tr>
<tr>
<c>Link protection type</c> <td align="center">1093</td>
<td align="left">Link protection type</td>
<c><xref target="RFC7752"/></c> <td align="left">
<xref target="RFC7752" format="default"/></td>
<c>1099</c> </tr>
<tr>
<c>Adjacency Segment Identifier (Adj-SID) TLV</c> <td align="center">1099</td>
<td align="left">Adjacency Segment Identifier (Adj-SID) TLV</td>
<c><xref target="ADJSIDTLV"/></c> <td align="left">
<xref target="ADJSIDTLV" format="default"/></td>
<c>1100</c> </tr>
<tr>
<c>LAN Adjacency Segment Identifier (Adj-SID) TLV</c> <td align="center">1100</td>
<td align="left">LAN Adjacency Segment Identifier (Adj-SID) TLV<
<c><xref target="LANADJSIDTLV"/></c> /td>
<td align="left">
<c>1114</c> <xref target="LANADJSIDTLV" format="default"/></td>
</tr>
<c>Unidirectional link delay</c> <tr>
<td align="center">1114</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional link delay</td>
<td align="left">
<c>1115</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Min/Max Unidirectional link delay</c> <tr>
<td align="center">1115</td>
<c><xref target="RFC8571"/></c> <td align="left">Min/Max Unidirectional link delay</td>
<td align="left">
<c>1116</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Unidirectional Delay Variation</c> <tr>
<td align="center">1116</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional Delay Variation</td>
<td align="left">
<c>1117</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Unidirectional packet loss</c> <tr>
<td align="center">1117</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional Link Loss</td>
<td align="left">
<c>1118</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Unidirectional residual bandwidth</c> <tr>
<td align="center">1118</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional residual bandwidth</td>
<td align="left">
<c>1119</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Unidirectional available bandwidth</c> <tr>
<td align="center">1119</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional available bandwidth</td>
<td align="left">
<c>1120</c> <xref target="RFC8571" format="default"/></td>
</tr>
<c>Unidirectional bandwidth utilization</c> <tr>
<td align="center">1120</td>
<c><xref target="RFC8571"/></c> <td align="left">Unidirectional Utilized Bandwidth</td>
</texttable> <td align="left">
<xref target="RFC8571" format="default"/></td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="PREFIX" numbered="true" toc="default">
<section anchor="PREFIX" title="Prefix Attribute TLVs "> <name>Prefix Attribute TLVs</name>
<t>The following Prefix Attribute TLVs are defined:</t> <t>The following Prefix Attribute TLVs are defined:</t>
<texttable anchor="prefix-attribute_tlv" title="Prefix Attribute TLVs"> <table anchor="prefix-attribute_tlv" align="center">
<ttcol align="center">Type</ttcol> <name>Prefix Attribute TLVs</name>
<thead>
<ttcol align="left">Description</ttcol> <tr>
<th align="center">Type</th>
<ttcol align="left">Section</ttcol> <th align="left">Description</th>
<th align="left">Section</th>
<c>1158</c> </tr>
</thead>
<c>Prefix SID</c> <tbody>
<tr>
<c><xref target="PREFIXSIDTLV"/></c> <td align="center">1158</td>
<td align="left">Prefix-SID</td>
<c>1159</c> <td align="left">
<xref target="PREFIXSIDTLV" format="default"/></td>
<c>Range</c> </tr>
<tr>
<c><xref target="RANGETLV"/></c> <td align="center">1159</td>
<td align="left">Range</td>
<c>1170</c> <td align="left">
<xref target="RANGETLV" format="default"/></td>
<c>Prefix Attribute Flags</c> </tr>
<tr>
<c><xref target="PREFIXATTRFLAGTLV"/></c> <td align="center">1170</td>
<td align="left">Prefix Attribute Flags</td>
<c>1171</c> <td align="left">
<xref target="PREFIXATTRFLAGTLV" format="default"/></td>
<c>Source Router-ID</c> </tr>
<tr>
<c><xref target="SOURCEIDTLV"/></c> <td align="center">1171</td>
</texttable> <td align="left">Source Router Identifier</td>
<td align="left">
<xref target="SOURCEIDTLV" format="default"/></td>
</tr>
<tr>
<td align="center">1174</td>
<td align="left">Source OSPF Router-ID</td>
<td align="left">
<xref target="SOURCEOSPFRIDTLV" format="default"/></td>
</tr>
</tbody>
</table>
<t>These TLVs should only be added to the BGP-LS Attribute associated <t>These TLVs should only be added to the BGP-LS Attribute associated
with the Prefix NLRI describing the prefix of the IGP node that is with the Prefix NLRI that describes the prefix of the IGP node that is
originating the corresponding IGP TLV/sub-TLV described below.</t> originating the corresponding IGP TLV/sub-TLV described below.</t>
<section anchor="PREFIXSIDTLV" numbered="true" toc="default">
<section anchor="PREFIXSIDTLV" title="Prefix SID TLV"> <name>Prefix-SID TLV</name>
<t>The Prefix SID TLV is used in order to advertise information <t>The Prefix-SID TLV is used in order to advertise information
related to a Prefix SID. This information is derived from Prefix-SID related to a Prefix-SID. This information is derived from the Prefix-S
sub-TLV of IS-IS (section 2.1 of <xref ID
target="I-D.ietf-isis-segment-routing-extensions"/>) and the Prefix Sub-TLV of IS-IS (<xref target="RFC8667" section="2.1" sectionFormat="
SID sub-TLV of OSPFv2 (section 5 of <xref of"/>), the Prefix-SID
target="I-D.ietf-ospf-segment-routing-extensions"/>) and OSPFv3 Sub-TLV of OSPFv2 (<xref target="RFC8665" section="5" sectionFormat="o
(section 6 of <xref f"/>), and the Prefix-SID
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t> Sub-TLV of OSPFv3
(<xref target="RFC8666" section="6" sectionFormat="of"/>).</t>
<t>The Prefix SID TLV has the following format: <figure <t>The Prefix-SID TLV has the following format: </t>
anchor="PFXSIDTLVFIG" title="Prefix SID TLV Format"> <figure anchor="PFXSIDTLVFIG">
<artwork><![CDATA[ <name>Prefix-SID TLV Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | Reserved | | Flags | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) // | SID/Index/Label (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list style="hanging">
<t>Type: 1158</t>
<t>Length: Variable. 7 or 8 depending on Label or Index encoding <dl>
of the SID</t>
<t>Flags: 1 octet value which should be set as: <list <dt>Type:</dt><dd> 1158</dd>
style="symbols">
<t>IS-IS Prefix SID flags are defined in section 2.1.1 of
<xref
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2 Prefix SID flags are defined in section 5 of <xref <dt>Length:</dt><dd> Variable. 7 or 8 octets depending on the label
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> or index encoding
of the SID.</dd>
<t>OSPFv3 Prefix SID flags are defined in section 6 of <xref <dt>Flags:</dt><dd><t> 1-octet value that should be set as: </t>
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
</list></t>
<t>Algorithm: 1 octet value identify the algorithm. The <ul spacing="normal">
semantics of algorithm are described in section 3.1.1 of <xref <li>IS-IS Prefix-SID flags as defined in
target="RFC8402"/>.</t> <xref target="RFC8667" section="2.1.1" sectionFormat="of"/>.</
li>
<li>OSPFv2 Prefix-SID flags as defined in <xref target="RFC8665"
section="5" sectionFormat="of"/>.</li>
<li>OSPFv3 Prefix-SID flags as defined in <xref target="RFC8665"
section="6" sectionFormat="of"/>.</li>
</ul>
</dd>
<t>Reserved: 2 octets that MUST be set to 0 and ignored on <dt>Algorithm:</dt><dd> 1-octet value identifies the algorithm. The
receipt.</t> semantics of the algorithm are described in <xref target="RFC8402"
section="3.1.1" sectionFormat="of"/>.</dd>
<t>SID/Index/Label: <list style="symbols"> <dt>Reserved:</dt><dd> 2 octets that <bcp14>MUST</bcp14> be set to 0
<t>IS-IS: Label or index value as defined in section 2.1 of and ignored on
<xref receipt.</dd>
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2: Label or index value as defined in section 5 of <dt>SID/Index/Label:</dt>
<xref <dd><t><br/></t>
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <dl spacing="normal">
<t>OSPFv3: Label or index value as defined in section 6 of <dt>IS-IS:</dt><dd> Label or index value as defined in
<xref <xref target="RFC8667" section="2.1" sectionFormat="of"/>.</dd
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t >
> <dt>OSPFv2:</dt><dd> Label or index value as defined in
</list></t> <xref target="RFC8665" section="5" sectionFormat="of"/>.</dd>
</list></t> <dt>OSPFv3:</dt><dd> Label or index value as defined in
<xref target="RFC8666" section="6" sectionFormat="of"/>.</dd>
</dl>
</dd>
</dl>
<t>The Flags and, as an extension, the SID/Index/Label fields of <t>The Flags and, as an extension, the SID/Index/Label fields of
this TLV are interpreted according to the respective underlying this TLV are interpreted according to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS
Prefix NLRI is used to determine the underlying protocol Prefix NLRI is used to determine the underlying protocol
specification for parsing these fields.</t> specification for parsing these fields.</t>
</section> </section>
<section anchor="PREFIXATTRFLAGTLV" title="Prefix Attribute Flags TLV"> <section anchor="PREFIXATTRFLAGTLV" numbered="true" toc="default">
<name>Prefix Attribute Flags TLV</name>
<t>The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute <t>The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute
flags information. These flags are defined for OSPFv2 in section 2.1 flags information. These flags are defined for OSPFv2 in
of <xref target="RFC7684"/>, for OSPFv3 in section A.4.1.1 of <xref <xref target="RFC7684" section="2.1" sectionFormat="of"/>, OSPFv3 in
target="RFC5340"/> and for IS-IS in section 2.1 of <xref <xref target="RFC5340" section="A.4.1.1" sectionFormat="of"/>, and IS-IS in <xre
target="RFC7794"/>.</t> f target="RFC7794" section="2.1" sectionFormat="of"/>.</t>
<t>The Prefix Attribute Flags TLV has the following format: <figure <t>The Prefix Attribute Flags TLV has the following format: </t>
anchor="PFXATRTLVFIG" title="Prefix Attribute Flags TLV Format"> <figure anchor="PFXATRTLVFIG">
<artwork><![CDATA[ 0 1 2 <name>Prefix Attribute Flags TLV Format</name>
3 <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 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 (variable) // | Flags (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<dl>
<t>Where:<list style="hanging"> <dt>Type:</dt><dd> 1170</dd>
<t>Type: 1170</t>
<t>Length: Variable.</t> <dt>Length:</dt><dd> Variable.</dd>
<t>Flags: a variable length flag field (according to the length <dt>Flags:</dt><dd><t> a variable-length Flag field (according to the Length
field). Flags are routing protocol specific and are to be set as field). Flags are routing protocol specific and are to be set as
below:<list style="symbols"> below:</t>
<t>IS-IS flags correspond to the IPv4/IPv6 Extended
Reachability Attribute Flags defined in section 2.1 of <xref
target="RFC7794"/></t>
<t>OSPFv2 flags correspond to the Flags field of the OSPFv2 <ul spacing="normal">
Extended Prefix TLV defined in section 2.1 of <xref <li>IS-IS flags correspond to the IPv4/IPv6 Extended
target="RFC7684"/></t> Reachability Attribute Flags defined in <xref target="RFC7794" s
ection="2.1" sectionFormat="of"/>.
In the case of the X-flag when associated with IPv6 prefix
reachability, the setting corresponds to the setting of the
X-flag in the fixed format of IS-IS TLVs 236 <xref target="RF
C5308" format="default"/> and 237
<xref target="RFC5120" format="default"/>.
</li>
<t>OSPFv3 flags map to the Prefix Options field defined in <li>OSPFv2 flags correspond to the Flags field of the
section A.4.1.1 of <xref target="RFC5340"/> and extended in OSPFv2 Extended Prefix TLV defined in
section 3.1 of <xref target="RFC8362"/></t> <xref target="RFC7684" section="2.1" sectionFormat="of"/>.</li>
</list></t> <li>OSPFv3 flags map to the Prefix Options field defined in
</list></t> <xref target="RFC5340" section="A.4.1.1" sectionFormat="of"/> a
nd extended in
<xref target="RFC8362" section="3.1" sectionFormat="of"/>.</li>
</ul>
</dd>
</dl>
<t>The Flags field of this TLV is interpreted according to the <t>The Flags field of this TLV is interpreted according to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The
Protocol-ID of the BGP-LS Prefix NLRI is used to determine the Protocol-ID of the BGP-LS Prefix NLRI is used to determine the
underlying protocol specification for parsing this field.</t> underlying protocol specification for parsing this field.</t>
</section> </section>
<section anchor="SOURCEIDTLV" <section anchor="SOURCEIDTLV" numbered="true" toc="default">
title="Source Router Identifier (Source Router-ID) TLV">
<t>The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of
the originator of the Prefix. For the IS-IS protocol this is derived
from the IPv4/IPv6 Source Router ID sub-TLV as defined in section
2.2 of <xref target="RFC7794"/>. For the OSPF protocol, this is
derived from the Prefix Source Router-ID sub-TLV as defined in
section 4 of <xref
target="I-D.ietf-lsr-ospf-prefix-originator"/>.</t>
<t>The Source Router-ID TLV has the following format: <figure <name>Source Router Identifier TLV</name>
anchor="SRCRIDTLVFIG" title="Source Router-ID TLV Format"> <t>The Source Router Identifier TLV contains the IPv4 or IPv6 Router I
<artwork><![CDATA[ 0 1 2 dentifier of
3 the originator of the prefix. For the IS-IS protocol, this is derived
from the IPv4/IPv6 Source Router ID Sub-TLV as defined in
<xref target="RFC7794" section="2.2" sectionFormat="of"/>. For the OSPF
protocol, this is
derived from the Prefix Source Router Address Sub-TLV as defined in
<xref target="RFC9084" section="2.2" sectionFormat="of"/>.</t>
<t>The Source Router Identifier TLV has the following format: </t>
<figure anchor="SRCRIDTLVFIG">
<name>Source Router Identifier 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 or 16 octet Router-ID // | 4- or 16-octet Router Identifier //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:</t>
<dl>
<dt>Type:</dt><dd> 1171</dd>
<dt>Length:</dt><dd> Variable. 4 or 16 octets for the IPv4 or IPv6 p
refix, respectively.</dd>
<dt>Router-ID:</dt><dd> the IPv4 or IPv6 Router-ID in the case of IS
-IS, and
the IPv4 or IPv6 Router Address in the case of OSPF.</dd>
</dl>
</section>
<section anchor="SOURCEOSPFRIDTLV" title="Source OSPF Router-ID TLV">
<t>The Source OSPF Router-ID TLV is applicable only for the OSPF
protocol and contains the OSPF Router-ID of the originator of the
prefix. It is derived from the Prefix Source OSPF Router-ID Sub-TLV
as defined in <xref target="RFC9084" section="2.1" sectionFormat="of"/
>.</t>
<t>The Source OSPF Router-ID TLV has the following format:</t>
<figure anchor="SRCOSPFRIDTLVFIG">
<name>Source OSPF Router-ID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4-octet OSPF Router-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:<list style="hanging"> <t>Where:</t>
<t>Type: 1171</t> <dl>
<dt>Type:</dt><dd>1174</dd>
<t>Length: Variable. 4 or 16 in case of IS-IS and 4 in case of <dt>Length:</dt><dd>4 octets</dd>
OSPF.</t>
<t>Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and <dt>OSPF Router-ID:</dt><dd>the OSPF Router-ID of the node origina
the OSPF Router-ID in the case of OSPF.</t> ting
</list></t> the prefix.</dd>
</dl>
</section> </section>
<section anchor="RANGETLV" title="Range TLV"> <section anchor="RANGETLV" numbered="true" toc="default">
<name>Range TLV</name>
<t>The Range TLV is used in order to advertise a range of <t>The Range TLV is used in order to advertise a range of
prefix-to-SID mappings as part of the Segment Routing Mapping Server prefix-to-SID mappings as part of the
(SRMS) functionality <xref SRMS functionality <xref target="RFC8661" format="default"/>, as defin
target="I-D.ietf-spring-segment-routing-ldp-interop"/>, as defined ed
in the respective underlying IGP SR extensions <xref in the respective underlying IGP SR extensions: <xref target="RFC8665"
target="I-D.ietf-ospf-segment-routing-extensions"/> (section 4), section="4" sectionFormat="of"/>,
<xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/> <xref target="RFC8666" section="5" sectionFormat="of"/>,
(section 5) and <xref and <xref target="RFC8667" section="2.4" sectionFormat="of"/>.
target="I-D.ietf-isis-segment-routing-extensions"/> (section 2.4).
The information advertised in the Range TLV is derived from the The information advertised in the Range TLV is derived from the
SID/Label Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 SID/Label Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3
Extended Prefix Range TLV in the case of OSPFv2/OSPFv3.</t> Extended Prefix Range TLV in the case of OSPFv2/OSPFv3.</t>
<t>A Prefix NLRI, that been advertised with a Range TLV, is <t>A Prefix NLRI, that has been advertised with a Range TLV, is
considered a normal routing prefix (i.e. prefix reachability) only considered a normal routing prefix (i.e., prefix reachability) only
when there is also an IGP metric TLV (TLV 1095) associated it. when there is also an IGP metric TLV (TLV 1095) associated it.
Otherwise, it is considered only as the first prefix in the range Otherwise, it is considered only as the first prefix in the range
for prefix-to-SID mapping advertisement.</t> for prefix-to-SID mapping advertisement.</t>
<t>The format of the Range TLV is as follows:</t>
<t>The format of the Range TLV is as follows:<figure <figure anchor="RANGETLVFIG">
anchor="RANGETLVFIG" title="Range TLV Format"> <name>Range TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[ 0
3 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 | Reserved | Range Size | | Flags | Reserved | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs // | sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Where:</t>
<t>Where:<list> <dl>
<t>Type: 1159</t> <dt>Type:</dt><dd> 1159</dd>
<dt>Length:</dt><dd> Variable. 11 or 12 octets depending on the labe
<t>Length: Variable. 11 or 12 depending on Label or Index l or index
encoding of the SID</t> encoding of the SID.</dd>
<t>Flags: 1 octet value which should be set as: <list
style="symbols">
<t>IS-IS SID/Label Binding TLV flags are defined in section
2.4.1 of <xref
target="I-D.ietf-isis-segment-routing-extensions"/>.</t>
<t>OSPFv2 OSPF Extended Prefix Range TLV flags are defined
in section 4 of <xref
target="I-D.ietf-ospf-segment-routing-extensions"/>.</t>
<t>OSPFv3 Extended Prefix Range TLV flags are defined in <dt>Flags:</dt><dd><t> 1-octet value that should be set as: </t>
section 5 of <xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t
>
</list></t>
<t>Reserved: 1 octet that MUST be set to 0 and ignored on <ul spacing="normal">
receipt.</t> <li>IS-IS SID/Label Binding TLV flags as defined in
<xref target="RFC8667" section="2.4.1" sectionFormat="of"/>.</
li>
<li>OSPFv2 OSPF Extended Prefix Range TLV flags as defined
in <xref target="RFC8665" section="4" sectionFormat="of"/>.</l
i>
<li>OSPFv3 Extended Prefix Range TLV flags as defined in
<xref target="RFC8666" section="5" sectionFormat="of"/>.</li>
</ul>
</dd>
<t>Range Size: 2 octets that carry the number of prefixes that <dt>Reserved:</dt><dd> 1 octet that <bcp14>MUST</bcp14> be set to 0
are covered by the advertisement..</t> and ignored on
</list></t> receipt.</dd>
<dt>Range Size:</dt><dd> 2 octets that carry the number of prefixes
that
are covered by the advertisement.</dd>
</dl>
<t>The Flags field of this TLV is interpreted according to the <t>The Flags field of this TLV is interpreted according to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The
Protocol-ID of the BGP-LS Prefix NLRI is used to determine the Protocol-ID of the BGP-LS Prefix NLRI is used to determine the
underlying protocol specification for parsing this field.</t> underlying protocol specification for parsing this field.</t>
<t>The prefix-to-SID mappings are advertised using sub-TLVs as <t>The prefix-to-SID mappings are advertised using sub-TLVs as
below:<figure> below:</t>
<artwork><![CDATA[IS-IS:
SID/Label Range TLV
Prefix-SID sub-TLV
OSPFv2/OSPFv3: <dl newline="true">
OSPFv2/OSPFv3 Extended Prefix Range TLV <dt>IS-IS:</dt>
Prefix SID sub-TLV <dd>
<dl newline="true" spacing="compact">
<dt>SID/Label Range TLV</dt>
<dd>Prefix-SID Sub-TLV</dd>
</dl>
</dd>
BGP-LS: <dt>OSPFv2/OSPFv3:</dt>
Range TLV <dd>
Prefix-SID TLV (used as a sub-TLV in this context) <dl newline="true" spacing="compact">
<dt>
OSPFv2/OSPFv3 Extended Prefix Range TLV
</dt>
<dd>
Prefix-SID Sub-TLV
</dd>
</dl>
</dd>
]]></artwork> <dt>BGP-LS:</dt>
</figure></t> <dd>
<dl newline="true" spacing="compact">
<dt>Range TLV</dt>
<dd>Prefix-SID TLV (used as a sub-TLV in this context)</dd>
</dl>
</dd>
</dl>
<t>The prefix-to-SID mapping information for the BGP-LS Prefix-SID <t>The prefix-to-SID mapping information for the BGP-LS Prefix-SID
TLV (used as sub-TLV in this context) is encoded as described in TLV (used as a sub-TLV in this context) is encoded as described in
<xref target="PREFIXSIDTLV"/>.</t> <xref target="PREFIXSIDTLV" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="ISISTLV" numbered="true" toc="default">
<section anchor="ISISTLV" <name>Equivalent IS-IS Segment Routing TLVs/Sub-TLVs</name>
title="Equivalent IS-IS Segment Routing TLVs/Sub-TLVs"> <t>This section illustrates the IS-IS Segment Routing Extensions TLVs
<t>This section illustrate the IS-IS Segment Routing Extensions TLVs
and sub-TLVs mapped to the ones defined in this document.</t> and sub-TLVs mapped to the ones defined in this document.</t>
<t>The following table, illustrates for each BGP-LS TLV, its <t>For each BGP-LS TLV, the following table illustrates its
equivalence in IS-IS.</t> equivalence in IS-IS.</t>
<texttable anchor="ISISTLVTAB" <table anchor="ISISTLVTAB" align="center">
title="IS-IS Segment Routing Extensions TLVs/Sub-TLVs"> <name>IS-IS Segment Routing Extensions TLVs/Sub-TLVs</name>
<ttcol align="left">Description</ttcol> <thead>
<tr>
<ttcol align="left">IS-IS TLV/sub-TLV</ttcol> <th align="left">Description</th>
<th align="left">IS-IS TLV/sub-TLV</th>
<ttcol align="left">Reference</ttcol> <th align="left">Reference</th>
</tr>
<c>SR Capabilities</c> </thead>
<tbody>
<c>SR-Capabilities sub-TLV (2)</c> <tr>
<td align="left">SR Capabilities</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SR-Capabilities Sub-TLV (2)</td>
<td align="left">
<c>SR Algorithm</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>SR-Algorithm sub-TLV (19)</c> <tr>
<td align="left">SR Algorithm</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SR-Algorithm Sub-TLV (19)</td>
<td align="left">
<c>SR Local Block</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>SR Local Block sub-TLV (22)</c> <tr>
<td align="left">SR Local Block</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SR Local Block Sub-TLV (22)</td>
<td align="left">
<c>SRMS Preference</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>SRMS Preference sub-TLV (19)</c> <tr>
<td align="left">SRMS Preference</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SRMS Preference Sub-TLV (19)</td>
<td align="left">
<c>Adjacency SID</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>Adj-SID sub-TLV (31)</c> <tr>
<td align="left">Adjacency SID</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">Adj-SID Sub-TLV (31)</td>
<td align="left">
<c>LAN Adjacency SID</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>LAN-Adj-SID sub-TLV (32)</c> <tr>
<td align="left">LAN Adjacency SID</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">LAN-Adj-SID Sub-TLV (32)</td>
<td align="left">
<c>Prefix SID</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>Prefix-SID sub-TLV (3)</c> <tr>
<td align="left">Prefix-SID</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">Prefix-SID Sub-TLV (3)</td>
<td align="left">
<c>Range</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>SID/Label Binding TLV (149)</c> <tr>
<td align="left">Range</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SID/Label Binding TLV (149)</td>
<td align="left">
<c>SID/Label</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>SID/Label sub-TLV (1)</c> <tr>
<td align="left">SID/Label</td>
<c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <td align="left">SID/Label Sub-TLV (1)</td>
<td align="left">
<c>Prefix Attribute Flags</c> <xref target="RFC8667" format="default"/></td>
</tr>
<c>Prefix Attributes Flags sub-TLV (4)</c> <tr>
<td align="left">Prefix Attribute Flags</td>
<c><xref target="RFC7794"/></c> <td align="left">Prefix Attribute Flags Sub-TLV (4)</td>
<td align="left">
<c>Source Router-ID</c> <xref target="RFC7794" format="default"/></td>
</tr>
<c>IPv4/IPv6 Source Router ID sub-TLV (11/12)</c> <tr>
<td align="left">Source Router Identifier</td>
<c><xref target="RFC7794"/></c> <td align="left">IPv4/IPv6 Source Router ID Sub-TLV (11/12)</td>
<td align="left">
<c>L2 Bundle Member Attributes</c> <xref target="RFC7794" format="default"/></td>
</tr>
<c>L2 Bundle Member Attributes TLV (25)</c> <tr>
<td align="left">L2 Bundle Member Attributes</td>
<c><xref target="I-D.ietf-isis-l2bundles"/></c> <td align="left">L2 Bundle Member Attributes TLV (25)</td>
</texttable> <td align="left">
<xref target="RFC8668" format="default"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="OSPFTLV" numbered="true" toc="default">
<section anchor="OSPFTLV" <name>Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs</name>
title="Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs"> <t>This section illustrates the OSPFv2 and OSPFv3 Segment Routing
<t>This section illustrate the OSPFv2 and OSPFv3 Segment Routing
Extensions TLVs and sub-TLVs mapped to the ones defined in this Extensions TLVs and sub-TLVs mapped to the ones defined in this
document.</t> document.</t>
<t>The following table, illustrates for each BGP-LS TLV, its <t>For each BGP-LS TLV, the following tables illustrate its
equivalence in OSPFv2 and OSPFv3.</t> equivalence in OSPFv2 and OSPFv3.</t>
<table anchor="OSPFTVLTAB" align="center">
<name>OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs</name>
<thead>
<tr>
<th align="left">Description</th>
<th align="left">OSPFv2 TLV/sub-TLV</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">SR Capabilities</td>
<td align="left">SID/Label Range TLV (9)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">SR Algorithm</td>
<td align="left">SR-Algorithm TLV (8)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">SR Local Block</td>
<td align="left">SR Local Block TLV (14)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">SRMS Preference</td>
<td align="left">SRMS Preference TLV (15)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">Adjacency SID</td>
<td align="left">Adj-SID Sub-TLV (2)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">LAN Adjacency SID</td>
<td align="left">LAN Adj-SID Sub-TLV (3)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">Prefix-SID</td>
<td align="left">Prefix-SID Sub-TLV (2)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">Range</td>
<td align="left">OSPF Extended Prefix Range TLV (2)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">SID/Label</td>
<td align="left">SID/Label Sub-TLV (1)</td>
<td align="left">
<xref target="RFC8665" format="default"/></td>
</tr>
<tr>
<td align="left">Prefix Attribute Flags</td>
<td align="left">Flags of OSPFv2 Extended Prefix TLV (1)</td>
<td align="left">
<xref target="RFC7684" format="default"/></td>
</tr>
<tr>
<td align="left">Source Router Identifier</td>
<td align="left">Prefix Source Router Address Sub-TLV (5)</td>
<td align="left">
<xref target="RFC9084" format="default"/></td>
</tr>
<tr>
<td align="left">Source OSPF Router-ID</td>
<td align="left">Prefix Source OSPF Router-ID Sub-TLV (4)</td>
<td align="left">
<xref target="RFC9084" format="default"/></td>
</tr>
</tbody>
</table>
<texttable anchor="OSPFTVLTAB" <table anchor="OSPFV3TVLTAB" align="center">
title="OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs"> <name>OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs</name>
<ttcol align="left">Description</ttcol> <thead>
<tr>
<ttcol align="left">OSPFv2 TLV/sub-TLV</ttcol> <th align="left">Description</th>
<th align="left">OSPFv3 TLV/sub-TLV</th>
<ttcol align="left">Reference</ttcol> <th align="left">Reference</th>
</tr>
<c>SR Capabilities</c> </thead>
<tbody>
<c>SID/Label Range TLV (9)</c> <tr>
<td align="left">SR Capabilities</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">SID/Label Range TLV (9)</td>
<td align="left">
<c>SR Algorithm</c> <xref target="RFC8665" format="default"/></td>
</tr>
<c>SR-Algorithm TLV (8)</c> <tr>
<td align="left">SR Algorithm</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">SR-Algorithm TLV (8)</td>
<td align="left">
<c>SR Local Block</c> <xref target="RFC8665" format="default"/></td>
</tr>
<c>SR Local Block TLV (14)</c> <tr>
<td align="left">SR Local Block</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">SR Local Block TLV (14)</td>
<td align="left">
<c>SRMS Preference</c> <xref target="RFC8665" format="default"/></td>
</tr>
<c>SRMS Preference TLV (15)</c> <tr>
<td align="left">SRMS Preference</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">SRMS Preference TLV (15)</td>
<td align="left">
<c>Adjacency SID</c> <xref target="RFC8665" format="default"/></td>
</tr>
<c>Adj-SID sub-TLV (2)</c> <tr>
<td align="left">Adjacency SID</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">Adj-SID Sub-TLV (5)</td>
<td align="left">
<c>LAN Adjacency SID</c> <xref target="RFC8666" format="default"/></td>
</tr>
<c>LAN Adj-SID sub-TLV (3)</c> <tr>
<td align="left">LAN Adjacency SID</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">LAN Adj-SID Sub-TLV (6)</td>
<td align="left">
<c>Prefix SID</c> <xref target="RFC8666" format="default"/></td>
</tr>
<c>Prefix SID sub-TLV (2)</c> <tr>
<td align="left">Prefix-SID</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">Prefix-SID Sub-TLV (4)</td>
<td align="left">
<c>Range</c> <xref target="RFC8666" format="default"/></td>
</tr>
<c>OSPF Extended Prefix Range TLV (2)</c> <tr>
<td align="left">Range</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">OSPFv3 Extended Prefix Range TLV (9)</td>
<td align="left">
<c>SID/Label</c> <xref target="RFC8666" format="default"/></td>
</tr>
<c>SID/Label sub-TLV (1)</c> <tr>
<td align="left">SID/Label</td>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <td align="left">SID/Label Sub-TLV (7)</td>
<td align="left">
<c>Prefix Attribute Flags</c> <xref target="RFC8666" format="default"/></td>
</tr>
<c>Flags of OSPFv2 Extended Prefix TLV (1)</c> <tr>
<td align="left">Prefix Attribute Flags</td>
<c><xref target="RFC7684"/></c> <td align="left">Prefix Option Fields of Prefix TLV types 3,5,6</t
d>
<c>Source Router-ID</c> <td align="left">
<xref target="RFC8362" format="default"/></td>
<c>Prefix Source Router-ID sub-TLV (TBD)</c> </tr>
<tr>
<c><xref target="I-D.ietf-lsr-ospf-prefix-originator"/></c> <td align="left">Source OSPF Router Identifier</td>
</texttable> <td align="left">Prefix Source Router Address Sub-TLV (28)</td>
<td align="left">
<texttable anchor="OSPFV3TVLTAB" <xref target="RFC9084" format="default"/></td>
title="OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs"> </tr>
<ttcol align="left">Description</ttcol> <tr>
<td align="left">Source OSPF Router-ID</td>
<ttcol align="left">OSPFv3 TLV/sub-TLV</ttcol> <td align="left">Prefix Source OSPF Router-ID Sub-TLV (27)</td>
<td align="left">
<ttcol align="left">Reference</ttcol> <xref target="RFC9084" format="default"/></td>
</tr>
<c>SR Capabilities</c> </tbody>
</table>
<c>SID/Label Range TLV (9)</c>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c>
<c>SR Algorithm</c>
<c>SR-Algorithm TLV (8)</c>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c>
<c>SR Local Block</c>
<c>SR Local Block TLV (14)</c>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c>
<c>SRMS Preference</c>
<c>SRMS Preference TLV (15)</c>
<c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c>
<c>Adjacency SID</c>
<c>Adj-SID sub-TLV (5)</c>
<c><xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></c>
<c>LAN Adjacency SID</c>
<c>LAN Adj-SID sub-TLV (6)</c>
<c><xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></c>
<c>Prefix SID</c>
<c>Prefix SID sub-TLV (4)</c>
<c><xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></c>
<c>Range</c>
<c>OSPFv3 Extended Prefix Range TLV (9)</c>
<c><xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></c>
<c>SID/Label</c>
<c>SID/Label sub-TLV (7)</c>
<c><xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></c>
<c>Prefix Attribute Flags</c>
<c>Prefix Option Fields of Prefix TLV types 3,5,6</c>
<c><xref target="RFC8362"/></c>
<c>Source Router-ID</c>
<c>Prefix Source Router-ID sub-TLV (TBD)</c>
<c><xref target="I-D.ietf-lsr-ospf-prefix-originator"/></c>
</texttable>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>Early allocation of codepoints has been done by IANA for this <t>IANA has registered the following code points in the "BGP-LS Node
document from the registry "BGP-LS Node Descriptor, Link Descriptor, Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
Prefix Descriptor, and Attribute TLVs" under the "BGP-LS Parameters" registry under the "Border Gateway Protocol - Link State (BGP-LS)
registry based on <xref target="BGPLSCODEPOINTS"/>. The column "IS-IS Parameter" registry based on <xref
target="BGPLSCODEPOINTS" format="default"/>. The column "IS-IS
TLV/Sub-TLV" defined in the registry does not require any value and TLV/Sub-TLV" defined in the registry does not require any value and
should be left empty.</t> should be left empty.</t>
<section anchor="TLVSUMMARY" numbered="true" toc="default">
<section anchor="TLVSUMMARY" title="TLV/Sub-TLV Code Points Summary"> <name>TLV/Sub-TLV Code Points Summary</name>
<t>This section contains the global table of all TLVs/sub-TLVs defined <t>This section contains the global table of all TLVs/sub-TLVs defined
in this document.</t> in this document.</t>
<table anchor="BGPLSCODEPOINTS" align="center">
<texttable anchor="BGPLSCODEPOINTS" <name>Summary of TLV/Sub-TLV Code Points</name>
title="Summary Table of TLV/Sub-TLV Codepoints"> <thead>
<ttcol align="center">TLV Code Point</ttcol> <tr>
<th align="center">TLV Code Point</th>
<ttcol align="left">Description</ttcol> <th align="left">Description</th>
<th align="left">Reference</th>
<ttcol align="right">Reference</ttcol> </tr>
</thead>
<c>1034</c> <tbody>
<tr>
<c>SR Capabilities</c> <td align="center">1034</td>
<td align="left">SR Capabilities</td>
<c><xref target="SRCAPTLV"/></c> <td align="right">
<xref target="SRCAPTLV" format="default"/></td>
<c>1035</c> </tr>
<tr>
<c>SR Algorithm</c> <td align="center">1035</td>
<td align="left">SR Algorithm</td>
<c><xref target="SRALGOTLV"/></c> <td align="right">
<xref target="SRALGOTLV" format="default"/></td>
<c>1036</c> </tr>
<tr>
<c>SR Local Block</c> <td align="center">1036</td>
<td align="left">SR Local Block</td>
<c><xref target="SRLB"/></c> <td align="right">
<xref target="SRLB" format="default"/></td>
<c>1037</c> </tr>
<tr>
<c>SRMS Preference</c> <td align="center">1037</td>
<td align="left">SRMS Preference</td>
<c><xref target="SRMSPREF"/></c> <td align="right">
<xref target="SRMSPREF" format="default"/></td>
<c>1099</c> </tr>
<tr>
<c>Adjacency SID</c> <td align="center">1099</td>
<td align="left">Adjacency SID</td>
<c><xref target="ADJSIDTLV"/></c> <td align="right">
<xref target="ADJSIDTLV" format="default"/></td>
<c>1100</c> </tr>
<tr>
<c>LAN Adjacency SID</c> <td align="center">1100</td>
<td align="left">LAN Adjacency SID</td>
<c><xref target="LANADJSIDTLV"/></c> <td align="right">
<xref target="LANADJSIDTLV" format="default"/></td>
<c>1158</c> </tr>
<tr>
<c>Prefix SID</c> <td align="center">1158</td>
<td align="left">Prefix-SID</td>
<c><xref target="PREFIXSIDTLV"/></c> <td align="right">
<xref target="PREFIXSIDTLV" format="default"/></td>
<c>1159</c> </tr>
<tr>
<c>Range</c> <td align="center">1159</td>
<td align="left">Range</td>
<c><xref target="RANGETLV"/></c> <td align="right">
<xref target="RANGETLV" format="default"/></td>
<c>1161</c> </tr>
<tr>
<c>SID/Label</c> <td align="center">1161</td>
<td align="left">SID/Label</td>
<c><xref target="SIDLABELTLV"/></c> <td align="right">
<xref target="SIDLABELTLV" format="default"/></td>
<c>1170</c> </tr>
<tr>
<c>Prefix Attribute Flags</c> <td align="center">1170</td>
<td align="left">Prefix Attribute Flags</td>
<c><xref target="PREFIXATTRFLAGTLV"/></c> <td align="right">
<xref target="PREFIXATTRFLAGTLV" format="default"/></td>
<c>1171</c> </tr>
<tr>
<c>Source Router-ID</c> <td align="center">1171</td>
<td align="left">Source Router Identifier</td>
<c><xref target="SOURCEIDTLV"/></c> <td align="right">
<xref target="SOURCEIDTLV" format="default"/></td>
<c>1172</c> </tr>
<tr>
<c>L2 Bundle Member Attributes</c> <td align="center">1172</td>
<td align="left">L2 Bundle Member Attributes</td>
<c><xref target="L2BUNDLETLV"/></c> <td align="right">
</texttable> <xref target="L2BUNDLETLV" format="default"/></td>
</tr>
<tr>
<td align="center">1174</td>
<td align="left">Source OSPF Router-ID</td>
<td align="right">
<xref target="SOURCEOSPFRIDTLV" format="default"/></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 the Manageability Considerations section of <xref tar
target="RFC7752"/>. Specifically, the malformed attribute tests for get="RFC7752" format="default"/>. Specifically, the malformed attribute tests fo
syntactic checks in the Fault Management section of <xref r
target="RFC7752"/> now encompass the new BGP-LS Attribute TLVs defined syntactic checks in the Fault Management section of <xref target="RFC7752"
format="default"/> now encompass the new BGP-LS Attribute TLVs defined
in this document. The semantic or content checking for the TLVs in this document. The semantic or content checking for the TLVs
specified in this document and their association with the BGP-LS NLRI specified 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 types or their BGP-LS Attribute is left to the consumer of the BGP-LS
information (e.g. an application or a controller) and not the BGP information (e.g., an application or a controller) and not the BGP
protocol.</t> protocol.</t>
<t>A consumer of the BGP-LS information retrieves this information over <t>A consumer of the BGP-LS information retrieves this information over
a BGP-LS session (refer Section 1 and 2 of <xref target="RFC7752"/>). a BGP-LS session (refer to Sections <xref target="RFC7752" section="1" sec tionFormat="bare"/> and <xref target="RFC7752" section="2" sectionFormat="bare"/ > of <xref target="RFC7752"/>).
The handling of semantic or content errors by the consumer would be The handling of semantic or content errors by the consumer would be
dictated by the nature of its application usage and hence is beyond the dictated by the nature of its application usage and hence is beyond the
scope of this document.</t> scope of this document.</t>
<t>This document only introduces new Attribute TLVs and any syntactic <t>This document only introduces new Attribute TLVs, and any syntactic
error in them would result in only that specific attribute being error in them would result in the BGP-LS Attribute being
discarded with an error log. The SR information introduced in BGP-LS by discarded with an error log.
this specification, may be used by BGP-LS consumer applications like a The SR information introduced in BGP-LS by
SR path computation engine (PCE) to learn the SR capabilities of the this specification may be used by BGP-LS consumer applications like an
SR Path Computation Engine (PCE) to learn the SR capabilities of the
nodes in the topology and the mapping of SR segments to those nodes. nodes in the topology and the mapping of SR segments to those nodes.
This can enable the SR PCE to perform path computations based on SR for This can enable the SR PCE to perform path computations based on SR for
traffic engineering use-cases and to steer traffic on paths different traffic engineering use cases and to steer traffic on paths different
from the underlying IGP based distributed best path computation. Errors from the underlying IGP-based distributed best-path computation. Errors
in the encoding or decoding of the SR information may result in the in the encoding or decoding of the SR information may result in the
unavailability of such information to the SR PCE or incorrect unavailability of such information to the SR PCE or incorrect
information being made available to it. This may result in the SR PCE information being made available to it. This may result in the SR PCE
not being able to perform the desired SR based optimization not being able to perform the desired SR-based optimization
functionality or to perform it in an unexpected or inconsistent manner. functionality or to perform it in an unexpected or inconsistent manner.
The handling of such errors by applications like SR PCE may be The handling of such errors by applications like SR PCE may be
implementation specific and out of scope of this document.</t> implementation specific and out of scope of this document.</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 SR features are covered by <xref aspects of the
target="I-D.ietf-spring-sr-yang"/>, <xref underlying SR features are covered by <xref target="RFC9020" format="defau
target="I-D.ietf-isis-sr-yang"/> and <xref lt"/>, <xref target="I-D.ietf-isis-sr-yang" format="default"/>, and <xref target
target="I-D.ietf-ospf-sr-yang"/>.</t> ="I-D.ietf-ospf-sr-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="RF
target="RFC7752"/>. The advertisement of the SR link attribute C7752" format="default"/>. The advertisement of the SR link attribute
information defined in this document presents similar risk as associated information defined in this document presents similar risk as associated
with the existing set of link attribute information as described in with the existing set of link attribute information as described in
<xref target="RFC7752"/>. The Security Considerations section of <xref <xref target="RFC7752" format="default"/>. The Security Considerations sec
target="RFC7752"/> also applies to these extensions. The procedures and tion of <xref target="RFC7752" format="default"/> also applies to these extensio
ns. The procedures and
new TLVs defined in this document, by themselves, do not affect the new TLVs defined in this document, by themselves, do not affect the
BGP-LS security model discussed in <xref target="RFC7752"/>.</t> BGP-LS security model discussed in <xref target="RFC7752" format="default" />.</t>
<t>The TLVs introduced in this document are used to propagate IGP <t>The TLVs introduced in this document are used to propagate IGP-defined
defined information (<xref information (see <xref target="RFC8665" format="default"/>, <xref target="
target="I-D.ietf-isis-segment-routing-extensions"/>, <xref RFC8666" format="default"/>, and <xref target="RFC8667" format="default"/>). The
target="I-D.ietf-ospf-segment-routing-extensions"/> and <xref se TLVs
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>). These TLVs represent the SR information associated with the IGP node, link, and
represent the SR information associated with the IGP node, link and
prefix. The IGP instances originating these TLVs are assumed to support prefix. The IGP instances originating these TLVs are assumed to support
all the required security and authentication mechanisms (as described in all the required security and authentication mechanisms (as described in
<xref target="I-D.ietf-isis-segment-routing-extensions"/>, <xref <xref target="RFC8665" format="default"/>, <xref target="RFC8666" format="
target="I-D.ietf-ospf-segment-routing-extensions"/> and <xref default"/>, and <xref target="RFC8667" format="default"/>) in order to
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>) in order to
prevent any security issue when propagating the TLVs into BGP-LS.</t> prevent any security issue when propagating the TLVs into BGP-LS.</t>
<t>BGP-LS SR extensions enable traffic engineering use-cases within the <t>BGP-LS SR extensions enable traffic engineering use cases within the
Segment Routing domain. SR operates within a trusted domain <xref SR domain. SR operates within a trusted domain <xref target="RFC8402" form
target="RFC8402"/> and its security considerations also apply to BGP-LS at="default"/>, 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/domains entirely within this trusted SR domain (e.g., between multiple ASes/domain s
within a single provider network). Therefore, precaution is necessary to within a single provider network). Therefore, precaution is necessary to
ensure that the link-state information (including SR information) ensure that the link-state information (including SR information)
advertised via BGP-LS sessions is limited to consumers in a secure advertised via BGP-LS sessions is limited to consumers in a secure
manner within this trusted SR domain. BGP peering sessions for manner within this trusted SR domain. BGP peering sessions for
address-families other than Link-State may be setup 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 recommended
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 anchor="Contributors" title="Contributors">
<t>The following people have substantially contributed to the editing of
this document:<figure>
<artwork><![CDATA[Peter Psenak
Cisco Systems
Email: ppsenak@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Les Ginsberg
Cisco Systems
Email: ginsberg@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Acee Lindem
Cisco Systems
Email: acee@cisco.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Saikat Ray
Individual
Email: raysaikat@gmail.com]]></artwork>
</figure><figure>
<artwork><![CDATA[Jeff Tantsura
Apstra Inc.
Email: jefftant.ietf@gmail.com]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Jeffrey Haas, Aijun Wang, Robert
Raszuk and Susan Hares for their review of this document and their
comments. The authors would also like to thank Alvaro Retana for his
extensive review and comments which helped correct issues and improve
the document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817 <displayreference target="I-D.ietf-isis-sr-yang" to="ISIS-SR-YANG"/>
4.xml"?> <displayreference target="I-D.ietf-ospf-sr-yang" to="OSPF-SR-YANG"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.420 <references>
2.xml"?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4202.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7752.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7794.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7684.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5120.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.5308.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5340.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8362.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8402.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8571.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.775 <!-- [I-D.ietf-isis-segment-routing-extensions] Published as RFC 8667 -->
2.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8667.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.779 <!-- [I-D.ietf-ospf-segment-routing-extensions] Published as RFC 8665 -->
4.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8665.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.768 <!-- [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Published as RFC 8666 -->
4.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8666.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.534 <!-- [I-D.ietf-isis-l2bundles] Published as RFC 8668 -->
0.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8668.xml"/>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.836 <!-- [I-D.ietf-lsr-ospf-prefix-originator] IESG state I-D Exists; companion docu
2.xml"?> ment RFC 9084 -->
<reference anchor='RFC9084' target='https://www.rfc-editor.org/info/rfc9084'>
<front>
<title>OSPF Prefix Originator Extensions</title>
<author initials='A' surname='Wang' fullname='Aijun Wang'>
<organization />
</author>
<author initials='A' surname='Lindem' fullname='Acee Lindem'>
<organization />
</author>
<author initials='J' surname='Dong' fullname='Jie Dong'>
<organization />
</author>
<author initials='P' surname='Psenak' fullname='Peter Psenak'>
<organization />
</author>
<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role="edit
or">
<organization />
</author>
<date month='August' year='2021' />
</front>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.840 <seriesInfo name="RFC" value="9084"/>
2.xml"?> <seriesInfo name="DOI" value="10.17487/RFC9084"/>
</reference>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.857 </references>
1.xml"?> <references>
<name>Informative References</name>
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions.xml"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.5706.xml"/>
<?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions.xml"?> <!-- [I-D.ietf-spring-segment-routing-ldp-interop] Published as RFC 8661
-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8661.xml"/>
<?rfc include="reference.I-D.ietf-ospf-ospfv3-segment-routing-extensions.x <!-- [I-D.ietf-isis-sr-yang] IESG state I-D Exists-->
ml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-isis-sr-yang-10.xml"/>
<?rfc include="reference.I-D.ietf-isis-l2bundles.xml"?> <!-- [I-D.ietf-ospf-sr-yang] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-ospf-sr-yang.xml"/>
<?rfc include="reference.I-D.ietf-lsr-ospf-prefix-originator.xml"?> <!-- formerly draft-ietf-spring-sr-yang-30; now RFC 9020 -->
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9020.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section anchor="Acknowledgements" numbered="false" toc="default">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.570 <name>Acknowledgements</name>
6.xml"?> <t>The authors would like to thank <contact fullname="Jeffrey
Haas"/>, <contact fullname="Aijun Wang"/>, <contact
fullname="Robert Raszuk"/>, and <contact fullname="Susan Hares"/>
for their review of this document and their comments. The
authors would also like to thank Alvaro Retana for his extensive
review and comments, which helped correct issues and improve the
document.</t>
</section>
<?rfc include="reference.I-D.ietf-spring-segment-routing-ldp-interop.xml" <section anchor="Contributors" numbered="false" toc="default">
?> <name>Contributors</name>
<t>The following people have substantially contributed to the editing of
this document:</t>
<?rfc include="reference.I-D.ietf-spring-sr-yang.xml"?> <contact fullname="Peter Psenak">
<organization>Cisco Systems</organization>
<address>
<?rfc include="reference.I-D.ietf-isis-sr-yang.xml"?> <email> ppsenak@cisco.com</email>
</address>
</contact>
<contact fullname="Les Ginsberg">
<organization>Cisco Systems</organization>
<address>
<email> ginsberg@cisco.com</email>
</address>
</contact>
<contact fullname="Acee Lindem">
<organization>Cisco Systems</organization>
<address>
<email>acee@cisco.com</email>
</address>
</contact>
<contact fullname="Saikat Ray">
<organization>Individual</organization>
<address>
<email>raysaikat@gmail.com</email>
</address>
</contact>
<contact fullname="Jeff Tantsura">
<organization>Apstra Inc.</organization>
<address>
<email>jefftant.ietf@gmail.com</email>
</address>
</contact>
</section>
<?rfc include="reference.I-D.ietf-ospf-sr-yang.xml"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 265 change blocks. 
1258 lines changed or deleted 1436 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/