One document matched: draft-filsfils-spring-segment-routing-central-epe-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-filsfils-spring-segment-routing-central-epe-05"
ipr="trust200902">
<front>
<title abbrev="Segment Routing Centralized EPE">Segment Routing
Centralized Egress Peer Engineering</title>
<author fullname="Clarence Filsfils" initials="C." role="editor"
surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<city>Brussels</city>
<region/>
<code/>
<country>BE</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." role="editor"
surname="Previdi">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>US</country>
</postal>
<email>keyupate@cisco.com</email>
</address>
</author>
<author fullname="Ebben Aries" initials="E." surname="Aries">
<organization>Facebook</organization>
<address>
<postal>
<street>1 Hacker Way</street>
<city>Menlo Park</city>
<region>CA</region>
<code>94025</code>
<country>US</country>
</postal>
<email>exa@fb.com</email>
</address>
</author>
<author fullname="Steve Shaw " initials="S." surname="Shaw">
<organization>Dropbox, Inc.</organization>
<address>
<postal>
<street>185 Berry Street, Suite 400</street>
<city>San Francisco</city>
<region>CA</region>
<code>94107</code>
<country>US</country>
</postal>
<email>shaw@dropbox.com</email>
</address>
</author>
<author fullname="Daniel Ginsburg" initials="D." surname="Ginsburg">
<organization>Yandex</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>RU</country>
</postal>
<email>dbg@yandex-team.ru</email>
</address>
</author>
<author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev">
<organization>Yandex</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country>RU</country>
</postal>
<email>fl0w@yandex-team.ru</email>
</address>
</author>
<date year="2015"/>
<workgroup>Network Working Group</workgroup>
<abstract>
<t>Segment Routing (SR) leverages source routing. A node steers a packet
through a controlled set of instructions, called segments, by prepending
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 path and service chain while maintaining per-flow state only
at the ingress node of the SR domain.</t>
<t>The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires minor
extension to the existing link-state routing protocols.</t>
<t>This document illustrates the application of Segment Routing to solve
the Egress Peer Engineering (EPE) requirement. The SR-based EPE solution
allows a centralized (SDN) controller to program any egress peer policy
at ingress border routers or at hosts within the domain. This document
is on the informational track.</t>
</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>
<middle>
<section anchor="INTRO" title="Introduction">
<t>The document is structured as follows: <list style="symbols">
<t><xref target="INTRO"/> states the EPE problem statement and
provides the key references.</t>
<t><xref target="BGPSEGMENTS"/> defines the different BGP Peering
Segments and the semantic associated to them.</t>
<t><xref target="TOPOBGPLS"/> describes the automated allocation of
BGP Peering SID’s by the EPE-enabled egress border router and
the automated signaling of the external peering topology and the
related BGP Peering SID’s to the collector <xref
target="I-D.previdi-idr-bgpls-segment-routing-epe"/>.</t>
<t><xref target="EPECTRL"/> overviews the components of a
centralized EPE controller. The definition of the EPE controller is
outside the scope of this document.</t>
<t><xref target="PROGRINPUTPOL"/> overviews the methods that could
be used by the centralized EPE controller to implement an EPE policy
at an ingress border router or at a source host within the domain.
The exhaustive definition of all the means to program an EPE input
policy is outside the scope of this document.</t>
</list></t>
<t>For editorial reasons, the solution is described for IPv4. A later
section describes how the same solution is applicable to IPv6.</t>
<section anchor="SRDOCS" title="Segment Routing Documents">
<t>The main references for this document are:<list style="symbols">
<t>SR Problem Statement: <xref
target="I-D.ietf-spring-problem-statement"/>.</t>
<t>SR Architecture: <xref
target="I-D.ietf-spring-segment-routing"/>.</t>
<t>Distribution of External Topology and TE Information using BGP:
<xref target="I-D.previdi-idr-bgpls-segment-routing-epe"/>.</t>
</list></t>
<t>The SR instantiation in the MPLS dataplane is described in <xref
target="I-D.ietf-spring-segment-routing-mpls"/>.</t>
<t>The SR IGP protocol extensions are defined in <xref
target="I-D.ietf-isis-segment-routing-extensions"/>, <xref
target="I-D.ietf-ospf-segment-routing-extensions"/> and <xref
target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>.</t>
<t>The Segment Routing PCE protocol extensions are defined in <xref
target="I-D.ietf-pce-segment-routing"/>.</t>
</section>
<section anchor="PROBSTATE" title="Problem Statement">
<t>The EPE problem statement is defined in <xref
target="I-D.ietf-spring-problem-statement"/>.</t>
<t>A centralized controller should be able to instruct an ingress PE
or a content source within the domain to use a specific egress PE and
a specific external interface/neighbor to reach a particular
destination.</t>
<t>We call this solution "EPE" for "Egress Peer Engineering". The
centralized controller is called the “EPE Controller”. The
egress border router where the EPE traffic-steering functionality is
implemented is called an EPE-enabled border router. The input policy
programmed at an ingress border router or at a source host is called
an EPE policy.</t>
<t>The requirements that have motivated the solution described in this
document are listed here below:<list style="symbols">
<t>The solution MUST apply to the Internet use-case where the
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 NOT make any assumption on the currently
deployed iBGP schemes (RRs, confederations or iBGP full meshes)
and MUST be able to support all of them.</t>
<t>The solution SHOULD minimize the need for new BGP capabilities
at the ingress PEs.</t>
<t>The solution MUST accommodate an ingress EPE policy at an
ingress PE or directly at an source host within the domain.</t>
<t>The solution MUST support automated FRR and fast
convergence.</t>
</list></t>
<t>The following reference diagram is used throughout this
document.</t>
<figure anchor="REFDIAGRAMFIG" title="Reference Diagram">
<artwork>+---------+ +------+
| | | |
| H B------D G
| | +---/| AS 2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K
| | +===F AS 3 |
+---------+ +------+
</artwork>
</figure>
<t>IPv4 addressing:<list style="symbols">
<t>C’s interface to D: 198.51.100.1/30, D’s interface:
198.51.100.2/30</t>
<t>C’s interface to E: 198.51.100.5/30, E’s interface:
198.51.100.6/30</t>
<t>C’s upper interface to F: 198.51.100.9/30, F’s
interface: 198.51.100.10/30</t>
<t>C’s lower interface to F: 198.51.100.13/30, F’s
interface: 198.51.100.14/30</t>
<t>Loopback of F used for eBGP multi-hop peering to C:
192.0.2.2/32</t>
<t>C’s loopback is 203.0.113.3/32 with SID 64</t>
</list></t>
<t>C’s BGP peering:<list style="symbols">
<t>Single-hop eBGP peering with neighbor 198.51.100.2 (D)</t>
<t>Single-hop eBGP peering with neighbor 198.51.100.6 (E)</t>
<t>Multi-hop eBGP peering with F on IP address 192.0.2.2 (F)</t>
</list></t>
<t>C’s resolution of the multi-hop eBGP session to F:<list
style="symbols">
<t>Static route 192.0.2.2/32 via 198.51.100.10</t>
<t>Static route 192.0.2.2/32 via 198.51.100.14</t>
</list></t>
<t>C is configured with local policy that defines a BGP PeerSet as the
set of peers (198.51.100.6 and 192.0.2.2)</t>
<t>X is the EPE controller within AS1 domain.</t>
<t>H is a content source within AS1 domain.</t>
</section>
</section>
<section anchor="BGPSEGMENTS" title="BGP Peering Segments">
<t>As defined in <xref target="I-D.ietf-spring-segment-routing"/>,
certain segments are defined by an Egress Peer Engineering (EPE) capable
node and corresponding to its attached peers. These segments are called
BGP peering segments or BGP Peering SIDs. They enable the expression of
source-routed inter-domain paths.</t>
<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
egress border router C of the AS and through a specific peer. At
minimum, a BGP Peering Engineering policy applied at an ingress PE
involves two segments: the Node SID of the chosen egress PE and then the
BGP Peering Segment for the chosen egress PE peer or peering
interface.</t>
<t><xref target="I-D.ietf-spring-segment-routing"/> defines three types
of BGP peering segments/SID's: PeerNodeSID, PeerAdjSID and
PeerSetSID.</t>
<t>The BGP extensions to signal these BGP peering segments are outlined
in the following section.</t>
</section>
<section anchor="TOPOBGPLS"
title="Distribution of External Topology and TE Information using BGP-LS">
<t>In ships-in-the-night mode with respect to the pre-existing iBGP
design, a BGP-LS session is established between the EPE-enabled border
router and the EPE controller.</t>
<t>As a result of its local configuration and according to the behavior
described in <xref target="I-D.previdi-idr-bgpls-segment-routing-epe"/>,
node C allocates the following BGP Peering Segments (<xref
target="I-D.ietf-spring-segment-routing"/>):<list style="symbols">
<t>A PeerNode segment for each of its defined peer (D, E and F).</t>
<t>A PeerAdj segment for each recursing interface to a multi-hop
peer (e.g.: the upper and lower interfaces from C to F in figure
1).</t>
<t>A PeerSet segment to the set of peers (E and F).</t>
</list></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’s to the EPE controller. Each
such BGP-LS route is described in the following subsections according to
the encoding details defined in <xref
target="I-D.previdi-idr-bgpls-segment-routing-epe"/>.</t>
<section anchor="PEERNODED"
title="EPE Route advertising the Peer D and its PeerNode SID ">
<t>Descriptors: <list style="symbols">
<t>Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1</t>
<t>Peer Descriptors (peer ASN): AS2</t>
<t>Link Descriptors (IPv4 interface address, neighbor IPv4
address): 198.51.100.1, 198.51.100.2</t>
</list></t>
<t>Attributes: <list style="symbols">
<t>PeerNode-SID: 1012</t>
</list></t>
</section>
<section anchor="PEERNODEE"
title="EPE Route advertising the Peer E and its PeerNode SID ">
<t>Descriptors: <list style="symbols">
<t>Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1</t>
<t>Peer Descriptors (peer ASN): AS3</t>
<t>Link Descriptors (IPv4 interface address, neighbor IPv4
address): 198.51.100.5, 198.51.100.6</t>
</list></t>
<t>Attributes: <list style="symbols">
<t>PeerNode-SID: 1022</t>
<t>PeerSetSID: 1060</t>
<t>Link Attributes: see section 3.3.2 of <xref
target="I-D.ietf-idr-ls-distribution"/></t>
</list></t>
</section>
<section anchor="PEERNODEF"
title="EPE Route advertising the Peer F and its PeerNode SID ">
<t>Descriptors: <list style="symbols">
<t>Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1</t>
<t>Peer Descriptors (peer ASN): AS3</t>
<t>Link Descriptors (IPv4 interface address, neighbor IPv4
address): 203.0.113.3, 192.0.2.2</t>
</list></t>
<t>Attributes: <list style="symbols">
<t>PeerNode-SID: 1052</t>
<t>PeerSetSID: 1060</t>
</list></t>
</section>
<section anchor="PEERNODEFLINK1"
title="EPE Route advertising a first PeerAdj to Peer F">
<t>Descriptors: <list style="symbols">
<t>Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1</t>
<t>Peer Descriptors (peer ASN): AS3</t>
<t>Link Descriptors (IPv4 interface address, neighbor IPv4
address): 198.51.100.9, 198.51.100.10</t>
</list></t>
<t>Attributes: <list style="symbols">
<t>PeerAdj-SID: 1032</t>
<t>LinkAttributes: see section 3.3.2 of <xref
target="I-D.ietf-idr-ls-distribution"/></t>
</list></t>
</section>
<section anchor="PEERNODEFLINK2"
title="EPE Route advertising a second PeerAdj to Peer F">
<t>Descriptors: <list style="symbols">
<t>Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1</t>
<t>Peer Descriptors (peer ASN): AS3</t>
<t>Link Descriptors (IPv4 interface address, neighbor IPv4
address): 198.51.100.13, 198.51.100.14</t>
</list></t>
<t>Attributes: <list style="symbols">
<t>PeerAdj-SID: 1042</t>
<t>LinkAttributes: see section 3.3.2 of <xref
target="I-D.ietf-idr-ls-distribution"/></t>
</list></t>
</section>
<section anchor="FRR" title="FRR">
<t>An EPE-enabled border router should allocate a FRR backup entry on
a per BGP Peering SID basis:<list style="symbols">
<t>PeerNode SID<list style="numbers">
<t>If multi-hop, backup via the remaining PeerADJ SIDs to the
same peer.</t>
<t>Else backup via local PeerNode SID to the same AS.</t>
<t>Else pop the PeerNode SID and perform an IP lookup (with
potential BGP PIC fall-back).</t>
</list></t>
<t>PeerAdj SID<list style="numbers">
<t>If to a multi-hop peer, backup via the remaining PeerADJ
SIDs to the same peer.</t>
<t>Else backup via PeerNode SID to the same AS.</t>
<t>Else pop the PeerNode SID and perform an IP lookup (with
potential BGP PIC fall-back).</t>
</list></t>
<t>PeerSet SID<list style="numbers">
<t>Backup via remaining PeerNode SIDs in the same PeerSet.</t>
<t>Else pop the PeerNode SID and IP lookup (with potential BGP
PIC fall-back).</t>
</list></t>
</list></t>
<t>We illustrate the different types of possible backups using the
reference diagram and considering the Peering SIDs allocated by C.</t>
<t>PeerNode SID 1052, allocated by C for peer F:<list style="symbols">
<t>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>
</list></t>
<t>PeerNode SID 1022, allocated by C for peer E:<list style="symbols">
<t>Upon the failure of the connected link CE, C can reroute all
the traffic onto the link to PeerNode SID 1052 (F).</t>
</list></t>
<t>PeerNode SID 1012, allocated by C for peer D:<list style="symbols">
<t>Upon the failure of the connected link CD, C can pop the
PeerNode SID and lookup the IP destination address in its FIB and
route accordingly.</t>
</list></t>
<t>PeerSet SID 1060, allocated by C for the set of peers E and F:<list
style="symbols">
<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
group.</t>
</list></t>
<t>For specific business reasons, the operator might not want the
default FRR behavior applied to a PeerNode SID or any of its dependent
PeerADJ SID.</t>
<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)
which overrules the default behavior which would have preferred F as a
backup for E.</t>
</section>
</section>
<section anchor="EPECTRL" title="EPE Controller">
<t>In this section, we provide a non-exhaustive set of inputs that an
EPE controller would likely collect such as to perform the EPE policy
decision.</t>
<t>The exhaustive definition is outside the scope of this document.</t>
<section anchor="PATHSFROMPEERS" title="Valid Paths From Peers">
<t>The EPE controller should collect all the paths advertised by all
the engineered peers.</t>
<t>This could be realized by setting an iBGP session with the
EPE-enabled border router, with “add-path all” and the
original next-hop preserved.</t>
<t>In this case, C would advertise the following Internet routes to
the EPE controller:<list style="symbols">
<t>NLRI <L/8>, nhop 198.51.100.2, AS Path {AS 2, 4}<list>
<t>X (i.e.: the EPE controller) knows that C receives a path
to L/8 via neighbor 198.51.100.2 of AS2.</t>
</list></t>
<t>NLRI <L/8>, nhop 198.51.100.6, AS Path {AS 3, 4}<list>
<t>X knows that C receives a path to L/8 via neighbor 198.51.100.6
of AS2.</t>
</list></t>
<t>NLRI <L/8>, nhop 192.0.2.2, AS Path {AS 3, 4} <list>
<t>X knows that C has an eBGP path to L/8 via AS3 via neighbor
192.0.2.2</t>
</list></t>
</list></t>
<t>An alternative option would be for an EPE collector to use BGP
Monitoring Protocol (BMP) to track the Adj-RIB-In of EPE-enabled
border routers.</t>
</section>
<section anchor="INTRATOPO" title="Intra-Domain Topology">
<t>The EPE controller should collect the internal topology and the
related IGP SIDs.</t>
<t>This could be realized by collecting the IGP LSDB of each area or
running a BGP-LS session with a node in each IGP area.</t>
</section>
<section anchor="EXTRATOPO" title="External Topology">
<t>Thanks to the collected BGP-LS routes described in the section 2
(BGP-LS advertisements), the EPE controller is able to maintain an
accurate description of the egress topology of node C. Furthermore,
the EPE controller is able to associate BGP Peering SIDs to the
various components of the external topology.</t>
</section>
<section anchor="SLA" title="SLA characteristics of each peer">
<t>The EPE controller might collect SLA characteristics across peers.
This requires an EPE solution as the SLA probes need to be steered via
non-best-path peers.</t>
<t>Unidirectional SLA monitoring of the desired path is likely
required. This might be possible when the application is controlled at
the source and the receiver side. Unidirectional monitoring
dissociates the SLA characteristic of the return path (which cannot
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
controlled).</t>
<t>Alternatively, Extended Metrics, as defined in <xref
target="I-D.ietf-isis-te-metric-extensions"/> could also be advertised
using new BGP-LS attributes.</t>
</section>
<section anchor="MATRIX" title="Traffic Matrix">
<t>The EPE controller might collect the traffic matrix to its peers or
the final destinations. IPFIX is a likely option.</t>
<t>An alternative option consists in collecting the link utilization
statistics of each of the internal and external links, also available
in the current definition of <xref
target="I-D.ietf-idr-ls-distribution"/>.</t>
</section>
<section anchor="BUSINESS" title="Business Policies">
<t>The EPE controller should collect business policies.</t>
</section>
<section anchor="EPEPOLICY" title="EPE Policy">
<t>On the basis of all these inputs (and likely others), the EPE
Controller decides to steer some demands away from their best BGP
path.</t>
<t>The EPE policy is likely expressed as a two-entry segment list
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
selected egress border router.</t>
<t>A few examples are provided hereafter:<list style="symbols">
<t>Prefer egress PE C and peer AS AS2: {64, 1012}.</t>
<t>Prefer egress PE C and peer AS AS3 via eBGP peer
198.51.100.6: {64, 1022}.</t>
<t>Prefer egress PE C and peer AS AS3 via eBGP peer
192.0.2.2: {64, 1052}.</t>
<t>Prefer egress PE C and peer AS AS3 via interface
198.51.100.14 of multi-hop eBGP peer 192.0.2.2: {64,
1042}.</t>
<t>Prefer egress PE C and any interface to any peer in the
group 1060: {64, 1060}.</t>
</list></t>
<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
traffic-engineering purposes. For example, if the Prefix SID of node B
is 60 and the 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 list
would be {60, 64, 1012}.</t>
</section>
</section>
<section anchor="PROGRINPUTPOL" title="Programming an input policy">
<t>The detailed/exhaustive description of all the means to implement an
EPE policy are outside the scope of this document. A few examples are
provided in this section.</t>
<section anchor="ATHOST" title="At a Host">
<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
to push. The global property of the IGP Prefix SID is particularly
convenient: the same policy could be programmed across hosts connected
to different routers.</t>
</section>
<section anchor="ATROUTER"
title="At a router – SR Traffic Engineering tunnel">
<t>The EPE controller can configure the ingress border router with 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>
<t>The tunnel T1 would be configured to push the required segment
list.</t>
<t>The tunnel and the steering policy could be configured via PCEP
according to <xref target="I-D.ietf-pce-segment-routing"/> and <xref
target="I-D.ietf-pce-pce-initiated-lsp"/> or via Netconf (<xref
target="RFC6241"/>).</t>
<t>Example: at A <figure suppress-title="true">
<artwork>Tunnel T1: push {64, 1042}
IP route L/8 set nhop T1
</artwork>
</figure></t>
</section>
<section anchor="ATROUTER3107"
title="At a Router – RFC3107 policy route">
<t>The EPE Controller could build a RFC3107 (<xref target="RFC3107"/>)
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>Label: the selected egress peer: 1042.</t>
<t>AS path: reflecting the selected valid AS path.</t>
<t>Some BGP policy to ensure it will be selected as best by the
ingress router.</t>
</list></t>
<t>This RFC3107 policy route “overwrites” an equivalent or
less-specific “best path”. As the best-path is changed,
this EPE input policy option influences the path propagated to the
upstream peer/customers.</t>
</section>
<section anchor="ATROUTERVPN"
title="At a Router – VPN policy route">
<t>The 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>
<t>Label: the selected egress peer: 1042.</t>
<t>Route-Target: selecting the appropriate VRF at the ingress
router.</t>
<t>AS path: reflecting the selected valid AS path.</t>
<t>Some BGP policy to ensure it will be selected as best by the
ingress router in the related VRF.</t>
</list></t>
<t>The related VRF must be preconfigured. A VRF fallback to the main
FIB might be beneficial to avoid replicating all the "normal" Internet
paths in each VRF.</t>
</section>
<section anchor="ATROUTERFLOWSPEC"
title="At a Router – Flowspec route">
<t>An EPE Controller builds a FlowSpec route and sends it to the
ingress router to engineer:<list style="symbols">
<t>Dissemination of Flow Specification Rules (<xref
target="RFC5575"/>.</t>
<t>Destination/Source IP Addresses, IP Protocol,
Destination/Source port (+1 component).</t>
<t>ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment.</t>
</list></t>
</section>
</section>
<section anchor="IPv6" title="IPv6">
<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
solution are applicable:<list style="symbols">
<t>BGP-LS-based signaling of the external topology and BGP Peering
Segments to the EPE controller.</t>
<t>Collection of various inputs by the EPE controller to come up
with a policy decision.</t>
<t>Programming at an ingress router or source host of the desired
EPE policy which consists in a list of segments to push on a defined
traffic class.</t>
</list></t>
</section>
<section anchor="BENEFITS" title="Benefits">
<t>The EPE solutions described in this document have the following
benefits:<list style="symbols">
<t>No assumption on the iBGP design with AS1.</t>
<t>Next-Hop-Self on the Internet routes propagated to the ingress
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 internal routing domain.</t>
<t>Consistent support for traffic-engineering within the domain and
at the external edge of the domain.</t>
<t>Support both host and ingress border router EPE policy
programming.</t>
<t>EPE functionality is only required on the EPE-enabled egress
border router and the EPE controller: an ingress policy can be
programmed at the ingress border router without any new
functionality.</t>
<t>Ability to deploy the same input policy across hosts connected to
different routers (avail the global property of IGP prefix
SIDs).</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not request any IANA allocations.</t>
</section>
<section anchor="Manageability" title="Manageability Considerations">
<t>TBD</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Acee Lindem for his comments and
contributiuon.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3107.xml"?>
<?rfc include="reference.RFC.6241.xml"?>
<?rfc include="reference.RFC.5575.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-spring-segment-routing.xml"?>
<?rfc include="reference.I-D.ietf-spring-problem-statement.xml"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls.xml"?>
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions.xml"?>
<?rfc include="reference.I-D.ietf-isis-te-metric-extensions.xml"?>
<?rfc include="reference.I-D.ietf-idr-ls-distribution.xml"?>
<?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions.xml"?>
<?rfc include="reference.I-D.ietf-ospf-ospfv3-segment-routing-extensions.xml"?>
<?rfc include="reference.I-D.ietf-pce-segment-routing.xml"?>
<?rfc include="reference.I-D.ietf-pce-pce-initiated-lsp.xml"?>
<?rfc include="reference.I-D.previdi-idr-bgpls-segment-routing-epe.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:25:41 |