idnits 2.17.1 draft-ietf-spring-segment-routing-central-epe-02.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2016) is 2774 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-05 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-07 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-06 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-09 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-09 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 2 errors (**), 0 flaws (~~), 9 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: March 17, 2017 E. Aries 6 Facebook 7 D. Ginsburg 8 D. Afanasiev 9 Yandex 10 September 13, 2016 12 Segment Routing Centralized BGP Peer Engineering 13 draft-ietf-spring-segment-routing-central-epe-02 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 and service chain while maintaining 22 per-flow state 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 minor 26 extension to the existing link-state routing protocols. 28 This document illustrates the application of Segment Routing to solve 29 the BGP Peer Engineering (BGP-PE) requirement. The SR-based BGP-PE 30 solution allows a centralized (SDN) controller to program any egress 31 peer policy at ingress border routers or at hosts within the domain. 32 This document is on the informational track. 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 http://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 March 17, 2017. 57 Copyright Notice 59 Copyright (c) 2016 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 (http://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. Segment Routing Documents . . . . . . . . . . . . . . . . 3 76 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 77 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 78 3. Distribution of External Topology and TE Information using 79 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID 7 81 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID 7 82 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID 8 83 3.4. BGP-PE Router advertising a first PeerAdj to Peer F . . . 8 84 3.5. BGP-PE Router advertising a second PeerAdj to Peer F . . 9 85 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 86 4. BGP-PE Controller . . . . . . . . . . . . . . . . . . . . . . 10 87 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 88 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 89 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 90 4.4. SLA characteristics of each peer . . . . . . . . . . . . 11 91 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 92 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 93 4.7. BGP-PE Policy . . . . . . . . . . . . . . . . . . . . . . 12 94 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 95 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 96 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 97 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 13 98 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 99 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 100 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 101 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 103 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 108 12.2. Informative References . . . . . . . . . . . . . . . . . 16 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 111 1. Introduction 113 The document is structured as follows: 115 o Section 1 states the BGP-PE problem statement and provides the key 116 references. 118 o Section 2 defines the different BGP Peering Segments and the 119 semantic associated to them. 121 o Section 3 describes the automated allocation of BGP Peering SID's 122 by the BGP-PE enabled egress border router and the automated 123 signaling of the external peering topology and the related BGP 124 Peering SID's to the collector 125 [I-D.ietf-idr-bgpls-segment-routing-epe]. 127 o Section 4 overviews the components of a centralized EPE 128 controller. The definition of the EPE controller is outside the 129 scope of this document. 131 o Section 5 overviews the methods that could be used by the 132 centralized BGP-PE controller to implement a BGP-PE policy at an 133 ingress border router or at a source host within the domain. The 134 exhaustive definition of all the means to program an BGP-PE input 135 policy is outside the scope of this document. 137 For editorial reasons, the solution is described for IPv4. A later 138 section describes how the same solution is applicable to IPv6. 140 1.1. Segment Routing Documents 142 The main references for this document are: 144 o SR Problem Statement: [I-D.ietf-spring-problem-statement]. 146 o SR Architecture: [I-D.ietf-spring-segment-routing]. 148 o Distribution of External Topology and TE Information using BGP: 149 [I-D.ietf-idr-bgpls-segment-routing-epe]. 151 The SR instantiation in the MPLS dataplane is described in 152 [I-D.ietf-spring-segment-routing-mpls]. 154 The SR IGP protocol extensions are defined in 155 [I-D.ietf-isis-segment-routing-extensions], 156 [I-D.ietf-ospf-segment-routing-extensions] and 157 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 159 The Segment Routing PCE protocol extensions are defined in 160 [I-D.ietf-pce-segment-routing]. 162 1.2. Problem Statement 164 The BGP-PE problem statement is defined in 165 [I-D.ietf-spring-problem-statement]. 167 A centralized controller should be able to instruct an ingress 168 Provider Edge router (PE) or a content source within the domain to 169 use a specific egress PE and a specific external interface/neighbor 170 to reach a particular destination. 172 We call this solution "BGP-PE" for "BGP Peer Engineering". The 173 centralized controller is called the "BGP-PE Controller". The egress 174 border router where the BGP-PE traffic-steering functionality is 175 implemented is called a BGP-PE-enabled border router. The input 176 policy programmed at an ingress border router or at a source host is 177 called a BGP-PE policy. 179 The requirements that have motivated the solution described in this 180 document are listed here below: 182 o The solution MUST apply to the Internet use-case where the 183 Internet routes are assumed to use IPv4 unlabeled or IPv6 184 unlabeled. It is not required to place the Internet routes in a 185 VRF and allocate labels on a per route, or on a per-path basis. 187 o The solution MUST NOT make any assumption on the currently 188 deployed iBGP schemes (RRs, confederations or iBGP full meshes) 189 and MUST be able to support all of them. 191 o The solution MUST be applicable to iBGP as well as eBGP peerings. 193 o The solution SHOULD minimize the need for new BGP capabilities at 194 the ingress PEs. 196 o The solution MUST accommodate an ingress BGP-PE policy at an 197 ingress PE or directly at an source host within the domain. 199 o The solution MUST support automated Fast Reroute (FRR) and fast 200 convergence mechanisms. 202 The following reference diagram is used throughout this document. 204 +---------+ +------+ 205 | | | | 206 | H B------D G 207 | | +---/| AS 2 |\ +------+ 208 | |/ +------+ \ | |---L/8 209 A AS1 C---+ \| | 210 | |\\ \ +------+ /| AS 4 |---M/8 211 | | \\ +-E |/ +------+ 212 | X | \\ | K 213 | | +===F AS 3 | 214 +---------+ +------+ 216 Figure 1: Reference Diagram 218 IPv4 addressing: 220 o C's interface to D: 198.51.100.1/30, D's interface: 221 198.51.100.2/30 223 o C's interface to E: 198.51.100.5/30, E's interface: 224 198.51.100.6/30 226 o C's upper interface to F: 198.51.100.9/30, F's interface: 227 198.51.100.10/30 229 o C's lower interface to F: 198.51.100.13/30, F's interface: 230 198.51.100.14/30 232 o Loopback of F used for eBGP multi-hop peering to C: 192.0.2.2/32 234 o C's loopback is 203.0.113.3/32 with SID 64 236 C's BGP peering: 238 o Single-hop eBGP peering with neighbor 198.51.100.2 (D) 240 o Single-hop eBGP peering with neighbor 198.51.100.6 (E) 241 o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F) 243 C's resolution of the multi-hop eBGP session to F: 245 o Static route 192.0.2.2/32 via 198.51.100.10 247 o Static route 192.0.2.2/32 via 198.51.100.14 249 C is configured with local policy that defines a BGP PeerSet as the 250 set of peers (198.51.100.6 and 192.0.2.2) 252 X is the BGP-PE controller within AS1 domain. 254 H is a content source within AS1 domain. 256 2. BGP Peering Segments 258 As defined in [I-D.ietf-spring-segment-routing], certain segments are 259 defined by BGP-PE capable node and corresponding to its attached 260 peers. These segments are called BGP peering segments or BGP Peering 261 SIDs. They enable the expression of source-routed inter-domain 262 paths. 264 An ingress border router of an AS may compose a list of segments to 265 steer a flow along a selected path within the AS, towards a selected 266 egress border router C of the AS and through a specific peer. At 267 minimum, a BGP Peering Engineering policy applied at an ingress PE 268 involves two segments: the Node SID of the chosen egress PE and then 269 the BGP Peering Segment for the chosen egress PE peer or peering 270 interface. 272 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 273 segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. 275 The BGP extensions to signal these BGP peering segments are outlined 276 in the following section. 278 3. Distribution of External Topology and TE Information using BGP-LS 280 In ships-in-the-night mode with respect to the pre-existing iBGP 281 design, a BGP-LS session is established between the BGP-PE enabled 282 border router and the BGP-PE controller. 284 As a result of its local configuration and according to the behavior 285 described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C 286 allocates the following BGP Peering Segments 287 ([I-D.ietf-spring-segment-routing]): 289 o A PeerNode segment for each of its defined peer (D, E and F). 291 o A PeerAdj segment for each recursing interface to a multi-hop peer 292 (e.g.: the upper and lower interfaces from C to F in figure 1). 294 o A PeerSet segment to the set of peers (E and F). 296 C programs its forwarding table accordingly: 298 Incoming Outgoing 299 Label Operation Interface 300 ------------------------------------ 301 1012 POP link to D 302 1022 POP link to E 303 1032 POP upper link to F 304 1042 POP lower link to F 305 1052 POP load balance on any link to F 306 1060 POP load balance on any link to E or to F 308 C signals the related BGP-LS NLRI's to the BGP-PE controller. Each 309 such BGP-LS route is described in the following subsections according 310 to the encoding details defined in 311 [I-D.ietf-idr-bgpls-segment-routing-epe]. 313 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID 315 Descriptors: 317 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 319 o Peer Descriptors (peer ASN): AS2 321 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 322 198.51.100.1, 198.51.100.2 324 Attributes: 326 o PeerNode-SID: 1012 328 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID 330 Descriptors: 332 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 334 o Peer Descriptors (peer ASN): AS3 335 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 336 198.51.100.5, 198.51.100.6 338 Attributes: 340 o PeerNode-SID: 1022 342 o PeerSetSID: 1060 344 o Link Attributes: see section 3.3.2 of [RFC7752] 346 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID 348 Descriptors: 350 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 352 o Peer Descriptors (peer ASN): AS3 354 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 355 203.0.113.3, 192.0.2.2 357 Attributes: 359 o PeerNode-SID: 1052 361 o PeerSetSID: 1060 363 3.4. BGP-PE Router advertising a first PeerAdj to Peer F 365 Descriptors: 367 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 369 o Peer Descriptors (peer ASN): AS3 371 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 372 198.51.100.9, 198.51.100.10 374 Attributes: 376 o PeerAdj-SID: 1032 378 o LinkAttributes: see section 3.3.2 of [RFC7752] 380 3.5. BGP-PE Router advertising a second PeerAdj to Peer F 382 Descriptors: 384 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 386 o Peer Descriptors (peer ASN): AS3 388 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 389 198.51.100.13, 198.51.100.14 391 Attributes: 393 o PeerAdj-SID: 1042 395 o LinkAttributes: see section 3.3.2 of [RFC7752] 397 3.6. Fast Reroute (FRR) 399 An BGP-PE enabled border router should allocate a FRR backup entry on 400 a per BGP Peering SID basis: 402 o PeerNode SID 404 1. If multi-hop, backup via the remaining PeerADJ SIDs to the 405 same peer. 407 2. Else backup via local PeerNode SID to the same AS. 409 3. Else pop the PeerNode SID and perform an IP lookup. 411 o PeerAdj SID 413 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 414 to the same peer. 416 2. Else backup via PeerNode SID to the same AS. 418 3. Else pop the PeerNode SID and perform an IP lookup. 420 o PeerSet SID 422 1. Backup via remaining PeerNode SIDs in the same PeerSet. 424 2. Else pop the PeerNode SID and IP lookup. 426 We illustrate the different types of possible backups using the 427 reference diagram and considering the Peering SIDs allocated by C. 429 PeerNode SID 1052, allocated by C for peer F: 431 o Upon the failure of the upper connected link CF, C can reroute all 432 the traffic onto the lower CF link to the same peer (F). 434 PeerNode SID 1022, allocated by C for peer E: 436 o Upon the failure of the connected link CE, C can reroute all the 437 traffic onto the link to PeerNode SID 1052 (F). 439 PeerNode SID 1012, allocated by C for peer D: 441 o Upon the failure of the connected link CD, C can pop the PeerNode 442 SID and lookup the IP destination address in its FIB and route 443 accordingly. 445 PeerSet SID 1060, allocated by C for the set of peers E and F: 447 o Upon the failure of a connected link in the group, the traffic to 448 PeerSet SID 1060 is rerouted on any other member of the group. 450 For specific business reasons, the operator might not want the 451 default FRR behavior applied to a PeerNode SID or any of its 452 dependent PeerADJ SID. 454 The operator should be able to associate a specific backup PeerNode 455 SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) 456 which overrules the default behavior which would have preferred F as 457 a backup for E. 459 4. BGP-PE Controller 461 In this section, we provide a non-exhaustive set of inputs that an 462 BGP-PE controller would likely collect such as to perform the BGP-PE 463 policy decision. 465 The exhaustive definition is outside the scope of this document. 467 4.1. Valid Paths From Peers 469 The BGP-PE controller should collect all the paths advertised by all 470 the engineered peers. 472 This could be realized by setting an iBGP session with the BGP-PE 473 enabled border router, with "add-path all" and the original next-hop 474 preserved. 476 In this case, C would advertise the following Internet routes to the 477 BGP-PE controller: 479 o NLRI , nhop 198.51.100.2, AS Path {AS 2, 4} 481 * X (i.e.: the BGP-PE controller) knows that C receives a path to 482 L/8 via neighbor 198.51.100.2 of AS2. 484 o NLRI , nhop 198.51.100.6, AS Path {AS 3, 4} 486 * X knows that C receives a path to L/8 via neighbor 198.51.100.6 487 of AS2. 489 o NLRI , nhop 192.0.2.2, AS Path {AS 3, 4} 491 * X knows that C has an eBGP path to L/8 via AS3 via neighbor 492 192.0.2.2 494 An alternative option would be for an BGP-PE collector to use BGP 495 Monitoring Protocol (BMP) to track the Adj-RIB-In of BGP-PE enabled 496 border routers. 498 4.2. Intra-Domain Topology 500 The BGP-PE controller should collect the internal topology and the 501 related IGP SIDs. 503 This could be realized by collecting the IGP LSDB of each area or 504 running a BGP-LS session with a node in each IGP area. 506 4.3. External Topology 508 Thanks to the collected BGP-LS routes described in the section 2 509 (BGP-LS advertisements), the BGP-PE controller is able to maintain an 510 accurate description of the egress topology of node C. Furthermore, 511 the BGP-PE controller is able to associate BGP Peering SIDs to the 512 various components of the external topology. 514 4.4. SLA characteristics of each peer 516 The BGP-PE controller might collect SLA characteristics across peers. 517 This requires an BGP-PE solution as the SLA probes need to be steered 518 via non-best-path peers. 520 Unidirectional SLA monitoring of the desired path is likely required. 521 This might be possible when the application is controlled at the 522 source and the receiver side. Unidirectional monitoring dissociates 523 the SLA characteristic of the return path (which cannot usually be 524 controlled) from the forward path (the one of interest for pushing 525 content from a source to a consumer and the one which can be 526 controlled). 528 Alternatively, Extended Metrics, as defined in 529 [I-D.ietf-isis-te-metric-extensions] could also be advertised using 530 new BGP-LS attributes. 532 4.5. Traffic Matrix 534 The BGP-PE controller might collect the traffic matrix to its peers 535 or the final destinations. IPFIX is a likely option. 537 An alternative option consists in collecting the link utilization 538 statistics of each of the internal and external links, also available 539 in the current definition of [RFC7752]. 541 4.6. Business Policies 543 The BGP-PE controller should collect business policies. 545 4.7. BGP-PE Policy 547 On the basis of all these inputs (and likely others), the BGP-PE 548 Controller decides to steer some demands away from their best BGP 549 path. 551 The BGP-PE policy is likely expressed as a two-entry segment list 552 where the first element is the IGP prefix SID of the selected egress 553 border router and the second element is a BGP Peering SID at the 554 selected egress border router. 556 A few examples are provided hereafter: 558 o Prefer egress PE C and peer AS AS2: {64, 1012}. 560 o Prefer egress PE C and peer AS AS3 via eBGP peer 198.51.100.6: 561 {64, 1022}. 563 o Prefer egress PE C and peer AS AS3 via eBGP peer 192.0.2.2: {64, 564 1052}. 566 o Prefer egress PE C and peer AS AS3 via interface 198.51.100.14 of 567 multi-hop eBGP peer 192.0.2.2: {64, 1042}. 569 o Prefer egress PE C and any interface to any peer in the group 570 1060: {64, 1060}. 572 Note that the first SID could be replaced by a list of segments. 573 This is useful when an explicit path within the domain is required 574 for traffic-engineering purposes. For example, if the Prefix SID of 575 node B is 60 and the BGP-PE controller would like to steer the 576 traffic from A to C via B then through the external link to peer D 577 then the segment list would be {60, 64, 1012}. 579 5. Programming an input policy 581 The detailed/exhaustive description of all the means to implement an 582 BGP-PE policy are outside the scope of this document. A few examples 583 are provided in this section. 585 5.1. At a Host 587 A static IP/MPLS route can be programmed at the host H. The static 588 route would define a destination prefix, a next-hop and a label stack 589 to push. The global property of the IGP Prefix SID is particularly 590 convenient: the same policy could be programmed across hosts 591 connected to different routers. 593 5.2. At a router - SR Traffic Engineering tunnel 595 The BGP-PE controller can configure the ingress border router with an 596 SR traffic engineering tunnel T1 and a steering-policy S1 which 597 causes a certain class of traffic to be mapped on the tunnel T1. 599 The tunnel T1 would be configured to push the required segment list. 601 The tunnel and the steering policy could be configured via PCEP 602 according to [I-D.ietf-pce-segment-routing] and 603 [I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]). 605 Example: at A 607 Tunnel T1: push {64, 1042} 608 IP route L/8 set nhop T1 610 5.3. At a Router - RFC3107 policy route 612 The BGP-PE Controller could build a RFC3107 ([RFC3107]) route (from 613 scratch) and send it to the ingress router: 615 o NLRI: the destination prefix to engineer: e.g., L/8. 617 o Next-Hop: the selected egress border router: C. 619 o Label: the selected egress peer: 1042. 621 o AS path: reflecting the selected valid AS path. 623 o Some BGP policy to ensure it will be selected as best by the 624 ingress router. 626 This RFC3107 policy route "overwrites" an equivalent or less-specific 627 "best path". As the best-path is changed, this EPE input policy 628 option influences the path propagated to the upstream peer/customers. 630 5.4. At a Router - VPN policy route 632 The EPE Controller could build a VPNv4 route (from scratch) and send 633 it to the ingress router: 635 o NLRI: the destination prefix to engineer: e.g., L/8. 637 o Next-Hop: the selected egress border router: C. 639 o Label: the selected egress peer: 1042. 641 o Route-Target: selecting the appropriate VRF at the ingress router. 643 o AS path: reflecting the selected valid AS path. 645 o Some BGP policy to ensure it will be selected as best by the 646 ingress router in the related VRF. 648 The related VRF must be preconfigured. A VRF fallback to the main 649 FIB might be beneficial to avoid replicating all the "normal" 650 Internet paths in each VRF. 652 5.5. At a Router - Flowspec route 654 An EPE Controller builds a FlowSpec route and sends it to the ingress 655 router to engineer: 657 o Dissemination of Flow Specification Rules ([RFC5575]. 659 o Destination/Source IP Addresses, IP Protocol, Destination/Source 660 port (+1 component). 662 o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment. 664 6. IPv6 666 The described solution is applicable to IPv6, either with MPLS-based 667 or IPv6-Native segments. In both cases, the same three steps of the 668 solution are applicable: 670 o BGP-LS-based signaling of the external topology and BGP Peering 671 Segments to the BGP-PE controller. 673 o Collection of various inputs by the BGP-PE controller to come up 674 with a policy decision. 676 o Programming at an ingress router or source host of the desired 677 BGP-PE policy which consists in a list of segments to push on a 678 defined traffic class. 680 7. Benefits 682 The BGP-PE solutions described in this document have the following 683 benefits: 685 o No assumption on the iBGP design within AS1. 687 o Next-Hop-Self on the Internet routes propagated to the ingress 688 border routers is possible. This is a common design rule to 689 minimize the number of IGP routes and to avoid importing external 690 churn into the internal routing domain. 692 o Consistent support for traffic-engineering within the domain and 693 at the external edge of the domain. 695 o Support both host and ingress border router BGP-PE policy 696 programming. 698 o BGP-PE functionality is only required on the BGP-PE enabled egress 699 border router and the BGP-PE controller: an ingress policy can be 700 programmed at the ingress border router without any new 701 functionality. 703 o Ability to deploy the same input policy across hosts connected to 704 different routers (avail the global property of IGP prefix SIDs). 706 8. IANA Considerations 708 This document does not request any IANA allocations. 710 9. Manageability Considerations 712 TBD 714 10. Security Considerations 716 TBD 718 11. Acknowledgements 720 The authors would like to thank Acee Lindem for his comments and 721 contribution. 723 12. References 725 12.1. Normative References 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 729 DOI 10.17487/RFC2119, March 1997, 730 . 732 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 733 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 734 . 736 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 737 and D. McPherson, "Dissemination of Flow Specification 738 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 739 . 741 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 742 and A. Bierman, Ed., "Network Configuration Protocol 743 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 744 . 746 12.2. Informative References 748 [I-D.ietf-idr-bgpls-segment-routing-epe] 749 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 750 and M. Chen, "Segment Routing BGP Egress Peer Engineering 751 BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- 752 epe-05 (work in progress), May 2016. 754 [I-D.ietf-isis-segment-routing-extensions] 755 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 756 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 757 Extensions for Segment Routing", draft-ietf-isis-segment- 758 routing-extensions-07 (work in progress), June 2016. 760 [I-D.ietf-isis-te-metric-extensions] 761 Previdi, S., Giacalone, S., Ward, D., Drake, J., and W. 762 Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 763 draft-ietf-isis-te-metric-extensions-11 (work in 764 progress), February 2016. 766 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 767 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 768 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 769 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 770 segment-routing-extensions-06 (work in progress), July 771 2016. 773 [I-D.ietf-ospf-segment-routing-extensions] 774 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 775 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 776 Extensions for Segment Routing", draft-ietf-ospf-segment- 777 routing-extensions-09 (work in progress), July 2016. 779 [I-D.ietf-pce-pce-initiated-lsp] 780 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 781 Extensions for PCE-initiated LSP Setup in a Stateful PCE 782 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 783 progress), July 2016. 785 [I-D.ietf-pce-segment-routing] 786 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 787 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 788 "PCEP Extensions for Segment Routing", draft-ietf-pce- 789 segment-routing-07 (work in progress), March 2016. 791 [I-D.ietf-spring-problem-statement] 792 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 793 Horneffer, M., and R. Shakir, "SPRING Problem Statement 794 and Requirements", draft-ietf-spring-problem-statement-08 795 (work in progress), April 2016. 797 [I-D.ietf-spring-segment-routing] 798 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 799 and R. Shakir, "Segment Routing Architecture", draft-ietf- 800 spring-segment-routing-09 (work in progress), July 2016. 802 [I-D.ietf-spring-segment-routing-mpls] 803 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 804 Litkowski, S., Horneffer, M., Shakir, R., 805 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 806 with MPLS data plane", draft-ietf-spring-segment-routing- 807 mpls-05 (work in progress), July 2016. 809 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 810 S. Ray, "North-Bound Distribution of Link-State and 811 Traffic Engineering (TE) Information Using BGP", RFC 7752, 812 DOI 10.17487/RFC7752, March 2016, 813 . 815 Authors' Addresses 817 Clarence Filsfils (editor) 818 Cisco Systems, Inc. 819 Brussels 820 BE 822 Email: cfilsfil@cisco.com 824 Stefano Previdi (editor) 825 Cisco Systems, Inc. 826 Via Del Serafico, 200 827 Rome 00142 828 Italy 830 Email: sprevidi@cisco.com 832 Ebben Aries 833 Facebook 834 1 Hacker Way 835 Menlo Park, CA 94025 836 US 838 Email: exa@fb.com 840 Daniel Ginsburg 841 Yandex 842 RU 844 Email: dbg@yandex-team.ru 846 Dmitry Afanasiev 847 Yandex 848 RU 850 Email: fl0w@yandex-team.ru