draft-ietf-spring-segment-routing-central-epe-04.txt   draft-ietf-spring-segment-routing-central-epe-05.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: August 20, 2017 E. Aries Expires: September 11, 2017 E. Aries
Juniper Networks Juniper Networks
D. Afanasiev D. Afanasiev
Yandex Yandex
February 16, 2017 March 10, 2017
Segment Routing Centralized BGP Egress Peer Engineering Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-04 draft-ietf-spring-segment-routing-central-epe-05
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 a
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 (SDN) controller to program any BGP-EPE solution allows a centralized (Software Defined Network, SDN)
egress peer policy at ingress border routers or at hosts within the controller to program any egress peer policy at ingress border
domain. routers or at hosts within the domain.
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].
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
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 August 20, 2017. This Internet-Draft will expire on September 11, 2017.
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 (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. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6
3. Distribution of Topology and TE Information using BGP-LS . . 7 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 . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 11 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
4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12
4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 4.7. BGP-EPE 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 . . . . . . . . . . . 14 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . 15 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15
6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Manageability Considerations . . . . . . . . . . . . . . . . 16 9. Manageability Considerations . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The document is structured as follows: The document is structured as follows:
o Section 1 states the BGP-EPE problem statement and provides the o Section 1 states the BGP-EPE problem statement and provides the
key references. key 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.
skipping to change at page 3, line 43 skipping to change at page 3, line 41
o Section 4 overviews the components of a centralized BGP-EPE o Section 4 overviews the components of a centralized BGP-EPE
controller. The definition of the BGP-EPE controller is outside controller. The definition of the BGP-EPE controller is outside
the scope of this document. the 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 BGP-EPE controller to implement a BGP-EPE policy at an centralized BGP-EPE controller to implement a BGP-EPE 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 BGP-EPE input exhaustive definition of all the means to program an BGP-EPE 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 and MPLS For editorial reasons, the solution is described with IPv6 addresses
SID. This solution is equally applicable to IPv6 with either MPLS-SR and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS
or IPv6 SR. SIDs and also to IPv6 with native IPv6 SIDs.
1.1. Segment Routing Documents
The main references for this document are:
o SR Problem Statement: [RFC7855].
o SR Architecture: [I-D.ietf-spring-segment-routing].
o Distribution of External Topology and TE Information using BGP:
[I-D.ietf-idr-bgpls-segment-routing-epe].
The SR instantiation in the MPLS dataplane is described in
[I-D.ietf-spring-segment-routing-mpls].
The SR IGP protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The Segment Routing PCE protocol extensions are defined in
[I-D.ietf-pce-segment-routing].
1.2. 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". We 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
skipping to change at page 5, line 9 skipping to change at page 4, line 35
o The solution MUST be applicable to any type of EPE router. While o The solution MUST be applicable to any type of EPE router. While
"Egress Peer Engineering" refers to "External" peering, the "Egress Peer Engineering" refers to "External" peering, the
solution MUST also be applicable to a router having internal solution MUST also be applicable to a router having internal
peers. 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 EPE or directly at an 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 MUST 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---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8 | |\\ \ +------+ /| AS 4 |---M/8
| | \\ +-E |/ +------+ | | \\ +-E |/ +------+
| X | \\ | K | X | \\ | K
| | +===F AS 3 | | | +===F AS 3 |
+---------+ +------+ +---------+ +------+
Figure 1: Reference Diagram Figure 1: Reference Diagram
IPv4 addressing: IP addressing:
o C's interface to D: 198.51.100.1/30, D's interface: o C's interface to D: 2001:db8:cd::c/64, D's interface:
198.51.100.2/30 2001:db8:cd::d/64
o C's interface to E: 198.51.100.5/30, E's interface: o C's interface to E: 2001:db8:ce::c/64, E's interface:
198.51.100.6/30 2001:db8:ce::e/64
o C's upper interface to F: 198.51.100.9/30, F's interface: o C's upper interface to F: 2001:db8:cf1::c/64, F's interface:
198.51.100.10/30 2001:db8:cf1::f/64
o C's lower interface to F: 198.51.100.13/30, F's interface: o C's lower interface to F: 2001:db8:cf2::c/64, F's interface:
198.51.100.14/30 2001:db8:cf2::f/64
o BGP router-ID of D: 192.0.2.4/32 o BGP router-ID of C: 192.0.2.3
o BGP router-ID of E: 192.0.2.3/32 o BGP router-ID of D: 192.0.2.4
o Loopback of F used for eBGP multi-hop peering to C: 192.0.2.2/32 o BGP router-ID of E: 192.0.2.5
o C's loopback is 203.0.113.3/32 with SID 64 o BGP router-ID of F: 192.0.2.6
C's BGP peering: o Loopback of F used for eBGP multi-hop peering to C:
2001:db8:f::f/128
o Single-hop eBGP peering with neighbor 198.51.100.2 (D) o C's loopback is 2001:db8:c::c/128 with SID 64
o Single-hop eBGP peering with neighbor 198.51.100.6 (E) C's BGP peering:
o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F) o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)
o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E)
o Multi-hop eBGP peering with F on IP address 2001:db8:f::f (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 to 2001:db8:f::f/128 via 2001:db8:cf1::f
o Static route 192.0.2.2/32 via 198.51.100.14 o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f
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 for E and 192.0.2.2 for F) set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F)
X is the BGP-EPE controller within AS1 domain. X is the BGP-EPE 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 BGP-EPE capable node and corresponding to its attached defined by BGP-EPE capable node and corresponding to its attached
peers. These segments are called BGP peering segments or BGP Peering peers. These segments are called BGP peering segments or BGP Peering
skipping to change at page 6, line 41 skipping to change at page 6, line 34
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 Egress Peering Engineering policy applied at an minimum, a BGP Egress Peering Engineering policy applied at an
ingress EPE involves two segments: the Node SID of the chosen egress ingress EPE involves two segments: the Node SID of the chosen egress
EPE and then the BGP Peering Segment for the chosen egress EPE peer EPE and then the BGP Peering Segment for the chosen egress EPE peer
or peering interface. or peering 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: PeerNode SID, PeerAdj SID and PeerSet SID. segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID.
A Peer Node Segment is a segment describing a peer, including the SID A Peer Node Segment is a segment describing a peer, including the SID
(PeerNode SID) allocated to it. (PeerNode SID) allocated to it.
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 10
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 session is established between the BGP-EPE enabled
border router and the BGP-EPE controller. 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, E and F). o A PeerNode segment for each of its defined peer (D: 1012, E: 1022
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
(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).
o A PeerSet segment to the set of peers (E and F). In this case the o A PeerSet segment to the set of peers (E and F). In this case the
PeerSet represents a set of peers (E, F) belonging to the same AS PeerSet represents a set of peers (E, F) belonging to the same AS
(AS 3). (AS 3).
C programs its forwarding table accordingly: C programs its forwarding table accordingly:
skipping to change at page 7, line 46 skipping to change at page 7, line 41
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 (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.4, AS2 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
198.51.100.1, 198.51.100.2 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 (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.3, AS3 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.5, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
198.51.100.5, 198.51.100.6 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 (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.2, AS3 o Peer Descriptors (peer BGP 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):
203.0.113.3, 192.0.2.2 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 (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1
o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.6, AS3
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.2, AS3
o Link Descriptors (IP interface address, neighbor IP address): o Link Descriptors (IP interface address, neighbor IP address):
198.51.100.9, 198.51.100.10 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 (router-ID, ASN): 203.0.113.3 , AS1 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3 , AS1
o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.2, AS3 o Peer 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):
198.51.100.13, 198.51.100.14 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)
An BGP-EPE enabled border router SHOULD allocate a FRR backup entry A BGP-EPE enabled border router MAY allocate a FRR backup entry on a
on a per BGP Peering SID basis: per BGP Peering SID basis (assuming inter-AS agreement on the FRR
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 11 skipping to change at page 10, line 7
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 the different types of possible backups using the We illustrate different types of possible backups using the reference
reference diagram and considering the Peering SIDs allocated by C. 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 46 skipping to change at page 10, line 42
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 an In this section, we 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 engineered peers. destination prefixes) advertised by all the BGP-EPE enabled border
router.
This could be realized by setting an iBGP session with the BGP-EPE This could be realized by setting an iBGP session with the BGP-EPE
enabled border router, with "add-path all" and the original next-hop enabled border router, with the router configured to advertise all
paths using BGP add-path [RFC7911] 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
BGP-EPE controller: BGP-EPE controller:
o NLRI <L/8>, nhop 198.51.100.2, AS Path {AS 2, 4} o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2,
4}
* X (i.e.: the BGP-EPE controller) knows that C receives a path * X (i.e.: the BGP-EPE controller) knows that C receives a path
to L/8 via neighbor 198.51.100.2 of AS2. to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2.
o NLRI <L/8>, nhop 198.51.100.6, AS Path {AS 3, 4} o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, 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 2001:db8:abcd::/48 via
of AS2. neighbor 2001:db8:ce::e of AS2.
o NLRI <L/8>, nhop 192.0.2.2, AS Path {AS 3, 4} o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, 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 2001:db8:abcd::/48 via AS3
192.0.2.2 via neighbor 2001:db8:f::f
An alternative option would be for an 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) to track the Adj-RIB-In of BGP-EPE enabled
border routers. 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
Thanks to the collected BGP-LS routes described in the section 2 Thanks to the collected BGP-LS routes described in section 2, the
(BGP-LS advertisements), the BGP-EPE controller is able to maintain BGP-EPE controller is able to maintain an accurate description of the
an accurate description of the egress topology of node C. egress topology of node C. Furthermore, the BGP-EPE controller is
Furthermore, the BGP-EPE controller is able to associate BGP Peering able to associate BGP Peering SIDs to the various components of the
SIDs to the various components of the external topology. external topology.
4.4. SLA characteristics of each peer 4.4. SLA characteristics of each peer
The BGP-EPE controller might collect SLA characteristics across The BGP-EPE controller might collect SLA characteristics across
peers. This requires an BGP-EPE solution as the SLA probes need to peers. This requires an BGP-EPE solution as the SLA probes need to
be steered via non-best-path peers. be steered 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
skipping to change at page 12, line 33 skipping to change at page 12, line 33
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 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 collect business policies. The BGP-EPE controller should be configured or collect (through any
mean) business policies. The mechanisms through which these policies
are configured or collected is outside the scope of this document.
4.7. BGP-EPE Policy 4.7. BGP-EPE Policy
On the basis of all these inputs (and likely others), the BGP-EPE On the basis of all these inputs (and likely others), the BGP-EPE
Controller decides to steer some demands away from their best BGP Controller decides to steer some demands away from their best BGP
path. path.
The BGP-EPE policy is likely expressed as a two-entry segment list The BGP-EPE policy is likely expressed as a two-entry segment list
where the first element is the IGP prefix SID of the selected egress where the first element is the IGP prefix SID of the selected egress
border router and the second element is a BGP Peering SID at the border router and the second element is a BGP Peering SID at the
selected egress border router. 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}. "64" being the SID
of PE C as defined in Section 1.1.
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 2001:db8:ce::e,
{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 2001:db8:f::f,
1052}. {64, 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 2001:db8:cf2::f
multi-hop eBGP peer 192.0.2.2: {64, 1042}. of multi-hop eBGP peer 2001:db8:f::f, {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 BGP-EPE controller would like to steer the node B is 60 and the BGP-EPE controller would like to steer the
traffic from A to C via B then through the external link to peer D traffic from A to C via B then through the external link to peer D
then the segment list would be {60, 64, 1012}. then the segment list would be {60, 64, 1012}.
skipping to change at page 13, line 43 skipping to change at page 13, line 46
hosts, which is convenient. hosts, which is convenient.
5.2. At a router - SR Traffic Engineering tunnel 5.2. At a router - SR Traffic Engineering tunnel
The BGP-EPE controller can configure the ingress border router with The BGP-EPE controller can configure the ingress border router with
an SR traffic engineering tunnel T1 and a steering-policy S1 which an SR traffic engineering tunnel T1 and a steering-policy S1 which
causes a certain class of traffic to be mapped on the tunnel T1. 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 multiple
according to [I-D.ietf-pce-segment-routing] and means. A few examples are given below:
[I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]).
Example: at A o PCEP according to [I-D.ietf-pce-segment-routing] and
[I-D.ietf-pce-pce-initiated-lsp].
Tunnel T1: push {64, 1042} o Netconf ([RFC6241]).
IP route L/8 set nhop T1
o Other static or ephemeral APIs
Example: at router A (Figure 1).
Tunnel T1: push {64, 1042}
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 ([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.
skipping to change at page 14, line 26 skipping to change at page 14, line 33
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
ingress router. ingress router.
This RFC3107 policy route "overwrites" an equivalent or less-specific This RFC3107 policy route "overwrites" an equivalent or less-specific
"best path". As the best-path is changed, this BGP-EPE input policy "best path". As the best-path is changed, this BGP-EPE input policy
option may influence the path propagated to the upstream peer/ option may influence the path propagated to the upstream peer/
customers. Indeed, implementations treating the SAFI-1 and SAFI-4 customers. Indeed, implementations treating the SAFI-1 and SAFI-4
routes for a given prefix as comparable would trigger a BGP WITHDRAW routes for a given prefix as comparable would trigger a BGP WITHDRAW
of the SAFI-1 route to them BGP upstream peers. of the SAFI-1 route to their BGP upstream peers.
5.4. At a Router - VPN policy route 5.4. At a Router - VPN policy route
The BGP-EPE Controller could build a VPNv4 route (from scratch) and The BGP-EPE Controller could build a VPNv4 route (from scratch) and
send it to the ingress router: 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.
skipping to change at page 15, line 5 skipping to change at page 15, line 9
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
ingress router in the related VRF. ingress router in the related VRF.
The related VRF must be preconfigured. A VRF fallback to the main The related VRF must be preconfigured. A VRF fallback to the main
FIB might be beneficial to avoid replicating all the "normal" FIB might be beneficial to avoid replicating all the "normal"
Internet paths in each VRF. Internet paths in each VRF.
5.5. At a Router - Flowspec route 6. IPv6 Dataplane
A BGP-EPE Controller builds a FlowSpec route and sends it to the
ingress router to engineer:
o Dissemination of Flow Specification Rules ([RFC5575].
o Destination/Source IP Addresses, IP Protocol, Destination/Source
port (+1 component).
o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment.
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 BGP-EPE controller. Segments to the BGP-EPE controller.
o Collection of various inputs by the BGP-EPE controller to come up o Collection of various inputs by the BGP-EPE controller to come up
with a policy decision. with a policy decision.
skipping to change at page 16, line 8 skipping to change at page 15, line 49
o Support both host and ingress border router BGP-EPE policy o Support both host and ingress border router BGP-EPE policy
programming. programming.
o BGP-EPE functionality is only required on the BGP-EPE enabled o BGP-EPE functionality is only required on the BGP-EPE enabled
egress border router and the BGP-EPE controller: an ingress policy egress border router and the BGP-EPE controller: an ingress policy
can be programmed at the ingress border router without any new can be programmed at the ingress border router without any new
functionality. 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 (assuming 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.
9. Manageability Considerations 9. Manageability Considerations
The BGP-EPE use-case described in this document requires BGP-LS The BGP-EPE use-case described in this document requires BGP-LS
([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
skipping to change at page 17, line 18 skipping to change at page 17, line 14
[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>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>. <http://www.rfc-editor.org/info/rfc3107>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
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>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., Dong, J., Previdi, S., Filsfils, C., Patel, K., Ray, S., Dong, J.,
and M. Chen, "Segment Routing BGP Egress Peer Engineering and M. Chen, "Segment Routing BGP Egress Peer Engineering
BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing-
epe-09 (work in progress), February 2017. epe-10 (work in progress), March 2017.
[I-D.ietf-idr-te-pm-bgp] [I-D.ietf-idr-te-pm-bgp]
Previdi, S., Wu, Q., Gredler, H., Ray, S., Previdi, S., Wu, Q., Gredler, H., Ray, S.,
jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg, jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg,
"BGP-LS Advertisement of IGP Traffic Engineering "BGP-LS Advertisement of IGP Traffic Engineering
Performance Metric Extensions", draft-ietf-idr-te-pm- Performance Metric Extensions", draft-ietf-idr-te-pm-
bgp-04 (work in progress), October 2016. bgp-04 (work in progress), October 2016.
[I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
"IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-09 (work in progress), October
2016.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-07 (work in progress), October
2016.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-10 (work in progress), October 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-07 (work in Model", draft-ietf-pce-pce-initiated-lsp-09 (work in
progress), July 2016. progress), March 2017.
[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.,
Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and
J. Hardwick, "PCEP Extensions for Segment Routing", draft- J. Hardwick, "PCEP Extensions for Segment Routing", draft-
ietf-pce-segment-routing-08 (work in progress), October ietf-pce-segment-routing-08 (work in progress), October
2016. 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. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-10 (work in progress), November spring-segment-routing-11 (work in progress), February
2016. 2017.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-07 (work in progress), February 2017.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
[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>. <http://www.rfc-editor.org/info/rfc7810>.
[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, <http://www.rfc-editor.org/info/rfc7855>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://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 (editor)
 End of changes. 79 change blocks. 
168 lines changed or deleted 127 lines changed or added

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