rfc9087.original   rfc9087.txt 
Network Working Group C. Filsfils, Ed. Internet Engineering Task Force (IETF) C. Filsfils, Ed.
Internet-Draft S. Previdi Request for Comments: 9087 S. Previdi
Intended status: Informational G. Dawra, Ed. Category: Informational G. Dawra, Ed.
Expires: June 24, 2018 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
E. Aries E. Aries
Juniper Networks Juniper Networks
D. Afanasiev D. Afanasiev
Yandex Yandex
December 21, 2017 August 2021
Segment Routing Centralized BGP Egress Peer Engineering Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-10
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 for the
flow through any topological path while maintaining per-flow state enforcement of a flow through any topological path while maintaining
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 a data plane 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 Networking,
controller to program any egress peer policy at ingress border or SDN) controller to program any egress peer policy at ingress
routers or at hosts within the domain. border routers or at hosts within the domain.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on June 24, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9087.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2021 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
(https://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
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement
2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 1.2. Requirements Language
3. Distribution of Topology and TE Information using BGP-LS . . 6 2. BGP Peering Segments
3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 3. Distribution of Topology and TE Information Using BGP-LS
3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 7 3.1. PeerNode SID to D
3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 3.2. PeerNode SID to E
3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 3.3. PeerNode SID to F
3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 3.4. First PeerAdj to F
3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 3.5. Second PeerAdj to F
4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 3.6. Fast Reroute (FRR)
4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 4. BGP-EPE Controller
4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 4.1. Valid Paths from Peers
4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 4.2. Intra-Domain Topology
4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 4.3. External Topology
4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.4. SLA Characteristics of Each Peer
4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.5. Traffic Matrix
4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies
5. Programming an input policy . . . . . . . . . . . . . . . . . 13 4.7. BGP-EPE Policy
5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Programming an Input Policy
5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 5.1. At a Host
5.3. At a Router - BGP Labeled Unicast route (RFC8277) . . . . 14 5.2. At a Router - SR Traffic-Engineering Tunnel
5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 5.3. At a Router - Unicast Route Labeled Using BGP (RFC 8277)
6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. At a Router - VPN Policy Route
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IPv6 Data Plane
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Benefits
9. Manageability Considerations . . . . . . . . . . . . . . . . 16 8. IANA Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Manageability Considerations
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.2. Informative References
13.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors
Authors' Addresses
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 * 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 * 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 * Section 3 describes the automated allocation of BGP Peering
Segment-IDs (SIDs) by the BGP-EPE enabled egress border router and Segment-IDs (SIDs) by the BGP-EPE-enabled egress border router and
the automated signaling of the external peering topology and the the automated signaling of the external peering topology and the
related BGP Peering SID's to the collector related BGP Peering SIDs to the collector [RFC9086].
[I-D.ietf-idr-bgpls-segment-routing-epe].
o Section 4 overviews the components of a centralized BGP-EPE * 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 * 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 a 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 with IPv6 addresses For editorial reasons, the solution is described with IPv6 addresses
and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS
SIDs and also to IPv6 with native IPv6 SIDs. SIDs and also to IPv6 with native IPv6 SIDs.
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 (PE) router 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.
Let's 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 * 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. VPN Routing and Forwarding (VRF) instance and allocate labels on a
per-route or per-path basis.
o The solution MUST support any deployed iBGP schemes (RRs, * The solution MUST support any deployed Internal BGP (iBGP) schemes
confederations or iBGP full meshes). (Route Reflectors (RRs), confederations, or iBGP full meshes).
o The solution MUST be applicable to both routers with external and * The solution MUST be applicable to both routers with external and
internal peers. internal peers.
o The solution should minimize the need for new BGP capabilities at * 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 * The solution MUST accommodate an ingress BGP-EPE policy at an
ingress PE or directly at a source within the domain. ingress PE or directly at a source within the domain.
o The solution MAY support automated Fast Reroute (FRR) and fast * 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---+ \| |
| |\\ \ +------+ /| 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
IP addressing: IP addressing:
o C's interface to D: 2001:db8:cd::c/64, D's interface: * C's interface to D: 2001:db8:cd::c/64, D's interface:
2001:db8:cd::d/64 2001:db8:cd::d/64
o C's interface to E: 2001:db8:ce::c/64, E's interface: * C's interface to E: 2001:db8:ce::c/64, E's interface:
2001:db8:ce::e/64 2001:db8:ce::e/64
o C's upper interface to F: 2001:db8:cf1::c/64, F's interface: * C's upper interface to F: 2001:db8:cf1::c/64, F's interface:
2001:db8:cf1::f/64 2001:db8:cf1::f/64
o C's lower interface to F: 2001:db8:cf2::c/64, F's interface: * C's lower interface to F: 2001:db8:cf2::c/64, F's interface:
2001:db8:cf2::f/64 2001:db8:cf2::f/64
o BGP router-ID of C: 192.0.2.3 * BGP router-ID of C: 192.0.2.3
o BGP router-ID of D: 192.0.2.4 * BGP router-ID of D: 192.0.2.4
o BGP router-ID of E: 192.0.2.5 * BGP router-ID of E: 192.0.2.5
o BGP router-ID of F: 192.0.2.6 * BGP router-ID of F: 192.0.2.6
o Loopback of F used for eBGP multi-hop peering to C: * Loopback of F used for External BGP (eBGP) multi-hop peering to C:
2001:db8:f::f/128 2001:db8:f::f/128
o C's loopback is 2001:db8:c::c/128 with SID 64 * C's loopback is 2001:db8:c::c/128 with SID 64
C's BGP peering: C's BGP peering:
o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) * Single-hop eBGP peering with neighbor 2001:db8:cd::d (D)
o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) * 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) * 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 to 2001:db8:f::f/128 via 2001:db8:cf1::f * Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f
o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f * 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 a local policy that defines a BGP PeerSet as the
set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F) 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 the AS1 domain.
H is a content source within AS1 domain. H is a content source within the AS1 domain.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. BGP Peering Segments 2. BGP Peering Segments
As defined in [I-D.ietf-spring-segment-routing], certain segments are As defined in [RFC8402], certain segments are defined by a BGP-EPE-
defined by a BGP-EPE capable node and corresponding to its attached capable node and correspond to their attached peers. These segments
peers. These segments are called BGP peering segments or BGP Peering are called BGP Peering Segments or BGP Peering SIDs. They enable the
SIDs. They enable the expression of source-routed inter-domain expression of 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 Egress Peering Engineering policy applied at an minimum, a BGP Egress Peer Engineering policy applied at an ingress
ingress EPE involves two segments: the Node SID of the chosen egress EPE involves two segments: the Node SID of the chosen egress EPE and
EPE and then the BGP Peering Segment for the chosen egress EPE peer then the BGP Peering Segment for the chosen egress EPE peer or
or peering interface. peering interface.
[I-D.ietf-spring-segment-routing] defines three types of BGP peering [RFC8402] defines three types of BGP Peering Segments/SIDs: PeerNode
segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID. SID, PeerAdj SID, and PeerSet SID.
A Peer Node Segment is a segment describing a peer, including the SID Peer Node Segment: 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 Peer Adjacency Segment: 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 Peer Set Segment: 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
set. the 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 [RFC7752] session is established between the BGP-EPE design, a Border Gateway Protocol - Link State (BGP-LS) [RFC7752]
enabled border router and the BGP-EPE controller. session is established between the BGP-EPE-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 [RFC9086], Node C allocates the following BGP Peering
allocates the following BGP Peering Segments Segments [RFC8402]:
([I-D.ietf-spring-segment-routing]):
o A PeerNode segment for each of its defined peer (D: 1012, E: 1022 * A PeerNode segment for each of its defined peers (D: 1012, E: 1022
and F: 1052). and F: 1052).
o A PeerAdj segment for each recursing interface to a multi-hop peer * 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 * A PeerSet segment to the set of peers (E and F). In this case,
PeerSet represents a set of peers (E, F) belonging to the same AS the PeerSet represents a set of peers (E, F) belonging to the same
(AS 3). AS (AS 3).
C programs its forwarding table accordingly: C programs its forwarding table accordingly:
Incoming Outgoing +================+===========+===============================+
Label Operation Interface | Incoming Label | Operation | Outgoing Interface |
------------------------------------ +================+===========+===============================+
1012 POP link to D | 1012 | POP | link to D |
1022 POP link to E +----------------+-----------+-------------------------------+
1032 POP upper link to F | 1022 | POP | link to E |
1042 POP lower link to F +----------------+-----------+-------------------------------+
1052 POP load balance on any link to F | 1032 | POP | upper link to F |
1060 POP load balance on any link to E or to F +----------------+-----------+-------------------------------+
| 1042 | POP | lower link to F |
+----------------+-----------+-------------------------------+
| 1052 | POP | load balance on any link to F |
+----------------+-----------+-------------------------------+
| 1060 | POP | load balance on any link to E |
| | | or to F |
+----------------+-----------+-------------------------------+
C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each Table 1
such BGP-LS route is described in the following subsections according
to the encoding details defined in C signals each related BGP-LS instance of Network Layer Reachability
[I-D.ietf-idr-bgpls-segment-routing-epe]. Information (NLRI) to the BGP-EPE controller. Each such BGP-LS route
is described in the following subsections according to the encoding
details defined in [RFC9086].
3.1. PeerNode SID to D 3.1. PeerNode SID to D
Descriptors: Descriptors:
o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000 192.0.2.3, AS1, 1000
o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2 * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2
o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): * 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 * PeerNode SID: 1012
3.2. PeerNode SID to E 3.2. PeerNode SID to E
Descriptors: Descriptors:
o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000 192.0.2.3, AS1, 1000
o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3 * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3
o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address):
2001:db8:ce::c, 2001:db8:ce::e 2001:db8:ce::c, 2001:db8:ce::e
Attributes: Attributes:
o PeerNode SID: 1022 * PeerNode SID: 1022
o PeerSetSID: 1060 * PeerSetSID: 1060
o Link Attributes: see section 3.3.2 of [RFC7752] * Link Attributes: see Section 3.3.2 of [RFC7752]
3.3. PeerNode SID to F 3.3. PeerNode SID to F
Descriptors: Descriptors:
o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000 192.0.2.3, AS1, 1000
o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address):
2001:db8:c::c, 2001:db8:f::f 2001:db8:c::c, 2001:db8:f::f
Attributes: Attributes:
o PeerNode SID: 1052 * PeerNode SID: 1052
o PeerSetSID: 1060 * PeerSetSID: 1060
3.4. First PeerAdj to F 3.4. First PeerAdj to F
Descriptors: Descriptors:
o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3, AS1, 1000 192.0.2.3, AS1, 1000
o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3
o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address):
2001:db8:cf1::c, 2001:db8:cf1::f 2001:db8:cf1::c, 2001:db8:cf1::f
Attributes: Attributes:
o PeerAdj-SID: 1032 * PeerAdj-SID: 1032
o LinkAttributes: see section 3.3.2 of [RFC7752] * Link Attributes: see Section 3.3.2 of [RFC7752]
3.5. Second PeerAdj to F 3.5. Second PeerAdj to F
Descriptors: Descriptors:
o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier):
192.0.2.3 , AS1 192.0.2.3 , AS1, 1000
o Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 * Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3
o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address):
2001:db8:cf2::c, 2001:db8:cf2::f 2001:db8:cf2::c, 2001:db8:cf2::f
Attributes: Attributes:
o PeerAdj-SID: 1042 * PeerAdj-SID: 1042
o LinkAttributes: see section 3.3.2 of [RFC7752] * Link Attributes: 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 an FRR backup entry on a
per BGP Peering SID basis. One example is as follows: per-BGP-Peering-SID basis. One example is as follows:
o PeerNode SID * PeerNode SID
1. If multi-hop, backup via the remaining PeerADJ SIDs (if 1. If multi-hop, back up 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, back up 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.
o PeerAdj SID * PeerAdj SID
1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 1. If to a multi-hop peer, back up via the remaining PeerADJ SIDs
(if available) to the same peer. (if available) to the same peer.
2. Else backup via a PeerNode SID to the same AS. 2. Else, back up 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 * PeerSet SID
1. Backup via remaining PeerNode SIDs in the same PeerSet. 1. Back up 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.
Let's illustrate different types of possible backups using the Let's illustrate 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 * 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 * 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).
PeerNode SID 1012, allocated by C for peer D: PeerNode SID 1012, allocated by C for peer D:
o Upon the failure of the connected link CD, C can pop the PeerNode * Upon the failure of the connected link CD, C can pop the PeerNode
SID and lookup the IP destination address in its FIB and route SID and look up the IP destination address in its FIB and route
accordingly. accordingly.
PeerSet SID 1060, allocated by C for the set of peers E and F: PeerSet SID 1060, allocated by C for the set of peers E and F:
o Upon the failure of a connected link in the group, the traffic to * Upon the failure of a connected link in the group, the traffic to
PeerSet SID 1060 is rerouted on any other member of the group. PeerSet SID 1060 is rerouted on any other member of the group.
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 SIDs.
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 that would have preferred F as a
a backup for E. backup for E.
4. BGP-EPE Controller 4. BGP-EPE Controller
In this section, Let's 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. routers.
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 the router configured to advertise all enabled border router, with the router configured to advertise all
paths using BGP add-path [RFC7911] and the original next-hop 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 <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2, * NLRI <2001:db8:abcd::/48>, next hop 2001:db8:cd::d, AS Path {AS 2,
4} 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 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2.
o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, AS Path {AS 3, * NLRI <2001:db8:abcd::/48>, next hop 2001:db8:ce::e, AS Path {AS 3,
4} 4}
* 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, * 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 the BGP
Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP- Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP-
EPE enabled 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 Link-State Database
running a BGP-LS session with a node in each IGP area. (LSDB) of each area or 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 section 2, the Thanks to the collected BGP-LS routes described in Section 3, the
BGP-EPE controller is able to maintain an accurate description of the BGP-EPE controller is able to maintain an accurate description of the
egress topology of node C. Furthermore, the BGP-EPE controller is egress topology of Node C. Furthermore, the BGP-EPE controller is
able to associate BGP Peering SIDs to the various components of the able to associate BGP Peering 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 Service Level Agreement (SLA)
peers. This requires an BGP-EPE solution as the SLA probes need to characteristics across peers. This requires a BGP-EPE solution, as
be steered via non-best-path peers. the SLA probes need to 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
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 that can be
controlled). controlled).
Alternatively, Extended Metrics, as defined in [RFC7810] could also Alternatively, Metric Extensions, as defined in [RFC8570], could also
be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). be advertised using BGP-LS [RFC8571].
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 [RFC7011] is a likely option. or the final destinations. IP Flow Information Export (IPFIX)
[RFC7011] is a likely option.
An alternative option consists in collecting the link utilization An alternative option consists of 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 in [RFC7752].
4.6. Business Policies 4.6. Business Policies
The BGP-EPE controller should be configured or collect business The BGP-EPE controller should be configured or collect business
policies through any desired mechanisms. These mechanisms by which policies through any desired mechanisms. These mechanisms by which
these policies are configured or collected are outside the scope of these policies are configured or collected are outside the scope of
this document. 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}. "64" being the SID * Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID
of PE C as defined in Section 1.1. of PE C as defined in Section 1.1.
o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, * 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 2001:db8:f::f, * Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f,
{64, 1052}. {64, 1052}.
o Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f * Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f
of multi-hop eBGP peer 2001:db8:f::f, {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 * 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}.
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 a
BGP-EPE policy are outside the scope of this document. A few BGP-EPE policy are outside the scope of this document. A few
examples are provided in this section. examples 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
to push. Assuming a global SRGB, at least on all access routers stack to push. Assuming the same Segment Routing Global Block
connecting the hosts, the same policy can be programmed across all (SRGB), at least on all access routers connecting the hosts, the same
hosts, which is convenient. policy can be programmed across all 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 multiple The tunnel and the steering policy could be configured via multiple
means. A few examples are given below: means. A few examples are given below:
o PCEP according to [I-D.ietf-pce-segment-routing] and * The Path Computation Element Communication Protocol (PCEP)
[I-D.ietf-pce-pce-initiated-lsp]. according to [RFC8664] and [RFC8281]
o Netconf ([RFC6241]). * NETCONF [RFC6241]
o Other static or ephemeral APIs * 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 - BGP Labeled Unicast route (RFC8277) 5.3. At a Router - Unicast Route Labeled Using BGP (RFC 8277)
The BGP-EPE Controller could build a BGP Labeled Unicast route The BGP-EPE controller could build a unicast route labeled using BGP
[RFC8277]) route (from scratch) and send it to the ingress router: [RFC8277] (from scratch) and send it to the ingress router.
o NLRI: the destination prefix to engineer: e.g., L/8. Such a route would require the following:
o Next-Hop: the selected egress border router: C. NLRI
the destination prefix to engineer (e.g., L/8)
o Label: the selected egress peer: 1042. Next Hop
the selected egress border router: C
o AS path: reflecting the selected valid AS path. Label
the selected egress peer: 1042
o Some BGP policy to ensure it will be selected as best by the Autonomous System (AS) path
ingress router. Note that as discussed in RFC 8277 section 5, the the selected valid AS path
comparison of labeled and unlabeled unicast BGP route is
implementation dependent and hence may require an implementation
specific policy on each ingress router.
This BGP Labeled unicast route (RFC8277) "overwrites" an equivalent Some BGP policy to ensure it will be selected as best by the ingress
or less-specific "best path". As the best-path is changed, this BGP- router. Note that as discussed in Section 5 of [RFC8277], the
EPE input policy option may influence the path propagated to the comparison of a labeled and unlabeled unicast BGP route is
upstream peer/customers. Indeed, implementations treating the SAFI-1 implementation dependent and hence may require an implementation-
and SAFI-4 routes for a given prefix as comparable would trigger a specific policy on each ingress router.
BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers.
5.4. At a Router - VPN policy route This unicast route labeled using BGP [RFC8277] "overwrites" an
equivalent or less-specific "best path". As the best path is
changed, this BGP-EPE input policy option may influence the path
propagated to the upstream peer/customers. Indeed, implementations
treating the SAFI-1 and SAFI-4 routes for a given prefix as
comparable would trigger a BGP WITHDRAW of the SAFI-1 route to their
BGP upstream peers.
The BGP-EPE Controller could build a VPNv4 route (from scratch) and 5.4. At a Router - VPN Policy Route
send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g., L/8. The BGP-EPE controller could build a VPNv4 route (from scratch) and
send it to the ingress router.
o Next-Hop: the selected egress border router: C. Such a route would require the following:
o Label: the selected egress peer: 1042. NLRI
the destination prefix to engineer: e.g., L/8
o Route-Target: selecting the appropriate VRF at the ingress router. Next Hop
the selected egress border router: C
o AS path: reflecting the selected valid AS path. Label
the selected egress peer: 1042
o Some BGP policy to ensure it will be selected as best by the Route-Target
ingress router in the related VRF. the selected appropriate VRF instance at the ingress router
The related VRF must be preconfigured. A VRF fallback to the main AS path
FIB might be beneficial to avoid replicating all the "normal" the selected valid AS path
Internet paths in each VRF.
6. IPv6 Dataplane Some BGP policy to ensure it will be selected as best by the ingress
router in the related VRF instance.
The related VRF instance must be preconfigured. A VRF fallback to
the main FIB might be beneficial to avoid replicating all the
"normal" Internet paths in each VRF instance.
6. IPv6 Data Plane
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 * 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 * Collecting, by the BGP-EPE controller, various inputs to come up
with a policy decision. with a policy decision.
o Programming at an ingress router or source host of the desired * Programming at an ingress router or source host of the desired
BGP-EPE policy which consists in a list of segments to push on a BGP-EPE policy, which consists of a list of segments to push on a
defined traffic class. defined traffic class.
7. Benefits 7. Benefits
The BGP-EPE solutions described in this document have the following The BGP-EPE solutions described in this document have the following
benefits: benefits:
o No assumption on the iBGP design within AS1. * No assumption on the iBGP design within AS1.
o Next-Hop-Self on the Internet routes propagated to the ingress * 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 * 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 BGP-EPE policy * Support for both host and ingress border router BGP-EPE policy
programming. programming.
o BGP-EPE functionality is only required on the BGP-EPE enabled * 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 * Ability to deploy the same input policy across hosts connected to
different routers (assuming the global property of IGP prefix different routers (assuming the global property of IGP Prefix-
SIDs). SIDs).
8. IANA Considerations 8. IANA Considerations
This document does not request any IANA allocations. This document has no IANA actions.
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 [RFC9086] and that
[I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions consists of additional BGP-LS descriptors and TLVs. Manageability
consists of additional BGP-LS descriptors and TLVs that will follow functions of BGP-LS, described in [RFC7752], also apply to the
the same. Manageability functions of BGP-LS, described in [RFC7752] extensions required by the EPE use case.
also apply to the extensions required by the EPE use-case.
Additional Manageability considerations are described in Additional manageability considerations are described in [RFC9086].
[I-D.ietf-idr-bgpls-segment-routing-epe].
10. Security Considerations 10. Security Considerations
[RFC7752] defines BGP-LS NLRIs and their associated security aspects. [RFC7752] defines BGP-LS NLRI instances and their associated security
aspects.
[I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS
extensions required by the BGP-EPE mechanisms described in this
document. BGP-EPE BGP-LS extensions also include the related
security.
11. Contributors
Daniel Ginsburg substantially contributed to the content of this
document.
12. Acknowledgements
The authors would like to thank Acee Lindem for his comments and
contribution.
13. References
13.1. Normative References [RFC9086] defines the BGP-LS extensions required by the BGP-EPE
mechanisms described in this document. BGP-EPE BGP-LS extensions
also include the related security.
[I-D.ietf-idr-bgpls-segment-routing-epe] 11. References
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-14 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing] 11.1. Normative References
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-14 (work
in progress), December 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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
13.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-idr-te-pm-bgp] [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment
Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
IGP Traffic Engineering Performance Metric Extensions", July 2018, <https://www.rfc-editor.org/info/rfc8402>.
draft-ietf-idr-te-pm-bgp-08 (work in progress), August
2017.
[I-D.ietf-pce-pce-initiated-lsp] [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K.,
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Ray, S., and J. Dong, "Border Gateway Protocol - Link
Extensions for PCE-initiated LSP Setup in a Stateful PCE State (BGP-LS) Extensions for Segment Routing BGP Egress
Model", draft-ietf-pce-pce-initiated-lsp-11 (work in Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
progress), October 2017. 2021, <https://www.rfc-editor.org/info/rfc9086>.
[I-D.ietf-pce-segment-routing] 11.2. Informative References
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-11 (work in progress),
November 2017.
[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,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX) "Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77, Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>. <https://www.rfc-editor.org/info/rfc7011>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016,
<https://www.rfc-editor.org/info/rfc7810>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854, Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016, DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>. <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, <https://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,
<https://www.rfc-editor.org/info/rfc7911>. <https://www.rfc-editor.org/info/rfc7911>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>. <https://www.rfc-editor.org/info/rfc8277>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
Acknowledgements
The authors would like to thank Acee Lindem for his comments and
contribution.
Contributors
Daniel Ginsburg substantially contributed to the content of this
document.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Gaurav Dawra (editor) Gaurav Dawra (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
USA United States of America
Email: gdawra.ietf@gmail.com Email: gdawra.ietf@gmail.com
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale CA 94089 Sunnyvale, CA 94089
US United States of America
Email: exa@juniper.net Email: exa@juniper.net
Dmitry Afanasiev Dmitry Afanasiev
Yandex Yandex
RU Russian Federation
Email: fl0w@yandex-team.ru Email: fl0w@yandex-team.ru
 End of changes. 188 change blocks. 
359 lines changed or deleted 385 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/