idnits 2.17.1 draft-ietf-spring-segment-routing-central-epe-10.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 (December 21, 2017) is 2316 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-14 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-14 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-08 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 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 4 Intended status: Informational G. Dawra, Ed. 5 Expires: June 24, 2018 Cisco Systems, Inc. 6 E. Aries 7 Juniper Networks 8 D. Afanasiev 9 Yandex 10 December 21, 2017 12 Segment Routing Centralized BGP Egress Peer Engineering 13 draft-ietf-spring-segment-routing-central-epe-10 15 Abstract 17 Segment Routing (SR) leverages source routing. A node steers a 18 packet through a controlled set of instructions, called segments, by 19 prepending the packet with an SR header. A segment can represent any 20 instruction topological or service-based. SR allows to enforce a 21 flow through any topological path while maintaining per-flow state 22 only at the ingress node of the SR domain. 24 The Segment Routing architecture can be directly applied to the MPLS 25 dataplane with no change on the forwarding plane. It requires a 26 minor extension to the existing link-state routing protocols. 28 This document illustrates the application of Segment Routing to solve 29 the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based 30 BGP-EPE solution allows a centralized (Software Defined Network, SDN) 31 controller to program any egress peer policy at ingress border 32 routers or at hosts within the domain. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on June 24, 2018. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 76 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 77 3. Distribution of Topology and TE Information using BGP-LS . . 6 78 3.1. PeerNode SID to D . . . . . . . . . . . . . . . . . . . . 7 79 3.2. PeerNode SID to E . . . . . . . . . . . . . . . . . . . . 7 80 3.3. PeerNode SID to F . . . . . . . . . . . . . . . . . . . . 8 81 3.4. First PeerAdj to F . . . . . . . . . . . . . . . . . . . 8 82 3.5. Second PeerAdj to F . . . . . . . . . . . . . . . . . . . 9 83 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 84 4. BGP-EPE Controller . . . . . . . . . . . . . . . . . . . . . 10 85 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 86 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 87 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 88 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 89 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 90 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 91 4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 92 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 93 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 94 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 95 5.3. At a Router - BGP Labeled Unicast route (RFC8277) . . . . 14 96 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 97 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 98 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 102 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 103 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 106 13.2. Informative References . . . . . . . . . . . . . . . . . 17 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 109 1. Introduction 111 The document is structured as follows: 113 o Section 1 states the BGP-EPE problem statement and provides the 114 key references. 116 o Section 2 defines the different BGP Peering Segments and the 117 semantic associated to them. 119 o Section 3 describes the automated allocation of BGP Peering 120 Segment-IDs (SIDs) by the BGP-EPE enabled egress border router and 121 the automated signaling of the external peering topology and the 122 related BGP Peering SID's to the collector 123 [I-D.ietf-idr-bgpls-segment-routing-epe]. 125 o Section 4 overviews the components of a centralized BGP-EPE 126 controller. The definition of the BGP-EPE controller is outside 127 the scope of this document. 129 o Section 5 overviews the methods that could be used by the 130 centralized BGP-EPE controller to implement a BGP-EPE policy at an 131 ingress border router or at a source host within the domain. The 132 exhaustive definition of all the means to program an BGP-EPE input 133 policy is outside the scope of this document. 135 For editorial reasons, the solution is described with IPv6 addresses 136 and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS 137 SIDs and also to IPv6 with native IPv6 SIDs. 139 1.1. Problem Statement 141 The BGP-EPE problem statement is defined in [RFC7855]. 143 A centralized controller should be able to instruct an ingress 144 Provider Edge router (PE) or a content source within the domain to 145 use a specific egress PE and a specific external interface/neighbor 146 to reach a particular destination. 148 Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering". 149 The centralized controller is called the "BGP-EPE Controller". The 150 egress border router where the BGP-EPE traffic steering functionality 151 is implemented is called a BGP-EPE enabled border router. The input 152 policy programmed at an ingress border router or at a source host is 153 called a BGP-EPE policy. 155 The requirements that have motivated the solution described in this 156 document are listed here below: 158 o The solution MUST apply to the Internet use-case where the 159 Internet routes are assumed to use IPv4 unlabeled or IPv6 160 unlabeled. It is not required to place the Internet routes in a 161 VRF and allocate labels on a per route, or on a per-path basis. 163 o The solution MUST support any deployed iBGP schemes (RRs, 164 confederations or iBGP full meshes). 166 o The solution MUST be applicable to both routers with external and 167 internal peers. 169 o The solution should minimize the need for new BGP capabilities at 170 the ingress PEs. 172 o The solution MUST accommodate an ingress BGP-EPE policy at an 173 ingress PE or directly at a source within the domain. 175 o The solution MAY support automated Fast Reroute (FRR) and fast 176 convergence mechanisms. 178 The following reference diagram is used throughout this document. 180 +---------+ +------+ 181 | | | | 182 | H B------D G 183 | | +---/| AS 2 |\ +------+ 184 | |/ +------+ \ | |---L/8 185 A AS1 C---+ \| | 186 | |\\ \ +------+ /| AS 4 |---M/8 187 | | \\ +-E |/ +------+ 188 | X | \\ | K 189 | | +===F AS 3 | 190 +---------+ +------+ 192 Figure 1: Reference Diagram 194 IP addressing: 196 o C's interface to D: 2001:db8:cd::c/64, D's interface: 197 2001:db8:cd::d/64 199 o C's interface to E: 2001:db8:ce::c/64, E's interface: 200 2001:db8:ce::e/64 202 o C's upper interface to F: 2001:db8:cf1::c/64, F's interface: 203 2001:db8:cf1::f/64 205 o C's lower interface to F: 2001:db8:cf2::c/64, F's interface: 206 2001:db8:cf2::f/64 208 o BGP router-ID of C: 192.0.2.3 210 o BGP router-ID of D: 192.0.2.4 212 o BGP router-ID of E: 192.0.2.5 214 o BGP router-ID of F: 192.0.2.6 216 o Loopback of F used for eBGP multi-hop peering to C: 217 2001:db8:f::f/128 219 o C's loopback is 2001:db8:c::c/128 with SID 64 221 C's BGP peering: 223 o Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) 225 o Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) 227 o Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F) 229 C's resolution of the multi-hop eBGP session to F: 231 o Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f 233 o Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f 235 C is configured with local policy that defines a BGP PeerSet as the 236 set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F) 238 X is the BGP-EPE controller within AS1 domain. 240 H is a content source within AS1 domain. 242 2. BGP Peering Segments 244 As defined in [I-D.ietf-spring-segment-routing], certain segments are 245 defined by a BGP-EPE capable node and corresponding to its attached 246 peers. These segments are called BGP peering segments or BGP Peering 247 SIDs. They enable the expression of source-routed inter-domain 248 paths. 250 An ingress border router of an AS may compose a list of segments to 251 steer a flow along a selected path within the AS, towards a selected 252 egress border router C of the AS and through a specific peer. At 253 minimum, a BGP Egress Peering Engineering policy applied at an 254 ingress EPE involves two segments: the Node SID of the chosen egress 255 EPE and then the BGP Peering Segment for the chosen egress EPE peer 256 or peering interface. 258 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 259 segments/SIDs: PeerNode SID, PeerAdj SID and PeerSet SID. 261 A Peer Node Segment is a segment describing a peer, including the SID 262 (PeerNode SID) allocated to it. 264 A Peer Adjacency Segment is a segment describing a link, including 265 the SID (PeerAdj SID) allocated to it. 267 A Peer Set Segment is a segment describing a link or a node that is 268 part of the set, including the SID (PeerSet SID) allocated to the 269 set. 271 3. Distribution of Topology and TE Information using BGP-LS 273 In ships-in-the-night mode with respect to the pre-existing iBGP 274 design, a BGP-LS [RFC7752] session is established between the BGP-EPE 275 enabled border router and the BGP-EPE controller. 277 As a result of its local configuration and according to the behavior 278 described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C 279 allocates the following BGP Peering Segments 280 ([I-D.ietf-spring-segment-routing]): 282 o A PeerNode segment for each of its defined peer (D: 1012, E: 1022 283 and F: 1052). 285 o A PeerAdj segment for each recursing interface to a multi-hop peer 286 (e.g.: the upper and lower interfaces from C to F in figure 1). 288 o A PeerSet segment to the set of peers (E and F). In this case the 289 PeerSet represents a set of peers (E, F) belonging to the same AS 290 (AS 3). 292 C programs its forwarding table accordingly: 294 Incoming Outgoing 295 Label Operation Interface 296 ------------------------------------ 297 1012 POP link to D 298 1022 POP link to E 299 1032 POP upper link to F 300 1042 POP lower link to F 301 1052 POP load balance on any link to F 302 1060 POP load balance on any link to E or to F 304 C signals the related BGP-LS NLRI's to the BGP-EPE controller. Each 305 such BGP-LS route is described in the following subsections according 306 to the encoding details defined in 307 [I-D.ietf-idr-bgpls-segment-routing-epe]. 309 3.1. PeerNode SID to D 311 Descriptors: 313 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): 314 192.0.2.3, AS1, 1000 316 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2 318 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor 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 Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 330 192.0.2.3, AS1, 1000 332 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3 334 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 335 2001:db8:ce::c, 2001:db8:ce::e 337 Attributes: 339 o PeerNode SID: 1022 341 o PeerSetSID: 1060 343 o Link Attributes: see section 3.3.2 of [RFC7752] 345 3.3. PeerNode SID to F 347 Descriptors: 349 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 350 192.0.2.3, AS1, 1000 352 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 354 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 355 2001:db8:c::c, 2001:db8:f::f 357 Attributes: 359 o PeerNode SID: 1052 361 o PeerSetSID: 1060 363 3.4. First PeerAdj to F 365 Descriptors: 367 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 368 192.0.2.3, AS1, 1000 370 o Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 372 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 373 2001:db8:cf1::c, 2001:db8:cf1::f 375 Attributes: 377 o PeerAdj-SID: 1032 379 o LinkAttributes: see section 3.3.2 of [RFC7752] 381 3.5. Second PeerAdj to F 383 Descriptors: 385 o Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier)): 386 192.0.2.3 , AS1 388 o Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 390 o Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): 391 2001:db8:cf2::c, 2001:db8:cf2::f 393 Attributes: 395 o PeerAdj-SID: 1042 397 o LinkAttributes: see section 3.3.2 of [RFC7752] 399 3.6. Fast Reroute (FRR) 401 A BGP-EPE enabled border router MAY allocate a FRR backup entry on a 402 per BGP Peering SID basis. One example is as follows: 404 o PeerNode SID 406 1. If multi-hop, backup via the remaining PeerADJ SIDs (if 407 available) to the same peer. 409 2. Else backup via another PeerNode SID to the same AS. 411 3. Else pop the PeerNode SID and perform an IP lookup. 413 o PeerAdj SID 415 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 416 (if available) to the same peer. 418 2. Else backup via a PeerNode SID to the same AS. 420 3. Else pop the PeerNode SID and perform an IP lookup. 422 o PeerSet SID 424 1. Backup via remaining PeerNode SIDs in the same PeerSet. 426 2. Else pop the PeerNode SID and IP lookup. 428 Let's illustrate different types of possible backups using the 429 reference diagram and considering the Peering SIDs allocated by C. 431 PeerNode SID 1052, allocated by C for peer F: 433 o Upon the failure of the upper connected link CF, C can reroute all 434 the traffic onto the lower CF link to the same peer (F). 436 PeerNode SID 1022, allocated by C for peer E: 438 o Upon the failure of the connected link CE, C can reroute all the 439 traffic onto the link to PeerNode SID 1052 (F). 441 PeerNode SID 1012, allocated by C for peer D: 443 o Upon the failure of the connected link CD, C can pop the PeerNode 444 SID and lookup the IP destination address in its FIB and route 445 accordingly. 447 PeerSet SID 1060, allocated by C for the set of peers E and F: 449 o Upon the failure of a connected link in the group, the traffic to 450 PeerSet SID 1060 is rerouted on any other member of the group. 452 For specific business reasons, the operator might not want the 453 default FRR behavior applied to a PeerNode SID or any of its 454 dependent PeerADJ SID. 456 The operator should be able to associate a specific backup PeerNode 457 SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) 458 which overrules the default behavior which would have preferred F as 459 a backup for E. 461 4. BGP-EPE Controller 463 In this section, Let's provide a non-exhaustive set of inputs that a 464 BGP-EPE controller would likely collect such as to perform the BGP- 465 EPE policy decision. 467 The exhaustive definition is outside the scope of this document. 469 4.1. Valid Paths From Peers 471 The BGP-EPE controller should collect all the BGP paths (i.e.: IP 472 destination prefixes) advertised by all the BGP-EPE enabled border 473 router. 475 This could be realized by setting an iBGP session with the BGP-EPE 476 enabled border router, with the router configured to advertise all 477 paths using BGP add-path [RFC7911] and the original next-hop 478 preserved. 480 In this case, C would advertise the following Internet routes to the 481 BGP-EPE controller: 483 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:cd::d, AS Path {AS 2, 484 4} 486 * X (i.e.: the BGP-EPE controller) knows that C receives a path 487 to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. 489 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:ce::e, AS Path {AS 3, 490 4} 492 * X knows that C receives a path to 2001:db8:abcd::/48 via 493 neighbor 2001:db8:ce::e of AS2. 495 o NLRI <2001:db8:abcd::/48>, next-hop 2001:db8:f::f, AS Path {AS 3, 496 4} 498 * X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 499 via neighbor 2001:db8:f::f 501 An alternative option would be for a BGP-EPE collector to use BGP 502 Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP- 503 EPE enabled border routers. 505 4.2. Intra-Domain Topology 507 The BGP-EPE controller should collect the internal topology and the 508 related IGP SIDs. 510 This could be realized by collecting the IGP LSDB of each area or 511 running a BGP-LS session with a node in each IGP area. 513 4.3. External Topology 515 Thanks to the collected BGP-LS routes described in section 2, the 516 BGP-EPE controller is able to maintain an accurate description of the 517 egress topology of node C. Furthermore, the BGP-EPE controller is 518 able to associate BGP Peering SIDs to the various components of the 519 external topology. 521 4.4. SLA characteristics of each peer 523 The BGP-EPE controller might collect SLA characteristics across 524 peers. This requires an BGP-EPE solution as the SLA probes need to 525 be steered via non-best-path peers. 527 Unidirectional SLA monitoring of the desired path is likely required. 528 This might be possible when the application is controlled at the 529 source and the receiver side. Unidirectional monitoring dissociates 530 the SLA characteristic of the return path (which cannot usually be 531 controlled) from the forward path (the one of interest for pushing 532 content from a source to a consumer and the one which can be 533 controlled). 535 Alternatively, Extended Metrics, as defined in [RFC7810] could also 536 be advertised using BGP-LS ([I-D.ietf-idr-te-pm-bgp]). 538 4.5. Traffic Matrix 540 The BGP-EPE controller might collect the traffic matrix to its peers 541 or the final destinations. IPFIX [RFC7011] is a likely option. 543 An alternative option consists in collecting the link utilization 544 statistics of each of the internal and external links, also available 545 in the current definition of [RFC7752]. 547 4.6. Business Policies 549 The BGP-EPE controller should be configured or collect business 550 policies through any desired mechanisms. These mechanisms by which 551 these policies are configured or collected are outside the scope of 552 this document. 554 4.7. BGP-EPE Policy 556 On the basis of all these inputs (and likely others), the BGP-EPE 557 Controller decides to steer some demands away from their best BGP 558 path. 560 The BGP-EPE policy is likely expressed as a two-entry segment list 561 where the first element is the IGP prefix SID of the selected egress 562 border router and the second element is a BGP Peering SID at the 563 selected egress border router. 565 A few examples are provided hereafter: 567 o Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID 568 of PE C as defined in Section 1.1. 570 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, 571 {64, 1022}. 573 o Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, 574 {64, 1052}. 576 o Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f 577 of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}. 579 o Prefer egress PE C and any interface to any peer in the group 580 1060: {64, 1060}. 582 Note that the first SID could be replaced by a list of segments. 583 This is useful when an explicit path within the domain is required 584 for traffic engineering purposes. For example, if the Prefix SID of 585 node B is 60 and the BGP-EPE controller would like to steer the 586 traffic from A to C via B then through the external link to peer D 587 then the segment list would be {60, 64, 1012}. 589 5. Programming an input policy 591 The detailed/exhaustive description of all the means to implement an 592 BGP-EPE policy are outside the scope of this document. A few 593 examples are provided in this section. 595 5.1. At a Host 597 A static IP/MPLS route can be programmed at the host H. The static 598 route would define a destination prefix, a next-hop and a label stack 599 to push. Assuming a global SRGB, at least on all access routers 600 connecting the hosts, the same policy can be programmed across all 601 hosts, which is convenient. 603 5.2. At a router - SR Traffic Engineering tunnel 605 The BGP-EPE controller can configure the ingress border router with 606 an SR traffic engineering tunnel T1 and a steering-policy S1 which 607 causes a certain class of traffic to be mapped on the tunnel T1. 609 The tunnel T1 would be configured to push the required segment list. 611 The tunnel and the steering policy could be configured via multiple 612 means. A few examples are given below: 614 o PCEP according to [I-D.ietf-pce-segment-routing] and 615 [I-D.ietf-pce-pce-initiated-lsp]. 617 o Netconf ([RFC6241]). 619 o Other static or ephemeral APIs 621 Example: at router A (Figure 1). 623 Tunnel T1: push {64, 1042} 624 IP route L/8 set next-hop T1 626 5.3. At a Router - BGP Labeled Unicast route (RFC8277) 628 The BGP-EPE Controller could build a BGP Labeled Unicast route 629 [RFC8277]) route (from scratch) and send it to the ingress router: 631 o NLRI: the destination prefix to engineer: e.g., L/8. 633 o Next-Hop: the selected egress border router: C. 635 o Label: the selected egress peer: 1042. 637 o AS path: reflecting the selected valid AS path. 639 o Some BGP policy to ensure it will be selected as best by the 640 ingress router. Note that as discussed in RFC 8277 section 5, the 641 comparison of labeled and unlabeled unicast BGP route is 642 implementation dependent and hence may require an implementation 643 specific policy on each ingress router. 645 This BGP Labeled unicast route (RFC8277) "overwrites" an equivalent 646 or less-specific "best path". As the best-path is changed, this BGP- 647 EPE input policy option may influence the path propagated to the 648 upstream peer/customers. Indeed, implementations treating the SAFI-1 649 and SAFI-4 routes for a given prefix as comparable would trigger a 650 BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers. 652 5.4. At a Router - VPN policy route 654 The BGP-EPE Controller could build a VPNv4 route (from scratch) and 655 send it to the ingress router: 657 o NLRI: the destination prefix to engineer: e.g., L/8. 659 o Next-Hop: the selected egress border router: C. 661 o Label: the selected egress peer: 1042. 663 o Route-Target: selecting the appropriate VRF at the ingress router. 665 o AS path: reflecting the selected valid AS path. 667 o Some BGP policy to ensure it will be selected as best by the 668 ingress router in the related VRF. 670 The related VRF must be preconfigured. A VRF fallback to the main 671 FIB might be beneficial to avoid replicating all the "normal" 672 Internet paths in each VRF. 674 6. IPv6 Dataplane 676 The described solution is applicable to IPv6, either with MPLS-based 677 or IPv6-Native segments. In both cases, the same three steps of the 678 solution are applicable: 680 o BGP-LS-based signaling of the external topology and BGP Peering 681 Segments to the BGP-EPE controller. 683 o Collection of various inputs by the BGP-EPE controller to come up 684 with a policy decision. 686 o Programming at an ingress router or source host of the desired 687 BGP-EPE policy which consists in a list of segments to push on a 688 defined traffic class. 690 7. Benefits 692 The BGP-EPE solutions described in this document have the following 693 benefits: 695 o No assumption on the iBGP design within AS1. 697 o Next-Hop-Self on the Internet routes propagated to the ingress 698 border routers is possible. This is a common design rule to 699 minimize the number of IGP routes and to avoid importing external 700 churn into the internal routing domain. 702 o Consistent support for traffic engineering within the domain and 703 at the external edge of the domain. 705 o Support both host and ingress border router BGP-EPE policy 706 programming. 708 o BGP-EPE functionality is only required on the BGP-EPE enabled 709 egress border router and the BGP-EPE controller: an ingress policy 710 can be programmed at the ingress border router without any new 711 functionality. 713 o Ability to deploy the same input policy across hosts connected to 714 different routers (assuming the global property of IGP prefix 715 SIDs). 717 8. IANA Considerations 719 This document does not request any IANA allocations. 721 9. Manageability Considerations 723 The BGP-EPE use-case described in this document requires BGP-LS 724 ([RFC7752]) extensions that are described in 725 [I-D.ietf-idr-bgpls-segment-routing-epe]. The required extensions 726 consists of additional BGP-LS descriptors and TLVs that will follow 727 the same. Manageability functions of BGP-LS, described in [RFC7752] 728 also apply to the extensions required by the EPE use-case. 730 Additional Manageability considerations are described in 731 [I-D.ietf-idr-bgpls-segment-routing-epe]. 733 10. Security Considerations 735 [RFC7752] defines BGP-LS NLRIs and their associated security aspects. 737 [I-D.ietf-idr-bgpls-segment-routing-epe] defines the BGP-LS 738 extensions required by the BGP-EPE mechanisms described in this 739 document. BGP-EPE BGP-LS extensions also include the related 740 security. 742 11. Contributors 744 Daniel Ginsburg substantially contributed to the content of this 745 document. 747 12. Acknowledgements 749 The authors would like to thank Acee Lindem for his comments and 750 contribution. 752 13. References 754 13.1. Normative References 756 [I-D.ietf-idr-bgpls-segment-routing-epe] 757 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 758 Dong, "BGP-LS extensions for Segment Routing BGP Egress 759 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 760 epe-14 (work in progress), December 2017. 762 [I-D.ietf-spring-segment-routing] 763 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 764 Litkowski, S., and R. Shakir, "Segment Routing 765 Architecture", draft-ietf-spring-segment-routing-14 (work 766 in progress), December 2017. 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, 770 DOI 10.17487/RFC2119, March 1997, 771 . 773 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 774 S. Ray, "North-Bound Distribution of Link-State and 775 Traffic Engineering (TE) Information Using BGP", RFC 7752, 776 DOI 10.17487/RFC7752, March 2016, 777 . 779 13.2. Informative References 781 [I-D.ietf-idr-te-pm-bgp] 782 Ginsberg, L., Previdi, S., Wu, Q., Gredler, H., Ray, S., 783 Tantsura, J., and C. Filsfils, "BGP-LS Advertisement of 784 IGP Traffic Engineering Performance Metric Extensions", 785 draft-ietf-idr-te-pm-bgp-08 (work in progress), August 786 2017. 788 [I-D.ietf-pce-pce-initiated-lsp] 789 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 790 Extensions for PCE-initiated LSP Setup in a Stateful PCE 791 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 792 progress), October 2017. 794 [I-D.ietf-pce-segment-routing] 795 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 796 and J. Hardwick, "PCEP Extensions for Segment Routing", 797 draft-ietf-pce-segment-routing-11 (work in progress), 798 November 2017. 800 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 801 and A. Bierman, Ed., "Network Configuration Protocol 802 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 803 . 805 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 806 "Specification of the IP Flow Information Export (IPFIX) 807 Protocol for the Exchange of Flow Information", STD 77, 808 RFC 7011, DOI 10.17487/RFC7011, September 2013, 809 . 811 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 812 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 813 RFC 7810, DOI 10.17487/RFC7810, May 2016, 814 . 816 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 817 Monitoring Protocol (BMP)", RFC 7854, 818 DOI 10.17487/RFC7854, June 2016, 819 . 821 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 822 Litkowski, S., Horneffer, M., and R. Shakir, "Source 823 Packet Routing in Networking (SPRING) Problem Statement 824 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 825 2016, . 827 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 828 "Advertisement of Multiple Paths in BGP", RFC 7911, 829 DOI 10.17487/RFC7911, July 2016, 830 . 832 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 833 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 834 . 836 Authors' Addresses 838 Clarence Filsfils (editor) 839 Cisco Systems, Inc. 840 Brussels 841 BE 843 Email: cfilsfil@cisco.com 845 Stefano Previdi 846 Cisco Systems, Inc. 847 Italy 849 Email: stefano@previdi.net 851 Gaurav Dawra (editor) 852 Cisco Systems, Inc. 853 USA 855 Email: gdawra.ietf@gmail.com 856 Ebben Aries 857 Juniper Networks 858 1133 Innovation Way 859 Sunnyvale CA 94089 860 US 862 Email: exa@juniper.net 864 Dmitry Afanasiev 865 Yandex 866 RU 868 Email: fl0w@yandex-team.ru