idnits 2.17.1 draft-filsfils-spring-segment-routing-central-epe-04.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 : ---------------------------------------------------------------------------- == There are 32 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3216 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 (-13) exists of draft-ietf-idr-ls-distribution-11 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-07 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-05 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). 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 K. Patel 5 Expires: January 7, 2016 Cisco Systems, Inc. 6 E. Aries 7 S. Shaw 8 Facebook 9 D. Ginsburg 10 D. Afanasiev 11 Yandex 12 July 6, 2015 14 Segment Routing Centralized Egress Peer Engineering 15 draft-filsfils-spring-segment-routing-central-epe-04 17 Abstract 19 Segment Routing (SR) leverages source routing. A node steers a 20 packet through a controlled set of instructions, called segments, by 21 prepending the packet with an SR header. A segment can represent any 22 instruction topological or service-based. SR allows to enforce a 23 flow through any topological path and service chain while maintaining 24 per-flow state only at the ingress node of the SR domain. 26 The Segment Routing architecture can be directly applied to the MPLS 27 dataplane with no change on the forwarding plane. It requires minor 28 extension to the existing link-state routing protocols. 30 This document illustrates the application of Segment Routing to solve 31 the Egress Peer Engineering (EPE) requirement. The SR-based EPE 32 solution allows a centralized (SDN) controller to program any egress 33 peer policy at ingress border routers or at hosts within the domain. 34 This document is on the informational track. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 7, 2016. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 4 78 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 79 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 80 3. Distribution of External Topology and TE Information using 81 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 3.1. EPE Route advertising the Peer D and its PeerNode SID . . 7 83 3.2. EPE Route advertising the Peer E and its PeerNode SID . . 7 84 3.3. EPE Route advertising the Peer F and its PeerNode SID . . 8 85 3.4. EPE Route advertising a first PeerAdj to Peer F . . . . . 8 86 3.5. EPE Route advertising a second PeerAdj to Peer F . . . . 9 87 3.6. FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 4. EPE Controller . . . . . . . . . . . . . . . . . . . . . . . 10 89 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 11 90 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 91 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 92 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 93 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 94 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 95 4.7. EPE Policy . . . . . . . . . . . . . . . . . . . . . . . 12 96 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 97 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 98 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 99 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 14 100 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 101 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 102 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 103 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 109 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 110 12.2. Informative References . . . . . . . . . . . . . . . . . 16 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 113 1. Introduction 115 The document is structured as follows: 117 o Section 1 states the EPE problem statement and provides the key 118 references. 120 o Section 2 defines the different BGP Peering Segments and the 121 semantic associated to them. 123 o Section 3 describes the automated allocation of BGP Peering SID's 124 by the EPE-enabled egress border router and the automated 125 signaling of the external peering topology and the related BGP 126 Peering SID's to the collector 127 [[I-D.previdi-idr-bgpls-segment-routing-epe]. 129 o Section 4 overviews the components of a centralized EPE 130 controller. The definition of the EPE controller is outside the 131 scope of this document. 133 o Section 5 overviews the methods that could be used by the 134 centralized EPE controller to implement an EPE policy at an 135 ingress border router or at a source host within the domain. The 136 exhaustive definition of all the means to program an EPE input 137 policy is outside the scope of this document. 139 For editorial reason, the solution is described for IPv4. A later 140 section describes how the same solution is applicable to IPv6. 142 1.1. Segment Routing Documents 144 The main references for this document are: 146 o SR Problem Statement: [I-D.ietf-spring-problem-statement]. 148 o SR Architecture: [I-D.ietf-spring-segment-routing]. 150 o Distribution of External Topology and TE Information using BGP: 151 [I-D.previdi-idr-bgpls-segment-routing-epe]. 153 The SR instantiation in the MPLS dataplane is described in 154 [I-D.ietf-spring-segment-routing-mpls]. 156 The SR IGP protocol extensions are defined in 157 [I-D.ietf-isis-segment-routing-extensions], 158 [I-D.ietf-ospf-segment-routing-extensions] and 159 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 161 The Segment Routing PCE protocol extensions are defined in 162 [I-D.ietf-pce-segment-routing]. 164 1.2. Problem Statement 166 The EPE problem statement is defined in 167 [I-D.ietf-spring-problem-statement]. 169 A centralized controller should be able to instruct an ingress PE or 170 a content source within the domain to use a specific egress PE and a 171 specific external interface to reach a particular destination. 173 We call this solution "EPE" for "Egress Peer Engineering". The 174 centralized controller is called the "EPE Controller". The egress 175 border router where the EPE traffic-steering functionality is 176 implemented is called an EPE-enabled border router. The input policy 177 programmed at an ingress border router or at a source host is called 178 an EPE policy. 180 The requirements that have motivated the solution described in this 181 document are listed here below: 183 o The solution MUST apply to the Internet use-case where the 184 Internet routes are assumed to use IPv4 unlabeled or IPv6 185 unlabeled. It is not required to place the Internet routes in a 186 VRF and allocate labels on a per route, or on a per-path basis. 188 o The solution MUST NOT make any assumption on the currently 189 deployed iBGP schemes (RRs, confederations or iBGP full meshes) 190 and MUST be able to support all of them. 192 o The solution SHOULD minimize the need for new BGP capabilities at 193 the ingress PEs. 195 o The solution MUST accommodate an ingress EPE policy at an ingress 196 PE or directly at an source host within the domain. 198 o The solution MUST support automated FRR and fast convergence. 200 The following reference diagram is used throughout this document. 202 +---------+ +------+ 203 | | | | 204 | H B------D G 205 | | +---/| AS 2 |\ +------+ 206 | |/ +------+ \ | |---L/8 207 A AS1 C---+ \| | 208 | |\\ \ +------+ /| AS 4 |---M/8 209 | | \\ +-E |/ +------+ 210 | X | \\ | K 211 | | +===F AS 3 | 212 +---------+ +------+ 214 Figure 1: Reference Diagram 216 IPv4 addressing: 218 o C's interface to D: 1.0.1.1/24, D's interface: 1.0.1.2/24 220 o C's interface to E: 1.0.2.1/24, E's interface: 1.0.2.2/24 222 o C's upper interface to F: 1.0.3.1/24, F's interface: 1.0.3.2/24 224 o C's lower interface to F: 1.0.4.1/24, F's interface: 1.0.4.2/24 226 o Loopback of F used for eBGP multi-hop peering to C: 1.0.5.2/32 228 o C's loopback is 3.3.3.3/32 with SID 64 230 C's BGP peering: 232 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 234 o Single-hop eBGP peering with neighbor 1.0.2.2 (E) 235 o Multi-hop eBGP peering with F on IP address 1.0.5.2 (F) 237 C's resolution of the multi-hop eBGP session to F: 239 o Static route 1.0.5.2/32 via 1.0.3.2 241 o Static route 1.0.5.2/32 via 1.0.4.2 243 C is configured with local policy that defines a BGP PeerSet as the 244 set of peers (1.0.2.2 and 1.0.5.2) 246 X is the EPE controller within AS1 domain. 248 H is a content source within AS1 domain. 250 2. BGP Peering Segments 252 AS defined in [I-D.ietf-spring-segment-routing], certain segments are 253 defined by an Egress Peer Engineering (EPE) capable node and 254 corresponding to its attached peers. These segments are called BGP 255 peering segments or BGP Peering SIDs. They enable the expression of 256 source-routed inter-domain paths. 258 An ingress border router of an AS may compose a list of segments to 259 steer a flow along a selected path within the AS, towards a selected 260 egress border router C of the AS and through a specific peer. At 261 minimum, a BGP Peering Engineering policy applied at an ingress PE 262 involves two segments: the Node SID of the chosen egress PE and then 263 the BGP Peering Segment for the chosen egress PE peer or peering 264 interface. 266 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 267 segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. 269 The BGP extensions to signal these BGP peering segments are outlined 270 in the following section. 272 3. Distribution of External 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 EPE-enabled 276 border router and the EPE controller. 278 As a result of its local configuration and according to the behavior 279 described in [I-D.previdi-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, E and F). 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). 290 C programs its forwarding table accordingly: 292 Incoming Outgoing 293 Label Operation Interface 294 ------------------------------------ 295 1012 POP link to D 296 1022 POP link to E 297 1032 POP upper link to F 298 1042 POP lower link to F 299 1052 POP load balance on any link to F 300 1060 POP load balance on any link to E or to F 302 C signals the related BGP-LS NLRI's to the EPE controller. Each such 303 BGP-LS route is described in the following subsections according to 304 the encoding details defined in 305 [I-D.previdi-idr-bgpls-segment-routing-epe]. 307 3.1. EPE Route advertising the Peer D and its PeerNode SID 309 Descriptors: 311 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 313 o Peer Descriptors (peer ASN): AS2 315 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 316 1.0.1.1, 1.0.1.2 318 Attributes: 320 o PeerNode-SID: 1012 322 3.2. EPE Route advertising the Peer E and its PeerNode SID 324 Descriptors: 326 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 328 o Peer Descriptors (peer ASN): AS3 329 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 330 1.0.2.1, 1.0.2.2 332 Attributes: 334 o PeerNode-SID: 1022 336 o PeerSetSID: 1060 338 o Link Attributes: see section 3.3.2 of 339 [I-D.ietf-idr-ls-distribution] 341 3.3. EPE Route advertising the Peer F and its PeerNode SID 343 Descriptors: 345 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 347 o Peer Descriptors (peer ASN): AS3 349 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 350 3.3.3.3, 1.0.5.2 352 Attributes: 354 o PeerNode-SID: 1052 356 o PeerSetSID: 1060 358 3.4. EPE Route advertising a first PeerAdj to Peer F 360 Descriptors: 362 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 364 o Peer Descriptors (peer ASN): AS3 366 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 367 1.0.3.1 , 1.0.3.2 369 Attributes: 371 o PeerAdj-SID: 1032 373 o LinkAttributes: see section 3.3.2 of 374 [I-D.ietf-idr-ls-distribution] 376 3.5. EPE Route advertising a second PeerAdj to Peer F 378 Descriptors: 380 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 382 o Peer Descriptors (peer ASN): AS3 384 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 385 1.0.4.1 , 1.0.4.2 387 Attributes: 389 o PeerAdj-SID: 1042 391 o LinkAttributes: see section 3.3.2 of 392 [I-D.ietf-idr-ls-distribution] 394 3.6. FRR 396 An EPE-enabled border router should allocate a FRR backup entry on a 397 per BGP Peering SID basis: 399 o PeerNode SID 401 1. If multi-hop, backup via the remaining PeerADJ SIDs to the 402 same peer. 404 2. Else backup via local PeerNode SID to the same AS. 406 3. Else pop the PeerNode SID and perform an IP lookup (with 407 potential BGP PIC fall-back). 409 o PeerAdj SID 411 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 412 to the same peer. 414 2. Else backup via PeerNode SID to the same AS. 416 3. Else pop the PeerNode SID and perform an IP lookup (with 417 potential BGP PIC fall-back). 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 (with potential BGP 424 PIC fall-back). 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. EPE Controller 461 In this section, we provide a non-exhaustive set of inputs that an 462 EPE controller would likely collect such as to perform the EPE policy 463 decision. 465 The exhaustive definition is outside the scope of this document. 467 4.1. Valid Paths From Peers 469 The EPE controller should collect all the paths advertised by all the 470 engineered peers. 472 This could be realized by setting an iBGP session with the EPE- 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 EPE controller: 479 o NLRI , nhop 1.0.1.2, AS Path {AS 2, 4} 481 * X (i.e.: the EPE controller) knows that C receives a path to 482 L/8 via neighbor 1.0.1.2 of AS2. 484 o NLRI , nhop 1.0.2.2, AS Path {AS 3, 4} 486 * X knows that C receives a path to L/8 via neighbor 1.0.2.2 of 487 AS2. 489 o NLRI , nhop 1.0.5.2, AS Path {AS 3, 4} 491 * X knows that C has an eBGP path to L/8 via AS3 via neighbor 492 1.0.5.2 494 An alternative option would be for an EPE collector to use BGP 495 Monitoring Protocol (BMP) to track the Adj-RIB-In of EPE-enabled 496 border routers. 498 4.2. Intra-Domain Topology 500 The EPE 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 EPE controller is able to maintain an 510 accurate description of the egress topology of node C. Furthermore, 511 the EPE 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 EPE controller might collect SLA characteristics across peers. 517 This requires an EPE 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 EPE controller might collect the traffic matrix to its peers or 535 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 [I-D.ietf-idr-ls-distribution]. 541 4.6. Business Policies 543 The EPE controller should collect business policies. 545 4.7. EPE Policy 547 On the basis of all these inputs (and likely others), the EPE 548 Controller decides to steer some demands away from their best BGP 549 path. 551 The EPE policy is likely expressed as a two-entry segment list where 552 the first element is the IGP prefix SID of the selected egress border 553 router and the second element is a BGP Peering SID at the selected 554 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 1.0.2.2: {64, 561 1022}. 563 o Prefer egress PE C and peer AS AS3 via eBGP peer 1.0.5.2: {64, 564 1052}. 566 o Prefer egress PE C and peer AS AS3 via interface 1.0.4.2 of multi- 567 hop eBGP peer 1.0.5.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 EPE controller would like to steer the traffic 576 from A to C via B then through the external link to peer D then the 577 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 EPE 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 EPE controller can configure the ingress border router with an SR 596 traffic engineering tunnel T1 and a steering-policy S1 which causes a 597 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 EPE 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 EPE controller. 673 o Collection of various inputs by the EPE controller to come up with 674 a policy decision. 676 o Programming at an ingress router or source host of the desired EPE 677 policy which consists in a list of segments to push on a defined 678 traffic class. 680 7. Benefits 682 The EPE solutions described in this document have the following 683 benefits: 685 o No assumption on the iBGP design with 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 EPE policy 696 programming. 698 o EPE functionality is only required on the EPE-enabled egress 699 border router and the EPE 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 contributiuon. 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, March 1997. 730 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 731 BGP-4", RFC 3107, May 2001. 733 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 734 and D. McPherson, "Dissemination of Flow Specification 735 Rules", RFC 5575, August 2009. 737 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 738 Bierman, "Network Configuration Protocol (NETCONF)", RFC 739 6241, June 2011. 741 12.2. Informative References 743 [I-D.ietf-idr-ls-distribution] 744 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 745 Ray, "North-Bound Distribution of Link-State and TE 746 Information using BGP", draft-ietf-idr-ls-distribution-11 747 (work in progress), June 2015. 749 [I-D.ietf-isis-segment-routing-extensions] 750 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 751 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 752 Extensions for Segment Routing", draft-ietf-isis-segment- 753 routing-extensions-05 (work in progress), June 2015. 755 [I-D.ietf-isis-te-metric-extensions] 756 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 757 A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering 758 (TE) Metric Extensions", draft-ietf-isis-te-metric- 759 extensions-07 (work in progress), June 2015. 761 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 762 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 763 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 764 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 765 segment-routing-extensions-03 (work in progress), June 766 2015. 768 [I-D.ietf-ospf-segment-routing-extensions] 769 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 770 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 771 Extensions for Segment Routing", draft-ietf-ospf-segment- 772 routing-extensions-05 (work in progress), June 2015. 774 [I-D.ietf-pce-pce-initiated-lsp] 775 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 776 Extensions for PCE-initiated LSP Setup in a Stateful PCE 777 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 778 progress), April 2015. 780 [I-D.ietf-pce-segment-routing] 781 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 782 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 783 "PCEP Extensions for Segment Routing", draft-ietf-pce- 784 segment-routing-05 (work in progress), May 2015. 786 [I-D.ietf-spring-problem-statement] 787 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 788 Horneffer, M., and R. Shakir, "SPRING Problem Statement 789 and Requirements", draft-ietf-spring-problem-statement-04 790 (work in progress), April 2015. 792 [I-D.ietf-spring-segment-routing] 793 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 794 and R. Shakir, "Segment Routing Architecture", draft-ietf- 795 spring-segment-routing-03 (work in progress), May 2015. 797 [I-D.ietf-spring-segment-routing-mpls] 798 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 799 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 800 and E. Crabbe, "Segment Routing with MPLS data plane", 801 draft-ietf-spring-segment-routing-mpls-01 (work in 802 progress), May 2015. 804 [I-D.previdi-idr-bgpls-segment-routing-epe] 805 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 806 and M. Chen, "Segment Routing Egress Peer Engineering BGP- 807 LS Extensions", draft-previdi-idr-bgpls-segment-routing- 808 epe-03 (work in progress), April 2015. 810 Authors' Addresses 812 Clarence Filsfils (editor) 813 Cisco Systems, Inc. 814 Brussels 815 BE 817 Email: cfilsfil@cisco.com 819 Stefano Previdi (editor) 820 Cisco Systems, Inc. 821 Via Del Serafico, 200 822 Rome 00142 823 Italy 825 Email: sprevidi@cisco.com 827 Keyur Patel 828 Cisco Systems, Inc. 829 US 831 Email: keyupate@cisco.com 833 Ebben Aries 834 Facebook 835 US 837 Email: exa@fb.com 839 Steve Shaw 840 Facebook 841 US 843 Email: shaw@fb.com 844 Daniel Ginsburg 845 Yandex 846 RU 848 Email: dbg@yandex-team.ru 850 Dmitry Afanasiev 851 Yandex 852 RU 854 Email: fl0w@yandex-team.ru