draft-ietf-spring-segment-routing-central-epe-06.txt   draft-ietf-spring-segment-routing-central-epe-07.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi
Intended status: Informational Cisco Systems, Inc. Intended status: Informational G. Dawra, Ed.
Expires: December 22, 2017 E. Aries Expires: May 1, 2018 Cisco Systems, Inc.
E. Aries
Juniper Networks Juniper Networks
D. Afanasiev D. Afanasiev
Yandex Yandex
June 20, 2017 October 28, 2017
Segment Routing Centralized BGP Egress Peer Engineering Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-06 draft-ietf-spring-segment-routing-central-epe-07
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 while maintaining per-flow state
per-flow state only at the ingress node of the SR domain. 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 a dataplane with no change on the forwarding plane. It requires a
minor extension to the existing link-state routing protocols. minor 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 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 Network, SDN)
controller to program any egress peer policy at ingress border controller to program any egress peer policy at ingress border
routers or at hosts within the domain. routers or at hosts within the domain.
skipping to change at page 1, line 48 skipping to change at page 1, line 49
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 December 22, 2017. This Internet-Draft will expire on May 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6
3. Distribution of Topology and TE Information using BGP-LS . . 6 3. Distribution of Topology and TE Information using BGP-LS . . 6
3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7
3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 8 3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 7
3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8
3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8
3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9
3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9
4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 4. BGP-EPE 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 . . . . . . . . . . . . 12 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12
4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12
skipping to change at page 4, line 7 skipping to change at page 4, line 7
1.1. Problem Statement 1.1. Problem Statement
The BGP-EPE problem statement is defined in [RFC7855]. The BGP-EPE problem statement is defined in [RFC7855].
A centralized controller should be able to instruct an ingress A centralized controller should be able to instruct an ingress
Provider Edge router (PE) or a content source within the domain to Provider Edge router (PE) or a content source within the domain to
use a specific egress PE and a specific external interface/neighbor use a specific egress PE and a specific external interface/neighbor
to reach a particular destination. to reach a particular destination.
We call this solution "BGP-EPE" for "BGP Egress Peer Engineering". Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering".
The centralized controller is called the "BGP-EPE Controller". The The centralized controller is called the "BGP-EPE Controller". The
egress border router where the BGP-EPE traffic steering functionality egress border router where the BGP-EPE traffic steering functionality
is implemented is called a BGP-EPE enabled border router. The input is implemented is called a BGP-EPE enabled border router. The input
policy programmed at an ingress border router or at a source host is policy programmed at an ingress border router or at a source host is
called a BGP-EPE policy. called a BGP-EPE 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 support any deployed iBGP schemes (RRs,
deployed iBGP schemes (RRs, confederations or iBGP full meshes) confederations or iBGP full meshes).
and MUST be able to support all of them.
o The solution MUST be applicable to any type of EPE router. While o The solution MUST be applicable to both routers with external and
"Egress Peer Engineering" refers to "External" peering, the internal peers.
solution MUST also be applicable to a router having internal
peers.
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 BGP-EPE policy at an o The solution MUST accommodate an ingress BGP-EPE policy at an
ingress PE or directly at a source host within the domain. ingress PE or directly at a source host within the domain.
o The solution MUST support automated Fast Reroute (FRR) and fast o The solution MAY support automated Fast Reroute (FRR) and fast
convergence mechanisms. 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---+ \| |
skipping to change at page 6, line 49 skipping to change at page 6, line 37
A Peer Adjacency Segment is a segment describing a link, including A Peer Adjacency Segment is a segment describing a link, including
the SID (PeerAdj SID) allocated to it. the SID (PeerAdj SID) allocated to it.
A Peer Set Segment is a segment describing a link or a node that is A Peer Set Segment is a segment describing a link or a node that is
part of the set, including the SID (PeerSet SID) allocated to the part of the set, including the SID (PeerSet SID) allocated to the
set. set.
3. Distribution of Topology and TE Information using BGP-LS 3. Distribution of 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 BGP-EPE enabled design, a BGP-LS [RFC7752] session is established between the BGP-EPE
border router and the BGP-EPE controller. enabled border router and the BGP-EPE 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: 1012, E: 1022 o A PeerNode segment for each of its defined peer (D: 1012, E: 1022
and F: 1052). and F: 1052).
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
skipping to change at page 7, line 41 skipping to change at page 7, line 30
C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each
such BGP-LS route is described in the following subsections according such BGP-LS route is described in the following subsections according
to 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. PeerNode SID to D 3.1. PeerNode SID to D
Descriptors: Descriptors:
o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000
o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address):
2001:db8:cd::c, 2001:db8:cd::d 2001:db8:cd::c, 2001:db8:cd::d
Attributes: Attributes:
o PeerNode SID: 1012 o PeerNode SID: 1012
3.2. PeerNode SID to E 3.2. PeerNode SID to E
Descriptors: Descriptors:
o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)):
192.0.2.3, AS1, 1000
o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.5, AS3 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
2001:db8:ce::c, 2001:db8:ce::e 2001:db8:ce::c, 2001:db8:ce::e
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 [RFC7752] o Link Attributes: see section 3.3.2 of [RFC7752]
3.3. PeerNode SID to F 3.3. PeerNode SID to F
Descriptors: Descriptors:
o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)):
192.0.2.3, AS1, 1000
o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.6, AS3 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
2001:db8:c::c, 2001:db8:f::f 2001:db8:c::c, 2001:db8:f::f
Attributes: Attributes:
o PeerNode SID: 1052 o PeerNode SID: 1052
o PeerSetSID: 1060 o PeerSetSID: 1060
3.4. First PeerAdj to F 3.4. First PeerAdj to F
Descriptors: Descriptors:
o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)):
192.0.2.3, AS1, 1000
o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.6, AS3 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
2001:db8:cf1::c, 2001:db8:cf1::f 2001:db8:cf1::c, 2001:db8:cf1::f
Attributes: Attributes:
o PeerAdj-SID: 1032 o PeerAdj-SID: 1032
o LinkAttributes: see section 3.3.2 of [RFC7752] o LinkAttributes: see section 3.3.2 of [RFC7752]
3.5. Second PeerAdj to F 3.5. Second PeerAdj to F
Descriptors: Descriptors:
o Node Descriptors (BGP router-ID, ASN): 192.0.2.3 , AS1 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)):
192.0.2.3 , AS1
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 o Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
2001:db8:cf2::c, 2001:db8:cf2::f 2001:db8:cf2::c, 2001:db8:cf2::f
Attributes: Attributes:
o PeerAdj-SID: 1042 o PeerAdj-SID: 1042
o LinkAttributes: see section 3.3.2 of [RFC7752] o LinkAttributes: see section 3.3.2 of [RFC7752]
3.6. Fast Reroute (FRR) 3.6. Fast Reroute (FRR)
A BGP-EPE enabled border router MAY allocate a FRR backup entry on a A BGP-EPE enabled border router MAY allocate a FRR backup entry on a
per BGP Peering SID basis (assuming inter-AS agreement on the FRR per BGP Peering SID basis. One example is as follows:
strategy/policy). One example is as follows:
o PeerNode SID o PeerNode SID
1. If multi-hop, backup via the remaining PeerADJ SIDs (if 1. If multi-hop, backup via the remaining PeerADJ SIDs (if
available) to the same peer. available) to the same peer.
2. Else backup via another PeerNode SID to the same AS. 2. Else backup via another PeerNode SID to the same AS.
3. Else pop the PeerNode SID and perform an IP lookup. 3. Else pop the PeerNode SID and perform an IP lookup.
skipping to change at page 10, line 7 skipping to change at page 10, line 5
2. Else backup via a PeerNode SID to the same AS. 2. Else backup via a PeerNode SID to the same AS.
3. Else pop the PeerNode SID and perform an IP lookup. 3. Else pop the PeerNode SID and perform an IP lookup.
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. 2. Else pop the PeerNode SID and IP lookup.
We illustrate different types of possible backups using the reference Let's illustrate different types of possible backups using the
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:
o Upon the failure of the connected link CE, C can reroute all the o Upon the failure of the connected link CE, C can reroute all the
traffic onto the link to PeerNode SID 1052 (F). traffic onto the link to PeerNode SID 1052 (F).
skipping to change at page 10, line 42 skipping to change at page 10, line 40
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. BGP-EPE Controller 4. BGP-EPE Controller
In this section, we provide a non-exhaustive set of inputs that a 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- BGP-EPE controller would likely collect such as to perform the BGP-
EPE policy decision. EPE 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 BGP-EPE controller should collect all the BGP paths (i.e.: IP 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. router.
skipping to change at page 11, line 32 skipping to change at page 11, line 32
* X knows that C receives a path to 2001:db8:abcd::/48 via * X knows that C receives a path to 2001:db8:abcd::/48 via
neighbor 2001:db8:ce::e of AS2. neighbor 2001:db8:ce::e of AS2.
o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3, o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3,
4} 4}
* X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 * X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3
via neighbor 2001:db8:f::f via neighbor 2001:db8:f::f
An alternative option would be for a BGP-EPE collector to use BGP An alternative option would be for a BGP-EPE collector to use BGP
Monitoring Protocol (BMP) to track the Adj-RIB-In of BGP-EPE enabled Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP-
border routers. EPE enabled border routers.
4.2. Intra-Domain Topology 4.2. Intra-Domain Topology
The BGP-EPE controller should collect the internal topology and the The BGP-EPE 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
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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 [RFC7810] could also Alternatively, Extended Metrics, as defined in [RFC7810] could also
be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]).
4.5. Traffic Matrix 4.5. Traffic Matrix
The BGP-EPE controller might collect the traffic matrix to its peers The BGP-EPE controller might collect the traffic matrix to its peers
or the final destinations. IPFIX is a likely option. or the final destinations. IPFIX [RFC7011] 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 [RFC7752]. in the current definition of [RFC7752].
4.6. Business Policies 4.6. Business Policies
The BGP-EPE controller should be configured or collect (through any The BGP-EPE controller should be configured or collect (through any
mean) business policies. The mechanisms through which these policies mean) business policies. The mechanisms through which these policies
are configured or collected is outside the scope of this document. are configured or collected is outside the scope of this document.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
o Other static or ephemeral APIs o Other static or ephemeral APIs
Example: at router A (Figure 1). Example: at router A (Figure 1).
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
5.3. At a Router - RFC3107 policy route 5.3. At a Router - RFC3107 policy route
The BGP-EPE Controller could build a RFC3107 ([RFC3107]) route (from The BGP-EPE Controller could build a RFC3107
scratch) and send it to the ingress router: ([I-D.ietf-mpls-rfc3107bis]) route (from 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.
o Some BGP policy to ensure it will be selected as best by the o Some BGP policy to ensure it will be selected as best by the
skipping to change at page 16, line 22 skipping to change at page 16, line 22
([RFC7752]) extensions that are described in ([RFC7752]) extensions that are described in
[I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions [I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions
consists of additional BGP-LS descriptors and TLVs that will follow consists of additional BGP-LS descriptors and TLVs that will follow
the same. Manageability functions of BGP-LS, described in [RFC7752] the same. Manageability functions of BGP-LS, described in [RFC7752]
also apply to the extensions required by the EPE use-case. also apply to the extensions required by the EPE use-case.
The operator MUST be capable of configuring, enabling, disabling the The operator MUST be capable of configuring, enabling, disabling the
advertisement of the EPE information as well as to control which advertisement of the EPE information as well as to control which
information is advertised to which internal or external peer. This information is advertised to which internal or external peer. This
is not different from what is required by a BGP speaker in terms of is not different from what is required by a BGP speaker in terms of
information origination and advertisement. In addition, the information origination and advertisement.
advertisement of EPE information MUST conform to standard BGP
advertisement and propagation rules (iBGP, eBGP, Route-Reflectors,
Confederations).
10. Security Considerations 10. Security Considerations
[RFC7752] defines BGP-LS NLRIs and their associated security aspects. [RFC7752] defines BGP-LS NLRIs and their associated security aspects.
[I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS
extensions required by the BGP-EPE mechanisms described in this extensions required by the BGP-EPE mechanisms described in this
document. BGP-EPE BGP-LS extensions also include the related document. BGP-EPE BGP-LS extensions also include the related
security. security.
skipping to change at page 17, line 5 skipping to change at page 16, line 47
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Acee Lindem for his comments and The authors would like to thank Acee Lindem for his comments and
contribution. contribution.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-13 (work in progress), June 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-13 (work
in progress), October 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
and A. Bierman, Ed., "Network Configuration Protocol S. Ray, "North-Bound Distribution of Link-State and
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, Traffic Engineering (TE) Information Using BGP", RFC 7752,
<http://www.rfc-editor.org/info/rfc6241>. DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-12 (work in progress), April 2017.
[I-D.ietf-idr-te-pm-bgp] [I-D.ietf-idr-te-pm-bgp]
Previdi, S., Wu, Q., Gredler, H., Ray, S., Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S.,
jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg, Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of
"BGP-LS Advertisement of IGP Traffic Engineering IGP Traffic Engineering Performance Metric Extensions",
Performance Metric Extensions", draft-ietf-idr-te-pm- draft-ietf-idr-te-pm-bgp-08 (work in progress), August
bgp-05 (work in progress), April 2017. 2017.
[I-D.ietf-mpls-rfc3107bis]
Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", draft-ietf-mpls-rfc3107bis-04 (work in
progress), August 2017.
[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-09 (work in Model", draft-ietf-pce-pce-initiated-lsp-11 (work in
progress), March 2017. progress), October 2017.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-09 (work in progress), draft-ietf-pce-segment-routing-10 (work in progress),
April 2017. October 2017.
[I-D.ietf-spring-segment-routing] [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and A. Bierman, Ed., "Network Configuration Protocol
and R. Shakir, "Segment Routing Architecture", draft-ietf- (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
spring-segment-routing-11 (work in progress), February <https://www.rfc-editor.org/info/rfc6241>.
2017.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
S. Ray, "North-Bound Distribution of Link-State and "Specification of the IP Flow Information Export (IPFIX)
Traffic Engineering (TE) Information Using BGP", RFC 7752, Protocol for the Exchange of Flow Information", STD 77,
DOI 10.17487/RFC7752, March 2016, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7011>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016, RFC 7810, DOI 10.17487/RFC7810, May 2016,
<http://www.rfc-editor.org/info/rfc7810>. <https://www.rfc-editor.org/info/rfc7810>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <http://www.rfc-editor.org/info/rfc7855>. 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911, "Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016, DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>. <https://www.rfc-editor.org/info/rfc7911>.
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
Stefano Previdi (editor) Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Gaurav Dawra (editor)
Cisco Systems, Inc.
USA
Email: gdawra@cisco.com
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale CA 94089 Sunnyvale CA 94089
US US
Email: exa@juniper.net Email: exa@juniper.net
Dmitry Afanasiev Dmitry Afanasiev
Yandex Yandex
RU RU
Email: fl0w@yandex-team.ru Email: fl0w@yandex-team.ru
 End of changes. 46 change blocks. 
85 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/