<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"docName="draft-ietf-idr-bgp-ls-segment-routing-ext-16" ipr="trust200902">number="9085" docName="draft-ietf-idr-bgp-ls-segment-routing-ext-18" ipr="trust200902" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <titleabbrev="BGP LS extensionsabbrev="BGP-LS Extensions for SegmentRouting">BGP Link-State extensionsRouting">Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title> <seriesInfo name="RFC" value="9085"/> <author fullname="Stefano Previdi" initials="S." surname="Previdi"> <organization>Huawei Technologies</organization> <address> <postal><street/><city>Rome</city><code/><country>Italy</country> </postal> <email>stefano@previdi.net</email> </address> </author> <author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Talaulikar"> <organization>Cisco Systems, Inc.</organization> <address> <postal><street/> <city/> <code/><country>India</country> </postal> <email>ketant@cisco.com</email> </address> </author> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <organization>Cisco Systems, Inc.</organization> <address> <postal><street/><city>Brussels</city><code/><country>Belgium</country> </postal> <email>cfilsfil@cisco.com</email> </address> </author> <author fullname="Hannes Gredler" initials="H." surname="Gredler"> <organization>RtBrick Inc.</organization> <address><postal> <street/> <city/> <region/> <code/> <country/> </postal><postal/> <email>hannes@rtbrick.com</email> </address> </author> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <organization>Huawei Technologies</organization> <address> <postal> <street>Huawei Building, No. 156 Beiqing Rd.</street> <city>Beijing</city> <code>100095</code> <country>China</country> </postal> <email>mach.chen@huawei.com</email> </address> </author> <dateyear=""/>month="August" year="2021"/> <area>Routing</area> <workgroup>Inter-Domain Routing</workgroup> <keyword>BGP-LS</keyword> <keyword>Segment Routing</keyword> <keyword>SID</keyword> <keyword>MPLS</keyword> <keyword>Label advertisement</keyword> <keyword>IS-IS</keyword> <keyword>OSPF</keyword> <keyword>OSPFv3</keyword> <abstract> <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topologicalsub-paths,subpaths, called "segments". These segments are advertised by routingprotocols e.g.protocols, e.g., by thelink statelink-state routing protocols (IS-IS,OSPFv2OSPFv2, and OSPFv3) within IGP topologies.</t> <t>This document defines extensions to theBGP Link-state address-familyBorder Gateway Protocol - Link State (BGP-LS) address family in order to carrysegment routingSR information via BGP.</t> </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> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Segment Routing (SR) allows for a flexible definition of end-to-end paths by combiningsub-pathssubpaths called "segments". A segment can represent any instruction: topological orservice-based.service based. A segment can have a local semantic to an SR node or global semantic within a domain. Within IGP topologies, an SR path is encoded as a sequence of topologicalsub-paths,subpaths, called "IGP segments". These segments are advertised by the link-state routing protocols (IS-IS,OSPFv2OSPFv2, and OSPFv3).</t> <t><xreftarget="RFC8402"/>target="RFC8402" format="default"/> defines theLink-Statelink-state IGP segments- Prefix, Node, Anycast-- prefix, node, anycast, andAdjacencyadjacency segments. Prefix segments, by 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 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 cases, is a one-hop path. Node and anycast segments are variations of the prefix segment with their specific characteristics.</t> <t>WhenSegment RoutingSR is enabled in an IGP domain, segments are advertised in the form of Segment Identifiers (SIDs). The IGP link-state routing protocols have been extended to advertise SIDs and other SR-related information. IGP extensions are described for: <xreftarget="I-D.ietf-isis-segment-routing-extensions">IS-IS</xref>,target="RFC8667" format="default">IS-IS</xref>, <xreftarget="I-D.ietf-ospf-segment-routing-extensions">OSPFv2</xref>target="RFC8665" format="default">OSPFv2</xref>, and <xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions">OSPFv3</xref>.target="RFC8666" format="default">OSPFv3</xref>. Using these extensions,Segment RoutingSR can be enabled within an IGP domain.</t><t>Segment Routing (SR)<t>SR allows advertisement of single or multi-hop paths. The flooding scope for the IGP extensions forSegment routingSR is IGP area-wide. Consequently, the contents of aLink StateLink-State Database (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGParea andarea; therefore, by using the IGPalonealone, it is not enough to construct segments across multiple IGPAreaarea orASAutonomous System (AS) boundaries.</t> <t>In order to address the need for applications that require topological visibility across IGP areas, or even acrossAutonomous Systems (AS),ASes, the BGP-LSaddress-family/sub-address-familyaddress family / subaddress family have been defined to allow BGP to carryLink-Statelink-state information. The BGP Network Layer Reachability Information (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called theBGP-LS attribute"BGP-LS Attribute" are defined in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. The identifying key of eachLink-Statelink-state object, namely a node, link, or prefix, is encoded in theNLRINLRI, and the properties of the object are encoded in the BGP-LSattribute.</t> <t><figure anchor="MECHANISM-CONSUMER-PRODUCER" title="Link State info collection"> <artwork><![CDATA[Attribute.</t> <figure anchor="MECHANISM-CONSUMER-PRODUCER"> <name>Link-State Information Collection</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------------+ | Consumer | +------------+ ^ | v +-------------------+ | BGP Speaker | +-----------+ |(Route-Reflector)(Route Reflector) | | Consumer | +-------------------+ +-----------+ ^ ^ ^ ^ | | | | +---------------+ | +-------------------+ | | | | | v v v v +-----------+ +-----------+ +-----------+ | BGP | | BGP | | BGP | | Speaker | | Speaker | . . . | Speaker | +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | IGP IGP IGP ]]></artwork></figure></t></figure> <t><xreftarget="MECHANISM-CONSUMER-PRODUCER"/>target="MECHANISM-CONSUMER-PRODUCER" format="default"/> denotes a typical deployment scenario. In each IGP area, one or more nodes are configured with BGP-LS. These BGP speakers form anIBGPInternal BGP (IBGP) mesh by connecting to one or moreroute-reflectors.route reflectors. This way, all BGP speakers (specifically theroute-reflectors)route reflectors) obtainLink-Statelink-state information from all IGP areas (and from other ASes fromEBGPExternal BGP (EBGP) peers). An external component connects to theroute-reflectorroute reflector to obtain this information (perhaps moderated by a policy regarding what information is or isn't advertised to the external component) as described in <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</t> <t>This document describes extensions to BGP-LS to advertise the SR information. An external component (e.g., a controller) can collect SR information from across an SR domain (as described in <xreftarget="RFC8402"/>)target="RFC8402" format="default"/>) and construct the end-to-end path (with its associated SIDs) thatneedneeds to be applied to an incoming packet to achieve the desired end-to-end forwarding. SR operates within a trusted domain consisting of a single AS or multiple ASes managed by the same administrativeentity e.g.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 described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.</t> </section> </section> <sectiontitle="BGP-LSnumbered="true" toc="default"> <name>BGP-LS Extensions for SegmentRouting">Routing</name> <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. Sections <xreftarget="ISISTLV"/>target="ISISTLV" format="counter"/> and <xreftarget="OSPFTLV"/> liststarget="OSPFTLV" format="counter"/> list the equivalent TLVs and sub-TLVs in the IS-IS,OSPFv2OSPFv2, and OSPFv3 protocols.</t> <t><xreftarget="RFC7752">BGP-LS</xref>target="RFC7752" format="default">BGP-LS</xref> defines the BGP-LS NLRI that can be a Node NLRI, a LinkNLRINLRI, or a PrefixNLRI. <xref target="RFC7752">BGP-LS</xref>NLRI, and it defines the TLVs that map link-state information to BGP-LS NLRI within the BGP-LS Attribute. This document 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 NLRIs.</t> <section anchor="NODE"title="Node Attributes TLVs">numbered="true" toc="default"> <name>Node Attribute TLVs</name> <t>The following Node Attribute TLVs are defined:</t><texttable<table anchor="node-attribute_tlv"title="Nodealign="center"> <name>Node AttributeTLVs"> <ttcol align="center">Type</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Section</ttcol> <c>1161</c> <c>SID/Label</c> <c><xref target="SIDLABELTLV"/></c> <c>1034</c> <c>SR Capabilities</c> <c><xref target="SRCAPTLV"/></c> <c>1035</c> <c>SR Algorithm</c> <c><xref target="SRALGOTLV"/></c> <c>1036</c> <c>SRTLVs</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">1161</td> <td align="left">SID/Label</td> <td align="right"> <xref target="SIDLABELTLV" format="default"/></td> </tr> <tr> <td align="center">1034</td> <td align="left">SR Capabilities</td> <td align="right"> <xref target="SRCAPTLV" format="default"/></td> </tr> <tr> <td align="center">1035</td> <td align="left">SR Algorithm</td> <td align="right"> <xref target="SRALGOTLV" format="default"/></td> </tr> <tr> <td align="center">1036</td> <td align="left">SR LocalBlock</c> <c><xref target="SRLB"/></c> <c>1037</c> <c>SRMS Preference</c> <c><xref target="SRMSPREF"/></c> </texttable>Block</td> <td align="right"> <xref target="SRLB" format="default"/></td> </tr> <tr> <td align="center">1037</td> <td align="left">SRMS Preference</td> <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 with the Node NLRIdescribingthat describes the IGP node that is originating the corresponding IGP TLV/sub-TLV described below.</t> <section anchor="SIDLABELTLV"title="SID/Label TLV">numbered="true" toc="default"> <name>SID/Label TLV</name> <t>The SID/Label TLV is used as a sub-TLV by the SR Capabilities (<xreftarget="SRCAPTLV"/>)target="SRCAPTLV" format="default"/>) and Segment Routing Local Block (SRLB) (<xreftarget="SRLB"/>)target="SRLB" format="default"/>) TLVs. This information is derived from theprotocol specificprotocol-specific advertisements.<list style="symbols"> <t>IS-IS,</t> <ul spacing="normal"> <li>IS-IS, as defined by the SID/Labelsub-TLVSub-TLV insection 2.3 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2/OSPFv3,target="RFC8667" section="2.3" sectionFormat="of"/>.</li> <li>OSPFv2/OSPFv3, as defined by the SID/Labelsub-TLVSub-TLV insection 2.1 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>target="RFC8665" section="2.1" sectionFormat="of"/> andsection 3.1 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t>target="RFC8666" section="3.1" sectionFormat="of"/>.</li> </ul> <t>The TLV has the following format: </t> <figureanchor="SIDLTLVFIG" title="SID/Labelanchor="SIDLTLVFIG"> <name>SID/Label TLVFormat"> <artwork><![CDATA[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1161</t> <t>Length:</figure> <t>Where:</t> <dl newline="false"> <dt>Type:</dt><dd> 1161</dd> <dt>Length:</dt><dd> Variable. Either 3 or 4 octets depending on whether the value is encoded as a label or as anindex/SID.</t> <t>SID/Label:index/SID.</dd> <dt>SID/Label:</dt><dd> If the length is set to 3, then the 20 rightmost bits represent a label (the total TLV size is7)7), and the 4 leftmost bits are set to 0. If the length is set to 4, then the value represents a32 bit32-bit SID (the total TLV size is8).</t> </list></t>8).</dd> </dl> </section> <section anchor="SRCAPTLV"title="SRnumbered="true" toc="default"> <name>SR CapabilitiesTLV">TLV</name> <t>The SR Capabilities TLV is used in order to advertise the node's SRCapabilitiescapabilities including its Segment Routing Global Base (SRGB) range(s). In the case of IS-IS, the capabilities also include the IPv4 and IPv6 support for the SR-MPLS forwarding plane. This information is derived from theprotocol specificprotocol-specific advertisements.<list style="symbols"> <t>IS-IS,</t> <ul spacing="normal"> <li>IS-IS, as defined by theSR Capabilities sub-TLVSR-Capabilities Sub-TLV insection 3.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2/OSPFv3,target="RFC8667" section="3.1" sectionFormat="of"/>.</li> <li>OSPFv2/OSPFv3, as defined by the SID/Label Range TLV insection 3.2 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.target="RFC8665" section="3.2" sectionFormat="of"/>. OSPFv3 leverages the same TLV as defined forOSPFv2.</t> </list></t>OSPFv2.</li> </ul> <t>The SR Capabilities TLV has the following format: </t> <figureanchor="SRCAPTLVFIG" title="SRanchor="SRCAPTLVFIG"> <name>SR Capabilities TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Labelsub-TLVSub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Labelsub-TLVSub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1034</t> <t>Length: Variable. Minimum</figure> <t>Where:</t> <dl spacing="normal"> <dt>Type:</dt> <dd>1034</dd> <dt>Length:</dt><dd>Variable. The minimum length is12.</t> <t>Flags:12 octets.</dd> <dt>Flags:</dt><dd> 1 octet of flags as defined insection 3.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" section="3.1" sectionFormat="of"/> for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 andMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Reserved:receipt.</dd> <dt>Reserved:</dt><dd> 1 octet thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Onereceipt.</dd> <dt>One or more entries, each of which have the followingformat:<list style="hanging"> <t>Range Size:format:</dt> <dd> <t><br/></t> <dl> <dt>Range Size:</dt><dd> 3octetoctets with a non-zero value indicating the number of labels in therange.</t> <t>SID/Label TLV (asrange.</dd> <dt>SID/Label TLV:</dt><dd>(as defined in <xreftarget="SIDLABELTLV"/>)target="SIDLABELTLV" format="default"/>) used assub-TLVa sub-TLV, which encodes the first label in the range. Since the SID/Label TLV is used to indicate the first label of the SRGB range, only label encoding is valid under the SR CapabilitiesTLV.</t> </list></t> </list></t>TLV.</dd> </dl> </dd> </dl> </section> <section anchor="SRALGOTLV"title="SR Algorithm TLV">numbered="true" toc="default"> <name>SR-Algorithm TLV</name> <t>TheSR AlgorithmSR-Algorithm TLV is used in order to advertise the SRAlgorithmsalgorithms supported by the node. This information is derived from theprotocol specificprotocol-specific advertisements.<list style="symbols"> <t>IS-IS,</t> <ul spacing="normal"> <li>IS-IS, as defined by the SR-Algorithmsub-TLVSub-TLV insection 3.2 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2/OSPFv3,target="RFC8667" section="3.2" sectionFormat="of"/>.</li> <li>OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV insection 3.1 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.target="RFC8665" section="3.1" sectionFormat="of"/>. OSPFv3 leverages the same TLV as defined forOSPFv2.</t> </list>The SR AlgorithmOSPFv2.</li> </ul> <t>The SR-Algorithm TLV has the following format: </t> <figureanchor="SRALGTLVFIG" title="SR Algorithmanchor="SRALGTLVFIG"> <name>SR-Algorithm TLVFormat"> <artwork><![CDATA[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1035</t> <t>Length:</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd> 1035</dd> <dt>Length:</dt><dd> Variable.MinimumThe minimum length is 1 octet and the maximum can be256.</t> <t>Algorithm:256.</dd> <dt>Algorithm:</dt><dd> One or more fields of 1 octet eachidentifyingthat identifies thealgorithm.</t> </list></t>algorithm.</dd> </dl> </section> <section anchor="SRLB"title="SRnumbered="true" toc="default"> <name>SR Local BlockTLV">TLV</name> <t>TheSR Local Block (SRLB)SRLB TLV contains the range(s) of labels the node has reserved for local SIDs. Local SIDs are used, e.g., in IGP (IS-IS, OSPF) forAdjacency-SIDs,Adjacency SIDs and may also be allocated by components other than IGP protocols. As an example, an application or a controller may instruct a node to allocate a specific local SID. Therefore, in order for such applications or controllers to know the range of local SIDs available,it is required thatthe nodeadvertisesis required to advertise its SRLB.</t> <t>This information is derived from theprotocol specificprotocol-specific advertisements.<list style="symbols"> <t>IS-IS,</t> <ul spacing="normal"> <li>IS-IS, as defined by theSR Local Block sub-TLVSRLB Sub-TLV insection 3.3 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2/OSPFv3,target="RFC8667" section="3.3" sectionFormat="of"/>.</li> <li>OSPFv2/OSPFv3, as defined by the SR Local Block TLV insection 3.3. of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.target="RFC8665" section="3.3" sectionFormat="of"/>. OSPFv3 leverages the same TLV as defined forOSPFv2.</t> </list></t>OSPFv2.</li> </ul> <t>The SRLB TLV has the following format: </t> <figureanchor="SRLBTLVFIG" title="SRLBanchor="SRLBTLVFIG"> <name>SRLB TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Labelsub-TLVSub-TLV 1 // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Range Size N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Labelsub-TLVSub-TLV N // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1036</t> <t>Length:</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd> 1036</dd> <dt>Length:</dt><dd> Variable.MinimumThe minimum length is12.</t> <t>Flags:12 octets.</dd> <dt>Flags:</dt><dd> 1 octet of flags. The flags are as defined insection 3.3 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>target="RFC8667" section="3.3" sectionFormat="of"/> for IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 andMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Reserved:receipt.</dd> <dt>Reserved:</dt><dd> 1 octet thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Onereceipt.</dd> <dt>One or more entries corresponding to a sub-range(s), each of which have the followingformat:<list style="hanging"> <t>Range Size: 3 octetformat:</dt> <dd> <t><br/></t> <dl> <dt>Range Size:</dt><dd> 3-octet value indicating the number of labels in therange.</t> <t>SID/Label TLV (asrange.</dd> <dt>SID/Label TLV:</dt><dd>(as defined in <xreftarget="SIDLABELTLV"/>)target="SIDLABELTLV" format="default"/>) used assub-TLVa sub-TLV, which encodes the first label in the sub-range. Since the SID/Label TLV is used to indicate the first label of the SRLB sub-range, only label encoding is valid under the SR Local BlockTLV.</t> </list></t> </list></t>TLV.</dd> </dl> </dd> </dl> </section> <section anchor="SRMSPREF"title="SRMSnumbered="true" toc="default"> <name>SRMS PreferenceTLV">TLV</name> <t>The Segment Routing Mapping Server (SRMS) Preference TLV is used in order to associate a preference with SRMS advertisements from a particular source. <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>target="RFC8661" format="default"/> specifies the SRMS functionality along with the SRMS preference of the node advertising the SRMS Prefix-to-SIDMappingmapping ranges.</t> <t>This information is derived from theprotocol specificprotocol-specific advertisements.<list style="symbols"> <t>IS-IS,</t> <ul spacing="normal"> <li>IS-IS, as defined by the SRMS Preferencesub-TLVSub-TLV insection 3.4 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2/OSPFv3,target="RFC8667" section="3.4" sectionFormat="of"/>.</li> <li>OSPFv2/OSPFv3, as defined by the SRMS Preference TLV insection 3.4 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.target="RFC8665" section="3.4" sectionFormat="of"/>. OSPFv3 leverages the same TLV as defined forOSPFv2.</t> </list></t>OSPFv2.</li> </ul> <t>The SRMS Preference TLV has the following format: </t> <figureanchor="SRMSTLVFIG" title="SRMSanchor="SRMSTLVFIG"> <name>SRMS Preference TLVFormat"> <artwork><![CDATA[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | +-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1037</t> <t>Length: 1.</t> <t>Preference:</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd> 1037</dd> <dt>Length:</dt><dd> 1 octet</dd> <dt>Preference:</dt><dd> 1 octet carrying an unsigned8 bit8-bit SRMSpreference.</t> </list></t>preference.</dd> </dl> </section> </section> <section anchor="LINK"title="Linknumbered="true" toc="default"> <name>Link AttributeTLVs">TLVs</name> <t>The following Link Attribute TLVs arearedefined:</t><texttable<table anchor="link-attribute_tlv"title="Linkalign="center"> <name>Link AttributeTLVs"> <ttcol align="center">Type</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Section</ttcol> <c>1099</c> <c>AdjacencyTLVs</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 SIDTLV</c> <c><xref target="ADJSIDTLV"/></c> <c>1100</c> <c>LANTLV</td> <td align="right"> <xref target="ADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1100</td> <td align="left">LAN Adjacency SIDTLV</c> <c><xref target="LANADJSIDTLV"/></c> <c>1172</c> <c>L2TLV</td> <td align="right"> <xref target="LANADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1172</td> <td align="left">L2 Bundle MemberTLV</c> <c><xref target="L2BUNDLETLV"/></c> </texttable>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 with the Link NLRIdescribingthat describes the link of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below.</t> <section anchor="ADJSIDTLV"title="Adjacencynumbered="true" toc="default"> <name>Adjacency SIDTLV">TLV</name> <t>The Adjacency SID TLV is used in order to advertise information related to an Adjacency SID. This information is derived from the Adj-SIDsub-TLVSub-TLV of IS-IS(section 2.2.1 of <xref target="I-D.ietf-isis-segment-routing-extensions"/>),(<xref target="RFC8667" section="2.2.1" sectionFormat="of"/>), OSPFv2(section 6.1 of <xref target="I-D.ietf-ospf-segment-routing-extensions"/>)(<xref target="RFC8665" section="6.1" sectionFormat="of"/>), and OSPFv3(section 7.1 of <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t>(<xref target="RFC8666" section="7.1" sectionFormat="of"/>).</t> <t>The Adjacency SID TLV has the following format: </t> <figureanchor="ADJSIDTLVFIG" title="Adjacencyanchor="ADJSIDTLVFIG"> <name>Adjacency SID TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1099</t> <t>Length:</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd>1099</dd> <dt>Length:</dt><dd> Variable. Either 7 or 8 octets depending onLabelthe label orIndexindex encoding of theSID</t> <t>Flags. 1 octetSID.</dd> <dt>Flags:</dt><dd><t> 1-octet valuewhichthat should be set as:<list style="symbols"> <t>IS-IS</t> <ul spacing="normal"> <li>IS-IS Adj-SID flagsareas defined insection 2.2.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2target="RFC8667" section="2.2.1" sectionFormat="of"/>.</li> <li>OSPFv2 Adj-SID flagsareas defined insection 6.1 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3target="RFC8665" section="6.1" sectionFormat="of"/>.</li> <li>OSPFv3 Adj-SID flagsareas defined insection 7.1 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t> <t>Weight:target="RFC8666" section="7.1" sectionFormat="of"/>.</li> </ul> </dd> <dt>Weight:</dt><dd> 1 octet carrying the weight used for load-balancing purposes. The use of weight is described insection 3.4 of<xreftarget="RFC8402"/>.</t> <t>Reserved:target="RFC8402" section="3.4" sectionFormat="of"/>.</dd> <dt>Reserved:</dt><dd> 2 octets thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>SID/Index/Label: <list style="symbols"> <t>IS-IS:receipt.</dd> <dt>SID/Index/Label: </dt> <dd><t><br/></t> <dl spacing="normal"> <dt>IS-IS:</dt><dd> Label or index value as defined insection 2.2.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2:target="RFC8667" section="2.2.1" sectionFormat="of"/>.</dd> <dt>OSPFv2:</dt><dd> Label or index value as defined insection 6.1 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3:target="RFC8665" section="6.1" sectionFormat="of"/>.</dd> <dt>OSPFv3:</dt><dd> Label or index value as defined insection 7.1 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t> </list></t>target="RFC8666" section="7.1" sectionFormat="of"/>.</dd> </dl> </dd> </dl> <t>The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS,OSPFv2OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields.</t> </section> <section anchor="LANADJSIDTLV"title="LANnumbered="true" toc="default"> <name>LAN Adjacency SIDTLV">TLV</name> <t>For a LAN, normally a node only announces its adjacency to the IS-ISpseudo-nodepseudonode (or the equivalent OSPF Designated and Backup Designated Routers). The LAN AdjacencySegmentSID TLV allows a node to announce adjacencies to all other nodes attached to the LAN in a single instance of the BGP-LS Link NLRI. Without this TLV, the corresponding BGP-LSlinkLink NLRI would need to be originated for each additional adjacency in order to advertise the SR TLVs for these neighbor adjacencies.</t> <t>This information is derived from the LAN-Adj-SIDsub-TLVSub-TLV of IS-IS(section 2.2.2 of <xref target="I-D.ietf-isis-segment-routing-extensions"/>) and(<xref target="RFC8667" sectionFormat="of" section="2.2.2"/>), the LAN Adj-SIDsub-TLVSub-TLV of OSPFv2(section 6.2 of <xref target="I-D.ietf-ospf-segment-routing-extensions"/>)(<xref target="RFC8665" sectionFormat="of" section="6.2"/>), andOSPFv3 (section 7.2the LAN Adj-SID Sub-TLV of<xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t>OSPFv3 (<xref target="RFC8666" sectionFormat="of" section="7.2"/>).</t> <t>The LAN Adjacency SID TLV has the following format: </t> <figureanchor="LADJSIDTLVFIG" title="LANanchor="LADJSIDTLVFIG"> <name>LAN Adjacency SID TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Neighbor ID / IS-ISSystem-IDSystem ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) // +---------------------------------------------------------------+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1100</t> <t>Length:</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt> <dd>1100</dd> <dt>Length:</dt><dd> Variable. ForIS-ISIS-IS, it would be 13 or 14 octets depending onLabelthe label orIndexindex encoding of the SID. ForOSPFOSPF, it would be 11 or 12 octets depending onLabelthe label orIndexindex encoding of theSID.</t> <t>Flags. 1 octetSID.</dd> <dt>Flags:</dt><dd><t> 1-octet valuewhichthat should be set as:<list style="symbols"> <t>IS-IS</t> <ul spacing="normal"> <li>IS-IS LAN Adj-SID flagsareas defined insection 2.2.2 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2target="RFC8667" section="2.2.2" sectionFormat="of"/>.</li> <li>OSPFv2 LAN Adj-SID flagsareas defined insection 6.2 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3target="RFC8665" section="6.2" sectionFormat="of"/>.</li> <li>OSPFv3 LAN Adj-SID flagsareas defined insection 7.2 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> </list></t> <t>Weight:target="RFC8666" section="7.2" sectionFormat="of"/>.</li> </ul> </dd> <dt>Weight:</dt><dd> 1 octet carrying the weight used for load-balancing purposes. The use of weight is described insection 3.4 of<xreftarget="RFC8402"/>.</t> <t>Reserved:target="RFC8402" section="3.4" sectionFormat="of"/>.</dd> <dt>Reserved:</dt><dd> 2 octets thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Neighbor ID:receipt.</dd> <dt>Neighbor ID:</dt><dd> 6 octets for IS-IS for theSystem-IDSystem ID, and 4 octets for OSPF for the OSPF Router-ID of theneighbor.</t> <t>SID/Index/Label: <list style="symbols"> <t>IS-IS:neighbor.</dd> <dt>SID/Index/Label: </dt> <dd><t><br/></t> <dl spacing="normal"> <dt>IS-IS:</dt><dd> Label or index value as defined insection 2.2.2 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2:target="RFC8667" section="2.2.2" sectionFormat="of"/>.</dd> <dt>OSPFv2:</dt><dd> Label or index value as defined insection 6.2 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3:target="RFC8665" section="6.2" sectionFormat="of"/>.</dd> <dt>OSPFv3:</dt><dd> Label or index value as defined insection 7.2 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t> </list></t>target="RFC8666" section="7.2" sectionFormat="of"/>.</dd> </dl> </dd> </dl> <t>The Neighbor ID,FlagsFlags, and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS,OSPFv2OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI is used to determine the underlying protocol specification for parsing these fields.</t> </section> <section anchor="L2BUNDLETLV"title="L2numbered="true" toc="default"> <name>L2 Bundle MemberAttribute TLV">Attributes TLV</name> <t>The L2 Bundle MemberAttributeAttributes TLV identifies an L2 Bundle Memberlinklink, which in turn is associated with a parent L3 link. The L3 link is described by the Link NLRI defined in <xreftarget="RFC7752"/>target="RFC7752" format="default"/>, and the L2 Bundle MemberAttributeAttributes TLV is associated with the Link NLRI. The TLVMAY<bcp14>MAY</bcp14> include sub-TLVswhichthat describe attributes associated with the bundle member. The identified bundle member represents a unidirectional path from the originating router to the neighbor specified in the parent L3Link.link. Multiple L2 Bundle MemberAttributeAttributes TLVsMAY<bcp14>MAY</bcp14> be associated with a Link NLRI.</t> <t>This information is derived from L2 Bundle Member Attributes TLV of IS-IS(section 2 of <xref target="I-D.ietf-isis-l2bundles"/>).(<xref target="RFC8668" section="2" sectionFormat="of"/>). The equivalent functionality has not been specified as yet for OSPF.</t> <t>The L2 Bundle MemberAttributeAttributes TLV has the following format: </t> <figureanchor="L2BTLVFIG" title="L2anchor="L2BTLVFIG"> <name>L2 Bundle Member Attributes TLVFormat"> <artwork><![CDATA[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2 Bundle Member Descriptor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Linkattribute sub-TLVs(variable)Attribute Sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1172</t> <t>Length: Variable.</t> <t>L2</figure> <t>Where:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd> 1172</dd> <dt>Length:</dt><dd> Variable.</dd> <dt>L2 Bundle MemberDescriptor: 4 octetsDescriptor:</dt><dd> 4-octet field that carries aLink Local Identifierlink-local identifier as defined in <xreftarget="RFC4202"/>.</t> </list></t>target="RFC4202" format="default"/>.</dd> </dl> <t>Link attributes for L2 Bundle MemberLinkslinks are advertised as sub-TLVs of the L2 Bundle MemberAttributeAttributes TLV. The sub-TLVs are identical to existing BGP-LS TLVs as identified in the table below.</t><texttable<table anchor="l2subtlvs"title="BGP-LSalign="center"> <name>BGP-LS Attribute TLVs are also used as sub-TLVs of the L2 Bundle MemberAttribute TLV"> <ttcolAttributes TLV</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcolPoint</th> <th align="left">Description</th> <th align="left">ReferenceDocument</ttcol> <c>1088</c> <c>AdministrativeDocument</th> </tr> </thead> <tbody> <tr> <td align="center">1088</td> <td align="left">Administrative group(color)</c> <c><xref target="RFC7752"/></c> <c>1089</c> <c>Maximum(color)</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1089</td> <td align="left">Maximum linkbandwidth</c> <c><xref target="RFC7752"/></c> <c>1090</c> <c>Max.bandwidth</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1090</td> <td align="left">Max. reservable linkbandwidth</c> <c><xref target="RFC7752"/></c> <c>1091</c> <c>Unreserved bandwidth</c> <c><xref target="RFC7752"/></c> <c>1092</c> <c>TEbandwidth</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1091</td> <td align="left">Unreserved bandwidth</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1092</td> <td align="left">TE defaultmetric</c> <c><xref target="RFC7752"/></c> <c>1093</c> <c>Linkmetric</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1093</td> <td align="left">Link protectiontype</c> <c><xref target="RFC7752"/></c> <c>1099</c> <c>Adjacencytype</td> <td align="left"> <xref target="RFC7752" format="default"/></td> </tr> <tr> <td align="center">1099</td> <td align="left">Adjacency Segment Identifier (Adj-SID)TLV</c> <c><xref target="ADJSIDTLV"/></c> <c>1100</c> <c>LANTLV</td> <td align="left"> <xref target="ADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1100</td> <td align="left">LAN Adjacency Segment Identifier (Adj-SID)TLV</c> <c><xref target="LANADJSIDTLV"/></c> <c>1114</c> <c>UnidirectionalTLV</td> <td align="left"> <xref target="LANADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1114</td> <td align="left">Unidirectional linkdelay</c> <c><xref target="RFC8571"/></c> <c>1115</c> <c>Min/Maxdelay</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1115</td> <td align="left">Min/Max Unidirectional linkdelay</c> <c><xref target="RFC8571"/></c> <c>1116</c> <c>Unidirectionaldelay</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1116</td> <td align="left">Unidirectional DelayVariation</c> <c><xref target="RFC8571"/></c> <c>1117</c> <c>Unidirectional packet loss</c> <c><xref target="RFC8571"/></c> <c>1118</c> <c>UnidirectionalVariation</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1117</td> <td align="left">Unidirectional Link Loss</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1118</td> <td align="left">Unidirectional residualbandwidth</c> <c><xref target="RFC8571"/></c> <c>1119</c> <c>Unidirectionalbandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1119</td> <td align="left">Unidirectional availablebandwidth</c> <c><xref target="RFC8571"/></c> <c>1120</c> <c>Unidirectional bandwidth utilization</c> <c><xref target="RFC8571"/></c> </texttable>bandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> <tr> <td align="center">1120</td> <td align="left">Unidirectional Utilized Bandwidth</td> <td align="left"> <xref target="RFC8571" format="default"/></td> </tr> </tbody> </table> </section> </section> <section anchor="PREFIX"title="Prefixnumbered="true" toc="default"> <name>Prefix AttributeTLVs ">TLVs</name> <t>The following Prefix Attribute TLVs are defined:</t><texttable<table anchor="prefix-attribute_tlv"title="Prefixalign="center"> <name>Prefix AttributeTLVs"> <ttcol align="center">Type</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="left">Section</ttcol> <c>1158</c> <c>Prefix SID</c> <c><xref target="PREFIXSIDTLV"/></c> <c>1159</c> <c>Range</c> <c><xref target="RANGETLV"/></c> <c>1170</c> <c>PrefixTLVs</name> <thead> <tr> <th align="center">Type</th> <th align="left">Description</th> <th align="left">Section</th> </tr> </thead> <tbody> <tr> <td align="center">1158</td> <td align="left">Prefix-SID</td> <td align="left"> <xref target="PREFIXSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1159</td> <td align="left">Range</td> <td align="left"> <xref target="RANGETLV" format="default"/></td> </tr> <tr> <td align="center">1170</td> <td align="left">Prefix AttributeFlags</c> <c><xref target="PREFIXATTRFLAGTLV"/></c> <c>1171</c> <c>Source Router-ID</c> <c><xref target="SOURCEIDTLV"/></c> </texttable>Flags</td> <td align="left"> <xref target="PREFIXATTRFLAGTLV" format="default"/></td> </tr> <tr> <td align="center">1171</td> <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 with the Prefix NLRIdescribingthat describes the prefix of the IGP node that is originating the corresponding IGP TLV/sub-TLV described below.</t> <section anchor="PREFIXSIDTLV"title="Prefix SID TLV">numbered="true" toc="default"> <name>Prefix-SID TLV</name> <t>ThePrefix SIDPrefix-SID TLV is used in order to advertise information related to aPrefix SID.Prefix-SID. This information is derived from the Prefix-SIDsub-TLVSub-TLV of IS-IS(section 2.1 of <xref target="I-D.ietf-isis-segment-routing-extensions"/>) and(<xref target="RFC8667" section="2.1" sectionFormat="of"/>), thePrefix SID sub-TLVPrefix-SID Sub-TLV of OSPFv2(section 5 of <xref target="I-D.ietf-ospf-segment-routing-extensions"/>)(<xref target="RFC8665" section="5" sectionFormat="of"/>), andOSPFv3 (section 6the Prefix-SID Sub-TLV of<xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).</t>OSPFv3 (<xref target="RFC8666" section="6" sectionFormat="of"/>).</t> <t>ThePrefix SIDPrefix-SID TLV has the following format: </t> <figureanchor="PFXSIDTLVFIG" title="Prefix SIDanchor="PFXSIDTLVFIG"> <name>Prefix-SID TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1158</t> <t>Length:</figure> <t>Where:</t> <dl> <dt>Type:</dt><dd> 1158</dd> <dt>Length:</dt><dd> Variable. 7 or 8 octets depending onLabelthe label orIndexindex encoding of theSID</t> <t>Flags: 1 octetSID.</dd> <dt>Flags:</dt><dd><t> 1-octet valuewhichthat should be set as:<list style="symbols"> <t>IS-IS Prefix SID</t> <ul spacing="normal"> <li>IS-IS Prefix-SID flagsareas defined insection 2.1.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2 Prefix SIDtarget="RFC8667" section="2.1.1" sectionFormat="of"/>.</li> <li>OSPFv2 Prefix-SID flagsareas defined insection 5 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3 Prefix SIDtarget="RFC8665" section="5" sectionFormat="of"/>.</li> <li>OSPFv3 Prefix-SID flagsareas defined insection 6 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> </list></t> <t>Algorithm: 1 octettarget="RFC8665" section="6" sectionFormat="of"/>.</li> </ul> </dd> <dt>Algorithm:</dt><dd> 1-octet valueidentifyidentifies the algorithm. The semantics of the algorithm are described insection 3.1.1 of<xreftarget="RFC8402"/>.</t> <t>Reserved:target="RFC8402" section="3.1.1" sectionFormat="of"/>.</dd> <dt>Reserved:</dt><dd> 2 octets thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>SID/Index/Label: <list style="symbols"> <t>IS-IS:receipt.</dd> <dt>SID/Index/Label:</dt> <dd><t><br/></t> <dl spacing="normal"> <dt>IS-IS:</dt><dd> Label or index value as defined insection 2.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2:target="RFC8667" section="2.1" sectionFormat="of"/>.</dd> <dt>OSPFv2:</dt><dd> Label or index value as defined insection 5 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3:target="RFC8665" section="5" sectionFormat="of"/>.</dd> <dt>OSPFv3:</dt><dd> Label or index value as defined insection 6 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t> </list></t>target="RFC8666" section="6" sectionFormat="of"/>.</dd> </dl> </dd> </dl> <t>The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS,OSPFv2OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing these fields.</t> </section> <section anchor="PREFIXATTRFLAGTLV"title="Prefixnumbered="true" toc="default"> <name>Prefix Attribute FlagsTLV">TLV</name> <t>The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute flags information. These flags are defined for OSPFv2 insection 2.1 of<xreftarget="RFC7684"/>, fortarget="RFC7684" section="2.1" sectionFormat="of"/>, OSPFv3 insection A.4.1.1 of<xreftarget="RFC5340"/>target="RFC5340" section="A.4.1.1" sectionFormat="of"/>, andforIS-IS insection 2.1 of<xreftarget="RFC7794"/>.</t>target="RFC7794" section="2.1" sectionFormat="of"/>.</t> <t>The Prefix Attribute Flags TLV has the following format: </t> <figureanchor="PFXATRTLVFIG" title="Prefixanchor="PFXATRTLVFIG"> <name>Prefix Attribute Flags TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1170</t> <t>Length: Variable.</t> <t>Flags:</figure> <t>Where:</t> <dl> <dt>Type:</dt><dd> 1170</dd> <dt>Length:</dt><dd> Variable.</dd> <dt>Flags:</dt><dd><t> avariable length flagvariable-length Flag field (according to thelengthLength field). Flags are routing protocol specific and are to be set asbelow:<list style="symbols"> <t>IS-ISbelow:</t> <ul spacing="normal"> <li>IS-IS flags correspond to the IPv4/IPv6 Extended Reachability Attribute Flags defined insection 2.1 of<xreftarget="RFC7794"/></t> <t>OSPFv2 flags correspond totarget="RFC7794" section="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="RFC5308" format="default"/> and 237 <xref target="RFC5120" format="default"/>. </li> <li>OSPFv2 flags correspond to the Flags field of the OSPFv2 Extended Prefix TLV defined insection 2.1 of<xreftarget="RFC7684"/></t> <t>OSPFv3target="RFC7684" section="2.1" sectionFormat="of"/>.</li> <li>OSPFv3 flags map to the Prefix Options field defined insection A.4.1.1 of<xreftarget="RFC5340"/>target="RFC5340" section="A.4.1.1" sectionFormat="of"/> and extended insection 3.1 of<xreftarget="RFC8362"/></t> </list></t> </list></t>target="RFC8362" section="3.1" sectionFormat="of"/>.</li> </ul> </dd> </dl> <t>The Flags field of this TLV is interpreted according to the respective underlying IS-IS,OSPFv2OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field.</t> </section> <section anchor="SOURCEIDTLV"title="Sourcenumbered="true" toc="default"> <name>Source Router Identifier(Source Router-ID) TLV">TLV</name> <t>The SourceRouter-IDRouter Identifier TLV contains the IPv4 or IPv6Router-IDRouter Identifier of the originator of thePrefix.prefix. For the IS-ISprotocolprotocol, this is derived from the IPv4/IPv6 Source Router IDsub-TLVSub-TLV as defined insection 2.2 of<xreftarget="RFC7794"/>.target="RFC7794" section="2.2" sectionFormat="of"/>. For the OSPF protocol, this is derived from the Prefix SourceRouter-ID sub-TLVRouter Address Sub-TLV as defined insection 4 of<xreftarget="I-D.ietf-lsr-ospf-prefix-originator"/>.</t>target="RFC9084" section="2.2" sectionFormat="of"/>.</t> <t>The SourceRouter-IDRouter Identifier TLV has the following format: </t> <figureanchor="SRCRIDTLVFIG" title="Source Router-IDanchor="SRCRIDTLVFIG"> <name>Source Router Identifier TLVFormat"> <artwork><![CDATA[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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |44- or16 octet Router-ID16-octet Router Identifier // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list style="hanging"> <t>Type: 1171</t> <t>Length:</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 prefix, respectively.</dd> <dt>Router-ID:</dt><dd> the IPv4 or IPv6 Router-ID in the case ofIS-ISIS-IS, and4 in case of OSPF.</t> <t>Router-ID:the IPv4 or IPv6Router-IDRouter Address in the case ofIS-ISOSPF.</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 thecasefollowing 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> </figure> <t>Where:</t> <dl> <dt>Type:</dt><dd>1174</dd> <dt>Length:</dt><dd>4 octets</dd> <dt>OSPF Router-ID:</dt><dd>the OSPF Router-ID ofOSPF.</t> </list></t>the node originating the prefix.</dd> </dl> </section> <section anchor="RANGETLV"title="Range TLV">numbered="true" toc="default"> <name>Range TLV</name> <t>The Range TLV is used in order to advertise a range of prefix-to-SID mappings as part of theSegment Routing Mapping Server (SRMS)SRMS functionality <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>,target="RFC8661" format="default"/>, as defined in the respective underlying IGP SRextensionsextensions: <xreftarget="I-D.ietf-ospf-segment-routing-extensions"/> (section 4), <xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/> (section 5)target="RFC8665" section="4" sectionFormat="of"/>, <xref target="RFC8666" section="5" sectionFormat="of"/>, and <xreftarget="I-D.ietf-isis-segment-routing-extensions"/> (section 2.4).target="RFC8667" section="2.4" sectionFormat="of"/>. 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 Extended Prefix Range TLV in the case of OSPFv2/OSPFv3.</t> <t>A Prefix NLRI, that has been advertised with a Range TLV, is considered a normal routing prefix(i.e.(i.e., prefix reachability) only when there is also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is considered only as the first prefix in the range for prefix-to-SID mapping advertisement.</t> <t>The format of the Range TLV is asfollows:<figure anchor="RANGETLVFIG" title="Rangefollows:</t> <figure anchor="RANGETLVFIG"> <name>Range TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure></t> <t>Where:<list> <t>Type: 1159</t> <t>Length:</figure> <t>Where:</t> <dl> <dt>Type:</dt><dd> 1159</dd> <dt>Length:</dt><dd> Variable. 11 or 12 octets depending onLabelthe label orIndexindex encoding of theSID</t> <t>Flags: 1 octetSID.</dd> <dt>Flags:</dt><dd><t> 1-octet valuewhichthat should be set as:<list style="symbols"> <t>IS-IS</t> <ul spacing="normal"> <li>IS-IS SID/Label Binding TLV flagsareas defined insection 2.4.1 of<xreftarget="I-D.ietf-isis-segment-routing-extensions"/>.</t> <t>OSPFv2target="RFC8667" section="2.4.1" sectionFormat="of"/>.</li> <li>OSPFv2 OSPF Extended Prefix Range TLV flagsareas defined insection 4 of<xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <t>OSPFv3target="RFC8665" section="4" sectionFormat="of"/>.</li> <li>OSPFv3 Extended Prefix Range TLV flagsareas defined insection 5 of<xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t> </list></t> <t>Reserved:target="RFC8666" section="5" sectionFormat="of"/>.</li> </ul> </dd> <dt>Reserved:</dt><dd> 1 octet thatMUST<bcp14>MUST</bcp14> be set to 0 and ignored onreceipt.</t> <t>Range Size:receipt.</dd> <dt>Range Size:</dt><dd> 2 octets that carry the number of prefixes that are covered by theadvertisement..</t> </list></t>advertisement.</dd> </dl> <t>The Flags field of this TLV is interpreted according to the respective underlying IS-IS,OSPFv2OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing this field.</t> <t>The prefix-to-SID mappings are advertised using sub-TLVs asbelow:<figure> <artwork><![CDATA[IS-IS: SID/Labelbelow:</t> <dl newline="true"> <dt>IS-IS:</dt> <dd> <dl newline="true" spacing="compact"> <dt>SID/Label RangeTLV Prefix-SID sub-TLV OSPFv2/OSPFv3:TLV</dt> <dd>Prefix-SID Sub-TLV</dd> </dl> </dd> <dt>OSPFv2/OSPFv3:</dt> <dd> <dl newline="true" spacing="compact"> <dt> OSPFv2/OSPFv3 Extended Prefix Range TLVPrefix SID sub-TLV BGP-LS: Range TLV</dt> <dd> Prefix-SID Sub-TLV </dd> </dl> </dd> <dt>BGP-LS:</dt> <dd> <dl newline="true" spacing="compact"> <dt>Range TLV</dt> <dd>Prefix-SID TLV (used as a sub-TLV in thiscontext) ]]></artwork> </figure></t>context)</dd> </dl> </dd> </dl> <t>The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV (used as a sub-TLV in this context) is encoded as described in <xreftarget="PREFIXSIDTLV"/>.</t>target="PREFIXSIDTLV" format="default"/>.</t> </section> </section> <section anchor="ISISTLV"title="Equivalentnumbered="true" toc="default"> <name>Equivalent IS-IS Segment RoutingTLVs/Sub-TLVs">TLVs/Sub-TLVs</name> <t>This sectionillustrateillustrates the IS-IS Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document.</t><t>The following table, illustrates for<t>For each BGP-LS TLV, the following table illustrates its equivalence in IS-IS.</t><texttable<table anchor="ISISTLVTAB"title="IS-ISalign="center"> <name>IS-IS Segment Routing ExtensionsTLVs/Sub-TLVs"> <ttcol align="left">Description</ttcol> <ttcolTLVs/Sub-TLVs</name> <thead> <tr> <th align="left">Description</th> <th align="left">IS-ISTLV/sub-TLV</ttcol> <ttcol align="left">Reference</ttcol> <c>SR Capabilities</c> <c>SR-Capabilities sub-TLV (2)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>SR Algorithm</c> <c>SR-Algorithm sub-TLV (19)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>SRTLV/sub-TLV</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">SR Capabilities</td> <td align="left">SR-Capabilities Sub-TLV (2)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">SR Algorithm</td> <td align="left">SR-Algorithm Sub-TLV (19)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">SR LocalBlock</c> <c>SRBlock</td> <td align="left">SR Local Blocksub-TLV (22)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>SRMS Preference</c> <c>SRMSSub-TLV (22)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">SRMS Preference</td> <td align="left">SRMS Preferencesub-TLV (19)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>Adjacency SID</c> <c>Adj-SID sub-TLV (31)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>LANSub-TLV (19)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">Adjacency SID</td> <td align="left">Adj-SID Sub-TLV (31)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">LAN AdjacencySID</c> <c>LAN-Adj-SID sub-TLV (32)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>Prefix SID</c> <c>Prefix-SID sub-TLV (3)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>Range</c> <c>SID/LabelSID</td> <td align="left">LAN-Adj-SID Sub-TLV (32)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">Prefix-SID</td> <td align="left">Prefix-SID Sub-TLV (3)</td> <td align="left"> <xref target="RFC8667" format="default"/></td> </tr> <tr> <td align="left">Range</td> <td align="left">SID/Label Binding TLV(149)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>SID/Label</c> <c>SID/Label sub-TLV (1)</c> <c><xref target="I-D.ietf-isis-segment-routing-extensions"/></c> <c>Prefix(149)</td> <td align="left"> <xref target="RFC8667" 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="RFC8667" format="default"/></td> </tr> <tr> <td align="left">Prefix Attribute Flags</td> <td align="left">Prefix AttributeFlags</c> <c>Prefix AttributesFlagssub-TLV (4)</c> <c><xref target="RFC7794"/></c> <c>Source Router-ID</c> <c>IPv4/IPv6Sub-TLV (4)</td> <td align="left"> <xref target="RFC7794" format="default"/></td> </tr> <tr> <td align="left">Source Router Identifier</td> <td align="left">IPv4/IPv6 Source Router IDsub-TLV (11/12)</c> <c><xref target="RFC7794"/></c> <c>L2Sub-TLV (11/12)</td> <td align="left"> <xref target="RFC7794" format="default"/></td> </tr> <tr> <td align="left">L2 Bundle MemberAttributes</c> <c>L2Attributes</td> <td align="left">L2 Bundle Member Attributes TLV(25)</c> <c><xref target="I-D.ietf-isis-l2bundles"/></c> </texttable>(25)</td> <td align="left"> <xref target="RFC8668" format="default"/></td> </tr> </tbody> </table> </section> <section anchor="OSPFTLV"title="Equivalentnumbered="true" toc="default"> <name>Equivalent OSPFv2/OSPFv3 Segment RoutingTLVs/Sub-TLVs">TLVs/Sub-TLVs</name> <t>This sectionillustrateillustrates the OSPFv2 and OSPFv3 Segment Routing Extensions TLVs and sub-TLVs mapped to the ones defined in this document.</t><t>The following table, illustrates for<t>For each BGP-LS TLV, the following tables illustrate its equivalence in OSPFv2 and OSPFv3.</t><texttable<table anchor="OSPFTVLTAB"title="OSPFv2align="center"> <name>OSPFv2 Segment Routing ExtensionsTLVs/Sub-TLVs"> <ttcol align="left">Description</ttcol> <ttcolTLVs/Sub-TLVs</name> <thead> <tr> <th align="left">Description</th> <th align="left">OSPFv2TLV/sub-TLV</ttcol> <ttcol align="left">Reference</ttcol> <c>SR Capabilities</c> <c>SID/LabelTLV/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)</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(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 LocalBlock</c> <c>SRBlock</td> <td align="left">SR Local Block TLV(14)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>SRMS Preference</c> <c>SRMS(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)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>Adjacency SID</c> <c>Adj-SID sub-TLV (2)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>LAN(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 AdjacencySID</c> <c>LANSID</td> <td align="left">LAN Adj-SIDsub-TLV (3)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>Prefix SID</c> <c>Prefix SID sub-TLV (2)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>Range</c> <c>OSPFSub-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)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>SID/Label</c> <c>SID/Label sub-TLV (1)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>Prefix(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 AttributeFlags</c> <c>FlagsFlags</td> <td align="left">Flags of OSPFv2 Extended Prefix TLV(1)</c> <c><xref target="RFC7684"/></c> <c>Source Router-ID</c> <c>Prefix(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-IDsub-TLV (TBD)</c> <c><xref target="I-D.ietf-lsr-ospf-prefix-originator"/></c> </texttable> <texttableSub-TLV (4)</td> <td align="left"> <xref target="RFC9084" format="default"/></td> </tr> </tbody> </table> <table anchor="OSPFV3TVLTAB"title="OSPFv3align="center"> <name>OSPFv3 Segment Routing ExtensionsTLVs/Sub-TLVs"> <ttcol align="left">Description</ttcol> <ttcolTLVs/Sub-TLVs</name> <thead> <tr> <th align="left">Description</th> <th align="left">OSPFv3TLV/sub-TLV</ttcol> <ttcol align="left">Reference</ttcol> <c>SR Capabilities</c> <c>SID/LabelTLV/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)</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(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 LocalBlock</c> <c>SRBlock</td> <td align="left">SR Local Block TLV(14)</c> <c><xref target="I-D.ietf-ospf-segment-routing-extensions"/></c> <c>SRMS Preference</c> <c>SRMS(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)</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(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 (5)</td> <td align="left"> <xref target="RFC8666" format="default"/></td> </tr> <tr> <td align="left">LAN AdjacencySID</c> <c>LANSID</td> <td align="left">LAN Adj-SIDsub-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>OSPFv3Sub-TLV (6)</td> <td align="left"> <xref target="RFC8666" format="default"/></td> </tr> <tr> <td align="left">Prefix-SID</td> <td align="left">Prefix-SID Sub-TLV (4)</td> <td align="left"> <xref target="RFC8666" format="default"/></td> </tr> <tr> <td align="left">Range</td> <td align="left">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(9)</td> <td align="left"> <xref target="RFC8666" format="default"/></td> </tr> <tr> <td align="left">SID/Label</td> <td align="left">SID/Label Sub-TLV (7)</td> <td align="left"> <xref target="RFC8666" format="default"/></td> </tr> <tr> <td align="left">Prefix AttributeFlags</c> <c>PrefixFlags</td> <td align="left">Prefix Option Fields of Prefix TLV types3,5,6</c> <c><xref target="RFC8362"/></c> <c>Source Router-ID</c> <c>Prefix3,5,6</td> <td align="left"> <xref target="RFC8362" format="default"/></td> </tr> <tr> <td align="left">Source OSPF Router Identifier</td> <td align="left">Prefix Source Router Address Sub-TLV (28)</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-IDsub-TLV (TBD)</c> <c><xref target="I-D.ietf-lsr-ospf-prefix-originator"/></c> </texttable>Sub-TLV (27)</td> <td align="left"> <xref target="RFC9084" format="default"/></td> </tr> </tbody> </table> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t>Early allocation of codepointsnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA hasbeen done by IANA for this document fromregistered the following code points in theregistry"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry under the"BGP-LS Parameters""Border Gateway Protocol - Link State (BGP-LS) Parameter" registry based on <xreftarget="BGPLSCODEPOINTS"/>.target="BGPLSCODEPOINTS" format="default"/>. The column "IS-IS TLV/Sub-TLV" defined in the registry does not require any value and should be left empty.</t> <section anchor="TLVSUMMARY"title="TLV/Sub-TLVnumbered="true" toc="default"> <name>TLV/Sub-TLV Code PointsSummary">Summary</name> <t>This section contains the global table of all TLVs/sub-TLVs defined in this document.</t><texttable<table anchor="BGPLSCODEPOINTS"title="Summary Tablealign="center"> <name>Summary of TLV/Sub-TLVCodepoints"> <ttcolCode Points</name> <thead> <tr> <th align="center">TLV CodePoint</ttcol> <ttcol align="left">Description</ttcol> <ttcol align="right">Reference</ttcol> <c>1034</c> <c>SR Capabilities</c> <c><xref target="SRCAPTLV"/></c> <c>1035</c> <c>SR Algorithm</c> <c><xref target="SRALGOTLV"/></c> <c>1036</c> <c>SRPoint</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="center">1034</td> <td align="left">SR Capabilities</td> <td align="right"> <xref target="SRCAPTLV" format="default"/></td> </tr> <tr> <td align="center">1035</td> <td align="left">SR Algorithm</td> <td align="right"> <xref target="SRALGOTLV" format="default"/></td> </tr> <tr> <td align="center">1036</td> <td align="left">SR LocalBlock</c> <c><xref target="SRLB"/></c> <c>1037</c> <c>SRMS Preference</c> <c><xref target="SRMSPREF"/></c> <c>1099</c> <c>Adjacency SID</c> <c><xref target="ADJSIDTLV"/></c> <c>1100</c> <c>LANBlock</td> <td align="right"> <xref target="SRLB" format="default"/></td> </tr> <tr> <td align="center">1037</td> <td align="left">SRMS Preference</td> <td align="right"> <xref target="SRMSPREF" format="default"/></td> </tr> <tr> <td align="center">1099</td> <td align="left">Adjacency SID</td> <td align="right"> <xref target="ADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1100</td> <td align="left">LAN AdjacencySID</c> <c><xref target="LANADJSIDTLV"/></c> <c>1158</c> <c>Prefix SID</c> <c><xref target="PREFIXSIDTLV"/></c> <c>1159</c> <c>Range</c> <c><xref target="RANGETLV"/></c> <c>1161</c> <c>SID/Label</c> <c><xref target="SIDLABELTLV"/></c> <c>1170</c> <c>PrefixSID</td> <td align="right"> <xref target="LANADJSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1158</td> <td align="left">Prefix-SID</td> <td align="right"> <xref target="PREFIXSIDTLV" format="default"/></td> </tr> <tr> <td align="center">1159</td> <td align="left">Range</td> <td align="right"> <xref target="RANGETLV" format="default"/></td> </tr> <tr> <td align="center">1161</td> <td align="left">SID/Label</td> <td align="right"> <xref target="SIDLABELTLV" format="default"/></td> </tr> <tr> <td align="center">1170</td> <td align="left">Prefix AttributeFlags</c> <c><xref target="PREFIXATTRFLAGTLV"/></c> <c>1171</c> <c>Source Router-ID</c> <c><xref target="SOURCEIDTLV"/></c> <c>1172</c> <c>L2Flags</td> <td align="right"> <xref target="PREFIXATTRFLAGTLV" format="default"/></td> </tr> <tr> <td align="center">1171</td> <td align="left">Source Router Identifier</td> <td align="right"> <xref target="SOURCEIDTLV" format="default"/></td> </tr> <tr> <td align="center">1172</td> <td align="left">L2 Bundle MemberAttributes</c> <c><xref target="L2BUNDLETLV"/></c> </texttable>Attributes</td> <td align="right"> <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 anchor="Manageability"title="Manageability Considerations">numbered="true" toc="default"> <name>Manageability Considerations</name> <t>This section is structured as recommended in <xreftarget="RFC5706"/>.</t>target="RFC5706" format="default"/>.</t> <t>The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed in the Manageability Considerations section of <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Specifically, the malformed attribute tests for syntactic checks in the Fault Management section of <xreftarget="RFC7752"/>target="RFC7752" format="default"/> now encompass the new BGP-LS Attribute TLVs defined in this document. The semantic or content checking for the TLVs 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 information(e.g.(e.g., an application or a controller) and not the BGP protocol.</t> <t>A consumer of the BGP-LS information retrieves this information over a BGP-LS session (referSection 1to Sections <xref target="RFC7752" section="1" sectionFormat="bare"/> and2<xref target="RFC7752" section="2" sectionFormat="bare"/> of <xref target="RFC7752"/>). 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 scope of this document.</t> <t>This document only introduces new AttributeTLVsTLVs, and any syntactic error in them would result inonly that specific attributethe BGP-LS Attribute being discarded with an error log. The SR information introduced in BGP-LS by thisspecification,specification may be used by BGP-LS consumer applications likeaan SRpath computation enginePath Computation Engine (PCE) to learn the SR capabilities of the 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 traffic engineeringuse-casesuse cases and to steer traffic on paths different from the underlyingIGP basedIGP-based distributedbest pathbest-path computation. Errors in the encoding or decoding of the SR information may result in the unavailability of such information to the SR PCE or incorrect information being made available to it. This may result in the SR PCE not being able to perform the desiredSR basedSR-based optimization functionality or to perform it in an unexpected or inconsistent manner. The handling of such errors by applications like SR PCE may be implementation specific and out of scope of this document.</t> <t>The extensions, specified in this document, do not introduce any new configuration or monitoring aspects in BGP or BGP-LS other than as discussed in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. The manageability aspects of the underlying SR features are covered by <xreftarget="I-D.ietf-spring-sr-yang"/>,target="RFC9020" format="default"/>, <xreftarget="I-D.ietf-isis-sr-yang"/>target="I-D.ietf-isis-sr-yang" format="default"/>, and <xreftarget="I-D.ietf-ospf-sr-yang"/>.</t>target="I-D.ietf-ospf-sr-yang" format="default"/>.</t> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. The advertisement of the SR link attribute information defined in this document presents similar risk as associated with the existing set of link attribute information as described in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. The Security Considerations section of <xreftarget="RFC7752"/>target="RFC7752" format="default"/> also applies to these extensions. The procedures and new TLVs defined in this document, by themselves, do not affect the BGP-LS security model discussed in <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</t> <t>The TLVs introduced in this document are used to propagateIGP definedIGP-defined information(<xref target="I-D.ietf-isis-segment-routing-extensions"/>,(see <xref target="RFC8665" format="default"/>, <xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>target="RFC8666" format="default"/>, and <xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>).target="RFC8667" format="default"/>). These TLVs represent the SR information associated with the IGP node,linklink, and prefix. The IGP instances originating these TLVs are assumed to support all the required security and authentication mechanisms (as described in <xreftarget="I-D.ietf-isis-segment-routing-extensions"/>,target="RFC8665" format="default"/>, <xreftarget="I-D.ietf-ospf-segment-routing-extensions"/>target="RFC8666" format="default"/>, and <xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>)target="RFC8667" format="default"/>) in order to prevent any security issue when propagating the TLVs into BGP-LS.</t> <t>BGP-LS SR extensions enable traffic engineeringuse-casesuse cases within theSegment RoutingSR domain. SR operates within a trusted domain <xreftarget="RFC8402"/>target="RFC8402" format="default"/>, and its security considerations also apply to BGP-LS sessions when carrying SR information. The SR traffic engineering policies using the SIDs advertised via BGP-LS are expected to be used entirely within this trusted SR domain(e.g.(e.g., between multipleAS/domainsASes/domains within a single provider network). Therefore, precaution is necessary to ensure that the link-state information (including SR information) advertised via BGP-LS sessions is limited to consumers in a secure manner within this trusted SR domain. BGP peering sessions foraddress-familiesaddress families other thanLink-Statelink state may besetupset up to routers outside the SR domain. The isolation of BGP-LS peering sessions is recommended to ensure that BGP-LS topology information (including the newly added SR information) is not advertised to an external BGP peering session outside the SR domain.</t> </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></middle> <back> <displayreference target="I-D.ietf-isis-sr-yang" to="ISIS-SR-YANG"/> <displayreference target="I-D.ietf-ospf-sr-yang" to="OSPF-SR-YANG"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7794.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8571.xml"/> <!-- [I-D.ietf-isis-segment-routing-extensions] Published as RFC 8667 --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8667.xml"/> <!-- [I-D.ietf-ospf-segment-routing-extensions] Published as RFC 8665 --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/> <!-- [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Published as RFC 8666 --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8666.xml"/> <!-- [I-D.ietf-isis-l2bundles] Published as RFC 8668 --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8668.xml"/> <!-- [I-D.ietf-lsr-ospf-prefix-originator] IESG state I-D Exists; companion document 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="editor"> <organization /> </author> <date month='August' year='2021' /> </front> <seriesInfo name="RFC" value="9084"/> <seriesInfo name="DOI" value="10.17487/RFC9084"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5706.xml"/> <!-- [I-D.ietf-spring-segment-routing-ldp-interop] Published as RFC 8661 --> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8661.xml"/> <!-- [I-D.ietf-isis-sr-yang] IESG state I-D Exists--> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-isis-sr-yang-10.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"/> <!-- 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> <section anchor="Acknowledgements"title="Acknowledgements">numbered="false" toc="default"> <name>Acknowledgements</name> <t>The authors would like to thankJeffrey Haas, Aijun Wang, Robert Raszuk and Susan Hares<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 andcommentscomments, which helped correct issues and improve the document.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7794.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7684.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8362.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml"?> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8571.xml"?> <?rfc include="reference.I-D.ietf-isis-segment-routing-extensions.xml"?> <?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions.xml"?> <?rfc include="reference.I-D.ietf-ospf-ospfv3-segment-routing-extensions.xml"?> <?rfc include="reference.I-D.ietf-isis-l2bundles.xml"?> <?rfc include="reference.I-D.ietf-lsr-ospf-prefix-originator.xml"?> </references> <references title="Informative References"> <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5706.xml"?> <?rfc include="reference.I-D.ietf-spring-segment-routing-ldp-interop.xml" ?> <?rfc include="reference.I-D.ietf-spring-sr-yang.xml"?> <?rfc include="reference.I-D.ietf-isis-sr-yang.xml"?> <?rfc include="reference.I-D.ietf-ospf-sr-yang.xml"?> </references><section anchor="Contributors" numbered="false" toc="default"> <name>Contributors</name> <t>The following people have substantially contributed to the editing of this document:</t> <contact fullname="Peter Psenak"> <organization>Cisco Systems</organization> <address> <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> </back> </rfc>