< draft-ietf-spring-segment-routing-central-epe-00.txt   draft-ietf-spring-segment-routing-central-epe-01.txt >
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi, Ed.
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: April 16, 2016 E. Aries Expires: September 22, 2016 E. Aries
Facebook Facebook
D. Ginsburg D. Ginsburg
D. Afanasiev D. Afanasiev
Yandex Yandex
October 14, 2015 March 21, 2016
Segment Routing Centralized Egress Peer Engineering Segment Routing Centralized BGP Peer Engineering
draft-ietf-spring-segment-routing-central-epe-00 draft-ietf-spring-segment-routing-central-epe-01
Abstract Abstract
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any prepending the packet with an SR header. A segment can represent any
instruction topological or service-based. SR allows to enforce a instruction topological or service-based. SR allows to enforce a
flow through any topological path and service chain while maintaining flow through any topological path and service chain while maintaining
per-flow state only at the ingress node of the SR domain. per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires minor dataplane with no change on the forwarding plane. It requires minor
extension to the existing link-state routing protocols. extension to the existing link-state routing protocols.
This document illustrates the application of Segment Routing to solve This document illustrates the application of Segment Routing to solve
the Egress Peer Engineering (EPE) requirement. The SR-based EPE the BGP Peer Engineering (BGP-PE) requirement. The SR-based BGP-PE
solution allows a centralized (SDN) controller to program any egress solution allows a centralized (SDN) controller to program any egress
peer policy at ingress border routers or at hosts within the domain. peer policy at ingress border routers or at hosts within the domain.
This document is on the informational track. This document is on the informational track.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 3 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6
3. Distribution of External Topology and TE Information using 3. Distribution of External Topology and TE Information using
BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. EPE Route advertising the Peer D and its PeerNode SID . . 7 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID 7
3.2. EPE Route advertising the Peer E and its PeerNode SID . . 7 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID 7
3.3. EPE Route advertising the Peer F and its PeerNode SID . . 8 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID 8
3.4. EPE Route advertising a first PeerAdj to Peer F . . . . . 8 3.4. BGP-PE Router advertising a first PeerAdj to Peer F . . . 8
3.5. EPE Route advertising a second PeerAdj to Peer F . . . . 8 3.5. BGP-PE Router advertising a second PeerAdj to Peer F . . 9
3.6. FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9
4. EPE Controller . . . . . . . . . . . . . . . . . . . . . . . 10 4. BGP-PE Controller . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10
4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11
4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11
4.4. SLA characteristics of each peer . . . . . . . . . . . . 11 4.4. SLA characteristics of each peer . . . . . . . . . . . . 11
4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12
4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12
4.7. EPE Policy . . . . . . . . . . . . . . . . . . . . . . . 12 4.7. BGP-PE Policy . . . . . . . . . . . . . . . . . . . . . . 12
5. Programming an input policy . . . . . . . . . . . . . . . . . 13 5. Programming an input policy . . . . . . . . . . . . . . . . . 13
5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13
5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 13 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 13
5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14
5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14
6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Manageability Considerations . . . . . . . . . . . . . . . . 15 9. Manageability Considerations . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 21 skipping to change at page 3, line 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The document is structured as follows: The document is structured as follows:
o Section 1 states the EPE problem statement and provides the key o Section 1 states the BGP-PE problem statement and provides the key
references. references.
o Section 2 defines the different BGP Peering Segments and the o Section 2 defines the different BGP Peering Segments and the
semantic associated to them. semantic associated to them.
o Section 3 describes the automated allocation of BGP Peering SID's o Section 3 describes the automated allocation of BGP Peering SID's
by the EPE-enabled egress border router and the automated by the BGP-PE enabled egress border router and the automated
signaling of the external peering topology and the related BGP signaling of the external peering topology and the related BGP
Peering SID's to the collector Peering SID's to the collector
[I-D.ietf-idr-bgpls-segment-routing-epe]. [I-D.ietf-idr-bgpls-segment-routing-epe].
o Section 4 overviews the components of a centralized EPE o Section 4 overviews the components of a centralized EPE
controller. The definition of the EPE controller is outside the controller. The definition of the EPE controller is outside the
scope of this document. scope of this document.
o Section 5 overviews the methods that could be used by the o Section 5 overviews the methods that could be used by the
centralized EPE controller to implement an EPE policy at an centralized BGP-PE controller to implement a BGP-PE policy at an
ingress border router or at a source host within the domain. The ingress border router or at a source host within the domain. The
exhaustive definition of all the means to program an EPE input exhaustive definition of all the means to program an BGP-PE input
policy is outside the scope of this document. policy is outside the scope of this document.
For editorial reasons, the solution is described for IPv4. A later For editorial reasons, the solution is described for IPv4. A later
section describes how the same solution is applicable to IPv6. section describes how the same solution is applicable to IPv6.
1.1. Segment Routing Documents 1.1. Segment Routing Documents
The main references for this document are: The main references for this document are:
o SR Problem Statement: [I-D.ietf-spring-problem-statement]. o SR Problem Statement: [I-D.ietf-spring-problem-statement].
skipping to change at page 4, line 23 skipping to change at page 4, line 23
The SR IGP protocol extensions are defined in The SR IGP protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The Segment Routing PCE protocol extensions are defined in The Segment Routing PCE protocol extensions are defined in
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
1.2. Problem Statement 1.2. Problem Statement
The EPE problem statement is defined in The BGP-PE problem statement is defined in
[I-D.ietf-spring-problem-statement]. [I-D.ietf-spring-problem-statement].
A centralized controller should be able to instruct an ingress PE or A centralized controller should be able to instruct an ingress
a content source within the domain to use a specific egress PE and a Provider Edge router (PE) or a content source within the domain to
specific external interface/neighbor to reach a particular use a specific egress PE and a specific external interface/neighbor
destination. to reach a particular destination.
We call this solution "EPE" for "Egress Peer Engineering". The We call this solution "BGP-PE" for "BGP Peer Engineering". The
centralized controller is called the "EPE Controller". The egress centralized controller is called the "BGP-PE Controller". The egress
border router where the EPE traffic-steering functionality is border router where the BGP-PE traffic-steering functionality is
implemented is called an EPE-enabled border router. The input policy implemented is called a BGP-PE-enabled border router. The input
programmed at an ingress border router or at a source host is called policy programmed at an ingress border router or at a source host is
an EPE policy. called a BGP-PE policy.
The requirements that have motivated the solution described in this The requirements that have motivated the solution described in this
document are listed here below: document are listed here below:
o The solution MUST apply to the Internet use-case where the o The solution MUST apply to the Internet use-case where the
Internet routes are assumed to use IPv4 unlabeled or IPv6 Internet routes are assumed to use IPv4 unlabeled or IPv6
unlabeled. It is not required to place the Internet routes in a 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. VRF and allocate labels on a per route, or on a per-path basis.
o The solution MUST NOT make any assumption on the currently o The solution MUST NOT make any assumption on the currently
deployed iBGP schemes (RRs, confederations or iBGP full meshes) deployed iBGP schemes (RRs, confederations or iBGP full meshes)
and MUST be able to support all of them. and MUST be able to support all of them.
o The solution MUST be applicable to iBGP as well as eBGP peerings.
o The solution SHOULD minimize the need for new BGP capabilities at o The solution SHOULD minimize the need for new BGP capabilities at
the ingress PEs. the ingress PEs.
o The solution MUST accommodate an ingress EPE policy at an ingress o The solution MUST accommodate an ingress BGP-PE policy at an
PE or directly at an source host within the domain. ingress PE or directly at an source host within the domain.
o The solution MUST support automated FRR and fast convergence. o The solution MUST support automated Fast Reroute (FRR) and fast
convergence mechanisms.
The following reference diagram is used throughout this document. The following reference diagram is used throughout this document.
+---------+ +------+ +---------+ +------+
| | | | | | | |
| 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
skipping to change at page 5, line 49 skipping to change at page 6, line 4
o Loopback of F used for eBGP multi-hop peering to C: 192.0.2.2/32 o Loopback of F used for eBGP multi-hop peering to C: 192.0.2.2/32
o C's loopback is 203.0.113.3/32 with SID 64 o C's loopback is 203.0.113.3/32 with SID 64
C's BGP peering: C's BGP peering:
o Single-hop eBGP peering with neighbor 198.51.100.2 (D) o Single-hop eBGP peering with neighbor 198.51.100.2 (D)
o Single-hop eBGP peering with neighbor 198.51.100.6 (E) o Single-hop eBGP peering with neighbor 198.51.100.6 (E)
o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F) o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F)
C's resolution of the multi-hop eBGP session to F: C's resolution of the multi-hop eBGP session to F:
o Static route 192.0.2.2/32 via 198.51.100.10 o Static route 192.0.2.2/32 via 198.51.100.10
o Static route 192.0.2.2/32 via 198.51.100.14 o Static route 192.0.2.2/32 via 198.51.100.14
C is configured with local policy that defines a BGP PeerSet as the 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) set of peers (198.51.100.6 and 192.0.2.2)
X is the EPE controller within AS1 domain. X is the BGP-PE controller within AS1 domain.
H is a content source within AS1 domain. H is a content source within AS1 domain.
2. BGP Peering Segments 2. BGP Peering Segments
As defined in [I-D.ietf-spring-segment-routing], certain segments are As defined in [I-D.ietf-spring-segment-routing], certain segments are
defined by an Egress Peer Engineering (EPE) capable node and defined by BGP-PE capable node and corresponding to its attached
corresponding to its attached peers. These segments are called BGP peers. These segments are called BGP peering segments or BGP Peering
peering segments or BGP Peering SIDs. They enable the expression of SIDs. They enable the expression of source-routed inter-domain
source-routed inter-domain paths. paths.
An ingress border router of an AS may compose a list of segments to 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 Peering Engineering policy applied at an ingress PE minimum, a BGP Peering Engineering policy applied at an ingress PE
involves two segments: the Node SID of the chosen egress PE and then 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 the BGP Peering Segment for the chosen egress PE peer or peering
interface. interface.
[I-D.ietf-spring-segment-routing] defines three types of BGP peering [I-D.ietf-spring-segment-routing] defines three types of BGP peering
segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID.
The BGP extensions to signal these BGP peering segments are outlined The BGP extensions to signal these BGP peering segments are outlined
in the following section. in the following section.
3. Distribution of External Topology and TE Information using BGP-LS 3. Distribution of External Topology and TE Information using BGP-LS
In ships-in-the-night mode with respect to the pre-existing iBGP In ships-in-the-night mode with respect to the pre-existing iBGP
design, a BGP-LS session is established between the EPE-enabled design, a BGP-LS session is established between the BGP-PE enabled
border router and the EPE controller. border router and the BGP-PE controller.
As a result of its local configuration and according to the behavior As a result of its local configuration and according to the behavior
described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C
allocates the following BGP Peering Segments allocates the following BGP Peering Segments
([I-D.ietf-spring-segment-routing]): ([I-D.ietf-spring-segment-routing]):
o A PeerNode segment for each of its defined peer (D, E and F). o A PeerNode segment for each of its defined peer (D, E and F).
o A PeerAdj segment for each recursing interface to a multi-hop peer o 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). (e.g.: the upper and lower interfaces from C to F in figure 1).
skipping to change at page 7, line 19 skipping to change at page 7, line 24
Incoming Outgoing Incoming Outgoing
Label Operation Interface Label Operation Interface
------------------------------------ ------------------------------------
1012 POP link to D 1012 POP link to D
1022 POP link to E 1022 POP link to E
1032 POP upper link to F 1032 POP upper link to F
1042 POP lower link to F 1042 POP lower link to F
1052 POP load balance on any link to F 1052 POP load balance on any link to F
1060 POP load balance on any link to E or to F 1060 POP load balance on any link to E or to F
C signals the related BGP-LS NLRI's to the EPE controller. Each such C signals the related BGP-LS NLRI's to the BGP-PE controller. Each
BGP-LS route is described in the following subsections according to such BGP-LS route is described in the following subsections according
the encoding details defined in to the encoding details defined in
[I-D.ietf-idr-bgpls-segment-routing-epe]. [I-D.ietf-idr-bgpls-segment-routing-epe].
3.1. EPE Route advertising the Peer D and its PeerNode SID 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID
Descriptors: Descriptors:
o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1
o Peer Descriptors (peer ASN): AS2 o Peer Descriptors (peer ASN): AS2
o Link Descriptors (IPv4 interface address, neighbor IPv4 address): o Link Descriptors (IPv4 interface address, neighbor IPv4 address):
198.51.100.1, 198.51.100.2 198.51.100.1, 198.51.100.2
Attributes: Attributes:
o PeerNode-SID: 1012 o PeerNode-SID: 1012
3.2. EPE Route advertising the Peer E and its PeerNode SID 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID
Descriptors: Descriptors:
o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1
o Peer Descriptors (peer ASN): AS3 o Peer Descriptors (peer ASN): AS3
o Link Descriptors (IPv4 interface address, neighbor IPv4 address): o Link Descriptors (IPv4 interface address, neighbor IPv4 address):
198.51.100.5, 198.51.100.6 198.51.100.5, 198.51.100.6
Attributes: Attributes:
o PeerNode-SID: 1022 o PeerNode-SID: 1022
o PeerSetSID: 1060 o PeerSetSID: 1060
o Link Attributes: see section 3.3.2 of o Link Attributes: see section 3.3.2 of [RFC7752]
[I-D.ietf-idr-ls-distribution]
3.3. EPE Route advertising the Peer F and its PeerNode SID 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID
Descriptors: Descriptors:
o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1
o Peer Descriptors (peer ASN): AS3 o Peer Descriptors (peer ASN): AS3
o Link Descriptors (IPv4 interface address, neighbor IPv4 address): o Link Descriptors (IPv4 interface address, neighbor IPv4 address):
203.0.113.3, 192.0.2.2 203.0.113.3, 192.0.2.2
Attributes: Attributes:
o PeerNode-SID: 1052 o PeerNode-SID: 1052
o PeerSetSID: 1060 o PeerSetSID: 1060
3.4. EPE Route advertising a first PeerAdj to Peer F 3.4. BGP-PE Router advertising a first PeerAdj to Peer F
Descriptors: Descriptors:
o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1
o Peer Descriptors (peer ASN): AS3 o Peer Descriptors (peer ASN): AS3
o Link Descriptors (IPv4 interface address, neighbor IPv4 address): o Link Descriptors (IPv4 interface address, neighbor IPv4 address):
198.51.100.9, 198.51.100.10 198.51.100.9, 198.51.100.10
Attributes: Attributes:
o PeerAdj-SID: 1032 o PeerAdj-SID: 1032
o LinkAttributes: see section 3.3.2 of o LinkAttributes: see section 3.3.2 of [RFC7752]
[I-D.ietf-idr-ls-distribution]
3.5. EPE Route advertising a second PeerAdj to Peer F 3.5. BGP-PE Router advertising a second PeerAdj to Peer F
Descriptors: Descriptors:
o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1
o Peer Descriptors (peer ASN): AS3 o Peer Descriptors (peer ASN): AS3
o Link Descriptors (IPv4 interface address, neighbor IPv4 address): o Link Descriptors (IPv4 interface address, neighbor IPv4 address):
198.51.100.13, 198.51.100.14 198.51.100.13, 198.51.100.14
Attributes: Attributes:
o PeerAdj-SID: 1042 o PeerAdj-SID: 1042
o LinkAttributes: see section 3.3.2 of o LinkAttributes: see section 3.3.2 of [RFC7752]
[I-D.ietf-idr-ls-distribution]
3.6. FRR 3.6. Fast Reroute (FRR)
An EPE-enabled border router should allocate a FRR backup entry on a An BGP-PE enabled border router should allocate a FRR backup entry on
per BGP Peering SID basis: a per BGP Peering SID basis:
o PeerNode SID o PeerNode SID
1. If multi-hop, backup via the remaining PeerADJ SIDs to the 1. If multi-hop, backup via the remaining PeerADJ SIDs to the
same peer. same peer.
2. Else backup via local PeerNode SID to the same AS. 2. Else backup via local PeerNode SID to the same AS.
3. Else pop the PeerNode SID and perform an IP lookup (with 3. Else pop the PeerNode SID and perform an IP lookup.
potential BGP PIC fall-back).
o PeerAdj SID o PeerAdj SID
1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs
to the same peer. to the same peer.
2. Else backup via PeerNode SID to the same AS. 2. Else backup via PeerNode SID to the same AS.
3. Else pop the PeerNode SID and perform an IP lookup (with 3. Else pop the PeerNode SID and perform an IP lookup.
potential BGP PIC fall-back).
o PeerSet SID o PeerSet SID
1. Backup via remaining PeerNode SIDs in the same PeerSet. 1. Backup via remaining PeerNode SIDs in the same PeerSet.
2. Else pop the PeerNode SID and IP lookup (with potential BGP 2. Else pop the PeerNode SID and IP lookup.
PIC fall-back).
We illustrate the different types of possible backups using the We illustrate the different types of possible backups using the
reference diagram and considering the Peering SIDs allocated by C. reference diagram and considering the Peering SIDs allocated by C.
PeerNode SID 1052, allocated by C for peer F: PeerNode SID 1052, allocated by C for peer F:
o Upon the failure of the upper connected link CF, C can reroute all o 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). the traffic onto the lower CF link to the same peer (F).
PeerNode SID 1022, allocated by C for peer E: PeerNode SID 1022, allocated by C for peer E:
skipping to change at page 10, line 33 skipping to change at page 10, line 35
For specific business reasons, the operator might not want the For specific business reasons, the operator might not want the
default FRR behavior applied to a PeerNode SID or any of its default FRR behavior applied to a PeerNode SID or any of its
dependent PeerADJ SID. dependent PeerADJ SID.
The operator should be able to associate a specific backup PeerNode 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 which overrules the default behavior which would have preferred F as
a backup for E. a backup for E.
4. EPE Controller 4. BGP-PE Controller
In this section, we provide a non-exhaustive set of inputs that an 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 BGP-PE controller would likely collect such as to perform the BGP-PE
decision. policy decision.
The exhaustive definition is outside the scope of this document. The exhaustive definition is outside the scope of this document.
4.1. Valid Paths From Peers 4.1. Valid Paths From Peers
The EPE controller should collect all the paths advertised by all the The BGP-PE controller should collect all the paths advertised by all
engineered peers. the engineered peers.
This could be realized by setting an iBGP session with the EPE- This could be realized by setting an iBGP session with the BGP-PE
enabled border router, with "add-path all" and the original next-hop enabled border router, with "add-path all" and the original next-hop
preserved. preserved.
In this case, C would advertise the following Internet routes to the In this case, C would advertise the following Internet routes to the
EPE controller: BGP-PE controller:
o NLRI <L/8>, nhop 198.51.100.2, AS Path {AS 2, 4} o NLRI <L/8>, nhop 198.51.100.2, AS Path {AS 2, 4}
* X (i.e.: the EPE controller) knows that C receives a path to * X (i.e.: the BGP-PE controller) knows that C receives a path to
L/8 via neighbor 198.51.100.2 of AS2. L/8 via neighbor 198.51.100.2 of AS2.
o NLRI <L/8>, nhop 198.51.100.6, AS Path {AS 3, 4} o NLRI <L/8>, nhop 198.51.100.6, AS Path {AS 3, 4}
* X knows that C receives a path to L/8 via neighbor 198.51.100.6 * X knows that C receives a path to L/8 via neighbor 198.51.100.6
of AS2. of AS2.
o NLRI <L/8>, nhop 192.0.2.2, AS Path {AS 3, 4} o NLRI <L/8>, nhop 192.0.2.2, AS Path {AS 3, 4}
* X knows that C has an eBGP path to L/8 via AS3 via neighbor * X knows that C has an eBGP path to L/8 via AS3 via neighbor
192.0.2.2 192.0.2.2
An alternative option would be for an EPE collector to use BGP An alternative option would be for an BGP-PE collector to use BGP
Monitoring Protocol (BMP) to track the Adj-RIB-In of EPE-enabled Monitoring Protocol (BMP) to track the Adj-RIB-In of BGP-PE enabled
border routers. border routers.
4.2. Intra-Domain Topology 4.2. Intra-Domain Topology
The EPE controller should collect the internal topology and the The BGP-PE controller should collect the internal topology and the
related IGP SIDs. related IGP SIDs.
This could be realized by collecting the IGP LSDB of each area or 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. running a BGP-LS session with a node in each IGP area.
4.3. External Topology 4.3. External Topology
Thanks to the collected BGP-LS routes described in the section 2 Thanks to the collected BGP-LS routes described in the section 2
(BGP-LS advertisements), the EPE controller is able to maintain an (BGP-LS advertisements), the BGP-PE controller is able to maintain an
accurate description of the egress topology of node C. Furthermore, accurate description of the egress topology of node C. Furthermore,
the EPE controller is able to associate BGP Peering SIDs to the the BGP-PE controller is able to associate BGP Peering SIDs to the
various components of the external topology. various components of the external topology.
4.4. SLA characteristics of each peer 4.4. SLA characteristics of each peer
The EPE controller might collect SLA characteristics across peers. The BGP-PE controller might collect SLA characteristics across peers.
This requires an EPE solution as the SLA probes need to be steered This requires an BGP-PE solution as the SLA probes need to be steered
via non-best-path peers. via non-best-path peers.
Unidirectional SLA monitoring of the desired path is likely required. Unidirectional SLA monitoring of the desired path is likely required.
This might be possible when the application is controlled at the This might be possible when the application is controlled at the
source and the receiver side. Unidirectional monitoring dissociates source and the receiver side. Unidirectional monitoring dissociates
the SLA characteristic of the return path (which cannot usually be the SLA characteristic of the return path (which cannot usually be
controlled) from the forward path (the one of interest for pushing controlled) from the forward path (the one of interest for pushing
content from a source to a consumer and the one which can be content from a source to a consumer and the one which can be
controlled). controlled).
Alternatively, Extended Metrics, as defined in Alternatively, Extended Metrics, as defined in
[I-D.ietf-isis-te-metric-extensions] could also be advertised using [I-D.ietf-isis-te-metric-extensions] could also be advertised using
new BGP-LS attributes. new BGP-LS attributes.
4.5. Traffic Matrix 4.5. Traffic Matrix
The EPE controller might collect the traffic matrix to its peers or The BGP-PE controller might collect the traffic matrix to its peers
the final destinations. IPFIX is a likely option. or the final destinations. IPFIX is a likely option.
An alternative option consists in collecting the link utilization 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 [I-D.ietf-idr-ls-distribution]. in the current definition of [RFC7752].
4.6. Business Policies 4.6. Business Policies
The EPE controller should collect business policies. The BGP-PE controller should collect business policies.
4.7. EPE Policy 4.7. BGP-PE Policy
On the basis of all these inputs (and likely others), the EPE On the basis of all these inputs (and likely others), the BGP-PE
Controller decides to steer some demands away from their best BGP Controller decides to steer some demands away from their best BGP
path. path.
The EPE policy is likely expressed as a two-entry segment list where The BGP-PE policy is likely expressed as a two-entry segment list
the first element is the IGP prefix SID of the selected egress border where the first element is the IGP prefix SID of the selected egress
router and the second element is a BGP Peering SID at the selected border router and the second element is a BGP Peering SID at the
egress border router. selected egress border router.
A few examples are provided hereafter: A few examples are provided hereafter:
o Prefer egress PE C and peer AS AS2: {64, 1012}. o Prefer egress PE C and peer AS AS2: {64, 1012}.
o Prefer egress PE C and peer AS AS3 via eBGP peer 198.51.100.6: o Prefer egress PE C and peer AS AS3 via eBGP peer 198.51.100.6:
{64, 1022}. {64, 1022}.
o Prefer egress PE C and peer AS AS3 via eBGP peer 192.0.2.2: {64, o Prefer egress PE C and peer AS AS3 via eBGP peer 192.0.2.2: {64,
1052}. 1052}.
o Prefer egress PE C and peer AS AS3 via interface 198.51.100.14 of o 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}. multi-hop eBGP peer 192.0.2.2: {64, 1042}.
o Prefer egress PE C and any interface to any peer in the group o Prefer egress PE C and any interface to any peer in the group
1060: {64, 1060}. 1060: {64, 1060}.
Note that the first SID could be replaced by a list of segments. 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 This is useful when an explicit path within the domain is required
for traffic-engineering purposes. For example, if the Prefix SID of 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 node B is 60 and the BGP-PE controller would like to steer the
from A to C via B then through the external link to peer D then the traffic from A to C via B then through the external link to peer D
segment list would be {60, 64, 1012}. then the segment list would be {60, 64, 1012}.
5. Programming an input policy 5. Programming an input policy
The detailed/exhaustive description of all the means to implement an The detailed/exhaustive description of all the means to implement an
EPE policy are outside the scope of this document. A few examples BGP-PE policy are outside the scope of this document. A few examples
are provided in this section. are provided in this section.
5.1. At a Host 5.1. At a Host
A static IP/MPLS route can be programmed at the host H. The static 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. The global property of the IGP Prefix SID is particularly to push. The global property of the IGP Prefix SID is particularly
convenient: the same policy could be programmed across hosts convenient: the same policy could be programmed across hosts
connected to different routers. connected to different routers.
5.2. At a router - SR Traffic Engineering tunnel 5.2. At a router - SR Traffic Engineering tunnel
The EPE controller can configure the ingress border router with an SR The BGP-PE controller can configure the ingress border router with an
traffic engineering tunnel T1 and a steering-policy S1 which causes a SR traffic engineering tunnel T1 and a steering-policy S1 which
certain class of traffic to be mapped on the tunnel T1. causes a certain class of traffic to be mapped on the tunnel T1.
The tunnel T1 would be configured to push the required segment list. The tunnel T1 would be configured to push the required segment list.
The tunnel and the steering policy could be configured via PCEP The tunnel and the steering policy could be configured via PCEP
according to [I-D.ietf-pce-segment-routing] and according to [I-D.ietf-pce-segment-routing] and
[I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]). [I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]).
Example: at A Example: at A
Tunnel T1: push {64, 1042} Tunnel T1: push {64, 1042}
IP route L/8 set nhop T1 IP route L/8 set nhop T1
5.3. At a Router - RFC3107 policy route 5.3. At a Router - RFC3107 policy route
The EPE Controller could build a RFC3107 ([RFC3107]) route (from The BGP-PE Controller could build a RFC3107 ([RFC3107]) route (from
scratch) and send it to the ingress router: scratch) and send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g., L/8. o NLRI: the destination prefix to engineer: e.g., L/8.
o Next-Hop: the selected egress border router: C. o Next-Hop: the selected egress border router: C.
o Label: the selected egress peer: 1042. o Label: the selected egress peer: 1042.
o AS path: reflecting the selected valid AS path. o AS path: reflecting the selected valid AS path.
skipping to change at page 15, line 6 skipping to change at page 15, line 6
o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment. o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment.
6. IPv6 6. IPv6
The described solution is applicable to IPv6, either with MPLS-based 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: solution are applicable:
o BGP-LS-based signaling of the external topology and BGP Peering o BGP-LS-based signaling of the external topology and BGP Peering
Segments to the EPE controller. Segments to the BGP-PE controller.
o Collection of various inputs by the EPE controller to come up with o Collection of various inputs by the BGP-PE controller to come up
a policy decision. with a policy decision.
o Programming at an ingress router or source host of the desired EPE o Programming at an ingress router or source host of the desired
policy which consists in a list of segments to push on a defined BGP-PE policy which consists in a list of segments to push on a
traffic class. defined traffic class.
7. Benefits 7. Benefits
The EPE solutions described in this document have the following The BGP-PE solutions described in this document have the following
benefits: benefits:
o No assumption on the iBGP design with AS1. o No assumption on the iBGP design within AS1.
o Next-Hop-Self on the Internet routes propagated to the ingress o Next-Hop-Self on the Internet routes propagated to the ingress
border routers is possible. This is a common design rule to border routers is possible. This is a common design rule to
minimize the number of IGP routes and to avoid importing external minimize the number of IGP routes and to avoid importing external
churn into the internal routing domain. churn into the internal routing domain.
o Consistent support for traffic-engineering within the domain and o Consistent support for traffic-engineering within the domain and
at the external edge of the domain. at the external edge of the domain.
o Support both host and ingress border router EPE policy o Support both host and ingress border router BGP-PE policy
programming. programming.
o EPE functionality is only required on the EPE-enabled egress o BGP-PE functionality is only required on the BGP-PE enabled egress
border router and the EPE controller: an ingress policy can be border router and the BGP-PE controller: an ingress policy can be
programmed at the ingress border router without any new programmed at the ingress border router without any new
functionality. functionality.
o Ability to deploy the same input policy across hosts connected to o Ability to deploy the same input policy across hosts connected to
different routers (avail the global property of IGP prefix SIDs). different routers (avail the global property of IGP prefix SIDs).
8. IANA Considerations 8. IANA Considerations
This document does not request any IANA allocations. This document does not request any IANA allocations.
skipping to change at page 16, line 43 skipping to change at page 16, line 43
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J.,
and M. Chen, "Segment Routing Egress Peer Engineering BGP- and M. Chen, "Segment Routing Egress Peer Engineering BGP-
LS Extensions", draft-ietf-idr-bgpls-segment-routing- LS Extensions", draft-ietf-idr-bgpls-segment-routing-
epe-00 (work in progress), June 2015. epe-02 (work in progress), December 2015.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-12
(work in progress), October 2015.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment- Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions-05 (work in progress), June 2015. routing-extensions-06 (work in progress), December 2015.
[I-D.ietf-isis-te-metric-extensions] [I-D.ietf-isis-te-metric-extensions]
Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, Previdi, S., Giacalone, S., Ward, D., Drake, J., and W.
A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
(TE) Metric Extensions", draft-ietf-isis-te-metric- draft-ietf-isis-te-metric-extensions-11 (work in
extensions-07 (work in progress), June 2015. progress), February 2016.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-03 (work in progress), June segment-routing-extensions-05 (work in progress), March
2015. 2016.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05 (work in progress), June 2015. routing-extensions-07 (work in progress), March 2016.
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-04 (work in Model", draft-ietf-pce-pce-initiated-lsp-05 (work in
progress), April 2015. progress), October 2015.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce- "PCEP Extensions for Segment Routing", draft-ietf-pce-
segment-routing-06 (work in progress), August 2015. segment-routing-06 (work in progress), August 2015.
[I-D.ietf-spring-problem-statement] [I-D.ietf-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., and R. Shakir, "SPRING Problem Statement Horneffer, M., and R. Shakir, "SPRING Problem Statement
and Requirements", draft-ietf-spring-problem-statement-04 and Requirements", draft-ietf-spring-problem-statement-07
(work in progress), April 2015. (work in progress), March 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft- and R. Shakir, "Segment Routing Architecture", draft-ietf-
ietf-spring-segment-routing-06 (work in progress), October spring-segment-routing-07 (work in progress), December
2015. 2015.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane", and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-01 (work in draft-ietf-spring-segment-routing-mpls-04 (work in
progress), May 2015. progress), March 2016.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
skipping to change at page 18, line 42 skipping to change at page 19, line 4
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
Email: exa@fb.com Email: exa@fb.com
Daniel Ginsburg Daniel Ginsburg
Yandex Yandex
RU RU
Email: dbg@yandex-team.ru Email: dbg@yandex-team.ru
Dmitry Afanasiev Dmitry Afanasiev
Yandex Yandex
RU RU
Email: fl0w@yandex-team.ru Email: fl0w@yandex-team.ru
Keyur Patel
Cisco Systems, Inc.
US
Email: keyupate@cisco.com
Steve Shaw
Dropbox, Inc.
185 Berry Street, Suite 400
San Francisco, CA 94107
US
Email: shaw@dropbox.com
 End of changes. 78 change blocks. 
133 lines changed or deleted 129 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/