rfc9086xml2.original.xml   rfc9086.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" submissionType="IETF"
<?rfc tocdepth="3"?> category="std" consensus="true" number="9086"
<?rfc tocindent="yes"?> docName="draft-ietf-idr-bgpls-segment-routing-epe-19" ipr="trust200902"
<?rfc symrefs="yes"?> obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
<?rfc sortrefs="yes"?> symRefs="true" sortRefs="true" version="3">
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgpls-segment-routing-epe-19"
ipr="trust200902">
<front> <front>
<title abbrev="Segment Routing EPE BGP-LS Extensions">BGP-LS extensions
for Segment Routing BGP Egress Peer Engineering</title>
<title abbrev="Segment Routing EPE BGP-LS Extensions">Border Gateway
Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering</title>
<seriesInfo name="RFC" value="9086"/>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Individual</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <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/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <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/> <street/>
<city>Brussels</city> <city>Brussels</city>
<region/> <region/>
<code/> <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="Keyur Patel" initials="K." surname="Patel"> <author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus, Inc.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<email>Keyur@arrcus.com</email> <email>Keyur@arrcus.com</email>
</address> </address>
</author> </author>
<author fullname="Saikat Ray" initials="S." surname="Ray"> <author fullname="Saikat Ray" initials="S." surname="Ray">
<organization>Individual Contributor</organization> <organization>Individual</organization>
<address> <address>
<email>raysaikat@gmail.com</email> <email>raysaikat@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jie Dong" initials="J." surname="Dong"> <author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<date year="2021" month="August"/>
<date year=""/>
<area>Routing</area> <area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup> <workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<abstract> <abstract>
<t>Segment Routing (SR) leverages source routing. A node steers a packet <t>
through a controlled set of instructions, called segments, by prepending A node steers a packet through a controlled set of instructions, called
the packet with an SR header. A segment can represent any instruction, segments, by prepending the packet with a list of segment identifiers (SIDs).
topological or service-based. SR segments allow steering a flow through
any topological path and service chain while maintaining per-flow state
only at the ingress node of the SR domain.</t>
<t>This document describes an extension to BGP Link-State (BGP-LS) for A segment can represent any instruction, topological or service based. SR
advertisement of BGP Peering Segments along with their BGP peering node segments allow steering a flow through any topological path and service chain
information so that efficient BGP Egress Peer Engineering (EPE) policies while maintaining per-flow state only at the ingress node of the SR
and strategies can be computed based on Segment Routing.</t> domain.</t>
<t>This document describes an extension to Border Gateway Protocol -
Link State (BGP-LS) for advertisement of BGP Peering Segments along with
their BGP peering node information so that efficient BGP Egress Peer
Engineering (EPE) policies and strategies can be computed based on
Segment Routing.</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 anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>Segment Routing (SR) leverages source routing. A node steers a packet <name>Introduction</name>
through a controlled set of instructions, called segments, by prepending <t>Segment Routing (SR) leverages source routing.
the packet with an SR header with segment identifiers (SID). A SID can
represent any instruction, topological or service-based. SR segments
allows to enforce a flow through any topological path or service
function while maintaining per-flow state only at the ingress node of
the SR domain.</t>
<t>The SR architecture <xref target="RFC8402"/> defines three types of
BGP Peering Segments that may be instantiated at a BGP node:<list
style="symbols">
<t>Peer Node Segment (PeerNode SID) : instruction to steer to a
specific peer node</t>
<t>Peer Adjacency Segment (PeerAdj SID) : instruction to steer over A node steers a packet through a controlled set of instructions, called
a specific local interface towards a specific peer node</t> segments, by prepending the packet with a list of segment identifiers (SIDs).
<t>Peer Set Segment (PeerSet SID) : instruction to load-balance to a A SID can represent any instruction, topological or service based. SR segments
set of specific peer nodes</t> allows to enforce a flow through any topological path or service function
</list></t> while maintaining per-flow state only at the ingress node of the SR
domain.</t>
<t>The SR architecture <xref target="RFC8402" format="default"/> defines t
hree types of
BGP Peering Segments that may be instantiated at a BGP node:</t>
<ul spacing="normal">
<li>Peer Node Segment (PeerNode SID) : instruction to steer to a
specific peer node</li>
<li>Peer Adjacency Segment (PeerAdj SID) : instruction to steer over
a specific local interface towards a specific peer node</li>
<li>Peer Set Segment (PeerSet SID) : instruction to load-balance to a
set of specific peer nodes</li>
</ul>
<t>SR can be directly applied to either to an MPLS dataplane (SR/MPLS) <t>SR can be directly applied to either an MPLS data plane (SR-MPLS)
with no change on the forwarding plane or to a modified IPv6 forwarding with no change on the forwarding plane or to a modified IPv6 forwarding
plane (SRv6).</t> plane (SRv6).</t>
<t>This document describes extensions to the BGP - Link State Network
Layer Reachability Information (BGP-LS NLRI) and the BGP-LS Attribute
defined for BGP-LS <xref target="RFC7752" format="default"/> for
advertising BGP peering segments from a BGP node along with its peering
topology information (i.e., its peers, interfaces, and peering
Autonomous Systems (ASes)) to enable computation of efficient BGP Egress
Peer Engineering (BGP-EPE) policies and strategies using the SR-MPLS
data plane. The corresponding extensions for SRv6 are specified in <xref
target="I-D.ietf-idr-bgpls-srv6-ext" format="default"/>.</t>
<t>This document describes extensions to the BGP Link-State NLRI (BGP-LS <t><xref target="RFC9087"
NLRI) and the BGP-LS Attribute defined for BGP-LS <xref format="default"/> illustrates a centralized controller-based BGP Egress
target="RFC7752"/> for advertising BGP peering segments from a BGP node Peer Engineering solution involving SR path computation using the BGP
along with its peering topology information (i.e., its peers, Peering Segments. This use case comprises a centralized controller that
interfaces, and peering ASs) to enable computation of efficient BGP learns the BGP Peering SIDs via BGP-LS and then uses this information to
Egress Peer Engineering (BGP-EPE) policies and strategies using the program a BGP-EPE policy at any node in the domain to perform traffic
SR/MPLS dataplane. The corresponding extensions for SRv6 are specified steering via a specific BGP egress node to specific External BGP
in <xref target="I-D.dawra-idr-bgpls-srv6-ext"/>.</t> (EBGP) peer(s) optionally also over a specific interface. The BGP-EPE
policy can be realized using the SR Policy framework <xref
<t><xref target="I-D.ietf-spring-segment-routing-central-epe"/> target="I-D.ietf-spring-segment-routing-policy" format="default"/>.</t>
illustrates a centralized controller-based BGP Egress Peer Engineering
solution involving SR path computation using the BGP Peering Segments.
This use case comprises a centralized controller that learns the BGP
Peering SIDs via BGP-LS and then uses this information to program a
BGP-EPE policy at any node in the domain to perform traffic steering via
a specific BGP egress node to a specific EBGP peer(s) optionally also
over a specific interface. The BGP-EPE policy can be realized using the
SR Policy framework <xref
target="I-D.ietf-spring-segment-routing-policy"/>.</t>
<t>This document introduces a new BGP-LS Protocol-ID for BGP and defines <t>This document introduces a new BGP-LS Protocol-ID for BGP and defines
new BGP-LS Node and Link Descriptor TLVs to facilitate advertising new BGP-LS Node and Link Descriptor TLVs to facilitate advertising
BGP-LS Link NLRI to represent the BGP peering topology. Further, it BGP-LS Link NLRI to represent the BGP peering topology. Further, it
specifies the BGP-LS Attribute TLVs for advertisement of the BGP Peering specifies the BGP-LS Attribute TLVs for advertisement of the BGP Peering
Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) to be Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) to be
advertised in the same BGP-LS Link NLRI.</t> advertised in the same BGP-LS Link NLRI.</t>
</section> </section>
<section anchor="BGPPEERINGSEG" title="BGP Peering Segments"> <section anchor="TERMINOLOGY">
<t>As described in <xref target="RFC8402"/>, a BGP-EPE enabled Egress PE <name>Requirements Language</name>
node instantiates SR Segments corresponding to its attached peers. These
segments are called BGP Peering Segments or BGP Peering SIDs. In case of <t>
EBGP, they enable the expression of source-routed inter-domain The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
paths.</t> "<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&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section anchor="BGPPEERINGSEG" numbered="true" toc="default">
<name>BGP Peering Segments</name>
<t>As described in <xref target="RFC8402" format="default"/>, a
BGP-EPE-enabled Egress Provider Edge (PE) node instantiates SR Segments co
rresponding to
its attached peers. These segments are called BGP Peering Segments or
BGP Peering SIDs. In the case of EBGP, they enable the expression of
source-routed interdomain paths.</t>
<t>An ingress border router of an AS may compose a list of SIDs to steer <t>An ingress border router of an AS may compose a list of SIDs to steer
a flow along a selected path within the AS, towards a selected egress a flow along a selected path within the AS, towards a selected egress
border router C of the AS, and to a specific EBGP peer. At minimum, a border router C of the AS, and to a specific EBGP peer. At minimum, a
BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID
of the chosen egress PE and then the BGP Peering SID for the chosen of the chosen egress PE and then the BGP Peering SID for the chosen
egress PE peer or peering interface.</t> egress PE peer or peering interface.</t>
<t>Each BGP session <bcp14>MUST</bcp14> be described by a PeerNode
<t>Each BGP session MUST be described by a PeerNode SID. The description SID. The description of the BGP session <bcp14>MAY</bcp14> be augmented
of the BGP session MAY be augmented by additional PeerAdj SIDs. Finally, by additional PeerAdj SIDs. Finally, multiple PeerNode SIDs or PeerAdj
multiple PeerNode SIDs or PeerAdj SIDs MAY be part of the same group/set SIDs <bcp14>MAY</bcp14> be part of the same group/set in order to group
in order to group EPE resources under a common PeerSet SID. These BGP EPE resources under a common PeerSet SID. These BGP Peering SIDs and
Peering SIDs and their encoding are described in detail in <xref their encoding are described in detail in <xref target="PEERSEGMENTS"
target="PEERSEGMENTS"/>.</t> format="default"/>.</t>
<t>The following BGP Peering SIDs need to be instantiated on a BGP <t>The following BGP Peering SIDs need to be instantiated on a BGP
router for each of its BGP peer sessions that are enabled for Egress router for each of its BGP peer sessions that are enabled for Egress
Peer Engineering:<list style="symbols"> Peer Engineering:</t>
<t>One PeerNode SID MUST be instantiated to describe the BGP peer <ul spacing="normal">
session.</t> <li>One PeerNode SID <bcp14>MUST</bcp14> be instantiated to describe
the BGP peer session.</li>
<t>One or more PeerAdj SID MAY be instantiated corresponding to the <li>One or more PeerAdj SID <bcp14>MAY</bcp14> be instantiated
underlying link(s) to the directly connected BGP peer session.</t> corresponding to the underlying link(s) to the directly connected BGP
peer session.</li>
<t>A PeerSet SID MAY be instantiated and additionally associated and <li>A PeerSet SID <bcp14>MAY</bcp14> be instantiated and additionally
shared between one or more PeerNode SIDs or PeerAdj SIDs.</t> associated and shared between one or more PeerNode SIDs or PeerAdj
</list></t> SIDs.</li>
</ul>
<t>While an egress point in a topology usually refers to EBGP sessions <t>While an egress point in a topology usually refers to EBGP sessions
between external peers, there's nothing in the extensions defined in between external peers, there's nothing in the extensions defined in
this document that would prevent the use of these extensions in the this document that would prevent the use of these extensions in the
context of IBGP sessions. However, unlike EBGP sessions which are context of Internal BGP (IBGP) sessions.
generally between directly connected BGP routers which are also along However, unlike EBGP sessions, which are generally between directly
the traffic forwarding path, IBGP peer sessions may be setup to BGP connected BGP routers also along the traffic forwarding path, IBGP peer
routers which are not in the forwarding path. As such, when the IBGP sessions may be set up to BGP routers that are not in the forwarding
design includes sessions with route-reflectors, a BGP router SHOULD NOT path.
instantiate a BGP Peering SID for those sessions to peer nodes which are As such, when the IBGP design includes sessions with route reflectors, a
not in the forwarding path since the purpose of BGP Peering SID is to BGP router <bcp14>SHOULD NOT</bcp14> instantiate a BGP Peering SID for
steer traffic to that specific peers. Thus, the applicability for IBGP those sessions to peer nodes that are not in the forwarding path since
peering may be limited to only those deployments where the IBGP peer is the purpose of BGP Peering SID is to steer traffic to those specific
also along the forwarding data path.</t> peers. Thus, the applicability for IBGP peering may be limited to only
those deployments where the IBGP peer is also along the forwarding data
path.</t>
<t>Any BGP Peering SIDs instantiated on the node are advertised via <t>Any BGP Peering SIDs instantiated on the node are advertised via
BGP-LS Link NLRI type as described in the sections below. An BGP-LS Link NLRI type as described in the sections below. An
illustration of the BGP Peering SIDs' allocations in a reference BGP illustration of the BGP Peering SIDs' allocations in a reference BGP
peering topology along with the information carried in the BGP-LS Link peering topology along with the information carried in the BGP-LS Link
NLRI and its corresponding BGP-LS Attribute are described in <xref NLRI and its corresponding BGP-LS Attribute are described in <xref target=
target="I-D.ietf-spring-segment-routing-central-epe"/>.</t> "RFC9087" format="default"/>.</t>
</section> </section>
<section anchor="EPENLRI" numbered="true" toc="default">
<section anchor="EPENLRI" <name>BGP-LS NLRI Advertisement for BGP Protocol</name>
title="BGP-LS NLRI Advertisement for BGP Protocol">
<t>This section describes the BGP-LS NLRI encodings that describe the <t>This section describes the BGP-LS NLRI encodings that describe the
BGP peering and link connectivity between BGP routers.</t> BGP peering and link connectivity between BGP routers.</t>
<t>This document specifies the advertisement of BGP peering topology <t>This document specifies the advertisement of BGP peering topology
information via BGP-LS Link NLRI type which requires use of a new BGP-LS information via BGP-LS Link NLRI type, which requires use of a new BGP-LS
Protocol-ID.</t> Protocol-ID.</t>
<table anchor="PROTOCOL-IDS" align="center">
<texttable anchor="PROTOCOL-IDS" <name>BGP-LS Protocol Identifier for BGP</name>
title="BGP-LS Protocol Identifier for BGP"> <thead>
<ttcol align="center">Protocol-ID</ttcol> <tr>
<th align="center">Protocol-ID</th>
<ttcol align="left">NLRI information source protocol</ttcol> <th align="left">NLRI Information Source Protocol</th>
</tr>
<c>7</c> </thead>
<tbody>
<c>BGP</c> <tr>
</texttable> <td align="center">7</td>
<td align="left">BGP</td>
</tr>
</tbody>
</table>
<t>The use of a new Protocol-ID allows separation and differentiation <t>The use of a new Protocol-ID allows separation and differentiation
between the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs between the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs
carrying IGP link-state information defined in <xref carrying IGP link-state information defined in <xref target="RFC7752" form
target="RFC7752"/>.</t> at="default"/>.</t>
<t>The BGP Peering information along with their Peering Segments are <t>The BGP Peering information along with their Peering Segments are
advertised using BGP-LS Link NLRI type with the Protocol-ID set to BGP. advertised using BGP-LS Link NLRI type with the Protocol-ID set to BGP.
The BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute TLVs
TLVs as defined in <xref target="RFC7752"/>. In order to correctly as defined in <xref target="RFC7752" format="default"/>. In order to
describe BGP nodes, new TLVs are defined in this section.</t> correctly describe BGP nodes, new TLVs are defined in this section.</t>
<t><xref target="RFC7752" format="default"/> defines BGP-LS Link NLRI
<t><xref target="RFC7752"/> defines Link NLRI Type is as follows: type as follows:
<figure anchor="LINKNLRI" title="BGP-LS Link NLRI"> </t>
<artwork><![CDATA[ 0 1 2 <figure anchor="LINKNLRI">
3 <name>BGP-LS Link NLRI</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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Protocol-ID | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
| (64 bits) | | (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local Node Descriptors // // Local Node Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote Node Descriptors // // Remote Node Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Descriptors // // Link Descriptors //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="hanging"> </figure>
<t>Node Descriptors and Link Descriptors are defined in <xref <dl newline="false" spacing="normal">
target="RFC7752"/>.</t> <dt/>
</list></t> <dd>Node Descriptors and Link Descriptors are defined in <xref target="R
FC7752" format="default"/>.</dd>
<section anchor="BGPIDCONFEDMEMBER" </dl>
title="BGP Router-ID and Member AS Number"> <section anchor="BGPIDCONFEDMEMBER" numbered="true" toc="default">
<t>Two new Node Descriptors TLVs are defined in this document:<list <name>BGP Router-ID and Member AS Number</name>
style="symbols"> <t>Two new Node Descriptor TLVs are defined in this document:</t>
<t>BGP Router Identifier (BGP Router-ID): <list style="hanging"> <ul spacing="normal">
<t>Type: 516</t> <li>
<t>BGP Router Identifier (BGP Router-ID): </t>
<t>Length: 4 octets</t> <dl newline="false" spacing="normal">
<dt/>
<t>Value: 4 octet unsigned non-zero integer representing the <dd>Type: 516</dd>
BGP Identifier as defined in <xref target="RFC6286"/>.</t> <dt/>
</list></t> <dd>Length: 4 octets</dd>
</list><list style="symbols"> <dt/>
<t>Member-AS Number (Member-ASN)<list style="hanging"> <dd>Value: 4-octet unsigned non-zero integer representing the
<t>Type: 517</t> BGP Identifier as defined in <xref target="RFC6286" format="defa
ult"/></dd>
<t>Length: 4 octets</t> </dl>
</li>
<t>Value: 4 octet unsigned non-zero integer representing the </ul>
Member-AS Number <xref target="RFC5065"/>.</t> <ul spacing="normal">
</list></t> <li>
</list></t> <t>Member-AS Number (Member-ASN)</t>
<dl newline="false" spacing="normal">
<dt/>
<dd>Type: 517</dd>
<dt/>
<dd>Length: 4 octets</dd>
<dt/>
<dd>Value: 4-octet unsigned non-zero integer representing the
Member-AS Number <xref target="RFC5065" format="default"/></dd>
</dl>
</li>
</ul>
</section> </section>
<section anchor="MANDATORYNODEDESC" numbered="true" toc="default">
<name>Mandatory BGP Node Descriptors</name>
<t>The following Node Descriptor TLVs <bcp14>MUST</bcp14> be included in
BGP-LS NLRI
as Local Node Descriptors when distributing BGP information:</t>
<ul spacing="normal">
<li>BGP Router-ID (TLV 516), which contains a valid BGP Identifier
of the local BGP node.</li>
<li>Autonomous System Number (TLV 512) <xref target="RFC7752"
format="default"/>, which contains the Autonomous System Number
(ASN) or AS Confederation Identifier (an ASN) <xref target="RFC5065"
format="default"/>, if confederations are used, of the local BGP
node.</li>
</ul>
<section anchor="MANDATORYNODEDESC" <t>Note that <xref target="RFC6286" sectionFormat="of" section="2.1"/>
title="Mandatory BGP Node Descriptors"> requires the BGP identifier (Router-ID) to be unique within an
<t>The following Node Descriptors TLVs MUST be included in BGP-LS NLRI Autonomous System and non-zero. Therefore, the &lt;ASN, BGP
as Local Node Descriptors when distributing BGP information:<list Router-ID&gt; tuple is globally unique. Their use in the Node
style="symbols"> Descriptor helps map Link-State NLRIs with BGP protocol-ID to a unique
<t>BGP Router-ID (TLV 516), which contains a valid BGP Identifier BGP router in the administrative domain where BGP-LS is enabled.</t>
of the local BGP node.</t> <t>The following Node Descriptor TLVs <bcp14>MUST</bcp14> be included in
BGP-LS Link
<t>Autonomous System Number (TLV 512) <xref target="RFC7752"/>,
which contains the ASN or AS Confederation Identifier (ASN) <xref
target="RFC5065"/>, if confederations are used, of the local BGP
node.</t>
</list></t>
<t>Note that <xref target="RFC6286"/> (section 2.1) requires the BGP
identifier (Router-ID) to be unique within an Autonomous System and
non-zero. Therefore, the &lt;ASN, BGP Router-ID&gt; tuple is globally
unique. Their use in the Node Descriptor helps map Link-State NLRIs
with BGP protocol-ID to a unique BGP router in the administrative
domain where BGP-LS is enabled.</t>
<t>The following Node Descriptors TLVs MUST be included in BGP-LS Link
NLRI as Remote Node Descriptors when distributing BGP NLRI as Remote Node Descriptors when distributing BGP
information:<list style="symbols"> information:</t>
<t>BGP Router-ID (TLV 516), which contains the valid BGP <ul spacing="normal">
Identifier of the peer BGP node.</t> <li>BGP Router-ID (TLV 516), which contains the valid BGP
Identifier of the peer BGP node.</li>
<li>Autonomous System Number (TLV 512) <xref target="RFC7752"
format="default"/>, which contains the ASN or the AS Confederation
Identifier (an ASN) <xref target="RFC5065" format="default"/>, if
confederations are used, of the peer BGP node.</li>
</ul>
<t>Autonomous System Number (TLV 512) <xref target="RFC7752"/>,
which contains the ASN or the AS Confederation Identifier (ASN)
<xref target="RFC5065"/>, if confederations are used, of the peer
BGP node.</t>
</list></t>
</section> </section>
<section anchor="OPTIONALNODEDESC" numbered="true" toc="default">
<section anchor="OPTIONALNODEDESC" title="Optional BGP Node Descriptors"> <name>Optional BGP Node Descriptors</name>
<t>The following Node Descriptors TLVs MAY be included in BGP-LS NLRI <t>The following Node Descriptor TLVs <bcp14>MAY</bcp14> be included in
as Local Node Descriptors when distributing BGP information:<list BGP-LS NLRI
style="symbols"> as Local Node Descriptors when distributing BGP information:</t>
<t>Member-ASN (TLV 517), which contains the ASN of the <ul spacing="normal">
<li>Member-ASN (TLV 517), which contains the ASN of the
confederation member (i.e., Member-AS Number), if BGP confederation member (i.e., Member-AS Number), if BGP
confederations are used, of the local BGP node.</t> confederations are used, of the local BGP node.</li>
<li>Node Descriptors as defined in <xref target="RFC7752" format="defa
<t>Node Descriptors as defined in <xref target="RFC7752"/>.</t> ult"/>.</li>
</list></t> </ul>
<t>The following Node Descriptor TLVs <bcp14>MAY</bcp14> be included in
<t>The following Node Descriptors TLVs MAY be included in BGP-LS Link BGP-LS Link
NLRI as Remote Node Descriptors when distributing BGP NLRI as Remote Node Descriptors when distributing BGP
information:<list style="symbols"> information:</t>
<t>Member-ASN (TLV 517), which contains the ASN of the <ul spacing="normal">
<li>Member-ASN (TLV 517), which contains the ASN of the
confederation member (i.e., Member-AS Number), if BGP confederation member (i.e., Member-AS Number), if BGP
confederations are used, of the peer BGP node.</t> confederations are used, of the peer BGP node.</li>
<li>Node Descriptors as defined in <xref target="RFC7752" format="defa
<t>Node Descriptors as defined in <xref target="RFC7752"/>.</t> ult"/>.</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="PEERSEGMENTS" numbered="true" toc="default">
<section anchor="PEERSEGMENTS" <name>BGP-LS Attributes for BGP Peering Segments</name>
title="BGP-LS Attributes for BGP Peering Segments">
<t>This section defines the BGP-LS Attributes corresponding to the <t>This section defines the BGP-LS Attributes corresponding to the
following BGP Peer Segment SIDs:<list style="hanging"> following BGP Peer Segment SIDs:</t>
<t>Peer Node Segment Identifier (PeerNode SID)</t> <ul>
<li>Peer Node Segment Identifier (PeerNode SID)
<t>Peer Adjacency Segment Identifier (PeerAdj SID)</t> </li>
<li>Peer Adjacency Segment Identifier (PeerAdj SID)
<t>Peer Set Segment Identifier (PeerSet SID)</t> </li>
</list></t> <li>Peer Set Segment Identifier (PeerSet SID)
</li>
</ul>
<t>The following new BGP-LS Link attributes TLVs are defined for use <t>The following new BGP-LS Link Attribute TLVs are defined for use
with BGP-LS Link NLRI for advertising BGP Peering SIDs:</t> with BGP-LS Link NLRI for advertising BGP Peering SIDs:</t>
<figure anchor="CODEPOINTVALUES" <table anchor="CODEPOINTVALUES">
title="BGP-LS TLV code points for BGP-EPE"> <name>BGP-LS TLV Code Points for BGP-EPE</name>
<artwork><![CDATA[+----------+---------------------------+ <thead>
| TLV Code | Description | <tr>
| Point | | <th>TLV Code Point</th>
+----------+---------------------------+ <th>Description</th>
| 1101 | PeerNode SID | </tr>
| 1102 | PeerAdj SID | </thead>
| 1103 | PeerSet SID | <tbody>
+----------+---------------------------+ <tr>
]]></artwork> <td>1101</td>
</figure> <td>PeerNode SID</td>
</tr>
<tr>
<td>1102</td>
<td>PeerAdj SID</td>
</tr>
<tr>
<td>1103</td>
<td>PeerSet SID</td>
</tr>
</tbody>
</table>
<t/> <t/>
<t>PeerNode SID, PeerAdj SID, and PeerSet SID all have the same format
<t>PeerNode SID, PeerAdj SID, and PeerSet SID have all the same format as defined below: </t>
defined here below: <figure anchor="PEERSID" <figure anchor="PEERSID">
title="BGP Peering SIDs TLV Format"> <name>BGP Peering SIDs 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 | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="symbols"> </figure>
<t>Type: 1101, 1102 or 1103 as listed in <xref <ul spacing="normal">
target="CODEPOINTVALUES"/>.</t> <li>Type: 1101, 1102, or 1103 as listed in <xref target="CODEPOINTVALUES
" format="default"/></li>
<t>Length: variable. Valid values are either 7 or 8 based on the <li>Length: variable. Valid values are either 7 or 8 based on whether
whether the encoding is done as a SID Index or a label.</t> the encoding is done as a SID Index or a label.</li>
<li>
<t>Flags: one octet of flags with the following definition: <figure <t>Flags: one octet of flags with the following definition: </t>
anchor="PEERINGSIDFLAGS" title="Peering SID TLV Flags Format"> <figure anchor="PEERINGSIDFLAGS">
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 <name>Peering SID TLV Flags Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6
7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L|B|P| Rsvd | |V|L|B|P| Rsvd |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="symbols"> </figure>
<t>V-Flag: Value flag. If set, then the SID carries a label <ul spacing="normal">
value. By default the flag is SET.</t> <li>V-Flag: Value Flag. If set, then the SID carries a label
value. By default, the flag is SET.</li>
<t>L-Flag: Local Flag. If set, then the value/index carried by <li>L-Flag: Local Flag. If set, then the value/index carried by
the SID has local significance. By default the flag is SET.</t> the SID has local significance. By default, the flag is SET.</li>
<li>B-Flag: Backup Flag. If set, the SID refers to a path that is
<t>B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection using fast reroute (FRR). The computation
eligible for protection using fast re-route (FRR). The of the backup forwarding path and its association with the BGP
computation of the backup forwarding path and its association Peering SID forwarding entry is implementation specific. <xref
with the BGP Peering SID forwarding entry is implementation target="RFC9087"
specific. <xref sectionFormat="of" section="3.6"/> discusses some of the possible
target="I-D.ietf-spring-segment-routing-central-epe"/> section ways of identifying backup paths for BGP Peering SIDs.</li>
3.6 discusses some of the possible ways of identifying backup <li>P-Flag: Persistent Flag: If set, the SID is persistently
paths for BGP Peering SIDs.</t>
<t>P-Flag: Persistent Flag: If set, the SID is persistently
allocated, i.e., the SID value remains consistent across router allocated, i.e., the SID value remains consistent across router
restart and session/interface flap.</t> restart and session/interface flap.</li>
<li>Rsvd bits: Reserved for future use and <bcp14>MUST</bcp14> be ze
<t>Rsvd bits: Reserved for future use and MUST be zero when ro when
originated and ignored when received.</t> originated and ignored when received.</li>
</list></t> </ul>
</li>
<t>Weight: 1 octet. The value represents the weight of the SID for <li>Weight: 1 octet. The value represents the weight of the SID for
the purpose of load balancing. An example use of the weight is the purpose of load balancing. An example use of the weight is
described in <xref target="RFC8402"/>.</t> described in <xref target="RFC8402" format="default"/>.</li>
<li>
<t>SID/Index/Label. According to the TLV length and to the V and L <t>SID/Index/Label. According to the TLV length and the V- and L-Flag
flags settings, it contains either: <list style="symbols"> settings, it contains either: </t>
<t>A 3 octet local label where the 20 rightmost bits are used <ul spacing="normal">
for encoding the label value. In this case, the V and L flags <li>A 3-octet local label where the 20 rightmost bits are used
MUST be SET.</t> for encoding the label value. In this case, the V- and L-Flags
<bcp14>MUST</bcp14> be SET.</li>
<t>A 4 octet index defining the offset in the Segment Routing <li>A 4-octet index defining the offset in the Segment Routing
Global Block (SRGB) <xref target="RFC8402"/> advertised by this Global Block (SRGB) <xref target="RFC8402" format="default"/>
router. In this case, the SRGB MUST be advertised using the advertised by this router. In this case, the SRGB
extensions defined in <xref <bcp14>MUST</bcp14> be advertised using the extensions defined in
target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t> <xref target="RFC9085" format="default"/>.</li>
</list></t> </ul>
</list></t> </li>
</ul>
<t>The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs <t>The values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs
SHOULD be persistent across router restart.</t> <bcp14>SHOULD</bcp14> be persistent across router restart.</t>
<t>When enabled for Egress Peer Engineering, the BGP router <bcp14>MUST</b
<t>When enabled for Egress Peer Engineering, the BGP router MUST include cp14> include
the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI
corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet
SID TLVs MAY be included in the BGP-LS Attribute for the BGP-LS Link SID TLVs <bcp14>MAY</bcp14> be included in the BGP-LS Attribute for the BG P-LS Link
NLRI.</t> NLRI.</t>
<t>Additional BGP-LS Link Attribute TLVs as defined in <xref target="RFC77
<t>Additional BGP-LS Link Attribute TLVs, as defined in <xref 52" format="default"/> <bcp14>MAY</bcp14> be included with the BGP-LS Link NLRI
target="RFC7752"/> MAY be included with the BGP-LS Link NLRI in order to in order to
advertise the characteristics of the peering link. E.g., one or more advertise the characteristics of the peering link, e.g., one or more
interface addresses (TLV 259 or TLV 261) of the underlying link(s) over interface addresses (TLV 259 or TLV 261) of the underlying link(s) over
which a multi-hop BGP peering session is setup may be included in the which a multi-hop BGP peering session is set up may be included in the
BGP-LS Attribute along with the PeerNode SID TLV.</t> BGP-LS Attribute along with the PeerNode SID TLV.</t>
<section anchor="PEERNODESID" numbered="true" toc="default">
<section anchor="PEERNODESID" title="Advertisement of the PeerNode SID"> <name>Advertisement of the PeerNode SID</name>
<t>The PeerNode SID TLV includes a SID associated with the BGP peer <t>The PeerNode SID TLV includes a SID associated with the BGP peer
node that is described by a BGP-LS Link NLRI as specified in <xref node that is described by a BGP-LS Link NLRI as specified in <xref targe
target="EPENLRI"/>.</t> t="EPENLRI" format="default"/>.</t>
<t>The PeerNode SID, at the BGP node advertising it, has the following <t>The PeerNode SID, at the BGP node advertising it, has the following
semantics (as defined in <xref target="RFC8402"/>):<list semantics (as defined in <xref target="RFC8402" format="default"/>):</t>
style="symbols"> <ul spacing="normal">
<t>SR operation: NEXT.</t> <li>SR operation: NEXT</li>
<li>Next-Hop: the connected peering node to which the segment is
<t>Next-Hop: the connected peering node to which the segment is associated</li>
associated.</t> </ul>
</list></t>
<t>The PeerNode SID is advertised with a BGP-LS Link NLRI, where: <t>The PeerNode SID is advertised with a BGP-LS Link NLRI, where:
<list style="symbols"> </t>
<t>Local Node Descriptors include:<list> <ul spacing="normal">
<t>Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress <li>
PE.</t> <t>Local Node Descriptors include:</t>
<ul spacing="normal">
<t>Local ASN (TLV 512).</t> <li>Local BGP Router-ID (TLV 516) of the BGP-EPE-enabled Egress
</list></t> PE</li>
<li>Local ASN (TLV 512)</li>
<t>Remote Node Descriptors include:<list> </ul>
<t>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in </li>
the BGP session)</t> <li>
<t>Remote Node Descriptors include:</t>
<t>Peer ASN (TLV 512).</t> <ul spacing="normal">
</list></t> <li>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in
the BGP session)</li>
<li>Peer ASN (TLV 512)</li>
</ul>
</li>
<li>
<t>Link Descriptors include the addresses used by the BGP session <t>Link Descriptors include the addresses used by the BGP session
encoded using TLVs as defined in <xref target="RFC7752"/>: <list> encoded using TLVs as defined in <xref target="RFC7752" format="defa
<t>IPv4 Interface Address (TLV 259) contains the BGP session ult"/>: </t>
IPv4 local address.</t> <ul spacing="normal">
<li>IPv4 Interface Address (TLV 259) contains the BGP session
<t>IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 local address.</li>
IPv4 peer address.</t> <li>IPv4 Neighbor Address (TLV 260) contains the BGP session
IPv4 peer address.</li>
<t>IPv6 Interface Address (TLV 261) contains the BGP session <li>IPv6 Interface Address (TLV 261) contains the BGP session
IPv6 local address.</t> IPv6 local address.</li>
<li>IPv6 Neighbor Address (TLV 262) contains the BGP session
<t>IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 peer address.</li>
IPv6 peer address.</t> </ul>
</list></t> </li>
<li>Link Attribute TLVs include the PeerNode SID TLV as defined in
<t>Link Attribute TLVs include the PeerNode SID TLV as defined in <xref target="PEERSID" format="default"/>.</li>
<xref target="PEERSID"/>.</t> </ul>
</list></t>
</section> </section>
<section anchor="PEERADJSID" numbered="true" toc="default">
<section anchor="PEERADJSID" title="Advertisement of the PeerAdj SID"> <name>Advertisement of the PeerAdj SID</name>
<t>The PeerAdj SID TLV includes a SID associated with the underlying <t>The PeerAdj SID TLV includes a SID associated with the underlying
link to the BGP peer node that is described by a BGP-LS Link NLRI as link to the BGP peer node that is described by a BGP-LS Link NLRI as
specified in <xref target="EPENLRI"/>.</t> specified in <xref target="EPENLRI" format="default"/>.</t>
<t>The PeerAdj SID, at the BGP node advertising it, has the following <t>The PeerAdj SID, at the BGP node advertising it, has the following
semantics (as defined in <xref target="RFC8402"/>):<list semantics (as defined in <xref target="RFC8402" format="default"/>):</t>
style="symbols"> <ul spacing="normal">
<t>SR operation: NEXT.</t> <li>SR operation: NEXT</li>
<li>Next-Hop: the interface peer address</li>
<t>Next-Hop: the interface peer address.</t> </ul>
</list></t> <t>The PeerAdj SID is advertised with a BGP-LS Link NLRI, where:</t>
<ul spacing="normal">
<t>The PeerAdj SID is advertised with a BGP-LS Link NLRI, where:<list <li>
style="symbols"> <t>Local Node Descriptors include:</t>
<t>Local Node Descriptors include:<list> <ul spacing="normal">
<t>Local BGP Router-ID (TLV 516) of the BGP-EPE enabled egress <li>Local BGP Router-ID (TLV 516) of the BGP-EPE-enabled Egress
PE.</t> PE</li>
<li>Local ASN (TLV 512)</li>
<t>Local ASN (TLV 512).</t> </ul>
</list></t> </li>
<li>
<t>Remote Node Descriptors include:<list> <t>Remote Node Descriptors include:</t>
<t>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in <ul spacing="normal">
the BGP session).</t> <li>Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in
the BGP session)</li>
<t>Peer ASN (TLV 512).</t> <li>Peer ASN (TLV 512)</li>
</list></t> </ul>
</li>
<t>Link Descriptors MUST include the following TLV, as defined in <li>
<xref target="RFC7752"/>: <list> <t>Link Descriptors <bcp14>MUST</bcp14> include the following TLV, a
<t>Link Local/Remote Identifiers (TLV 258) contains the s defined in
<xref target="RFC7752" format="default"/>: </t>
<ul spacing="normal">
<li>Link Local/Remote Identifiers (TLV 258) contains the
4-octet Link Local Identifier followed by the 4-octet Link 4-octet Link Local Identifier followed by the 4-octet Link
Remote Identifier. The value 0 is used by default when the Remote Identifier. The value 0 is used by default when the
link remote identifier is unknown.</t> link remote identifier is unknown.</li>
</list></t> </ul>
</li>
<t>Additional Link Descriptors TLVs, as defined in <xref <li>
target="RFC7752"/>, MAY also be included to describe the addresses <t>Additional Link Descriptors TLVs, as defined in <xref target="RFC
corresponding to the link between the BGP routers: <list> 7752" format="default"/>, <bcp14>MAY</bcp14> also be included to describe the ad
<t>IPv4 Interface Address (Sub-TLV 259) contains the address dresses
corresponding to the link between the BGP routers: </t>
<ul spacing="normal">
<li>IPv4 Interface Address (Sub-TLV 259) contains the address
of the local interface through which the BGP session is of the local interface through which the BGP session is
established.</t> established.</li>
<li>IPv6 Interface Address (Sub-TLV 261) contains the address
<t>IPv6 Interface Address (Sub-TLV 261) contains the address
of the local interface through which the BGP session is of the local interface through which the BGP session is
established.</t> established.</li>
<li>IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4
<t>IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address of the peer interface used by the BGP session.</li>
address of the peer interface used by the BGP session.</t> <li>IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6
address of the peer interface used by the BGP session.</li>
<t>IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 </ul>
address of the peer interface used by the BGP session.</t> </li>
</list></t> <li>Link Attribute TLVs include the PeerAdj SID TLV as defined in
<xref target="PEERSID" format="default"/>.</li>
<t>Link Attribute TLVs include the PeerAdj SID TLV as defined in </ul>
<xref target="PEERSID"/>.</t>
</list></t>
</section> </section>
<section anchor="PEERSETSID" numbered="true" toc="default">
<section anchor="PEERSETSID" title="Advertisement of the PeerSet SID "> <name>Advertisement of the PeerSet SID</name>
<t>The PeerSet SID TLV includes a SID that is shared amongst BGP peer <t>The PeerSet SID TLV includes a SID that is shared amongst BGP peer
nodes or the underlying links that are described by BGP-LS Link NLRI nodes or the underlying links that are described by BGP-LS Link NLRI
as specified in <xref target="EPENLRI"/>.</t> as specified in <xref target="EPENLRI" format="default"/>.</t>
<t>The PeerSet SID, at the BGP node advertising it, has the following <t>The PeerSet SID, at the BGP node advertising it, has the following
semantics (as defined in <xref target="RFC8402"/>):<list semantics (as defined in <xref target="RFC8402" format="default"/>):</t>
style="symbols"> <ul spacing="normal">
<t>SR operation: NEXT.</t> <li>SR operation: NEXT</li>
<li>Next-Hop: load-balance across any connected interface to any
<t>Next-Hop: load balance across any connected interface to any peer in the associated peer set</li>
peer in the associated peer set.</t> </ul>
</list></t>
<t>The PeerSet SID TLV containing the same SID value (encoded as <t>The PeerSet SID TLV containing the same SID value (encoded as
defined in <xref target="PEERSID"/>) is included in the BGP-LS defined in <xref target="PEERSID" format="default"/>) is included in the BGP-LS
Attribute for all of the BGP-LS Link NLRI corresponding to the Attribute for all of the BGP-LS Link NLRI corresponding to the
PeerNode or PeerAdj segments associated with the peer set.</t> PeerNode or PeerAdj segments associated with the peer set.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document defines:</t>
<ul>
<li>A new Protocol-ID: BGP. The code point is from the "BGP-LS Protocol-IDs" reg
istry.
</li>
<li>Two new TLVs: BGP-Router-ID and BGP Confederation Member. The code points
are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" registry.
</li>
<li>Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID, and PeerSet
SID. The code points are in the "BGP-LS Node Descriptor, Link Descriptor,
Prefix Descriptor, and Attribute TLVs" registry.
</li>
</ul>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANAPROT" numbered="true" toc="default">
<t>This document defines:<list style="hanging"> <name>New BGP-LS Protocol-ID</name>
<t>A new Protocol-ID: BGP. The codepoint is from the "BGP-LS <t>This document defines a new value in the registry "BGP-LS
Protocol-IDs" registry.</t> Protocol-IDs":</t>
<t>Two new TLVs: BGP-Router-ID and BGP Confederation Member. The <table anchor="BGPPROT">
codepoints are in the "BGP-LS Node Descriptor, Link Descriptor, <name>BGP-LS Protocol-ID</name>
Prefix Descriptor, and Attribute TLVs" registry.</t> <thead>
<tr>
<th>Protocol-ID</th>
<th>NLRI information source protocol</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>7</td>
<td>BGP</td>
<td>RFC 9086</td>
</tr>
<t>Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID and </tbody>
PeerSet SID. The codepoints are in the "BGP-LS Node Descriptor, Link </table>
Descriptor, Prefix Descriptor, and Attribute TLVs" registry.</t>
</list></t>
<section anchor="IANAPROT" title="New BGP-LS Protocol-ID">
<t>This document defines a new value in the registry "BGP-LS
Protocol-IDs":<figure align="center" anchor="BGPPROT"
title="BGP Protocol Codepoint">
<artwork align="center"><![CDATA[+----------------------------------
--------------------+
| Codepoint | Description | Status |
+------------------------------------------------------+
| 7 | BGP | Early Allocation by IANA |
+------------------------------------------------------+]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANANODEATTR" numbered="true" toc="default">
<section anchor="IANANODEATTR" <name>Node Descriptors and Link Attribute TLVs</name>
title="Node Descriptors and Link Attribute TLVs"> <t>This document defines five new TLVs in the registry "BGP-LS Node
<t>This document defines 5 new TLVs in the registry "BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs":<list style="symbols"> TLVs":</t>
<t>Two new node descriptor TLVs</t> <ul spacing="normal">
<li>Two new Node Descriptor TLVs</li>
<t>Three new link attribute TLVs</t> <li>Three new Link Attribute TLVs</li>
</list></t> </ul>
<t>All five of the new code points are in the same registry: "BGP-LS Nod
<t>All the new 5 codepoints are in the same registry: "BGP-LS Node e
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs".</t> TLVs".</t>
<t>The following new Node Descriptor TLVs are defined: </t>
<t>The following new Node Descriptors TLVs are defined: <figure <table anchor="DESCODE">
align="center" anchor="DESCCODE" <name>BGP-LS Descriptor TLV Code Points</name>
title="BGP-LS Descriptor TLVs Codepoints"> <thead>
<artwork align="center"><![CDATA[+---------------------------------- <tr>
---------------------------------+ <th>TLV Code Point</th>
| Codepoint | Description | Status | <th>Description</th>
+-------------------------------------------------------------------+ <th>Reference</th>
| 516 | BGP Router-ID | Early Allocation by IANA | </tr>
| 517 | BGP Confederation Member | Early Allocation by IANA | </thead>
+------------+------------------------------------------------------+]]></artwor <tbody>
k> <tr>
</figure></t> <td>516</td>
<td>BGP Router-ID</td>
<td>RFC 9086</td>
</tr>
<tr>
<td>517</td>
<td>BGP Confederation Member</td>
<td>RFC 9086</td>
</tr>
</tbody>
</table>
<t>The following new Link Attribute TLVs are defined: </t>
<table anchor="ATTRCODE">
<name>BGP-LS Attribute TLV Code Points</name>
<thead>
<tr>
<th>TLV Code Point</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>1101</td>
<td>PeerNode SID </td>
<td>RFC 9086</td>
</tr>
<tr>
<td>1102</td>
<td>PeerAdj SID</td>
<td>RFC 9086</td>
</tr>
<tr>
<td>1103</td>
<td>PeerSet SID</td>
<td>RFC 9086</td>
</tr>
</tbody>
</table>
<t>The following new Link Attribute TLVs are defined: <figure
align="center" anchor="ATTRCODE"
title="BGP-LS Attribute TLVs Codepoints">
<artwork align="center"><![CDATA[+----------------------------------
---------------------------------+
| Codepoint | Description | Status |
+-------------------------------------------------------------------+
| 1101 | PeerNode SID | Early Allocation by IANA |
| 1102 | PeerAdj SID | Early Allocation by IANA |
| 1103 | PeerSet SID | Early Allocation by IANA |
+------------+------------------------------------------------------+]]></artwor
k>
</figure></t>
</section> </section>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>Manageability 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 BGP-LS distribution <xref existing IGP topology information BGP-LS distribution <xref
target="RFC7752"/> by adding support for distribution of BGP peering target="RFC7752" format="default"/> by adding support for distribution
topology information. As such, the Manageability Considerations section of BGP peering topology information. As such, <xref target="RFC7752"
of <xref target="RFC7752"/> applies to these new extensions as well.</t> sectionFormat="of" section="6"/> (Manageability Considerations) applies
to these new extensions as well.</t>
<t>Specifically, the malformed Link-State NLRI and BGP-LS Attribute <t>Specifically, the malformed Link-State NLRI and BGP-LS Attribute
tests for syntactic checks in the Fault Management section of <xref tests for syntactic checks in <xref target="RFC7752" sectionFormat="of"
target="RFC7752"/> now apply to the TLVs defined in this document. The section="6.2.2"/> (Fault Management) now apply to the TLVs defined in
semantic or content checking for the TLVs specified in this document and this document. The semantic or content checking for the TLVs specified
their association with the BGP-LS NLRI types or their associated BGP-LS in this document and their association with the BGP-LS NLRI types or
Attributes is left to the consumer of the BGP-LS information (e.g., an their associated BGP-LS Attributes is left to the consumer of the BGP-LS
application or a controller) and not the BGP protocol.</t> information (e.g., an application or a controller) and not the BGP
protocol.</t>
<t>A consumer of the BGP-LS information retrieves this information from <t>A consumer of the BGP-LS information retrieves this information from
a BGP Speaker, over a BGP-LS session (refer Section 1 and 2 of <xref a BGP Speaker, over a BGP-LS session (refer to Sections <xref
target="RFC7752"/>). The handling of semantic or content errors by the target="RFC7752" sectionFormat="bare" section="1"/> and <xref
consumer would be dictated by the nature of its application usage and target="RFC7752" sectionFormat="bare" section="2"/> of <xref
hence is beyond the scope of this document. It may be expected that an target="RFC7752" format="default"/>). The handling of semantic or
error detected in the NLRI descriptor TLVs would result in that specific content errors by the consumer would be dictated by the nature of its
NLRI update being unusable and hence its update to be discarded along application usage and is hence beyond the scope of this document. It may
with an error log. While an error in Attribute TLVs would result in only be expected that an error detected in the NLRI Descriptor TLVs would
that specific attribute being discarded with an error log.</t> result in that specific NLRI update being unusable and hence its update
to be discarded along with an error log, whereas an error in Attribute
TLVs would result in only that specific attribute being discarded with
an error log.</t>
<t>The operator MUST be provided with the options of configuring, <t>The operator <bcp14>MUST</bcp14> be provided with the options of config uring,
enabling, and disabling the advertisement of each of the PeerNode SID, enabling, and disabling the advertisement of each of the PeerNode SID,
PeerAdj SID, and PeerSet SID as well as control of which information is PeerAdj SID, and PeerSet SID as well as control of which information is
advertised to which internal or external peer. This is not different advertised to which internal or external peer. This is not different
from what is required by a BGP speaker in terms of information from what is required by a BGP speaker in terms of information
origination and advertisement.</t> origination and advertisement.</t>
<t>BGP Peering Segments are associated with the normal BGP routing <t>BGP Peering Segments are associated with the normal BGP routing
peering sessions. However, the BGP peering information along with these peering sessions. However, the BGP peering information along with these
Peering Segments themselves are advertised via a distinct BGP-LS peering Peering Segments themselves are advertised via a distinct BGP-LS peering
session. It is expected that this isolation as described in <xref session. It is expected that this isolation as described in <xref
target="RFC7752"/> is followed when advertising BGP peering topology target="RFC7752" format="default"/> is followed when advertising BGP
information via BGP-LS.</t> peering topology information via BGP-LS.</t>
<t>BGP-EPE functionality enables the capability for instantiation of an <t>BGP-EPE functionality enables the capability for instantiation of an
SR path for traffic engineering a flow via an egress BGP router to a SR path for traffic engineering a flow via an egress BGP router to a
specific peer, bypassing the normal BGP best path routing for that flow specific peer, bypassing the normal BGP best-path routing for that flow
and any routing policies implemented in BGP on that egress BGP router. and any routing policies implemented in BGP on that egress BGP router.
As with any traffic engineering solution, the controller or application As with any traffic-engineering solution, the controller or application
implementing the policy needs to ensure that there is no looping or implementing the policy needs to ensure that there is no looping or
mis-routing of traffic. Traffic counters corresponding to the MPLS label misrouting of traffic. Traffic counters corresponding to the MPLS label
of the BGP Peering SID on the router would indicate the traffic being of the BGP Peering SID on the router would indicate the traffic being
forwarded based on the specific EPE path. Monitoring these counters and forwarded based on the specific EPE path. Monitoring these counters and
the flows hitting the corresponding MPLS forwarding entry would help the flows hitting the corresponding MPLS forwarding entry would help
identify issues, if any, with traffic engineering over the EPE paths. identify issues, if any, with traffic engineering over the EPE paths.
Errors in the encoding or decoding of the SR information in the TLVs Errors in the encoding or decoding of the SR information in the TLVs
defined in this document may result in the unavailability of such defined in this document may result in the unavailability of such
information to a Centralized EPE Controller or incorrect information information to a Centralized EPE Controller or incorrect information
being made available to it. This may result in the controller not being being made available to it. This may result in the controller not being
able to perform the desired SR based optimization functionality or to able to perform the desired SR-based optimization functionality or
perform it in an unexpected or inconsistent manner. The handling of such performing it in an unexpected or inconsistent manner. The handling of
errors by applications like such a controller may be implementation such errors by applications like such a controller may be implementation
specific and out of scope of this document.</t> specific and out of scope of this document.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t><xref target="RFC7752"/> defines BGP-LS NLRI to which the extensions <t><xref target="RFC7752" format="default"/> defines BGP-LS NLRI to
defined in this document apply. The Security Considerations section of which the extensions defined in this document apply. <xref
<xref target="RFC7752"/> also applies to these extensions. The target="RFC7752" sectionFormat="of" section="8"/> also applies to these ex
procedures and new TLVs defined in this document, by themselves, do not tensions. The procedures and new
affect the BGP-LS security model discussed in <xref TLVs defined in this document, by themselves, do not affect the BGP-LS
target="RFC7752"/>.</t> security model discussed in <xref target="RFC7752"
format="default"/>.</t>
<t>BGP-EPE enables engineering of traffic when leaving the <t>BGP-EPE enables engineering of traffic when leaving the
administrative domain via an egress BGP router. Therefore precaution is administrative domain via an egress BGP router. Therefore, precaution is
necessary to ensure that the BGP peering information collected via necessary to ensure that the BGP peering information collected via
BGP-LS is limited to specific consumers in a secure manner. Segment BGP-LS is limited to specific consumers in a secure manner. Segment
Routing operates within a trusted domain <xref target="RFC8402"/> and Routing operates within a trusted domain <xref target="RFC8402" format="de fault"/>, and
its security considerations also apply to BGP Peering Segments. The its security considerations also apply to BGP Peering Segments. The
BGP-EPE policies are expected to be used entirely within this trusted SR BGP-EPE policies are expected to be used entirely within this trusted SR
domain (e.g., between multiple AS/domains within a single provider domain (e.g., between multiple AS/domains within a single provider
network).</t> network).</t>
<t>The isolation of BGP-LS peering sessions is also required to ensure <t>The isolation of BGP-LS peering sessions is also required to ensure
that BGP-LS topology information (including the newly added BGP peering that BGP-LS topology information (including the newly added BGP peering
topology) is not advertised to an external BGP peering session outside topology) is not advertised to an external BGP peering session outside
an administrative domain.</t> an administrative domain.</t>
</section> </section>
<section anchor="Contributors" title="Contributors"> </middle>
<figure> <back>
<artwork><![CDATA[Mach (Guoyi) Chen
Huawei Technologies
China
Email: mach.chen@huawei.com]]></artwork> <displayreference target="I-D.ietf-spring-segment-routing-policy" to="SR-POLICY"
</figure> />
<figure> <displayreference target="I-D.ietf-idr-bgpls-srv6-ext" to="BGPLS-SRV6"/>
<artwork><![CDATA[Acee Lindem
Cisco Systems Inc.
US
Email: acee@cisco.com]]></artwork> <references>
</figure> <name>References</name>
</section> <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6286.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5065.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<section anchor="Acknowledgements" title="Acknowledgements"> <reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
<t>The authors would like to thank Jakob Heitz, Howard Yang, Hannes <front>
Gredler, Peter Psenak, Arjun Sreekantiah and Bruno Decraene for their <title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Rout
feedback and comments. Susan Hares helped in improving the clarity of ing</title>
the document with her substantial contributions during her shepherd's
review. 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>
<back> <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<references title="Normative References"> <organization />
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211 </author>
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.628 <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='edit
6.xml"?> or'>
<organization />
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.506 <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
5.xml"?> <organization />
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.840 <author initials='H' surname='Gredler' fullname='Hannes Gredler'>
2.xml"?> <organization />
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.775 <author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
2.xml"?> <organization />
</author>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.817 4.xml"?> <date month="August" year="2021"/>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?> </front>
</references> <seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>
<references title="Informative References"> </references>
<?rfc include="reference.I-D.ietf-spring-segment-routing-central-epe.xml"?
>
<?rfc include="reference.I-D.ietf-spring-segment-routing-policy.xml"?> <references>
<name>Informative References</name>
<?rfc include="reference.I-D.dawra-idr-bgpls-srv6-ext.xml"?> <reference anchor='RFC9087' target='https://www.rfc-editor.org/info/rfc9087'>
<front>
<title>Segment Routing Centralized BGP Egress Peer Engineering</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role='edito
r'>
<organization />
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<author initials='G' surname='Dawra' fullname='Gaurav Dawra' role='editor'>
<organization />
</author>
<author initials='E' surname='Aries' fullname='Ebben Aries'>
<organization />
</author>
<author initials='D' surname='Afanasiev' fullname='Dmitry Afanasiev'>
<organization />
</author>
<date month="August" year="2021"/>
</front>
<seriesInfo name="RFC" value="9087"/>
<seriesInfo name="DOI" value="10.17487/RFC9087"/>
</reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-sp
ring-segment-routing-policy-13.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-id
r-bgpls-srv6-ext.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Jakob Heitz"/>,
<contact fullname="Howard Yang"/>, <contact fullname="Hannes
Gredler"/>, <contact fullname="Peter Psenak"/>, <contact fullname="Arjun
Sreekantiah"/>, and <contact fullname="Bruno Decraene"/> for their
feedback and comments. <contact fullname="Susan Hares"/> helped in improvi
ng the clarity of
the document with her substantial contributions during her shepherd's
review. The authors would also like to thank <contact fullname="Alvaro Ret
ana"/> for his
extensive review and comments, which helped correct issues and improve
the document.</t>
</section>
<section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>China
</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author fullname="Acee Lindem" initials="A" surname="Lindem">
<organization>Cisco Systems Inc.</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>United States of America
</country>
</postal>
<email>acee@cisco.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 141 change blocks. 
601 lines changed or deleted 726 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/