rfc9087xml2.original.xml   rfc9087.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc tocindent="yes"?> docName="draft-ietf-spring-segment-routing-central-epe-10" number="9087"
<?rfc symrefs="yes"?> ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
<?rfc sortrefs="yes"?> category="info" consensus="true" xml:lang="en" tocInclude="true"
<?rfc comments="yes"?> tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-ietf-spring-segment-routing-central-epe-10"
ipr="trust200902">
<front> <front>
<title abbrev="Segment Routing Centralized EPE">Segment Routing <title abbrev="Segment Routing Centralized EPE">Segment Routing
Centralized BGP Egress Peer Engineering</title> Centralized BGP Egress Peer Engineering</title>
<seriesInfo name="RFC" value="9087"/>
<author fullname="Clarence Filsfils" initials="C." role="editor" <author fullname="Clarence Filsfils" initials="C." role="editor" surname="Fi
surname="Filsfils"> lsfils">
<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>BE</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi"> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Gaurav Dawra" initials="G." role="editor" surname="Dawra">
<author fullname="Gaurav Dawra" initials="G." role="editor"
surname="Dawra">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>gdawra.ietf@gmail.com</email> <email>gdawra.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Ebben Aries" initials="E." surname="Aries"> <author fullname="Ebben Aries" initials="E." surname="Aries">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1133 Innovation Way</street> <street>1133 Innovation Way</street>
<city>Sunnyvale</city> <city>Sunnyvale</city>
<region>CA</region>
<code>CA 94089</code> <code>94089</code>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>exa@juniper.net</email> <email>exa@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev"> <author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev">
<organization>Yandex</organization> <organization>Yandex</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>Russian Federation</country>
<country>RU</country>
</postal> </postal>
<email>fl0w@yandex-team.ru</email> <email>fl0w@yandex-team.ru</email>
</address> </address>
</author> </author>
<date year="2021" month="August" />
<date year="2017"/> <area>RTG</area>
<workgroup>SPRING</workgroup>
<workgroup>Network Working Group</workgroup>
<abstract> <abstract>
<t>Segment Routing (SR) leverages source routing. A node steers a packet <t>Segment Routing (SR) leverages source routing. A node steers a packet
through a controlled set of instructions, called segments, by prepending through a controlled set of instructions, called segments, by prepending
the packet with an SR header. A segment can represent any instruction the packet with an SR header. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through any topological or service based. SR allows for the enforcement of a flow
topological path while maintaining per-flow state only at the ingress through any topological path while maintaining per-flow state only at
node of the SR domain.</t> the ingress node of the SR domain.</t>
<t>The Segment Routing architecture can be directly applied to the MPLS <t>The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires a minor data plane with no change on the forwarding plane. It requires a minor
extension to the existing link-state routing protocols.</t> extension to the existing link-state routing protocols.</t>
<t>This document illustrates the application of Segment Routing to solve <t>This document illustrates the application of Segment Routing to solve
the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based
BGP-EPE solution allows a centralized (Software Defined Network, SDN) BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN )
controller to program any egress peer policy at ingress border routers controller to program any egress peer policy at ingress border routers
or at hosts within the domain.</t> or at hosts within the domain.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>The document is structured as follows: <list style="symbols"> <name>Introduction</name>
<t><xref target="INTRO"/> states the BGP-EPE problem statement and <t>The document is structured as follows: </t>
provides the key references.</t>
<t><xref target="BGPSEGMENTS"/> defines the different BGP Peering <ul>
Segments and the semantic associated to them.</t>
<t><xref target="TOPOBGPLS"/> describes the automated allocation of <li><xref target="INTRO" format="default"/> states the BGP-EPE problem statement
BGP Peering Segment-IDs (SIDs) by the BGP-EPE enabled egress border and provides the key references.
router and the automated signaling of the external peering topology </li>
and the related BGP Peering SID&rsquo;s to the collector <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>.</t>
<t><xref target="BGPPECTRL"/> overviews the components of a <li><xref target="BGPSEGMENTS" format="default"/> defines the different BGP
centralized BGP-EPE controller. The definition of the BGP-EPE Peering Segments and the semantic associated to them.
controller is outside the scope of this document.</t> </li>
<t><xref target="PROGRINPUTPOL"/> overviews the methods that could <li><xref target="TOPOBGPLS" format="default"/> describes the automated
be used by the centralized BGP-EPE controller to implement a BGP-EPE allocation of BGP Peering Segment-IDs (SIDs) by the BGP-EPE-enabled egress
policy at an ingress border router or at a source host within the border router and the automated signaling of the external peering topology and
domain. The exhaustive definition of all the means to program an the related BGP Peering SIDs to the collector <xref
BGP-EPE input policy is outside the scope of this document.</t> target="RFC9086" format="default"/>.
</list></t> </li>
<li><xref target="BGPPECTRL" format="default"/> overviews the components of a
centralized BGP-EPE controller. The definition of the BGP-EPE controller is
outside the scope of this document.
</li>
<li><xref target="PROGRINPUTPOL" format="default"/> overviews the methods that
could be used by the centralized BGP-EPE controller to implement a BGP-EPE
policy at an ingress border router or at a source host within the domain. The
exhaustive definition of all the means to program a BGP-EPE input policy is
outside the scope of this document.
</li>
</ul>
<t>For editorial reasons, the solution is described with IPv6 addresses <t>For editorial reasons, the solution is described with IPv6 addresses
and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS
SIDs and also to IPv6 with native IPv6 SIDs.</t> SIDs and also to IPv6 with native IPv6 SIDs.</t>
<section anchor="PROBSTATE" numbered="true" toc="default">
<section anchor="PROBSTATE" title="Problem Statement"> <name>Problem Statement</name>
<t>The BGP-EPE problem statement is defined in <xref <t>The BGP-EPE problem statement is defined in <xref target="RFC7855" fo
target="RFC7855"/>.</t> rmat="default"/>.</t>
<t>A centralized controller should be able to instruct an ingress <t>A centralized controller should be able to instruct an ingress
Provider Edge router (PE) or a content source within the domain to use Provider Edge (PE) router or a content source within the domain to use
a specific egress PE and a specific external interface/neighbor to a specific egress PE and a specific external interface/neighbor to
reach a particular destination.</t> reach a particular destination.</t>
<t>Let's call this solution "BGP-EPE" for "BGP Egress Peer <t>Let's call this solution "BGP-EPE" for "BGP Egress Peer
Engineering". The centralized controller is called the &ldquo;BGP-EPE Engineering". The centralized controller is called the "BGP-EPE
Controller&rdquo;. The egress border router where the BGP-EPE traffic controller". The egress border router where the BGP-EPE traffic
steering functionality is implemented is called a BGP-EPE enabled steering functionality is implemented is called a BGP-EPE-enabled
border router. The input policy programmed at an ingress border router border router. The input policy programmed at an ingress border router
or at a source host is called a BGP-EPE policy.</t> or at a source host is called a BGP-EPE policy.</t>
<t>The requirements that have motivated the solution described in this <t>The requirements that have motivated the solution described in this
document are listed here below:<list style="symbols"> document are listed here below:</t>
<t>The solution MUST apply to the Internet use-case where the <ul spacing="normal">
Internet routes are assumed to use IPv4 unlabeled or IPv6
unlabeled. It is not required to place the Internet routes in a
VRF and allocate labels on a per route, or on a per-path
basis.</t>
<t>The solution MUST support any deployed iBGP schemes (RRs,
confederations or iBGP full meshes).</t>
<t>The solution MUST be applicable to both routers with external
and internal peers.</t>
<t>The solution should minimize the need for new BGP capabilities
at the ingress PEs.</t>
<t>The solution MUST accommodate an ingress BGP-EPE policy at an <li>The solution <bcp14>MUST</bcp14> apply to the Internet use case
ingress PE or directly at a source within the domain.</t> where the Internet routes are assumed to use IPv4 unlabeled or IPv6
unlabeled.
<t>The solution MAY support automated Fast Reroute (FRR) and fast It is not required to place the Internet routes in a VPN Routing and
convergence mechanisms.</t> Forwarding (VRF) instance and allocate labels on a per-route or
</list></t> per-path basis.
</li>
<li>The solution <bcp14>MUST</bcp14> support any deployed Internal BGP
(iBGP)
schemes (Route Reflectors (RRs),
confederations, or iBGP full meshes).</li>
<li>The solution <bcp14>MUST</bcp14> be applicable to both routers wit
h external
and internal peers.</li>
<li>The solution should minimize the need for new BGP capabilities
at the ingress PEs.</li>
<li>The solution <bcp14>MUST</bcp14> accommodate an ingress BGP-EPE po
licy at an
ingress PE or directly at a source within the domain.</li>
<li>The solution <bcp14>MAY</bcp14> support automated Fast Reroute (FR
R) and fast
convergence mechanisms.</li>
</ul>
<t>The following reference diagram is used throughout this <t>The following reference diagram is used throughout this
document.</t> document.</t>
<figure anchor="REFDIAGRAMFIG">
<figure anchor="REFDIAGRAMFIG" title="Reference Diagram"> <name>Reference Diagram</name>
<artwork>+---------+ +------+ <artwork name="" type="" align="left" alt=""><![CDATA[+---------+
+------+
| | | | | | | |
| H B------D G | H B------D G
| | +---/| AS 2 |\ +------+ | | +---/| AS 2 |\ +------+
| |/ +------+ \ | |---L/8 | |/ +------+ \ | |---L/8
A AS1 C---+ \| | A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8 | |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+ | | \\ +-E |/ +------+
| X | \\ | K | X | \\ | K
| | +===F AS 3 | | | +===F AS 3 |
+---------+ +------+ +---------+ +------+
</artwork> ]]></artwork>
</figure> </figure>
<t>IP addressing:</t>
<ul spacing="normal">
<li>C's interface to D: 2001:db8:cd::c/64, D's
interface: 2001:db8:cd::d/64</li>
<li>C's interface to E: 2001:db8:ce::c/64, E's
interface: 2001:db8:ce::e/64</li>
<li>C's upper interface to F: 2001:db8:cf1::c/64, F's
interface: 2001:db8:cf1::f/64</li>
<li>C's lower interface to F: 2001:db8:cf2::c/64, F's
interface: 2001:db8:cf2::f/64</li>
<li>BGP router-ID of C: 192.0.2.3</li>
<li>BGP router-ID of D: 192.0.2.4</li>
<li>BGP router-ID of E: 192.0.2.5</li>
<li>BGP router-ID of F: 192.0.2.6</li>
<li>Loopback of F used for External BGP (eBGP) multi-hop peering to
C: 2001:db8:f::f/128</li>
<li>C's loopback is 2001:db8:c::c/128 with SID 64</li>
</ul>
<t>C's BGP peering:</t>
<ul spacing="normal">
<li>Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)</li>
<li>Single-hop eBGP peering with neighbor 2001:db8:ce::e (E)</li>
<li>Multi-hop eBGP peering with F on IP address 2001:db8:f::f
(F)</li>
</ul>
<t>C's resolution of the multi-hop eBGP session to F:</t>
<ul spacing="normal">
<li>Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f</li>
<li>Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f</li>
</ul>
<t>C is configured with a local policy that defines a BGP PeerSet as the
set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F).</t>
<t>X is the BGP-EPE controller within the AS1 domain.</t>
<t>H is a content source within the AS1 domain.</t>
</section>
<t>IP addressing:<list style="symbols"> <section>
<t>C&rsquo;s interface to D: 2001:db8:cd::c/64, D&rsquo;s <name>Requirements Language</name>
interface: 2001:db8:cd::d/64</t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>C&rsquo;s interface to E: 2001:db8:ce::c/64, E&rsquo;s "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
interface: 2001:db8:ce::e/64</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>C&rsquo;s upper interface to F: 2001:db8:cf1::c/64, F&rsquo;s "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
interface: 2001:db8:cf1::f/64</t> to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
<t>C&rsquo;s lower interface to F: 2001:db8:cf2::c/64, F&rsquo;s as shown here.
interface: 2001:db8:cf2::f/64</t> </t>
<t>BGP router-ID of C: 192.0.2.3</t>
<t>BGP router-ID of D: 192.0.2.4</t>
<t>BGP router-ID of E: 192.0.2.5</t>
<t>BGP router-ID of F: 192.0.2.6</t>
<t>Loopback of F used for eBGP multi-hop peering to C:
2001:db8:f::f/128</t>
<t>C&rsquo;s loopback is 2001:db8:c::c/128 with SID 64</t>
</list></t>
<t>C&rsquo;s BGP peering:<list style="symbols">
<t>Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)</t>
<t>Single-hop eBGP peering with neighbor 2001:db8:ce::e (E)</t>
<t>Multi-hop eBGP peering with F on IP address 2001:db8:f::f
(F)</t>
</list></t>
<t>C&rsquo;s resolution of the multi-hop eBGP session to F:<list
style="symbols">
<t>Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f</t>
<t>Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f</t>
</list></t>
<t>C is configured with local policy that defines a BGP PeerSet as the
set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F)</t>
<t>X is the BGP-EPE controller within AS1 domain.</t>
<t>H is a content source within AS1 domain.</t> </section>
</section>
</section> </section>
<section anchor="BGPSEGMENTS" numbered="true" toc="default">
<section anchor="BGPSEGMENTS" title="BGP Peering Segments"> <name>BGP Peering Segments</name>
<t>As defined in <xref target="I-D.ietf-spring-segment-routing"/>, <t>As defined in <xref target="RFC8402" format="default"/>, certain
certain segments are defined by a BGP-EPE capable node and corresponding segments are defined by a BGP-EPE-capable node and correspond to their
to its attached peers. These segments are called BGP peering segments or attached peers. These segments are called BGP Peering Segments or BGP
BGP Peering SIDs. They enable the expression of source-routed Peering SIDs. They enable the expression of source-routed inter-domain
inter-domain paths.</t> paths.</t>
<t>An ingress border router of an AS may compose a list of segments to <t>An ingress border router of an AS may compose a list of segments to
steer a flow along a selected path within the AS, towards a selected steer a flow along a selected path within the AS, towards a selected
egress border router C of the AS and through a specific peer. At egress border router C of the AS and through a specific peer. At
minimum, a BGP Egress Peering Engineering policy applied at an ingress minimum, a BGP Egress Peer Engineering policy applied at an ingress
EPE involves two segments: the Node SID of the chosen egress EPE and EPE involves two segments: the Node SID of the chosen egress EPE and
then the BGP Peering Segment for the chosen egress EPE peer or peering then the BGP Peering Segment for the chosen egress EPE peer or peering
interface.</t> interface.</t>
<t><xref target="RFC8402" format="default"/> defines three types
<t><xref target="I-D.ietf-spring-segment-routing"/> defines three types of BGP Peering Segments/SIDs: PeerNode SID, PeerAdj SID, and PeerSet
of BGP peering segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet
SID.</t> SID.</t>
<t>A Peer Node Segment is a segment describing a peer, including the SID <ul empty="true">
(PeerNode SID) allocated to it.</t> <li>
<dl newline="false">
<t>A Peer Adjacency Segment is a segment describing a link, including
the SID (PeerAdj SID) allocated to it.</t>
<t>A Peer Set Segment is a segment describing a link or a node that is <dt>Peer Node Segment:
part of the set, including the SID (PeerSet SID) allocated to the </dt>
set.</t> <dd>A segment describing a peer, including the SID (PeerNode SID) allocated to i
</section> t
</dd>
<section anchor="TOPOBGPLS" <dt>Peer Adjacency Segment:
title="Distribution of Topology and TE Information using BGP-LS"> </dt>
<t>In ships-in-the-night mode with respect to the pre-existing iBGP <dd>A segment describing a link, including the SID (PeerAdj SID) allocated to it
design, a BGP-LS <xref target="RFC7752"/> session is established between </dd>
the BGP-EPE enabled border router and the BGP-EPE controller.</t>
<t>As a result of its local configuration and according to the behavior <dt>Peer Set Segment:
described in <xref target="I-D.ietf-idr-bgpls-segment-routing-epe"/>, </dt>
node C allocates the following BGP Peering Segments (<xref <dd>A segment describing a link or a node that is part of the set, including
target="I-D.ietf-spring-segment-routing"/>):<list style="symbols"> the SID (PeerSet SID) allocated to the set
<t>A PeerNode segment for each of its defined peer (D: 1012, E: 1022 </dd>
and F: 1052).</t>
<t>A PeerAdj segment for each recursing interface to a multi-hop </dl>
peer (e.g.: the upper and lower interfaces from C to F in figure </li>
1).</t> </ul>
<t>A PeerSet segment to the set of peers (E and F). In this case the </section>
<section anchor="TOPOBGPLS" numbered="true" toc="default">
<name>Distribution of Topology and TE Information Using BGP-LS</name>
<t>In ships-in-the-night mode with respect to the pre-existing iBGP
design, a Border Gateway Protocol - Link State (BGP-LS) <xref
target="RFC7752" format="default"/> session is established between the
BGP-EPE-enabled border router and the BGP-EPE controller.</t>
<t>As a result of its local configuration and according to the behavior
described in <xref target="RFC9086" format="default"/>,
Node C allocates the following BGP Peering Segments <xref
target="RFC8402" format="default"/>:</t>
<ul spacing="normal">
<li>A PeerNode segment for each of its defined peers (D: 1012, E: 1022
and F: 1052).</li>
<li>A PeerAdj segment for each recursing interface to a multi-hop
peer (e.g., the upper and lower interfaces from C to F in <xref
target="REFDIAGRAMFIG"/>).</li>
<li>A PeerSet segment to the set of peers (E and F). In this case, the
PeerSet represents a set of peers (E, F) belonging to the same AS PeerSet represents a set of peers (E, F) belonging to the same AS
(AS 3).</t> (AS 3).</li>
</list></t> </ul>
<t>C programs its forwarding table accordingly:</t>
<t>C programs its forwarding table accordingly:<figure
suppress-title="true">
<artwork>Incoming Outgoing
Label Operation Interface
1012 POP link to D
1022 POP link to E
1032 POP upper link to F
1042 POP lower link to F
1052 POP load balance on any link to F
1060 POP load balance on any link to E or to F
</artwork>
</figure></t>
<t>C signals the related BGP-LS NLRI&rsquo;s to the BGP-EPE controller.
Each such BGP-LS route is described in the following subsections
according to the encoding details defined in <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>.</t>
<section anchor="PEERNODED" title="PeerNode SID to D">
<t>Descriptors: <list style="symbols">
<t>Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000</t>
<t>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, <table anchor="c-table">
AS2</t>
<t>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor <thead>
Address): 2001:db8:cd::c, 2001:db8:cd::d</t> <tr>
</list></t> <th>Incoming Label</th>
<th>Operation</th>
<th>Outgoing Interface</th>
</tr>
</thead>
<tbody>
<tr>
<td>1012</td>
<td>POP</td>
<td>link to D</td>
</tr>
<tr>
<td>1022</td>
<td>POP</td>
<td>link to E</td>
</tr>
<tr>
<td>1032</td>
<td>POP</td>
<td>upper link to F</td>
</tr>
<tr>
<td>1042</td>
<td>POP</td>
<td>lower link to F</td>
</tr>
<tr>
<td>1052</td>
<td>POP</td>
<td>load balance on any link to F</td>
</tr>
<tr>
<td>1060</td>
<td>POP</td>
<td>load balance on any link to E or to F</td>
</tr>
</tbody>
</table>
<t>Attributes: <list style="symbols"> <t>C signals each related BGP-LS instance of Network Layer Reachability
<t>PeerNode SID: 1012</t> Information (NLRI) to the BGP-EPE controller. Each such BGP-LS route is
</list></t> described in the following subsections according to the encoding details
defined in <xref target="RFC9086" format="default"/>.</t>
<section anchor="PEERNODED" numbered="true" toc="default">
<name>PeerNode SID to D</name>
<t>Descriptors: </t>
<ul spacing="normal">
<li>Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000</li>
<li>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4,
AS2</li>
<li>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
Address): 2001:db8:cd::c, 2001:db8:cd::d</li>
</ul>
<t>Attributes: </t>
<ul spacing="normal">
<li>PeerNode SID: 1012</li>
</ul>
</section> </section>
<section anchor="PEERNODEE" numbered="true" toc="default">
<section anchor="PEERNODEE" title="PeerNode SID to E"> <name>PeerNode SID to E</name>
<t>Descriptors: <list style="symbols"> <t>Descriptors: </t>
<t>Local Node Descriptors (BGP router-ID, ASN, BGP-LS <ul spacing="normal">
Identifier)): 192.0.2.3, AS1, 1000</t> <li>Local Node Descriptors (BGP router-ID, ASN, BGP-LS
Identifier): 192.0.2.3, AS1, 1000</li>
<t>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, <li>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5,
AS3</t> AS3</li>
<li>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
<t>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:ce::c, 2001:db8:ce::e</li>
Address): 2001:db8:ce::c, 2001:db8:ce::e</t> </ul>
</list></t> <t>Attributes: </t>
<ul spacing="normal">
<t>Attributes: <list style="symbols"> <li>PeerNode SID: 1022</li>
<t>PeerNode SID: 1022</t> <li>PeerSetSID: 1060</li>
<li>Link Attributes: see <xref target="RFC7752" sectionFormat="of"
<t>PeerSetSID: 1060</t> section="3.3.2"/></li>
</ul>
<t>Link Attributes: see section 3.3.2 of <xref
target="RFC7752"/></t>
</list></t>
</section> </section>
<section anchor="PEERNODEF" numbered="true" toc="default">
<section anchor="PEERNODEF" title="PeerNode SID to F"> <name>PeerNode SID to F</name>
<t>Descriptors: <list style="symbols"> <t>Descriptors: </t>
<t>Local Node Descriptors (BGP router-ID, ASN, BGP-LS <ul spacing="normal">
Identifier)): 192.0.2.3, AS1, 1000</t> <li>Local Node Descriptors (BGP router-ID, ASN, BGP-LS
Identifier): 192.0.2.3, AS1, 1000</li>
<t>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, <li>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6,
AS3</t> AS3</li>
<li>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
<t>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:c::c, 2001:db8:f::f</li>
Address): 2001:db8:c::c, 2001:db8:f::f</t> </ul>
</list></t> <t>Attributes: </t>
<ul spacing="normal">
<t>Attributes: <list style="symbols"> <li>PeerNode SID: 1052</li>
<t>PeerNode SID: 1052</t> <li>PeerSetSID: 1060</li>
</ul>
<t>PeerSetSID: 1060</t>
</list></t>
</section> </section>
<section anchor="PEERNODEFLINK1" numbered="true" toc="default">
<section anchor="PEERNODEFLINK1" title="First PeerAdj to F"> <name>First PeerAdj to F</name>
<t>Descriptors: <list style="symbols"> <t>Descriptors: </t>
<t>Local Node Descriptors (BGP router-ID, ASN, BGP-LS <ul spacing="normal">
Identifier)): 192.0.2.3, AS1, 1000</t> <li>Local Node Descriptors (BGP router-ID, ASN, BGP-LS
Identifier): 192.0.2.3, AS1, 1000</li>
<t>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, <li>Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6,
AS3</t> AS3</li>
<li>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
<t>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 2001:db8:cf1::c, 2001:db8:cf1::f</li>
Address): 2001:db8:cf1::c, 2001:db8:cf1::f</t> </ul>
</list></t> <t>Attributes: </t>
<ul spacing="normal">
<t>Attributes: <list style="symbols"> <li>PeerAdj-SID: 1032</li>
<t>PeerAdj-SID: 1032</t> <li>Link Attributes: see <xref target="RFC7752"
sectionFormat="of" section="3.3.2"/></li>
<t>LinkAttributes: see section 3.3.2 of <xref </ul>
target="RFC7752"/></t>
</list></t>
</section> </section>
<section anchor="PEERNODEFLINK2" numbered="true" toc="default">
<name>Second PeerAdj to F</name>
<t>Descriptors: </t>
<section anchor="PEERNODEFLINK2" title="Second PeerAdj to F"> <ul spacing="normal">
<t>Descriptors: <list style="symbols"> <li>Local Node Descriptors (BGP router-ID, ASN, BGP-LS
<t>Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 192.0.2.3 , AS1, 1000</li>
Identifier)): 192.0.2.3 , AS1</t> <li>Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6,
AS3</li>
<t>Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, <li>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor
AS3</t> Address): 2001:db8:cf2::c, 2001:db8:cf2::f</li>
</ul>
<t>Link Descriptors (IPv6 Interface Address, IPv6 Neighbor <t>Attributes: </t>
Address): 2001:db8:cf2::c, 2001:db8:cf2::f</t> <ul spacing="normal">
</list></t> <li>PeerAdj-SID: 1042</li>
<li>Link Attributes: see <xref target="RFC7752" sectionFormat="of"
<t>Attributes: <list style="symbols"> section="3.3.2"/></li>
<t>PeerAdj-SID: 1042</t> </ul>
<t>LinkAttributes: see section 3.3.2 of <xref
target="RFC7752"/></t>
</list></t>
</section> </section>
<section anchor="FRR" numbered="true" toc="default">
<section anchor="FRR" title="Fast Reroute (FRR)"> <name>Fast Reroute (FRR)</name>
<t>A BGP-EPE enabled border router MAY allocate a FRR backup entry on <t>A BGP-EPE-enabled border router <bcp14>MAY</bcp14> allocate an FRR ba
a per BGP Peering SID basis. One example is as follows:<list ckup entry on
style="symbols"> a per-BGP-Peering-SID basis. One example is as follows:</t>
<t>PeerNode SID<list style="numbers"> <ul spacing="normal">
<t>If multi-hop, backup via the remaining PeerADJ SIDs (if <li>
available) to the same peer.</t> <t>PeerNode SID</t>
<ol spacing="normal" type="1">
<t>Else backup via another PeerNode SID to the same AS.</t> <li>If multi-hop, back up via the remaining PeerADJ SIDs (if
available) to the same peer.</li>
<t>Else pop the PeerNode SID and perform an IP lookup.</t> <li>Else, back up via another PeerNode SID to the same AS.</li>
</list></t> <li>Else, pop the PeerNode SID and perform an IP lookup.</li>
</ol>
<t>PeerAdj SID<list style="numbers"> </li>
<t>If to a multi-hop peer, backup via the remaining PeerADJ <li>
SIDs (if available) to the same peer.</t> <t>PeerAdj SID</t>
<ol spacing="normal" type="1">
<t>Else backup via a PeerNode SID to the same AS.</t> <li>If to a multi-hop peer, back up via the remaining PeerADJ
SIDs (if available) to the same peer.</li>
<t>Else pop the PeerNode SID and perform an IP lookup.</t> <li>Else, back up via a PeerNode SID to the same AS.</li>
</list></t> <li>Else, pop the PeerNode SID and perform an IP lookup.</li>
</ol>
<t>PeerSet SID<list style="numbers"> </li>
<t>Backup via remaining PeerNode SIDs in the same PeerSet.</t> <li>
<t>PeerSet SID</t>
<t>Else pop the PeerNode SID and IP lookup.</t> <ol spacing="normal" type="1">
</list></t> <li>Back up via remaining PeerNode SIDs in the same PeerSet.</li>
</list></t> <li>Else, pop the PeerNode SID and IP lookup.</li>
</ol>
</li>
</ul>
<t>Let's illustrate different types of possible backups using the <t>Let's illustrate different types of possible backups using the
reference diagram and considering the Peering SIDs allocated by C.</t> reference diagram and considering the Peering SIDs allocated by C.</t>
<t>PeerNode SID 1052, allocated by C for peer F:</t>
<t>PeerNode SID 1052, allocated by C for peer F:<list style="symbols"> <ul spacing="normal">
<t>Upon the failure of the upper connected link CF, C can reroute <li>Upon the failure of the upper connected link CF, C can reroute
all the traffic onto the lower CF link to the same peer (F).</t> all the traffic onto the lower CF link to the same peer (F).</li>
</list></t> </ul>
<t>PeerNode SID 1022, allocated by C for peer E:</t>
<t>PeerNode SID 1022, allocated by C for peer E:<list style="symbols"> <ul spacing="normal">
<t>Upon the failure of the connected link CE, C can reroute all <li>Upon the failure of the connected link CE, C can reroute all
the traffic onto the link to PeerNode SID 1052 (F).</t> the traffic onto the link to PeerNode SID 1052 (F).</li>
</list></t> </ul>
<t>PeerNode SID 1012, allocated by C for peer D:</t>
<t>PeerNode SID 1012, allocated by C for peer D:<list style="symbols"> <ul spacing="normal">
<t>Upon the failure of the connected link CD, C can pop the <li>Upon the failure of the connected link CD, C can pop the
PeerNode SID and lookup the IP destination address in its FIB and PeerNode SID and look up the IP destination address in its FIB and
route accordingly.</t> route accordingly.</li>
</list></t> </ul>
<t>PeerSet SID 1060, allocated by C for the set of peers E and F:</t>
<t>PeerSet SID 1060, allocated by C for the set of peers E and F:<list <ul spacing="normal">
style="symbols"> <li>Upon the failure of a connected link in the group, the traffic
<t>Upon the failure of a connected link in the group, the traffic
to PeerSet SID 1060 is rerouted on any other member of the to PeerSet SID 1060 is rerouted on any other member of the
group.</t> group.</li>
</list></t> </ul>
<t>For specific business reasons, the operator might not want the <t>For specific business reasons, the operator might not want the
default FRR behavior applied to a PeerNode SID or any of its dependent default FRR behavior applied to a PeerNode SID or any of its dependent
PeerADJ SID.</t> PeerADJ SIDs.</t>
<t>The operator should be able to associate a specific backup PeerNode <t>The operator should be able to associate a specific backup PeerNode
SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) SID for a PeerNode SID; e.g., 1022 (E) must be backed up by 1012 (D),
which overrules the default behavior which would have preferred F as a which overrules the default behavior that would have preferred F as a
backup for E.</t> backup for E.</t>
</section> </section>
</section> </section>
<section anchor="BGPPECTRL" numbered="true" toc="default">
<section anchor="BGPPECTRL" title="BGP-EPE Controller"> <name>BGP-EPE Controller</name>
<t>In this section, Let's provide a non-exhaustive set of inputs that a <t>In this section, Let's provide a non-exhaustive set of inputs that a
BGP-EPE controller would likely collect such as to perform the BGP-EPE BGP-EPE controller would likely collect such as to perform the BGP-EPE
policy decision.</t> policy decision.</t>
<t>The exhaustive definition is outside the scope of this document.</t> <t>The exhaustive definition is outside the scope of this document.</t>
<section anchor="PATHSFROMPEERS" numbered="true" toc="default">
<section anchor="PATHSFROMPEERS" title="Valid Paths From Peers"> <name>Valid Paths from Peers</name>
<t>The BGP-EPE controller should collect all the BGP paths (i.e.: IP <t>The BGP-EPE controller should collect all the BGP paths (i.e., IP
destination prefixes) advertised by all the BGP-EPE enabled border destination prefixes) advertised by all the BGP-EPE-enabled border
router.</t> routers.</t>
<t>This could be realized by setting an iBGP session with the
<t>This could be realized by setting an iBGP session with the BGP-EPE BGP-EPE-enabled border router, with the router configured to advertise
enabled border router, with the router configured to advertise all all paths using BGP ADD-PATH <xref target="RFC7911" format="default"/>
paths using BGP add-path <xref target="RFC7911"/> and the original and the original next hop preserved.</t>
next-hop preserved.</t>
<t>In this case, C would advertise the following Internet routes to <t>In this case, C would advertise the following Internet routes to
the BGP-EPE controller:<list style="symbols"> the BGP-EPE controller:</t>
<t>NLRI &lt;2001:db8:abcd::/48&gt;, next-hop 2001:db8:cd::d, AS <ul spacing="normal">
Path {AS 2, 4}<list> <li>
<t>X (i.e.: the BGP-EPE controller) knows that C receives a <t>NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:cd::d, AS
Path {AS 2, 4}</t>
<ul spacing="normal">
<li>X (i.e., the BGP-EPE controller) knows that C receives a
path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of path to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of
AS2.</t> AS2.</li>
</list></t> </ul>
</li>
<t>NLRI &lt;2001:db8:abcd::/48&gt;, next-hop 2001:db8:ce::e, AS <li>
Path {AS 3, 4}<list> <t>NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:ce::e, AS
<t>X knows that C receives a path to 2001:db8:abcd::/48 via Path {AS 3, 4}</t>
neighbor 2001:db8:ce::e of AS2.</t> <ul spacing="normal">
</list></t> <li>X knows that C receives a path to 2001:db8:abcd::/48 via
neighbor 2001:db8:ce::e of AS2.</li>
<t>NLRI &lt;2001:db8:abcd::/48&gt;, next-hop 2001:db8:f::f, AS </ul>
Path {AS 3, 4} <list> </li>
<t>X knows that C has an eBGP path to 2001:db8:abcd::/48 via <li>
AS3 via neighbor 2001:db8:f::f</t> <t>NLRI &lt;2001:db8:abcd::/48&gt;, next hop 2001:db8:f::f, AS
</list></t> Path {AS 3, 4} </t>
</list></t> <ul spacing="normal">
<li>X knows that C has an eBGP path to 2001:db8:abcd::/48 via
<t>An alternative option would be for a BGP-EPE collector to use BGP AS3 via neighbor 2001:db8:f::f.</li>
Monitoring Protocol (BMP) <xref target="RFC7854"/> to track the </ul>
Adj-RIB-In of BGP-EPE enabled border routers.</t> </li>
</ul>
<t>An alternative option would be for a BGP-EPE collector to use the
BGP Monitoring Protocol (BMP) <xref target="RFC7854"
format="default"/> to track the Adj-RIB-In of BGP-EPE-enabled border
routers.</t>
</section> </section>
<section anchor="INTRATOPO" numbered="true" toc="default">
<section anchor="INTRATOPO" title="Intra-Domain Topology"> <name>Intra-Domain Topology</name>
<t>The BGP-EPE controller should collect the internal topology and the <t>The BGP-EPE controller should collect the internal topology and the
related IGP SIDs.</t> related IGP SIDs.</t>
<t>This could be realized by collecting the IGP Link-State Database
<t>This could be realized by collecting the IGP LSDB of each area or (LSDB) of each area or running a BGP-LS session with a node in each
running a BGP-LS session with a node in each IGP area.</t> IGP area.</t>
</section> </section>
<section anchor="EXTRATOPO" numbered="true" toc="default">
<name>External Topology</name>
<section anchor="EXTRATOPO" title="External Topology"> <t>Thanks to the collected BGP-LS routes described in <xref
<t>Thanks to the collected BGP-LS routes described in section 2, the target="TOPOBGPLS"/>, the BGP-EPE controller is able to maintain an
BGP-EPE controller is able to maintain an accurate description of the accurate description of the egress topology of Node C. Furthermore,
egress topology of node C. Furthermore, the BGP-EPE controller is able the BGP-EPE controller is able to associate BGP Peering SIDs to the
to associate BGP Peering SIDs to the various components of the various components of the external topology.</t>
external topology.</t>
</section> </section>
<section anchor="SLA" numbered="true" toc="default">
<name>SLA Characteristics of Each Peer</name>
<section anchor="SLA" title="SLA characteristics of each peer"> <t>The BGP-EPE controller might collect Service Level Agreement (SLA)
<t>The BGP-EPE controller might collect SLA characteristics across characteristics across peers. This requires a BGP-EPE solution, as the
peers. This requires an BGP-EPE solution as the SLA probes need to be SLA probes need to be steered via non-best-path peers.</t>
steered via non-best-path peers.</t>
<t>Unidirectional SLA monitoring of the desired path is likely <t>Unidirectional SLA monitoring of the desired path is likely
required. This might be possible when the application is controlled at required. This might be possible when the application is controlled at
the source and the receiver side. Unidirectional monitoring the source and the receiver side. Unidirectional monitoring
dissociates the SLA characteristic of the return path (which cannot dissociates the SLA characteristic of the return path (which cannot
usually be controlled) from the forward path (the one of interest for usually be controlled) from the forward path (the one of interest for
pushing content from a source to a consumer and the one which can be pushing content from a source to a consumer and the one that can be
controlled).</t> controlled).</t>
<t>Alternatively, Extended Metrics, as defined in <xref <t>Alternatively, Metric Extensions, as defined in <xref target="RFC8570
target="RFC7810"/> could also be advertised using BGP-LS (<xref " format="default"/>, could also be advertised using BGP-LS <xref target="RFC857
target="I-D.ietf-idr-te-pm-bgp"/>).</t> 1" format="default"/>.</t>
</section> </section>
<section anchor="MATRIX" title="Traffic Matrix"> <section anchor="MATRIX" numbered="true" toc="default">
<name>Traffic Matrix</name>
<t>The BGP-EPE controller might collect the traffic matrix to its <t>The BGP-EPE controller might collect the traffic matrix to its
peers or the final destinations. IPFIX <xref target="RFC7011"/> is a peers or the final destinations. IP Flow Information Export (IPFIX)
likely option.</t> <xref target="RFC7011" format="default"/> is a likely option.</t>
<t>An alternative option consists of collecting the link utilization
<t>An alternative option consists in collecting the link utilization
statistics of each of the internal and external links, also available statistics of each of the internal and external links, also available
in the current definition of <xref target="RFC7752"/>.</t> in the current definition in <xref target="RFC7752" format="default"/>.< /t>
</section> </section>
<section anchor="BUSINESS" title="Business Policies"> <section anchor="BUSINESS" numbered="true" toc="default">
<name>Business Policies</name>
<t>The BGP-EPE controller should be configured or collect business <t>The BGP-EPE controller should be configured or collect business
policies through any desired mechanisms. These mechanisms by which policies through any desired mechanisms. These mechanisms by which
these policies are configured or collected are outside the scope of these policies are configured or collected are outside the scope of
this document.</t> this document.</t>
</section> </section>
<section anchor="BGPPOLICY" numbered="true" toc="default">
<section anchor="BGPPOLICY" title="BGP-EPE Policy"> <name>BGP-EPE Policy</name>
<t>On the basis of all these inputs (and likely others), the BGP-EPE <t>On the basis of all these inputs (and likely others), the BGP-EPE
Controller decides to steer some demands away from their best BGP controller decides to steer some demands away from their best BGP
path.</t> path.</t>
<t>The BGP-EPE policy is likely expressed as a two-entry segment list <t>The BGP-EPE policy is likely expressed as a two-entry segment list
where the first element is the IGP prefix SID of the selected egress where the first element is the IGP Prefix-SID of the selected egress
border router and the second element is a BGP Peering SID at the border router and the second element is a BGP Peering SID at the
selected egress border router.</t> selected egress border router.</t>
<t>A few examples are provided hereafter:</t>
<t>A few examples are provided hereafter:<list style="symbols"> <ul spacing="normal">
<t>Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the <li>Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the
SID of PE C as defined in <xref target="PROBSTATE"/>.</t> SID of PE C as defined in <xref target="PROBSTATE" format="default"/
>.</li>
<t>Prefer egress PE C and peer AS AS3 via eBGP peer <li>Prefer egress PE C and peer AS AS3 via eBGP peer
2001:db8:ce::e, {64, 1022}.</t> 2001:db8:ce::e, {64, 1022}.</li>
<li>Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f,
<t>Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, {64, 1052}.</li>
{64, 1052}.</t> <li>Prefer egress PE C and peer AS AS3 via interface
<t>Prefer egress PE C and peer AS AS3 via interface
2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64, 2001:db8:cf2::f of multi-hop eBGP peer 2001:db8:f::f, {64,
1042}.</t> 1042}.</li>
<li>Prefer egress PE C and any interface to any peer in the group
<t>Prefer egress PE C and any interface to any peer in the group 1060: {64, 1060}.</li>
1060: {64, 1060}.</t> </ul>
</list></t>
<t>Note that the first SID could be replaced by a list of segments. <t>Note that the first SID could be replaced by a list of segments.
This is useful when an explicit path within the domain is required for This is useful when an explicit path within the domain is required for
traffic engineering purposes. For example, if the Prefix SID of node B traffic-engineering purposes. For example, if the Prefix-SID of Node B
is 60 and the BGP-EPE controller would like to steer the traffic from is 60 and the BGP-EPE controller would like to steer the traffic from
A to C via B then through the external link to peer D then the segment A to C via B then through the external link to peer D, then the segment
list would be {60, 64, 1012}.</t> list would be {60, 64, 1012}.</t>
</section> </section>
</section> </section>
<section anchor="PROGRINPUTPOL" title="Programming an input policy"> <section anchor="PROGRINPUTPOL" numbered="true" toc="default">
<t>The detailed/exhaustive description of all the means to implement an <name>Programming an Input Policy</name>
<t>The detailed/exhaustive description of all the means to implement a
BGP-EPE policy are outside the scope of this document. A few examples BGP-EPE policy are outside the scope of this document. A few examples
are provided in this section.</t> are provided in this section.</t>
<section anchor="ATHOST" numbered="true" toc="default">
<name>At a Host</name>
<section anchor="ATHOST" title="At a Host">
<t>A static IP/MPLS route can be programmed at the host H. The static <t>A static IP/MPLS route can be programmed at the host H. The static
route would define a destination prefix, a next-hop and a label stack route would define a destination prefix, a next hop, and a label stack
to push. Assuming a global SRGB, at least on all access routers to push. Assuming the same Segment Routing Global Block (SRGB), at
connecting the hosts, the same policy can be programmed across all least on all access routers connecting the hosts, the same policy can
hosts, which is convenient.</t> be programmed across all hosts, which is convenient.</t>
</section> </section>
<section anchor="ATROUTER" numbered="true" toc="default">
<section anchor="ATROUTER" <name>At a Router - SR Traffic-Engineering Tunnel</name>
title="At a router &ndash; SR Traffic Engineering tunnel">
<t>The BGP-EPE controller can configure the ingress border router with <t>The BGP-EPE controller can configure the ingress border router with
an SR traffic engineering tunnel T1 and a steering-policy S1 which an SR traffic-engineering tunnel T1 and a steering policy S1, which
causes a certain class of traffic to be mapped on the tunnel T1.</t> causes a certain class of traffic to be mapped on the tunnel T1.</t>
<t>The tunnel T1 would be configured to push the required segment <t>The tunnel T1 would be configured to push the required segment
list.</t> list.</t>
<t>The tunnel and the steering policy could be configured via multiple <t>The tunnel and the steering policy could be configured via multiple
means. A few examples are given below:<list style="symbols"> means. A few examples are given below:</t>
<t>PCEP according to <xref target="I-D.ietf-pce-segment-routing"/> <ul spacing="normal">
and <xref target="I-D.ietf-pce-pce-initiated-lsp"/>.</t> <li>The Path Computation Element Communication Protocol (PCEP) accordi
ng
<t>Netconf (<xref target="RFC6241"/>).</t> to <xref target="RFC8664" format="default"/> and <xref
target="RFC8281" format="default"/></li>
<t>Other static or ephemeral APIs</t> <li>NETCONF <xref target="RFC6241" format="default"/></li>
</list></t> <li>Other static or ephemeral APIs</li>
</ul>
<t>Example: at router A (<xref target="REFDIAGRAMFIG"/>).<figure <t>Example: at router A (<xref target="REFDIAGRAMFIG" format="default"/>
align="left" suppress-title="true"> ).</t>
<artwork align="center"> <sourcecode>
Tunnel T1: push {64, 1042} Tunnel T1: push {64, 1042}
IP route L/8 set next-hop T1 IP route L/8 set next-hop T1
</artwork> </sourcecode>
</figure></t>
</section> </section>
<section anchor="ATROUTER8277" <section anchor="ATROUTER8277" numbered="true" toc="default">
title="At a Router &ndash; BGP Labeled Unicast route (RFC8277)"> <name>At a Router - Unicast Route Labeled Using BGP (RFC 8277)</name>
<t>The BGP-EPE Controller could build a BGP Labeled Unicast route
<xref target="RFC8277"/>) route (from scratch) and send it to the
ingress router:<list style="symbols">
<t>NLRI: the destination prefix to engineer: e.g., L/8.</t>
<t>Next-Hop: the selected egress border router: C.</t> <t>The BGP-EPE controller could build a unicast route labeled using BGP
<xref target="RFC8277"/> (from scratch) and send it to the ingress
router.</t>
<t>Label: the selected egress peer: 1042.</t> <t>Such a route would require the following:</t>
<t>AS path: reflecting the selected valid AS path.</t> <dl newline="true">
<t>Some BGP policy to ensure it will be selected as best by the <dt>NLRI
ingress router. Note that as discussed in RFC 8277 section 5, the </dt>
comparison of labeled and unlabeled unicast BGP route is <dd>the destination prefix to engineer (e.g., L/8)
implementation dependent and hence may require an implementation </dd>
specific policy on each ingress router.</t>
</list></t>
<t>This BGP Labeled unicast route (RFC8277) &ldquo;overwrites&rdquo; <dt>Next Hop
an equivalent or less-specific &ldquo;best path&rdquo;. As the </dt>
best-path is changed, this BGP-EPE input policy option may influence <dd>the selected egress border router: C
</dd>
<dt>Label
</dt>
<dd>the selected egress peer: 1042
</dd>
<dt>Autonomous System (AS) path
</dt>
<dd>the selected valid AS path
</dd>
</dl>
<t>
Some BGP policy to ensure it will be selected as best by the ingress
router. Note that as discussed in <xref target="RFC8277" sectionFormat="of"
section="5"/>, the comparison of a labeled and unlabeled unicast BGP route
is implementation dependent and hence may require an implementation-specific
policy on each ingress router.
</t>
<t>This unicast route labeled using BGP <xref target="RFC8277"/> "overwr
ites"
an equivalent or less-specific "best path". As the
best path is changed, this BGP-EPE input policy option may influence
the path propagated to the upstream peer/customers. Indeed, the path propagated to the upstream peer/customers. Indeed,
implementations treating the SAFI-1 and SAFI-4 routes for a given implementations treating the SAFI-1 and SAFI-4 routes for a given
prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route prefix as comparable would trigger a BGP WITHDRAW of the SAFI-1 route
to their BGP upstream peers.</t> to their BGP upstream peers.</t>
</section> </section>
<section anchor="ATROUTERVPN" numbered="true" toc="default">
<name>At a Router - VPN Policy Route</name>
<t>The BGP-EPE controller could build a VPNv4 route (from scratch) and
send it to the ingress router.</t>
<section anchor="ATROUTERVPN" <t>Such a route would require the following:</t>
title="At a Router &ndash; VPN policy route">
<t>The BGP-EPE Controller could build a VPNv4 route (from scratch) and
send it to the ingress router:<list style="symbols">
<t>NLRI: the destination prefix to engineer: e.g., L/8.</t>
<t>Next-Hop: the selected egress border router: C.</t> <dl newline="true">
<t>Label: the selected egress peer: 1042.</t> <dt>NLRI
</dt>
<dd>the destination prefix to engineer: e.g., L/8
</dd>
<t>Route-Target: selecting the appropriate VRF at the ingress <dt>Next Hop
router.</t> </dt>
<dd>the selected egress border router: C
</dd>
<t>AS path: reflecting the selected valid AS path.</t> <dt>Label
</dt>
<dd>the selected egress peer: 1042
</dd>
<t>Some BGP policy to ensure it will be selected as best by the <dt>Route-Target
ingress router in the related VRF.</t> </dt>
</list></t> <dd>the selected appropriate VRF instance at the ingress router
</dd>
<t>The related VRF must be preconfigured. A VRF fallback to the main <dt>AS path
</dt>
<dd>the selected valid AS path
</dd>
</dl>
<t>
Some BGP policy to ensure it will be selected as best by the ingress
router in the related VRF instance.
</t>
<t>The related VRF instance must be preconfigured. A VRF fallback to the
main
FIB might be beneficial to avoid replicating all the "normal" Internet FIB might be beneficial to avoid replicating all the "normal" Internet
paths in each VRF.</t> paths in each VRF instance.</t>
</section> </section>
</section> </section>
<section anchor="IPv6" numbered="true" toc="default">
<section anchor="IPv6" title="IPv6 Dataplane"> <name>IPv6 Data Plane</name>
<t>The described solution is applicable to IPv6, either with MPLS-based <t>The described solution is applicable to IPv6, either with MPLS-based
or IPv6-Native segments. In both cases, the same three steps of the or IPv6-native segments. In both cases, the same three steps of the
solution are applicable:<list style="symbols"> solution are applicable:</t>
<t>BGP-LS-based signaling of the external topology and BGP Peering <ul spacing="normal">
Segments to the BGP-EPE controller.</t> <li>BGP-LS-based signaling of the external topology and BGP Peering
Segments to the BGP-EPE controller.</li>
<t>Collection of various inputs by the BGP-EPE controller to come up
with a policy decision.</t>
<t>Programming at an ingress router or source host of the desired <li>Collecting, by the BGP-EPE controller, various inputs to come up
BGP-EPE policy which consists in a list of segments to push on a with a policy decision.</li>
defined traffic class.</t> <li>Programming at an ingress router or source host of the desired
</list></t> BGP-EPE policy, which consists of a list of segments to push on a
defined traffic class.</li>
</ul>
</section> </section>
<section anchor="BENEFITS" numbered="true" toc="default">
<section anchor="BENEFITS" title="Benefits"> <name>Benefits</name>
<t>The BGP-EPE solutions described in this document have the following <t>The BGP-EPE solutions described in this document have the following
benefits:<list style="symbols"> benefits:</t>
<t>No assumption on the iBGP design within AS1.</t> <ul spacing="normal">
<li>No assumption on the iBGP design within AS1.</li>
<t>Next-Hop-Self on the Internet routes propagated to the ingress <li>Next-hop-self on the Internet routes propagated to the ingress
border routers is possible. This is a common design rule to minimize border routers is possible. This is a common design rule to minimize
the number of IGP routes and to avoid importing external churn into the number of IGP routes and to avoid importing external churn into
the internal routing domain.</t> the internal routing domain.</li>
<li>Consistent support for traffic engineering within the domain and
<t>Consistent support for traffic engineering within the domain and at the external edge of the domain.</li>
at the external edge of the domain.</t> <li>Support for both host and ingress border router BGP-EPE policy
programming.</li>
<t>Support both host and ingress border router BGP-EPE policy <li>BGP-EPE functionality is only required on the BGP-EPE-enabled
programming.</t> egress border router and the BGP-EPE controller; an ingress policy
<t>BGP-EPE functionality is only required on the BGP-EPE enabled
egress border router and the BGP-EPE controller: an ingress policy
can be programmed at the ingress border router without any new can be programmed at the ingress border router without any new
functionality.</t> functionality.</li>
<li>Ability to deploy the same input policy across hosts connected to
<t>Ability to deploy the same input policy across hosts connected to different routers (assuming the global property of IGP
different routers (assuming the global property of IGP prefix Prefix-SIDs).</li>
SIDs).</t> </ul>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any IANA allocations.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Manageability" title="Manageability Considerations"> <name>IANA Considerations</name>
<t>The BGP-EPE use-case described in this document requires BGP-LS <t>This document has no IANA actions.</t>
(<xref target="RFC7752"/>) extensions that are described in <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>. The required
extensions consists of additional BGP-LS descriptors and TLVs that will
follow the same. Manageability functions of BGP-LS, described in <xref
target="RFC7752"/> also apply to the extensions required by the EPE
use-case.</t>
<t>Additional Manageability considerations are described in <xref
target="I-D.ietf-idr-bgpls-segment-routing-epe"/>.</t>
</section> </section>
<section anchor="Manageability" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>
The BGP-EPE use case described in this document requires BGP-LS <xref
target="RFC7752" format="default"/> extensions that are described in <xref
target="RFC9086" format="default"/> and that consists of additional BGP-LS
descriptors and TLVs. Manageability functions of BGP-LS, described in <xref
target="RFC7752" format="default"/>, also apply to the extensions required by
the EPE use case.
<section anchor="Security" title="Security Considerations"> </t>
<t><xref target="RFC7752"/> defines BGP-LS NLRIs and their associated
security aspects.</t>
<t><xref target="I-D.ietf-idr-bgpls-segment-routing-epe"/> defines the <t>Additional manageability considerations are described in <xref target="
BGP-LS extensions required by the BGP-EPE mechanisms described in this RFC9086" format="default"/>.</t>
document. BGP-EPE BGP-LS extensions also include the related
security.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Contributors" title="Contributors"> <name>Security Considerations</name>
<t>Daniel Ginsburg substantially contributed to the content of this <t><xref target="RFC7752" format="default"/> defines BGP-LS NLRI
document.</t> instances and their associated security aspects.</t>
<t><xref target="RFC9086"
format="default"/> defines the BGP-LS extensions required by the BGP-EPE
mechanisms described in this document. BGP-EPE BGP-LS extensions also
include the related security.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Acee Lindem for his comments and
contribution.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.7752.xml"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<?rfc include="reference.I-D.ietf-idr-bgpls-segment-routing-epe.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.
xml"/>
<?rfc include="reference.I-D.ietf-spring-segment-routing.xml"?> <reference anchor="RFC9086" target="https://www.rfc-editor.org/info/rfc9086">
</references> <front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segmen
t Routing BGP Egress Peer Engineering</title>
<author initials="S." surname="Previdi" fullname="Stefano Previdi">
<organization>Individual</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" rol
e="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Patel" fullname="Keyur Patel">
<organization>Arrcus, Inc.</organization>
</author>
<author initials="S." surname="Ray" fullname="Saikat Ray">
<organization>Individual Contributor</organization>
</author>
<author initials="J." surname="Dong" fullname="Jie Dong">
<organization>Huawei Technologies</organization>
</author>
<date month="August" year="2021" />
<references title="Informative References"> </front>
<?rfc include="reference.RFC.7855.xml"?> <seriesInfo name="RFC" value="9086"/>
<seriesInfo name="DOI" value="10.17487/RFC9086"/>
</reference>
<?rfc include="reference.RFC.7911.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402. xml"/>
<?rfc include="reference.RFC.7810.xml"?> </references>
<references>
<name>Informative References</name>
<?rfc include="reference.RFC.7854.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7855.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7911.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8570.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7854.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8277.
xml"/>
<?rfc include="reference.RFC.7011.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664. xml"/>
<?rfc include="reference.RFC.6241.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281. xml"/>
<?rfc include="reference.RFC.8277.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8571.
xml"/>
</references>
</references>
<?rfc include="reference.I-D.ietf-pce-segment-routing.xml"?> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Acee Lindem"/> for h
is comments and
contribution.</t>
</section>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp.xml"?> <section anchor="Contributors" numbered="false" toc="default">
<name>Contributors</name>
<t><contact fullname="Daniel Ginsburg"/> substantially contributed to the
content of this
document.</t>
</section>
<?rfc include="reference.I-D.ietf-idr-te-pm-bgp.xml"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 158 change blocks. 
611 lines changed or deleted 701 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/