idnits 2.17.1 draft-filsfils-spring-segment-routing-central-epe-00.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 (May 26, 2014) is 3622 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 (-04) exists of draft-filsfils-spring-segment-routing-01 == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-mpls-01 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-05 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-00 == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-00 == Outdated reference: A later version (-08) exists of draft-ietf-spring-problem-statement-00 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-04 == Outdated reference: A later version (-02) exists of draft-psenak-ospf-segment-routing-ospfv3-extension-01 == Outdated reference: A later version (-03) exists of draft-sivabalan-pce-segment-routing-02 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: November 27, 2014 Cisco Systems, Inc. 6 E. Aries 7 Facebook 8 D. Ginsburg 9 D. Afanasiev 10 Yandex 11 May 26, 2014 13 Segment Routing Centralized Egress Peer Engineering 14 draft-filsfils-spring-segment-routing-central-epe-00 16 Abstract 18 Segment Routing (SR) leverages source routing. A node steers a 19 packet through a controlled set of instructions, called segments, by 20 prepending the packet with an SR header. A segment can represent any 21 instruction topological or service-based. SR allows to enforce a 22 flow through any topological path and service chain while maintaining 23 per-flow state only at the ingress node of the SR domain. 25 The Segment Routing architecture can be directly applied to the MPLS 26 dataplane with no change on the forwarding plane. It requires minor 27 extension to the existing link-state routing protocols. 29 This document illustrates the application of Segment Routing to solve 30 the Egress Peer Engineering (EPE) requirement. The SR-based EPE 31 solution allows a centralized (SDN) controller to program any egress 32 peer policy at ingress border routers or at hosts within the domain. 33 This document is on the informational track. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in RFC 2119 [RFC2119]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on November 27, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 4 77 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 78 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 79 3. Distribution of External Topology and TE Information using 80 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.1. EPE Route advertising the Peer D and its PeerNode SID . . 7 82 3.2. EPE Route advertising the Peer E and its PeerNode SID . . 7 83 3.3. EPE Route advertising the Peer F and its PeerNode SID . . 8 84 3.4. EPE Route advertising a first PeerAdj to Peer F . . . . . 8 85 3.5. EPE Route advertising a second PeerAdj to Peer F . . . . 9 86 3.6. FRR . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4. EPE Controller . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 11 89 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 90 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 91 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 92 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 93 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 94 4.7. EPE Policy . . . . . . . . . . . . . . . . . . . . . . . 12 95 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 96 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 97 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 98 5.3. At a Router - BGP3107 policy route . . . . . . . . . . . 14 99 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 100 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 101 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 104 9. Manageability Considerations . . . . . . . . . . . . . . . . 16 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 107 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 109 12.2. Informative References . . . . . . . . . . . . . . . . . 16 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 112 1. Introduction 114 The document is structured as follows: 116 o Section 1 reminds the EPE problem statement and provides the key 117 references. 119 o Section 2 defines the different BGP Peering Segments and the 120 semantic associated to them. 122 o Section 3 describes the automated allocation of BGP Peering SID's 123 by the EPE-enabled egress border router and the automated 124 signaling of the external peering topology and the related BGP 125 Peering SID's to the collector [draft-previdi-idr-bgpls-segment- 126 routing-epe-00]. 128 o Section 4 overviews the components of a centralized EPE 129 controller. The definition of the EPE controller is outside the 130 scope of this document. 132 o Section 5 overviews the methods that could be used by the 133 centralized EPE controller to implement an EPE policy at an 134 ingress border router or at a source host within the domain. The 135 exhaustive definition of all the means to program an EPE input 136 policy is outside the scope of this document. 138 For editorial reason, the solution is described for IPv4. A later 139 section describes how the same solution is applicable to IPv6. 141 1.1. Segment Routing Documents 143 The main references for this document are: 145 o SR Problem Statement: [I-D.ietf-spring-problem-statement]. 147 o SR Architecture: [I-D.filsfils-spring-segment-routing]. 149 o Distribution of External Topology and TE Information using BGP: 150 draft-previdi-idr-bgpls-segment-routing-epe-00.txt 152 The SR instantiation in the MPLS dataplane is described in 153 [I-D.filsfils-spring-segment-routing-mpls]. 155 The SR IGP protocol extensions are defined in 156 [I-D.ietf-isis-segment-routing-extensions], 157 [I-D.psenak-ospf-segment-routing-extensions] and 158 [I-D.psenak-ospf-segment-routing-ospfv3-extension]. 160 The Segment Routing PCE protocol extensions are defined in 161 [I-D.sivabalan-pce-segment-routing]. 163 1.2. Problem Statement 165 The EPE problem statement is defined in 166 [I-D.ietf-spring-problem-statement]. 168 A centralized controller should be able to instruct an ingress PE or 169 a content source within the domain to use a specific egress PE and a 170 specific external interface to reach a particular destination. 172 We call this solution "EPE" for "Egress Peer Engineering". The 173 centralized controller is called the "EPE Controller". The egress 174 border router where the EPE traffic-steering functionality is 175 implemented is called an EPE-enabled border router. The input policy 176 programmed at an ingress border router or at a source host is called 177 an EPE 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 SHOULD minimize the need for new BGP capabilities at 192 the ingress PE's. 194 o The solution MUST accommodate an ingress EPE policy at an ingress 195 PE or directly at an source host within the domain. 197 o The solution MUST support automated FRR and fast convergence. 199 The following reference diagram is used throughout this document. 201 +---------+ +------+ 202 | | | | 203 | H B------D G 204 | | +---/| AS 2 |\ +------+ 205 | |/ +------+ \ | |---L/8 206 A AS1 C---+ \| | 207 | |\\ \ +------+ /| AS 4 |---M/8 208 | | \\ +-E |/ +------+ 209 | X | \\ | K 210 | | +===F AS 3 | 211 +---------+ +------+ 213 Figure 1: Reference Diagram 215 IPv4 addressing: 217 o C's interface to D: 1.0.1.1/24, D's interface: 1.0.1.2/24 219 o C's interface to E: 1.0.2.1/24, E's interface: 1.0.2.2/24 221 o C's upper interface to F: 1.0.3.1/24, F's interface: 1.0.3.2/24 223 o C's lower interface to F: 1.0.4.1/24, F's interface: 1.0.4.2/24 225 o Loopback of F used for eBGP multi-hop peering to C: 1.0.5.2/32 227 o C's loopback is 3.3.3.3/32 with SID 64 229 C's BGP peering: 231 o Single-hop eBGP peering with neighbor 1.0.1.2 (D) 233 o Single-hop eBGP peering with neighbor 1.0.2.2 (E) 234 o Multi-hop eBGP peering with F on ip address 1.0.5.2 (F) 236 C's resolution of the multi-hop eBGP session to F: 238 o Static route 1.0.5.2/32 via 1.0.3.2 240 o Static route 1.0.5.2/32 via 1.0.4.2 242 C is configured with local policy that defines a BGP PeerSet as the 243 set of peers (1.0.2.2 and 1.0.5.2) 245 X is the EPE controller within AS1 domain. 247 H is a content source within AS1 domain. 249 2. BGP Peering Segments 251 AS defined in [I-D.filsfils-spring-segment-routing], Segments are 252 defined by a Egress Peer Engineering (EPE) capable node and 253 corresponding to its attached peers. These segments are called BGP 254 peering segments or BGP Peering SIDs. They enable the expression of 255 source-routed inter-domain paths. 257 An ingress border router of an AS may compose a list of segments to 258 steer a flow along a selected path within the AS, towards a selected 259 egress border router C of the AS and through a specific peer. At 260 minimum, a BGP Peering Engineering policy applied at an ingress PE 261 involves two segments: the Node SID of the chosen egress PE and then 262 the BGP Peering Segment for the chosen egress PE peer or peering 263 interface. 265 [I-D.filsfils-spring-segment-routing] defines three types of BGP 266 peering segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. 268 The BGP extensions to signal these BGP peering segments are outlined 269 in the following section. 271 3. Distribution of External Topology and TE Information using BGP-LS 273 In ships-in-the-night mode with respect to the pre-existing iBGP 274 design, a BGPLS session is established between the EPE-enabled border 275 router and the EPE controller. 277 As a result of its local configuration and according to the behavior 278 described in draft-previdi-idr-bgpls-segment-routing-epe-00, node C 279 allocates the following BGP Peering Segments 280 ([I-D.filsfils-spring-segment-routing]): 282 o A PeerNode segment for each of its defined peer (D, E and F). 284 o A PeerAdj segment for each recursing interface to a multi-hop peer 285 (e.g.: the upper and lower interfaces from C to F in figure 1). 287 o A PeerSet segment to the set of peers (E and F). 289 C programs its forwarding table accordingly: 291 Incoming Outgoing 292 Label Operation Interface 293 ------------------------------------ 294 1012 POP link to D 295 1022 POP link to E 296 1032 POP upper link to F 297 1042 POP lower link to F 298 1052 POP loadbalance on any link to F 299 1060 POP loadbalance on any link to E or to F 301 C signals the related BGP-LS NLRI's to the EPE controller. Each such 302 BGP-LS route is described in the following sub-sections according to 303 the encoding details defined in draft-previdi-idr-bgpl-segment- 304 routing-epe-00. 306 3.1. EPE Route advertising the Peer D and its PeerNode SID 308 Descriptors: 310 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 312 o Peer Descriptors (peer ASN): AS2 314 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 315 1.0.1.1, 1.0.1.2 317 Attributes: 319 o Adj-SID: 1012 321 3.2. EPE Route advertising the Peer E and its PeerNode SID 323 Descriptors: 325 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 327 o Peer Descriptors (peer ASN): AS3 328 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 329 1.0.2.1, 1.0.2.2 331 Attributes: 333 o Adj-SID: 1022 335 o PeerSetSID: 1060 337 o Link Attributes: see section 3.3.2 of 338 [I-D.ietf-idr-ls-distribution] 340 3.3. EPE Route advertising the Peer F and its PeerNode SID 342 Descriptors: 344 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 346 o Peer Descriptors (peer ASN): AS3 348 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 349 3.3.3.3, 1.0.5.2 351 Attributes: 353 o Adj-SID: 1052 355 o PeerSetSID: 1060 357 3.4. EPE Route advertising a first PeerAdj to Peer F 359 Descriptors: 361 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 363 o Peer Descriptors (peer ASN): AS3 365 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 366 1.0.3.1 , 1.0.3.2 368 Attributes: 370 o Adj-SID: 1032 372 o LinkAttributes: see section 3.3.2 of 373 [I-D.ietf-idr-ls-distribution] 375 3.5. EPE Route advertising a second PeerAdj to Peer F 377 Descriptors: 379 o Node Descriptors (router-ID, ASN): 3.3.3.3 , AS1 381 o Peer Descriptors (peer ASN): AS3 383 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 384 1.0.4.1 , 1.0.4.2 386 Attributes: 388 o Adj-SID: 1042 390 o LinkAttributes: see section 3.3.2 of 391 [I-D.ietf-idr-ls-distribution] 393 3.6. FRR 395 An EPE-enabled border router should allocate a FRR backup entry on a 396 per BGP Peering SID basis: 398 o PeerNode SID 400 1. If multi-hop, backup via the remaining PeerADJ SID's to the 401 same peer. 403 2. Else backup via local PeerNode SID to the same AS. 405 3. Else pop the PeerNode SID and IP lookup (with potential BGP 406 PIC fall-back). 408 o PeerAdj SID 410 1. If to a multi-hop peer, backup via the remaining PeerADJ SID's 411 to the same peer. 413 2. Else backup via PeerNode SID to the same AS. 415 3. Else pop the PeerNode SID and IP lookup (with potential BGP 416 PIC fall-back). 418 o PeerSet SID 420 1. Backup via remaining PeerNode SID in the same PeerSet. 422 2. Else pop the PeerSet SID and IP lookup (with potential BGP PIC 423 fall-back). 425 We illustrate the different types of possible backups using the 426 reference diagram and considering the Peering SID's allocated by C. 428 PeerNode SID 1052, allocated by C for peer F: 430 o Upon the failure of the upper connected link CF, C can reroute all 431 the traffic onto the lower CF link to the same peer (F). 433 PeerNode SID 1022, allocated by C for peer E: 435 o Upon the failure of the connected link CE, C can reroute all the 436 traffic onto the link to PeerNode SID 1052 (F). 438 PeerNode SID 1012, allocated by C for peer D: 440 o Upon the failure of the connected link CD, C can pop the PeerNode 441 SID and lookup the IP destination address in its FIB and route 442 accordingly. 444 PeerSet SID 1060, allocated by C for the set of peers E and F: 446 o Upon the failure of a connected link in the group, the traffic to 447 PeerSet SID 1060 is rerouted on any other member of the group. 449 For specific business reasons, the operator might not want the 450 default FRR behavior applied to a PeerNode SID or any of its 451 depending PeerADJ SID. 453 The operator should be able to associate a specific backup PeerNode 454 SID for a PeerNode SID: e.g. 1022 (E) must be backed up by 1012 (D) 455 which over-rules the default behavior which would have preferred F as 456 a backup for E. 458 4. EPE Controller 460 In this section, we provide a non-exhaustive set of inputs that an 461 EPE controller would likely collect such as to perform the EPE policy 462 decision. 464 The exhaustive definition is outside the scope of this document. 466 4.1. Valid Paths From Peers 468 The EPE controller should collect all the paths advertised by all the 469 engineered peers. 471 This could be realized by setting an iBGP session with the EPE- 472 enabled border router, with "add-path all" and original next-hop 473 preserved. 475 In this case, C would advertise the following Internet routes to the 476 EPE controller: 478 o NLRI , nhop 1.0.1.2, AS Path {AS 2, 4} 480 * X (i.e.: the EPE controller) knows that C receives a path to 481 L/8 via neighbor 1.0.1.2 of AS2. 483 o NLRI , nhop 1.0.2.2, AS Path {AS 3, 4} 485 * X knows that C receives a path to L/8 via neighbor 1.0.2.2 of 486 AS2. 488 o NLRI , nhop 1.0.5.2, AS Path {AS 3, 4} 490 * X knows that C has an eBGP path to L/8 via AS3 via neighbor 491 1.0.5.2 493 An alternative option consists in Adj-RIB-In BMP from EPE-enabled 494 border router to the EPE collector. 496 4.2. Intra-Domain Topology 498 The EPE controller should collect the internal topology and the 499 related IGP SID's. 501 This could be realized by collecting the IGP LSDB of each area or 502 running a BGP-LS session with a node in each IGP area. 504 4.3. External Topology 506 Thanks to the collected BGP-LS routes described in the section 2 507 (BGPLS advertisements), the EPE controller is able to maintain an 508 accurate description of the egress topology of node C. Furthermore, 509 the EPE controller is able to associate BGP Peering SID's to the 510 various components of the external topology. 512 4.4. SLA characteristics of each peer 514 The EPE controller might collect SLA characteristics across peers. 515 This requires an EPE solution as the SL A probes need to be steered 516 via non-best-path peers. 518 Uni-directional SLA monitoring of the desired path is likely 519 required. This might be possible when the application is controlled 520 at the source and the receiver side. Uni-directional monitoring 521 dissociates the SLA characteristic of the return path (which cannot 522 usually be controlled) from the forward path (the one of interest for 523 pushing content from a source to a consumer and the one which can be 524 controlled). 526 Alternatively, Extended Metrics, as defined in 527 [I-D.ietf-isis-te-metric-extensions] could also be advertised using 528 new bgpls attributes. 530 4.5. Traffic Matrix 532 The EPE controller might collect the traffic matrix to its peers or 533 the final destinations. IPFIX is a likely option. 535 An alternative option consists in collecting the link utilization 536 statistics of each of the internal and external links, also available 537 in current definition of [I-D.ietf-idr-ls-distribution]. 539 4.6. Business Policies 541 The EPE controller should collect business policies. 543 4.7. EPE Policy 545 On the basis of all these inputs (and likely other), the EPE 546 Controller decides to steer some demands away from their best BGP 547 path. 549 The EPE policy is likely expressed as a two-entry segment list where 550 the first element is the IGP prefix SID of the selected egress border 551 router and the second element is a BGP Peering SID at the selected 552 egress border router. 554 A few examples are provided hereafter: 556 o Prefer egress PE C and peer AS AS2: {64, 1012}. 558 o Prefer egress PE C and peer AS AS3 via ebgp peer 1.0.2.2: {64, 559 1022}. 561 o Prefer egress PE C and peer AS AS3 via ebgp peer 1.0.5.2: {64, 562 1052}. 564 o Prefer egress PE C and peer AS AS3 via interface 1.0.4.2 of multi- 565 hop ebgp peer 1.0.5.2: {64, 1042}. 567 o Prefer egress PE C and any interface to any peer in the group 568 1060: {64, 1060}. 570 Note that the first SID could be replaced by a list of segments. 571 This is useful when an explicit path within the domain is required 572 for traffic-engineering purpose. For example, if the Prefix SID of 573 node B is 60 and the EPE controller would like to steer the traffic 574 from A to C via B then through the external link to peer D then the 575 segment list would be {60, 64, 1012}. 577 5. Programming an input policy 579 The detailed/exhaustive description of all the means to implement an 580 EPE policy are outside the scope of this document. A few examples 581 are provided in this section. 583 5.1. At a Host 585 A static IP/MPLS route can be programmed at the host H. The static 586 route would define a destination prefix, a next-hop and a label stack 587 to push. The global property of the IGP Prefix SID is particularly 588 convenient: the same policy could be programmed across hosts 589 connected to different routers. 591 5.2. At a router - SR Traffic Engineering tunnel 593 The EPE controller can configure the ingress border router with an SR 594 traffic engineering tunnel T1 and a steering-policy S1 which causes a 595 certain class of traffic to be mapped on the tunnel T1. 597 The tunnel T1 would be configured to push the require segment list. 599 The tunnel and the steering policy could be configured via PCEP 600 according to [I-D.sivabalan-pce-segment-routing] and 601 [I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]). 603 Example: at A 605 Tunnel T1: push {64, 1042} 606 IP route L/8 set nhop T1 608 5.3. At a Router - BGP3107 policy route 610 The EPE Controller could build a BGP3107 ([RFC3107]) route (from 611 scratch) and send it to the ingress router: 613 o NLRI: the destination prefix to engineer: e.g. L/8. 615 o Next-Hop: the selected egress border router: C. 617 o Label: the selected egress peer: 1042. 619 o AS path: reflecting the valid AS path of the selected. 621 o Some BGP policy to ensure it be selected as best by the ingress 622 router. 624 This BGP3107 policy route "overwrites" an equivalent or less-specific 625 "best path". As the best-path is changed, this EPE input policy 626 option influences the path propagated to the upstream peer/customers. 628 5.4. At a Router - VPN policy route 630 The EPE Controller could build a VPNv4 route (from scratch) and send 631 it to the ingress router: 633 o NLRI: the destination prefix to engineer: e.g. L/8. 635 o Next-Hop: the selected egress border router: C. 637 o Label: the selected egress peer: 1042. 639 o Route-Target: selecting the appropriate VRF at the ingress router. 641 o AS path: reflecting the valid AS path of the selected. 643 o Some BGP policy to ensure it be selected as best by the ingress 644 router in the related VRF. 646 The related VRF must be pre-configured. A VRF fall-back into main 647 FIB might be beneficial to avoid replicating all the "normal" 648 internet paths in each VRF. 650 5.5. At a Router - Flowspec route 652 EPE Controller builds a FlowSpec route and sends it to the ingress 653 router to engineer: 655 o Dissemination of Flow Specification Rules ([RFC5575]. 657 o Destination/Source IP Addresses, IP Protocol, Destination/Source 658 port (+1 component). 660 o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment. 662 6. IPv6 664 The described solution is applicable to IPv6, either with MPLS-based 665 or IPv6-Native segments. In both cases, the same three steps of the 666 solution are applicable: 668 o BGP-LS-based signaling of the external topology and BGP Peering 669 Segments to the EPE controller. 671 o Collection of various inputs by the EPE controller to come up with 672 a policy decision. 674 o Programming at an ingress router or source host of the desired EPE 675 policy which consists in a list of segments to push on a defined 676 traffic class. 678 7. Benefits 680 The EPE solutions described in this document has the following 681 benefits: 683 o No assumption on the iBGP design with AS1. 685 o Next-Hop-Self on the internet routes propagated to the ingress 686 border routers is possible. This is a common design rule to 687 minimize the number of IGP routes and to avoid importing external 688 churn into the internal domain. 690 o Consistent support for traffic-engineering within the domain and 691 at the external edge of the domain. 693 o Support host and ingress border router EPE policy programming. 695 o EPE functionality is only required on the EPE-enabled egress 696 border router and the EPE controller: an ingress policy can be 697 programmed at the ingress border router without any new 698 functionality. 700 o Ability to deploy the same input policy across hosts connected to 701 different routers (global property of the IGP prefix SID). 703 8. IANA Considerations 705 TBD 707 9. Manageability Considerations 709 TBD 711 10. Security Considerations 713 TBD 715 11. Acknowledgements 717 TBD 719 12. References 721 12.1. Normative References 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 727 BGP-4", RFC 3107, May 2001. 729 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 730 and D. McPherson, "Dissemination of Flow Specification 731 Rules", RFC 5575, August 2009. 733 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 734 Bierman, "Network Configuration Protocol (NETCONF)", RFC 735 6241, June 2011. 737 12.2. Informative References 739 [I-D.filsfils-spring-segment-routing] 740 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 741 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 742 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 743 "Segment Routing Architecture", draft-filsfils-spring- 744 segment-routing-01 (work in progress), May 2014. 746 [I-D.filsfils-spring-segment-routing-mpls] 747 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 748 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 749 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 750 "Segment Routing with MPLS data plane", draft-filsfils- 751 spring-segment-routing-mpls-01 (work in progress), April 752 2014. 754 [I-D.ietf-idr-ls-distribution] 755 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 756 Ray, "North-Bound Distribution of Link-State and TE 757 Information using BGP", draft-ietf-idr-ls-distribution-05 758 (work in progress), May 2014. 760 [I-D.ietf-isis-segment-routing-extensions] 761 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 762 Litkowski, S., and J. Tantsura, "IS-IS Extensions for 763 Segment Routing", draft-ietf-isis-segment-routing- 764 extensions-00 (work in progress), April 2014. 766 [I-D.ietf-isis-te-metric-extensions] 767 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 768 A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering 769 (TE) Metric Extensions", draft-ietf-isis-te-metric- 770 extensions-03 (work in progress), April 2014. 772 [I-D.ietf-pce-pce-initiated-lsp] 773 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 774 Extensions for PCE-initiated LSP Setup in a Stateful PCE 775 Model", draft-ietf-pce-pce-initiated-lsp-00 (work in 776 progress), December 2013. 778 [I-D.ietf-spring-problem-statement] 779 Previdi, S., Filsfils, C., Decraene, B., Litkowski, S., 780 Horneffer, M., Geib, R., Shakir, R., and R. Raszuk, 781 "SPRING Problem Statement and Requirements", draft-ietf- 782 spring-problem-statement-00 (work in progress), May 2014. 784 [I-D.psenak-ospf-segment-routing-extensions] 785 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 786 Shakir, R., and W. Henderickx, "OSPF Extensions for 787 Segment Routing", draft-psenak-ospf-segment-routing- 788 extensions-04 (work in progress), February 2014. 790 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 791 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 792 Shakir, R., and W. Henderickx, "OSPFv3 Extensions for 793 Segment Routing", draft-psenak-ospf-segment-routing- 794 ospfv3-extension-01 (work in progress), February 2014. 796 [I-D.sivabalan-pce-segment-routing] 797 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and 798 R. Raszuk, "PCEP Extensions for Segment Routing", draft- 799 sivabalan-pce-segment-routing-02 (work in progress), 800 October 2013. 802 Authors' Addresses 804 Clarence Filsfils (editor) 805 Cisco Systems, Inc. 806 Brussels 807 BE 809 Email: cfilsfil@cisco.com 811 Stefano Previdi (editor) 812 Cisco Systems, Inc. 813 Via Del Serafico, 200 814 Rome 00142 815 Italy 817 Email: sprevidi@cisco.com 819 Keyur Patel 820 Cisco Systems, Inc. 821 US 823 Email: keyupate@cisco.com 825 Ebben Aries 826 Facebook 827 US 829 Email: exa@fb.com 830 Daniel Ginsburg 831 Yandex 832 RU 834 Email: dbg@yandex-team.ru 836 Dmitry Afanasiev 837 Yandex 838 RU 840 Email: fl0w@yandex-team.ru