idnits 2.17.1 draft-filsfils-spring-segment-routing-central-epe-05.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 (August 29, 2015) is 3162 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-06 == 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-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 Summary: 2 errors (**), 0 flaws (~~), 11 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, Ed. 4 Intended status: Informational K. Patel 5 Expires: March 1, 2016 Cisco Systems, Inc. 6 E. Aries 7 Facebook 8 S. Shaw 9 Dropbox, Inc. 10 D. Ginsburg 11 D. Afanasiev 12 Yandex 13 August 29, 2015 15 Segment Routing Centralized Egress Peer Engineering 16 draft-filsfils-spring-segment-routing-central-epe-05 18 Abstract 20 Segment Routing (SR) leverages source routing. A node steers a 21 packet through a controlled set of instructions, called segments, by 22 prepending the packet with an SR header. A segment can represent any 23 instruction topological or service-based. SR allows to enforce a 24 flow through any topological path and service chain while maintaining 25 per-flow state only at the ingress node of the SR domain. 27 The Segment Routing architecture can be directly applied to the MPLS 28 dataplane with no change on the forwarding plane. It requires minor 29 extension to the existing link-state routing protocols. 31 This document illustrates the application of Segment Routing to solve 32 the Egress Peer Engineering (EPE) requirement. The SR-based EPE 33 solution allows a centralized (SDN) controller to program any egress 34 peer policy at ingress border routers or at hosts within the domain. 35 This document is on the informational track. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on March 1, 2016. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 4 79 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 80 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 81 3. Distribution of External Topology and TE Information using 82 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 3.1. EPE Route advertising the Peer D and its PeerNode SID . . 7 84 3.2. EPE Route advertising the Peer E and its PeerNode SID . . 8 85 3.3. EPE Route advertising the Peer F and its PeerNode SID . . 8 86 3.4. EPE Route advertising a first PeerAdj to Peer F . . . . . 8 87 3.5. EPE Route advertising a second PeerAdj to Peer F . . . . 9 88 3.6. FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4. EPE Controller . . . . . . . . . . . . . . . . . . . . . . . 10 90 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 11 91 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 92 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 93 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 94 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 95 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 96 4.7. EPE Policy . . . . . . . . . . . . . . . . . . . . . . . 12 97 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 98 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 99 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 100 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 14 101 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 102 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 103 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 106 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 108 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 111 12.2. Informative References . . . . . . . . . . . . . . . . . 16 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 114 1. Introduction 116 The document is structured as follows: 118 o Section 1 states the EPE problem statement and provides the key 119 references. 121 o Section 2 defines the different BGP Peering Segments and the 122 semantic associated to them. 124 o Section 3 describes the automated allocation of BGP Peering SID's 125 by the EPE-enabled egress border router and the automated 126 signaling of the external peering topology and the related BGP 127 Peering SID's to the collector 128 [I-D.previdi-idr-bgpls-segment-routing-epe]. 130 o Section 4 overviews the components of a centralized EPE 131 controller. The definition of the EPE controller is outside the 132 scope of this document. 134 o Section 5 overviews the methods that could be used by the 135 centralized EPE controller to implement an EPE policy at an 136 ingress border router or at a source host within the domain. The 137 exhaustive definition of all the means to program an EPE input 138 policy is outside the scope of this document. 140 For editorial reasons, the solution is described for IPv4. A later 141 section describes how the same solution is applicable to IPv6. 143 1.1. Segment Routing Documents 145 The main references for this document are: 147 o SR Problem Statement: [I-D.ietf-spring-problem-statement]. 149 o SR Architecture: [I-D.ietf-spring-segment-routing]. 151 o Distribution of External Topology and TE Information using BGP: 152 [I-D.previdi-idr-bgpls-segment-routing-epe]. 154 The SR instantiation in the MPLS dataplane is described in 155 [I-D.ietf-spring-segment-routing-mpls]. 157 The SR IGP protocol extensions are defined in 158 [I-D.ietf-isis-segment-routing-extensions], 159 [I-D.ietf-ospf-segment-routing-extensions] and 160 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 162 The Segment Routing PCE protocol extensions are defined in 163 [I-D.ietf-pce-segment-routing]. 165 1.2. Problem Statement 167 The EPE problem statement is defined in 168 [I-D.ietf-spring-problem-statement]. 170 A centralized controller should be able to instruct an ingress PE or 171 a content source within the domain to use a specific egress PE and a 172 specific external interface/neighbor to reach a particular 173 destination. 175 We call this solution "EPE" for "Egress Peer Engineering". The 176 centralized controller is called the "EPE Controller". The egress 177 border router where the EPE traffic-steering functionality is 178 implemented is called an EPE-enabled border router. The input policy 179 programmed at an ingress border router or at a source host is called 180 an EPE policy. 182 The requirements that have motivated the solution described in this 183 document are listed here below: 185 o The solution MUST apply to the Internet use-case where the 186 Internet routes are assumed to use IPv4 unlabeled or IPv6 187 unlabeled. It is not required to place the Internet routes in a 188 VRF and allocate labels on a per route, or on a per-path basis. 190 o The solution MUST NOT make any assumption on the currently 191 deployed iBGP schemes (RRs, confederations or iBGP full meshes) 192 and MUST be able to support all of them. 194 o The solution SHOULD minimize the need for new BGP capabilities at 195 the ingress PEs. 197 o The solution MUST accommodate an ingress EPE policy at an ingress 198 PE or directly at an source host within the domain. 200 o The solution MUST support automated FRR and fast convergence. 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) 242 o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F) 244 C's resolution of the multi-hop eBGP session to F: 246 o Static route 192.0.2.2/32 via 198.51.100.10 248 o Static route 192.0.2.2/32 via 198.51.100.14 250 C is configured with local policy that defines a BGP PeerSet as the 251 set of peers (198.51.100.6 and 192.0.2.2) 253 X is the EPE controller within AS1 domain. 255 H is a content source within AS1 domain. 257 2. BGP Peering Segments 259 As defined in [I-D.ietf-spring-segment-routing], certain segments are 260 defined by an Egress Peer Engineering (EPE) capable node and 261 corresponding to its attached peers. These segments are called BGP 262 peering segments or BGP Peering SIDs. They enable the expression of 263 source-routed inter-domain paths. 265 An ingress border router of an AS may compose a list of segments to 266 steer a flow along a selected path within the AS, towards a selected 267 egress border router C of the AS and through a specific peer. At 268 minimum, a BGP Peering Engineering policy applied at an ingress PE 269 involves two segments: the Node SID of the chosen egress PE and then 270 the BGP Peering Segment for the chosen egress PE peer or peering 271 interface. 273 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 274 segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. 276 The BGP extensions to signal these BGP peering segments are outlined 277 in the following section. 279 3. Distribution of External Topology and TE Information using BGP-LS 281 In ships-in-the-night mode with respect to the pre-existing iBGP 282 design, a BGP-LS session is established between the EPE-enabled 283 border router and the EPE controller. 285 As a result of its local configuration and according to the behavior 286 described in [I-D.previdi-idr-bgpls-segment-routing-epe], node C 287 allocates the following BGP Peering Segments 288 ([I-D.ietf-spring-segment-routing]): 290 o A PeerNode segment for each of its defined peer (D, E and F). 292 o A PeerAdj segment for each recursing interface to a multi-hop peer 293 (e.g.: the upper and lower interfaces from C to F in figure 1). 295 o A PeerSet segment to the set of peers (E and F). 297 C programs its forwarding table accordingly: 299 Incoming Outgoing 300 Label Operation Interface 301 ------------------------------------ 302 1012 POP link to D 303 1022 POP link to E 304 1032 POP upper link to F 305 1042 POP lower link to F 306 1052 POP load balance on any link to F 307 1060 POP load balance on any link to E or to F 309 C signals the related BGP-LS NLRI's to the EPE controller. Each such 310 BGP-LS route is described in the following subsections according to 311 the encoding details defined in 312 [I-D.previdi-idr-bgpls-segment-routing-epe]. 314 3.1. EPE Route advertising the Peer D and its PeerNode SID 316 Descriptors: 318 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 320 o Peer Descriptors (peer ASN): AS2 322 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 323 198.51.100.1, 198.51.100.2 325 Attributes: 327 o PeerNode-SID: 1012 329 3.2. EPE Route advertising the Peer E and its PeerNode SID 331 Descriptors: 333 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 335 o Peer Descriptors (peer ASN): AS3 337 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 338 198.51.100.5, 198.51.100.6 340 Attributes: 342 o PeerNode-SID: 1022 344 o PeerSetSID: 1060 346 o Link Attributes: see section 3.3.2 of 347 [I-D.ietf-idr-ls-distribution] 349 3.3. EPE Route advertising the Peer F and its PeerNode SID 351 Descriptors: 353 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 355 o Peer Descriptors (peer ASN): AS3 357 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 358 203.0.113.3, 192.0.2.2 360 Attributes: 362 o PeerNode-SID: 1052 364 o PeerSetSID: 1060 366 3.4. EPE Route advertising a first PeerAdj to Peer F 368 Descriptors: 370 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 372 o Peer Descriptors (peer ASN): AS3 374 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 375 198.51.100.9, 198.51.100.10 377 Attributes: 379 o PeerAdj-SID: 1032 381 o LinkAttributes: see section 3.3.2 of 382 [I-D.ietf-idr-ls-distribution] 384 3.5. EPE Route advertising a second PeerAdj to Peer F 386 Descriptors: 388 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 390 o Peer Descriptors (peer ASN): AS3 392 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 393 198.51.100.13, 198.51.100.14 395 Attributes: 397 o PeerAdj-SID: 1042 399 o LinkAttributes: see section 3.3.2 of 400 [I-D.ietf-idr-ls-distribution] 402 3.6. FRR 404 An EPE-enabled border router should allocate a FRR backup entry on a 405 per BGP Peering SID basis: 407 o PeerNode SID 409 1. If multi-hop, backup via the remaining PeerADJ SIDs to the 410 same peer. 412 2. Else backup via local PeerNode SID to the same AS. 414 3. Else pop the PeerNode SID and perform an IP lookup (with 415 potential BGP PIC fall-back). 417 o PeerAdj SID 419 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 420 to the same peer. 422 2. Else backup via PeerNode SID to the same AS. 424 3. Else pop the PeerNode SID and perform an IP lookup (with 425 potential BGP PIC fall-back). 427 o PeerSet SID 429 1. Backup via remaining PeerNode SIDs in the same PeerSet. 431 2. Else pop the PeerNode SID and IP lookup (with potential BGP 432 PIC fall-back). 434 We illustrate the different types of possible backups using the 435 reference diagram and considering the Peering SIDs allocated by C. 437 PeerNode SID 1052, allocated by C for peer F: 439 o Upon the failure of the upper connected link CF, C can reroute all 440 the traffic onto the lower CF link to the same peer (F). 442 PeerNode SID 1022, allocated by C for peer E: 444 o Upon the failure of the connected link CE, C can reroute all the 445 traffic onto the link to PeerNode SID 1052 (F). 447 PeerNode SID 1012, allocated by C for peer D: 449 o Upon the failure of the connected link CD, C can pop the PeerNode 450 SID and lookup the IP destination address in its FIB and route 451 accordingly. 453 PeerSet SID 1060, allocated by C for the set of peers E and F: 455 o Upon the failure of a connected link in the group, the traffic to 456 PeerSet SID 1060 is rerouted on any other member of the group. 458 For specific business reasons, the operator might not want the 459 default FRR behavior applied to a PeerNode SID or any of its 460 dependent PeerADJ SID. 462 The operator should be able to associate a specific backup PeerNode 463 SID for a PeerNode SID: e.g., 1022 (E) must be backed up by 1012 (D) 464 which overrules the default behavior which would have preferred F as 465 a backup for E. 467 4. EPE Controller 469 In this section, we provide a non-exhaustive set of inputs that an 470 EPE controller would likely collect such as to perform the EPE policy 471 decision. 473 The exhaustive definition is outside the scope of this document. 475 4.1. Valid Paths From Peers 477 The EPE controller should collect all the paths advertised by all the 478 engineered peers. 480 This could be realized by setting an iBGP session with the EPE- 481 enabled border router, with "add-path all" and the original next-hop 482 preserved. 484 In this case, C would advertise the following Internet routes to the 485 EPE controller: 487 o NLRI , nhop 198.51.100.2, AS Path {AS 2, 4} 489 * X (i.e.: the EPE controller) knows that C receives a path to 490 L/8 via neighbor 198.51.100.2 of AS2. 492 o NLRI , nhop 198.51.100.6, AS Path {AS 3, 4} 494 * X knows that C receives a path to L/8 via neighbor 198.51.100.6 495 of AS2. 497 o NLRI , nhop 192.0.2.2, AS Path {AS 3, 4} 499 * X knows that C has an eBGP path to L/8 via AS3 via neighbor 500 192.0.2.2 502 An alternative option would be for an EPE collector to use BGP 503 Monitoring Protocol (BMP) to track the Adj-RIB-In of EPE-enabled 504 border routers. 506 4.2. Intra-Domain Topology 508 The EPE controller should collect the internal topology and the 509 related IGP SIDs. 511 This could be realized by collecting the IGP LSDB of each area or 512 running a BGP-LS session with a node in each IGP area. 514 4.3. External Topology 516 Thanks to the collected BGP-LS routes described in the section 2 517 (BGP-LS advertisements), the EPE controller is able to maintain an 518 accurate description of the egress topology of node C. Furthermore, 519 the EPE controller is able to associate BGP Peering SIDs to the 520 various components of the external topology. 522 4.4. SLA characteristics of each peer 524 The EPE controller might collect SLA characteristics across peers. 525 This requires an EPE solution as the SLA probes need to be steered 526 via non-best-path peers. 528 Unidirectional SLA monitoring of the desired path is likely required. 529 This might be possible when the application is controlled at the 530 source and the receiver side. Unidirectional monitoring dissociates 531 the SLA characteristic of the return path (which cannot usually be 532 controlled) from the forward path (the one of interest for pushing 533 content from a source to a consumer and the one which can be 534 controlled). 536 Alternatively, Extended Metrics, as defined in 537 [I-D.ietf-isis-te-metric-extensions] could also be advertised using 538 new BGP-LS attributes. 540 4.5. Traffic Matrix 542 The EPE controller might collect the traffic matrix to its peers or 543 the final destinations. IPFIX is a likely option. 545 An alternative option consists in collecting the link utilization 546 statistics of each of the internal and external links, also available 547 in the current definition of [I-D.ietf-idr-ls-distribution]. 549 4.6. Business Policies 551 The EPE controller should collect business policies. 553 4.7. EPE Policy 555 On the basis of all these inputs (and likely others), the EPE 556 Controller decides to steer some demands away from their best BGP 557 path. 559 The EPE policy is likely expressed as a two-entry segment list where 560 the first element is the IGP prefix SID of the selected egress border 561 router and the second element is a BGP Peering SID at the selected 562 egress border router. 564 A few examples are provided hereafter: 566 o Prefer egress PE C and peer AS AS2: {64, 1012}. 568 o Prefer egress PE C and peer AS AS3 via eBGP peer 198.51.100.6: 569 {64, 1022}. 571 o Prefer egress PE C and peer AS AS3 via eBGP peer 192.0.2.2: {64, 572 1052}. 574 o Prefer egress PE C and peer AS AS3 via interface 198.51.100.14 of 575 multi-hop eBGP peer 192.0.2.2: {64, 1042}. 577 o Prefer egress PE C and any interface to any peer in the group 578 1060: {64, 1060}. 580 Note that the first SID could be replaced by a list of segments. 581 This is useful when an explicit path within the domain is required 582 for traffic-engineering purposes. For example, if the Prefix SID of 583 node B is 60 and the EPE controller would like to steer the traffic 584 from A to C via B then through the external link to peer D then the 585 segment list would be {60, 64, 1012}. 587 5. Programming an input policy 589 The detailed/exhaustive description of all the means to implement an 590 EPE policy are outside the scope of this document. A few examples 591 are provided in this section. 593 5.1. At a Host 595 A static IP/MPLS route can be programmed at the host H. The static 596 route would define a destination prefix, a next-hop and a label stack 597 to push. The global property of the IGP Prefix SID is particularly 598 convenient: the same policy could be programmed across hosts 599 connected to different routers. 601 5.2. At a router - SR Traffic Engineering tunnel 603 The EPE controller can configure the ingress border router with an SR 604 traffic engineering tunnel T1 and a steering-policy S1 which causes a 605 certain class of traffic to be mapped on the tunnel T1. 607 The tunnel T1 would be configured to push the required segment list. 609 The tunnel and the steering policy could be configured via PCEP 610 according to [I-D.ietf-pce-segment-routing] and 611 [I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]). 613 Example: at A 615 Tunnel T1: push {64, 1042} 616 IP route L/8 set nhop T1 618 5.3. At a Router - RFC3107 policy route 620 The EPE Controller could build a RFC3107 ([RFC3107]) route (from 621 scratch) and send it to the ingress router: 623 o NLRI: the destination prefix to engineer: e.g., L/8. 625 o Next-Hop: the selected egress border router: C. 627 o Label: the selected egress peer: 1042. 629 o AS path: reflecting the selected valid AS path. 631 o Some BGP policy to ensure it will be selected as best by the 632 ingress router. 634 This RFC3107 policy route "overwrites" an equivalent or less-specific 635 "best path". As the best-path is changed, this EPE input policy 636 option influences the path propagated to the upstream peer/customers. 638 5.4. At a Router - VPN policy route 640 The EPE Controller could build a VPNv4 route (from scratch) and send 641 it to the ingress router: 643 o NLRI: the destination prefix to engineer: e.g., L/8. 645 o Next-Hop: the selected egress border router: C. 647 o Label: the selected egress peer: 1042. 649 o Route-Target: selecting the appropriate VRF at the ingress router. 651 o AS path: reflecting the selected valid AS path. 653 o Some BGP policy to ensure it will be selected as best by the 654 ingress router in the related VRF. 656 The related VRF must be preconfigured. A VRF fallback to the main 657 FIB might be beneficial to avoid replicating all the "normal" 658 Internet paths in each VRF. 660 5.5. At a Router - Flowspec route 662 An EPE Controller builds a FlowSpec route and sends it to the ingress 663 router to engineer: 665 o Dissemination of Flow Specification Rules ([RFC5575]. 667 o Destination/Source IP Addresses, IP Protocol, Destination/Source 668 port (+1 component). 670 o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment. 672 6. IPv6 674 The described solution is applicable to IPv6, either with MPLS-based 675 or IPv6-Native segments. In both cases, the same three steps of the 676 solution are applicable: 678 o BGP-LS-based signaling of the external topology and BGP Peering 679 Segments to the EPE controller. 681 o Collection of various inputs by the EPE controller to come up with 682 a policy decision. 684 o Programming at an ingress router or source host of the desired EPE 685 policy which consists in a list of segments to push on a defined 686 traffic class. 688 7. Benefits 690 The EPE solutions described in this document have the following 691 benefits: 693 o No assumption on the iBGP design with AS1. 695 o Next-Hop-Self on the Internet routes propagated to the ingress 696 border routers is possible. This is a common design rule to 697 minimize the number of IGP routes and to avoid importing external 698 churn into the internal routing domain. 700 o Consistent support for traffic-engineering within the domain and 701 at the external edge of the domain. 703 o Support both host and ingress border router EPE policy 704 programming. 706 o EPE functionality is only required on the EPE-enabled egress 707 border router and the EPE controller: an ingress policy can be 708 programmed at the ingress border router without any new 709 functionality. 711 o Ability to deploy the same input policy across hosts connected to 712 different routers (avail the global property of IGP prefix SIDs). 714 8. IANA Considerations 716 This document does not request any IANA allocations. 718 9. Manageability Considerations 720 TBD 722 10. Security Considerations 724 TBD 726 11. Acknowledgements 728 The authors would like to thank Acee Lindem for his comments and 729 contributiuon. 731 12. References 733 12.1. Normative References 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 737 RFC2119, March 1997, 738 . 740 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 741 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 742 . 744 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 745 and D. McPherson, "Dissemination of Flow Specification 746 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 747 . 749 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 750 and A. Bierman, Ed., "Network Configuration Protocol 751 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 752 . 754 12.2. Informative References 756 [I-D.ietf-idr-ls-distribution] 757 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 758 Ray, "North-Bound Distribution of Link-State and TE 759 Information using BGP", draft-ietf-idr-ls-distribution-11 760 (work in progress), June 2015. 762 [I-D.ietf-isis-segment-routing-extensions] 763 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 764 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 765 Extensions for Segment Routing", draft-ietf-isis-segment- 766 routing-extensions-05 (work in progress), June 2015. 768 [I-D.ietf-isis-te-metric-extensions] 769 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 770 A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering 771 (TE) Metric Extensions", draft-ietf-isis-te-metric- 772 extensions-07 (work in progress), June 2015. 774 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 775 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 776 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 777 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 778 segment-routing-extensions-03 (work in progress), June 779 2015. 781 [I-D.ietf-ospf-segment-routing-extensions] 782 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 783 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 784 Extensions for Segment Routing", draft-ietf-ospf-segment- 785 routing-extensions-05 (work in progress), June 2015. 787 [I-D.ietf-pce-pce-initiated-lsp] 788 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 789 Extensions for PCE-initiated LSP Setup in a Stateful PCE 790 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 791 progress), April 2015. 793 [I-D.ietf-pce-segment-routing] 794 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 795 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 796 "PCEP Extensions for Segment Routing", draft-ietf-pce- 797 segment-routing-06 (work in progress), August 2015. 799 [I-D.ietf-spring-problem-statement] 800 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 801 Horneffer, M., and R. Shakir, "SPRING Problem Statement 802 and Requirements", draft-ietf-spring-problem-statement-04 803 (work in progress), April 2015. 805 [I-D.ietf-spring-segment-routing] 806 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 807 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 808 ietf-spring-segment-routing-04 (work in progress), July 809 2015. 811 [I-D.ietf-spring-segment-routing-mpls] 812 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 813 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 814 and E. Crabbe, "Segment Routing with MPLS data plane", 815 draft-ietf-spring-segment-routing-mpls-01 (work in 816 progress), May 2015. 818 [I-D.previdi-idr-bgpls-segment-routing-epe] 819 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 820 and M. Chen, "Segment Routing Egress Peer Engineering BGP- 821 LS Extensions", draft-previdi-idr-bgpls-segment-routing- 822 epe-03 (work in progress), April 2015. 824 Authors' Addresses 826 Clarence Filsfils (editor) 827 Cisco Systems, Inc. 828 Brussels 829 BE 831 Email: cfilsfil@cisco.com 833 Stefano Previdi (editor) 834 Cisco Systems, Inc. 835 Via Del Serafico, 200 836 Rome 00142 837 Italy 839 Email: sprevidi@cisco.com 841 Keyur Patel 842 Cisco Systems, Inc. 843 US 845 Email: keyupate@cisco.com 847 Ebben Aries 848 Facebook 849 1 Hacker Way 850 Menlo Park, CA 94025 851 US 853 Email: exa@fb.com 854 Steve Shaw 855 Dropbox, Inc. 856 185 Berry Street, Suite 400 857 San Francisco, CA 94107 858 US 860 Email: shaw@dropbox.com 862 Daniel Ginsburg 863 Yandex 864 RU 866 Email: dbg@yandex-team.ru 868 Dmitry Afanasiev 869 Yandex 870 RU 872 Email: fl0w@yandex-team.ru