idnits 2.17.1 draft-ietf-spring-segment-routing-central-epe-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2017) is 2473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-12 == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-05 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-09 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: December 22, 2017 E. Aries 6 Juniper Networks 7 D. Afanasiev 8 Yandex 9 June 20, 2017 11 Segment Routing Centralized BGP Egress Peer Engineering 12 draft-ietf-spring-segment-routing-central-epe-06 14 Abstract 16 Segment Routing (SR) leverages source routing. A node steers a 17 packet through a controlled set of instructions, called segments, by 18 prepending the packet with an SR header. A segment can represent any 19 instruction topological or service-based. SR allows to enforce a 20 flow through any topological path and service chain while maintaining 21 per-flow state only at the ingress node of the SR domain. 23 The Segment Routing architecture can be directly applied to the MPLS 24 dataplane with no change on the forwarding plane. It requires a 25 minor extension to the existing link-state routing protocols. 27 This document illustrates the application of Segment Routing to solve 28 the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based 29 BGP-EPE solution allows a centralized (Software Defined Network, SDN) 30 controller to program any egress peer policy at ingress border 31 routers or at hosts within the domain. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on December 22, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 75 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 76 3. Distribution of Topology and TE Information using BGP-LS . . 6 77 3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 78 3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 8 79 3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 80 3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 81 3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 82 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 83 4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 84 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 85 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 86 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 87 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 88 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 89 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 90 4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 91 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 92 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 93 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 94 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 14 95 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 96 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 97 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 100 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 101 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 105 13.2. Informative References . . . . . . . . . . . . . . . . . 17 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 The document is structured as follows: 112 o Section 1 states the BGP-EPE problem statement and provides the 113 key references. 115 o Section 2 defines the different BGP Peering Segments and the 116 semantic associated to them. 118 o Section 3 describes the automated allocation of BGP Peering SID's 119 by the BGP-EPE enabled egress border router and the automated 120 signaling of the external peering topology and the related BGP 121 Peering SID's to the collector 122 [I-D.ietf-idr-bgpls-segment-routing-epe]. 124 o Section 4 overviews the components of a centralized BGP-EPE 125 controller. The definition of the BGP-EPE controller is outside 126 the scope of this document. 128 o Section 5 overviews the methods that could be used by the 129 centralized BGP-EPE controller to implement a BGP-EPE policy at an 130 ingress border router or at a source host within the domain. The 131 exhaustive definition of all the means to program an BGP-EPE input 132 policy is outside the scope of this document. 134 For editorial reasons, the solution is described with IPv6 addresses 135 and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS 136 SIDs and also to IPv6 with native IPv6 SIDs. 138 1.1. Problem Statement 140 The BGP-EPE problem statement is defined in [RFC7855]. 142 A centralized controller should be able to instruct an ingress 143 Provider Edge router (PE) or a content source within the domain to 144 use a specific egress PE and a specific external interface/neighbor 145 to reach a particular destination. 147 We call this solution "BGP-EPE" for "BGP Egress Peer Engineering". 148 The centralized controller is called the "BGP-EPE Controller". The 149 egress border router where the BGP-EPE traffic steering functionality 150 is implemented is called a BGP-EPE enabled border router. The input 151 policy programmed at an ingress border router or at a source host is 152 called a BGP-EPE policy. 154 The requirements that have motivated the solution described in this 155 document are listed here below: 157 o The solution MUST apply to the Internet use-case where the 158 Internet routes are assumed to use IPv4 unlabeled or IPv6 159 unlabeled. It is not required to place the Internet routes in a 160 VRF and allocate labels on a per route, or on a per-path basis. 162 o The solution MUST NOT make any assumption on the currently 163 deployed iBGP schemes (RRs, confederations or iBGP full meshes) 164 and MUST be able to support all of them. 166 o The solution MUST be applicable to any type of EPE router. While 167 "Egress Peer Engineering" refers to "External" peering, the 168 solution MUST also be applicable to a router having internal 169 peers. 171 o The solution SHOULD minimize the need for new BGP capabilities at 172 the ingress PEs. 174 o The solution MUST accommodate an ingress BGP-EPE policy at an 175 ingress PE or directly at a source host within the domain. 177 o The solution MUST support automated Fast Reroute (FRR) and fast 178 convergence mechanisms. 180 The following reference diagram is used throughout this document. 182 +---------+ +------+ 183 | | | | 184 | H B------D G 185 | | +---/| AS 2 |\ +------+ 186 | |/ +------+ \ | |---L/8 187 A AS1 C---+ \| | 188 | |\\ \ +------+ /| AS 4 |---M/8 189 | | \\ +-E |/ +------+ 190 | X | \\ | K 191 | | +===F AS 3 | 192 +---------+ +------+ 194 Figure 1: Reference Diagram 196 IP addressing: 198 o C's interface to D: 2001:db8:cd::c/64, D's interface: 199 2001:db8:cd::d/64 201 o C's interface to E: 2001:db8:ce::c/64, E's interface: 202 2001:db8:ce::e/64 204 o C's upper interface to F: 2001:db8:cf1::c/64, F's interface: 205 2001:db8:cf1::f/64 207 o C's lower interface to F: 2001:db8:cf2::c/64, F's interface: 208 2001:db8:cf2::f/64 210 o BGP router-ID of C: 192.0.2.3 212 o BGP router-ID of D: 192.0.2.4 214 o BGP router-ID of E: 192.0.2.5 216 o BGP router-ID of F: 192.0.2.6 218 o Loopback of F used for eBGP multi-hop peering to C: 219 2001:db8:f::f/128 221 o C's loopback is 2001:db8:c::c/128 with SID 64 223 C's BGP peering: 225 o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) 227 o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) 229 o Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F) 230 C's resolution of the multi-hop eBGP session to F: 232 o Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f 234 o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f 236 C is configured with local policy that defines a BGP PeerSet as the 237 set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F) 239 X is the BGP-EPE controller within AS1 domain. 241 H is a content source within AS1 domain. 243 2. BGP Peering Segments 245 As defined in [I-D.ietf-spring-segment-routing], certain segments are 246 defined by BGP-EPE capable node and corresponding to its attached 247 peers. These segments are called BGP peering segments or BGP Peering 248 SIDs. They enable the expression of source-routed inter-domain 249 paths. 251 An ingress border router of an AS may compose a list of segments to 252 steer a flow along a selected path within the AS, towards a selected 253 egress border router C of the AS and through a specific peer. At 254 minimum, a BGP Egress Peering Engineering policy applied at an 255 ingress EPE involves two segments: the Node SID of the chosen egress 256 EPE and then the BGP Peering Segment for the chosen egress EPE peer 257 or peering interface. 259 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 260 segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID. 262 A Peer Node Segment is a segment describing a peer, including the SID 263 (PeerNode SID) allocated to it. 265 A Peer Adjacency Segment is a segment describing a link, including 266 the SID (PeerAdj SID) allocated to it. 268 A Peer Set Segment is a segment describing a link or a node that is 269 part of the set, including the SID (PeerSet SID) allocated to the 270 set. 272 3. Distribution of Topology and TE Information using BGP-LS 274 In ships-in-the-night mode with respect to the pre-existing iBGP 275 design, a BGP-LS session is established between the BGP-EPE enabled 276 border router and the BGP-EPE controller. 278 As a result of its local configuration and according to the behavior 279 described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C 280 allocates the following BGP Peering Segments 281 ([I-D.ietf-spring-segment-routing]): 283 o A PeerNode segment for each of its defined peer (D: 1012, E: 1022 284 and F: 1052). 286 o A PeerAdj segment for each recursing interface to a multi-hop peer 287 (e.g.: the upper and lower interfaces from C to F in figure 1). 289 o A PeerSet segment to the set of peers (E and F). In this case the 290 PeerSet represents a set of peers (E, F) belonging to the same AS 291 (AS 3). 293 C programs its forwarding table accordingly: 295 Incoming Outgoing 296 Label Operation Interface 297 ------------------------------------ 298 1012 POP link to D 299 1022 POP link to E 300 1032 POP upper link to F 301 1042 POP lower link to F 302 1052 POP load balance on any link to F 303 1060 POP load balance on any link to E or to F 305 C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each 306 such BGP-LS route is described in the following subsections according 307 to the encoding details defined in 308 [I-D.ietf-idr-bgpls-segment-routing-epe]. 310 3.1. PeerNode SID to D 312 Descriptors: 314 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 316 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.4, AS2 318 o Link Descriptors (IP interface address, neighbor IP address): 319 2001:db8:cd::c, 2001:db8:cd::d 321 Attributes: 323 o PeerNode SID: 1012 325 3.2. PeerNode SID to E 327 Descriptors: 329 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 331 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.5, AS3 333 o Link Descriptors (IP interface address, neighbor IP address): 334 2001:db8:ce::c, 2001:db8:ce::e 336 Attributes: 338 o PeerNode SID: 1022 340 o PeerSetSID: 1060 342 o Link Attributes: see section 3.3.2 of [RFC7752] 344 3.3. PeerNode SID to F 346 Descriptors: 348 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 350 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.6, AS3 352 o Link Descriptors (IP interface address, neighbor IP address): 353 2001:db8:c::c, 2001:db8:f::f 355 Attributes: 357 o PeerNode SID: 1052 359 o PeerSetSID: 1060 361 3.4. First PeerAdj to F 363 Descriptors: 365 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3, AS1 367 o Peer Descriptors (peer BGP router-ID, peer ASN): 192.0.2.6, AS3 369 o Link Descriptors (IP interface address, neighbor IP address): 370 2001:db8:cf1::c, 2001:db8:cf1::f 372 Attributes: 374 o PeerAdj-SID: 1032 376 o LinkAttributes: see section 3.3.2 of [RFC7752] 378 3.5. Second PeerAdj to F 380 Descriptors: 382 o Node Descriptors (BGP router-ID, ASN): 192.0.2.3 , AS1 384 o Peer Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 386 o Link Descriptors (IP interface address, neighbor IP address): 387 2001:db8:cf2::c, 2001:db8:cf2::f 389 Attributes: 391 o PeerAdj-SID: 1042 393 o LinkAttributes: see section 3.3.2 of [RFC7752] 395 3.6. Fast Reroute (FRR) 397 A BGP-EPE enabled border router MAY allocate a FRR backup entry on a 398 per BGP Peering SID basis (assuming inter-AS agreement on the FRR 399 strategy/policy). One example is as follows: 401 o PeerNode SID 403 1. If multi-hop, backup via the remaining PeerADJ SIDs (if 404 available) to the same peer. 406 2. Else backup via another PeerNode SID to the same AS. 408 3. Else pop the PeerNode SID and perform an IP lookup. 410 o PeerAdj SID 412 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 413 (if available) to the same peer. 415 2. Else backup via a PeerNode SID to the same AS. 417 3. Else pop the PeerNode SID and perform an IP lookup. 419 o PeerSet SID 421 1. Backup via remaining PeerNode SIDs in the same PeerSet. 423 2. Else pop the PeerNode SID and IP lookup. 425 We illustrate different types of possible backups using the reference 426 diagram and considering the Peering SIDs allocated by C. 428 PeerNode SID 1052, allocated by C for peer F: 430 o Upon the failure of the upper connected link CF, C can reroute all 431 the traffic onto the lower CF link to the same peer (F). 433 PeerNode SID 1022, allocated by C for peer E: 435 o Upon the failure of the connected link CE, C can reroute all the 436 traffic onto the link to PeerNode SID 1052 (F). 438 PeerNode SID 1012, allocated by C for peer D: 440 o Upon the failure of the connected link CD, C can pop the PeerNode 441 SID and lookup the IP destination address in its FIB and route 442 accordingly. 444 PeerSet SID 1060, allocated by C for the set of peers E and F: 446 o Upon the failure of a connected link in the group, the traffic to 447 PeerSet SID 1060 is rerouted on any other member of the group. 449 For specific business reasons, the operator might not want the 450 default FRR behavior applied to a PeerNode SID or any of its 451 dependent PeerADJ SID. 453 The operator should be able to associate a specific backup PeerNode 454 SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) 455 which overrules the default behavior which would have preferred F as 456 a backup for E. 458 4. BGP-EPE Controller 460 In this section, we provide a non-exhaustive set of inputs that a 461 BGP-EPE controller would likely collect such as to perform the BGP- 462 EPE policy decision. 464 The exhaustive definition is outside the scope of this document. 466 4.1. Valid Paths From Peers 468 The BGP-EPE controller should collect all the BGP paths (i.e.: IP 469 destination prefixes) advertised by all the BGP-EPE enabled border 470 router. 472 This could be realized by setting an iBGP session with the BGP-EPE 473 enabled border router, with the router configured to advertise all 474 paths using BGP add-path [RFC7911] and the original next-hop 475 preserved. 477 In this case, C would advertise the following Internet routes to the 478 BGP-EPE controller: 480 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2, 481 4} 483 * X (i.e.: the BGP-EPE controller) knows that C receives a path 484 to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. 486 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, AS Path {AS 3, 487 4} 489 * X knows that C receives a path to 2001:db8:abcd::/48 via 490 neighbor 2001:db8:ce::e of AS2. 492 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3, 493 4} 495 * X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 496 via neighbor 2001:db8:f::f 498 An alternative option would be for a BGP-EPE collector to use BGP 499 Monitoring Protocol (BMP) to track the Adj-RIB-In of BGP-EPE enabled 500 border routers. 502 4.2. Intra-Domain Topology 504 The BGP-EPE controller should collect the internal topology and the 505 related IGP SIDs. 507 This could be realized by collecting the IGP LSDB of each area or 508 running a BGP-LS session with a node in each IGP area. 510 4.3. External Topology 512 Thanks to the collected BGP-LS routes described in section 2, the 513 BGP-EPE controller is able to maintain an accurate description of the 514 egress topology of node C. Furthermore, the BGP-EPE controller is 515 able to associate BGP Peering SIDs to the various components of the 516 external topology. 518 4.4. SLA characteristics of each peer 520 The BGP-EPE controller might collect SLA characteristics across 521 peers. This requires an BGP-EPE solution as the SLA probes need to 522 be steered via non-best-path peers. 524 Unidirectional SLA monitoring of the desired path is likely required. 525 This might be possible when the application is controlled at the 526 source and the receiver side. Unidirectional monitoring dissociates 527 the SLA characteristic of the return path (which cannot usually be 528 controlled) from the forward path (the one of interest for pushing 529 content from a source to a consumer and the one which can be 530 controlled). 532 Alternatively, Extended Metrics, as defined in [RFC7810] could also 533 be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). 535 4.5. Traffic Matrix 537 The BGP-EPE controller might collect the traffic matrix to its peers 538 or the final destinations. IPFIX is a likely option. 540 An alternative option consists in collecting the link utilization 541 statistics of each of the internal and external links, also available 542 in the current definition of [RFC7752]. 544 4.6. Business Policies 546 The BGP-EPE controller should be configured or collect (through any 547 mean) business policies. The mechanisms through which these policies 548 are configured or collected is outside the scope of this document. 550 4.7. BGP-EPE Policy 552 On the basis of all these inputs (and likely others), the BGP-EPE 553 Controller decides to steer some demands away from their best BGP 554 path. 556 The BGP-EPE policy is likely expressed as a two-entry segment list 557 where the first element is the IGP prefix SID of the selected egress 558 border router and the second element is a BGP Peering SID at the 559 selected egress border router. 561 A few examples are provided hereafter: 563 o Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID 564 of PE C as defined in Section 1.1. 566 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, 567 {64, 1022}. 569 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, 570 {64, 1052}. 572 o Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f 573 of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}. 575 o Prefer egress PE C and any interface to any peer in the group 576 1060: {64, 1060}. 578 Note that the first SID could be replaced by a list of segments. 579 This is useful when an explicit path within the domain is required 580 for traffic engineering purposes. For example, if the Prefix SID of 581 node B is 60 and the BGP-EPE controller would like to steer the 582 traffic from A to C via B then through the external link to peer D 583 then the segment list would be {60, 64, 1012}. 585 5. Programming an input policy 587 The detailed/exhaustive description of all the means to implement an 588 BGP-EPE policy are outside the scope of this document. A few 589 examples are provided in this section. 591 5.1. At a Host 593 A static IP/MPLS route can be programmed at the host H. The static 594 route would define a destination prefix, a next-hop and a label stack 595 to push. Assuming a global SRGB, at least on all access routers 596 connecting the hosts, the same policy can be programmed across all 597 hosts, which is convenient. 599 5.2. At a router - SR Traffic Engineering tunnel 601 The BGP-EPE controller can configure the ingress border router with 602 an SR traffic engineering tunnel T1 and a steering-policy S1 which 603 causes a certain class of traffic to be mapped on the tunnel T1. 605 The tunnel T1 would be configured to push the required segment list. 607 The tunnel and the steering policy could be configured via multiple 608 means. A few examples are given below: 610 o PCEP according to [I-D.ietf-pce-segment-routing] and 611 [I-D.ietf-pce-pce-initiated-lsp]. 613 o Netconf ([RFC6241]). 615 o Other static or ephemeral APIs 617 Example: at router A (Figure 1). 619 Tunnel T1: push {64, 1042} 620 IP route L/8 set next-hop T1 622 5.3. At a Router - RFC3107 policy route 624 The BGP-EPE Controller could build a RFC3107 ([RFC3107]) route (from 625 scratch) and send it to the ingress router: 627 o NLRI: the destination prefix to engineer: e.g., L/8. 629 o Next-Hop: the selected egress border router: C. 631 o Label: the selected egress peer: 1042. 633 o AS path: reflecting the selected valid AS path. 635 o Some BGP policy to ensure it will be selected as best by the 636 ingress router. 638 This RFC3107 policy route "overwrites" an equivalent or less-specific 639 "best path". As the best-path is changed, this BGP-EPE input policy 640 option may influence the path propagated to the upstream peer/ 641 customers. Indeed, implementations treating the SAFI-1 and SAFI-4 642 routes for a given prefix as comparable would trigger a BGP WITHDRAW 643 of the SAFI-1 route to their BGP upstream peers. 645 5.4. At a Router - VPN policy route 647 The BGP-EPE Controller could build a VPNv4 route (from scratch) and 648 send it to the ingress router: 650 o NLRI: the destination prefix to engineer: e.g., L/8. 652 o Next-Hop: the selected egress border router: C. 654 o Label: the selected egress peer: 1042. 656 o Route-Target: selecting the appropriate VRF at the ingress router. 658 o AS path: reflecting the selected valid AS path. 660 o Some BGP policy to ensure it will be selected as best by the 661 ingress router in the related VRF. 663 The related VRF must be preconfigured. A VRF fallback to the main 664 FIB might be beneficial to avoid replicating all the "normal" 665 Internet paths in each VRF. 667 6. IPv6 Dataplane 669 The described solution is applicable to IPv6, either with MPLS-based 670 or IPv6-Native segments. In both cases, the same three steps of the 671 solution are applicable: 673 o BGP-LS-based signaling of the external topology and BGP Peering 674 Segments to the BGP-EPE controller. 676 o Collection of various inputs by the BGP-EPE controller to come up 677 with a policy decision. 679 o Programming at an ingress router or source host of the desired 680 BGP-EPE policy which consists in a list of segments to push on a 681 defined traffic class. 683 7. Benefits 685 The BGP-EPE solutions described in this document have the following 686 benefits: 688 o No assumption on the iBGP design within AS1. 690 o Next-Hop-Self on the Internet routes propagated to the ingress 691 border routers is possible. This is a common design rule to 692 minimize the number of IGP routes and to avoid importing external 693 churn into the internal routing domain. 695 o Consistent support for traffic engineering within the domain and 696 at the external edge of the domain. 698 o Support both host and ingress border router BGP-EPE policy 699 programming. 701 o BGP-EPE functionality is only required on the BGP-EPE enabled 702 egress border router and the BGP-EPE controller: an ingress policy 703 can be programmed at the ingress border router without any new 704 functionality. 706 o Ability to deploy the same input policy across hosts connected to 707 different routers (assuming the global property of IGP prefix 708 SIDs). 710 8. IANA Considerations 712 This document does not request any IANA allocations. 714 9. Manageability Considerations 716 The BGP-EPE use-case described in this document requires BGP-LS 717 ([RFC7752]) extensions that are described in 718 [I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions 719 consists of additional BGP-LS descriptors and TLVs that will follow 720 the same. Manageability functions of BGP-LS, described in [RFC7752] 721 also apply to the extensions required by the EPE use-case. 723 The operator MUST be capable of configuring, enabling, disabling the 724 advertisement of the EPE information as well as to control which 725 information is advertised to which internal or external peer. This 726 is not different from what is required by a BGP speaker in terms of 727 information origination and advertisement. In addition, the 728 advertisement of EPE information MUST conform to standard BGP 729 advertisement and propagation rules (iBGP, eBGP, Route-Reflectors, 730 Confederations). 732 10. Security Considerations 734 [RFC7752] defines BGP-LS NLRIs and their associated security aspects. 736 [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS 737 extensions required by the BGP-EPE mechanisms described in this 738 document. BGP-EPE BGP-LS extensions also include the related 739 security. 741 11. Contributors 743 Daniel Ginsburg substantially contributed to the content of this 744 document. 746 12. Acknowledgements 748 The authors would like to thank Acee Lindem for his comments and 749 contribution. 751 13. References 753 13.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, 757 DOI 10.17487/RFC2119, March 1997, 758 . 760 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 761 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 762 . 764 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 765 and A. Bierman, Ed., "Network Configuration Protocol 766 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 767 . 769 13.2. Informative References 771 [I-D.ietf-idr-bgpls-segment-routing-epe] 772 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 773 Dong, "BGP-LS extensions for Segment Routing BGP Egress 774 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 775 epe-12 (work in progress), April 2017. 777 [I-D.ietf-idr-te-pm-bgp] 778 Previdi, S., Wu, Q., Gredler, H., Ray, S., 779 jefftant@gmail.com, j., Filsfils, C., and L. Ginsberg, 780 "BGP-LS Advertisement of IGP Traffic Engineering 781 Performance Metric Extensions", draft-ietf-idr-te-pm- 782 bgp-05 (work in progress), April 2017. 784 [I-D.ietf-pce-pce-initiated-lsp] 785 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 786 Extensions for PCE-initiated LSP Setup in a Stateful PCE 787 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 788 progress), March 2017. 790 [I-D.ietf-pce-segment-routing] 791 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 792 and J. Hardwick, "PCEP Extensions for Segment Routing", 793 draft-ietf-pce-segment-routing-09 (work in progress), 794 April 2017. 796 [I-D.ietf-spring-segment-routing] 797 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 798 and R. Shakir, "Segment Routing Architecture", draft-ietf- 799 spring-segment-routing-11 (work in progress), February 800 2017. 802 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 803 S. Ray, "North-Bound Distribution of Link-State and 804 Traffic Engineering (TE) Information Using BGP", RFC 7752, 805 DOI 10.17487/RFC7752, March 2016, 806 . 808 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 809 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 810 RFC 7810, DOI 10.17487/RFC7810, May 2016, 811 . 813 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 814 Litkowski, S., Horneffer, M., and R. Shakir, "Source 815 Packet Routing in Networking (SPRING) Problem Statement 816 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 817 2016, . 819 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 820 "Advertisement of Multiple Paths in BGP", RFC 7911, 821 DOI 10.17487/RFC7911, July 2016, 822 . 824 Authors' Addresses 826 Clarence Filsfils (editor) 827 Cisco Systems, Inc. 828 Brussels 829 BE 831 Email: cfilsfil@cisco.com 833 Stefano Previdi (editor) 834 Cisco Systems, Inc. 835 Italy 837 Email: stefano@previdi.net 839 Ebben Aries 840 Juniper Networks 841 1133 Innovation Way 842 Sunnyvale CA 94089 843 US 845 Email: exa@juniper.net 846 Dmitry Afanasiev 847 Yandex 848 RU 850 Email: fl0w@yandex-team.ru