idnits 2.17.1 draft-ietf-spring-segment-routing-central-epe-03.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 (November 20, 2016) is 2704 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-06 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-09 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-07 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-10 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-05 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Filsfils, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: May 24, 2017 E. Aries 6 Juniper Networks 7 D. Afanasiev 8 Yandex 9 November 20, 2016 11 Segment Routing Centralized BGP Peer Engineering 12 draft-ietf-spring-segment-routing-central-epe-03 14 Abstract 16 Segment Routing (SR) leverages source routing. A node steers a 17 packet through a controlled set of instructions, called segments, by 18 prepending the packet with an SR header. A segment can represent any 19 instruction topological or service-based. SR allows to enforce a 20 flow through any topological path and service chain while maintaining 21 per-flow state only at the ingress node of the SR domain. 23 The Segment Routing architecture can be directly applied to the MPLS 24 dataplane with no change on the forwarding plane. It requires minor 25 extension to the existing link-state routing protocols. 27 This document illustrates the application of Segment Routing to solve 28 the BGP Peer Engineering (BGP-PE) requirement. The SR-based BGP-PE 29 solution allows a centralized (SDN) controller to program any egress 30 peer policy at ingress border routers or at hosts within the domain. 31 This document is on the informational track. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on May 24, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Segment Routing Documents . . . . . . . . . . . . . . . . 3 75 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 76 2. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 6 77 3. Distribution of External Topology and TE Information using 78 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID 7 80 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID 7 81 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID 8 82 3.4. BGP-PE Router advertising a first PeerAdj to Peer F . . . 8 83 3.5. BGP-PE Router advertising a second PeerAdj to Peer F . . 8 84 3.6. Fast Reroute (FRR) . . . . . . . . . . . . . . . . . . . 9 85 4. BGP-PE Controller . . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 87 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 88 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 89 4.4. SLA characteristics of each peer . . . . . . . . . . . . 11 90 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 91 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 92 4.7. BGP-PE Policy . . . . . . . . . . . . . . . . . . . . . . 12 93 5. Programming an input policy . . . . . . . . . . . . . . . . . 13 94 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 96 5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 13 97 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 98 5.5. At a Router - Flowspec route . . . . . . . . . . . . . . 14 99 6. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 102 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 105 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 108 13.2. Informative References . . . . . . . . . . . . . . . . . 16 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 111 1. Introduction 113 The document is structured as follows: 115 o Section 1 states the BGP-PE problem statement and provides the key 116 references. 118 o Section 2 defines the different BGP Peering Segments and the 119 semantic associated to them. 121 o Section 3 describes the automated allocation of BGP Peering SID's 122 by the BGP-PE enabled egress border router and the automated 123 signaling of the external peering topology and the related BGP 124 Peering SID's to the collector 125 [I-D.ietf-idr-bgpls-segment-routing-epe]. 127 o Section 4 overviews the components of a centralized EPE 128 controller. The definition of the EPE controller is outside the 129 scope of this document. 131 o Section 5 overviews the methods that could be used by the 132 centralized BGP-PE controller to implement a BGP-PE policy at an 133 ingress border router or at a source host within the domain. The 134 exhaustive definition of all the means to program an BGP-PE input 135 policy is outside the scope of this document. 137 For editorial reasons, the solution is described for IPv4. A later 138 section describes how the same solution is applicable to IPv6. 140 1.1. Segment Routing Documents 142 The main references for this document are: 144 o SR Problem Statement: [RFC7855]. 146 o SR Architecture: [I-D.ietf-spring-segment-routing]. 148 o Distribution of External Topology and TE Information using BGP: 149 [I-D.ietf-idr-bgpls-segment-routing-epe]. 151 The SR instantiation in the MPLS dataplane is described in 152 [I-D.ietf-spring-segment-routing-mpls]. 154 The SR IGP protocol extensions are defined in 155 [I-D.ietf-isis-segment-routing-extensions], 156 [I-D.ietf-ospf-segment-routing-extensions] and 157 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 159 The Segment Routing PCE protocol extensions are defined in 160 [I-D.ietf-pce-segment-routing]. 162 1.2. Problem Statement 164 The BGP-PE problem statement is defined in [RFC7855]. 166 A centralized controller should be able to instruct an ingress 167 Provider Edge router (PE) or a content source within the domain to 168 use a specific egress PE and a specific external interface/neighbor 169 to reach a particular destination. 171 We call this solution "BGP-PE" for "BGP Peer Engineering". The 172 centralized controller is called the "BGP-PE Controller". The egress 173 border router where the BGP-PE traffic-steering functionality is 174 implemented is called a BGP-PE-enabled border router. The input 175 policy programmed at an ingress border router or at a source host is 176 called a BGP-PE policy. 178 The requirements that have motivated the solution described in this 179 document are listed here below: 181 o The solution MUST apply to the Internet use-case where the 182 Internet routes are assumed to use IPv4 unlabeled or IPv6 183 unlabeled. It is not required to place the Internet routes in a 184 VRF and allocate labels on a per route, or on a per-path basis. 186 o The solution MUST NOT make any assumption on the currently 187 deployed iBGP schemes (RRs, confederations or iBGP full meshes) 188 and MUST be able to support all of them. 190 o The solution MUST be applicable to iBGP as well as eBGP peerings. 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 BGP-PE policy at an 196 ingress PE or directly at an source host within the domain. 198 o The solution MUST support automated Fast Reroute (FRR) and fast 199 convergence mechanisms. 201 The following reference diagram is used throughout this document. 203 +---------+ +------+ 204 | | | | 205 | H B------D G 206 | | +---/| AS 2 |\ +------+ 207 | |/ +------+ \ | |---L/8 208 A AS1 C---+ \| | 209 | |\\ \ +------+ /| AS 4 |---M/8 210 | | \\ +-E |/ +------+ 211 | X | \\ | K 212 | | +===F AS 3 | 213 +---------+ +------+ 215 Figure 1: Reference Diagram 217 IPv4 addressing: 219 o C's interface to D: 198.51.100.1/30, D's interface: 220 198.51.100.2/30 222 o C's interface to E: 198.51.100.5/30, E's interface: 223 198.51.100.6/30 225 o C's upper interface to F: 198.51.100.9/30, F's interface: 226 198.51.100.10/30 228 o C's lower interface to F: 198.51.100.13/30, F's interface: 229 198.51.100.14/30 231 o Loopback of F used for eBGP multi-hop peering to C: 192.0.2.2/32 233 o C's loopback is 203.0.113.3/32 with SID 64 235 C's BGP peering: 237 o Single-hop eBGP peering with neighbor 198.51.100.2 (D) 239 o Single-hop eBGP peering with neighbor 198.51.100.6 (E) 241 o Multi-hop eBGP peering with F on IP address 192.0.2.2 (F) 242 C's resolution of the multi-hop eBGP session to F: 244 o Static route 192.0.2.2/32 via 198.51.100.10 246 o Static route 192.0.2.2/32 via 198.51.100.14 248 C is configured with local policy that defines a BGP PeerSet as the 249 set of peers (198.51.100.6 and 192.0.2.2) 251 X is the BGP-PE controller within AS1 domain. 253 H is a content source within AS1 domain. 255 2. BGP Peering Segments 257 As defined in [I-D.ietf-spring-segment-routing], certain segments are 258 defined by BGP-PE capable node and corresponding to its attached 259 peers. These segments are called BGP peering segments or BGP Peering 260 SIDs. They enable the expression of source-routed inter-domain 261 paths. 263 An ingress border router of an AS may compose a list of segments to 264 steer a flow along a selected path within the AS, towards a selected 265 egress border router C of the AS and through a specific peer. At 266 minimum, a BGP Peering Engineering policy applied at an ingress PE 267 involves two segments: the Node SID of the chosen egress PE and then 268 the BGP Peering Segment for the chosen egress PE peer or peering 269 interface. 271 [I-D.ietf-spring-segment-routing] defines three types of BGP peering 272 segments/SID's: PeerNodeSID, PeerAdjSID and PeerSetSID. 274 The BGP extensions to signal these BGP peering segments are outlined 275 in the following section. 277 3. Distribution of External Topology and TE Information using BGP-LS 279 In ships-in-the-night mode with respect to the pre-existing iBGP 280 design, a BGP-LS session is established between the BGP-PE enabled 281 border router and the BGP-PE controller. 283 As a result of its local configuration and according to the behavior 284 described in [I-D.ietf-idr-bgpls-segment-routing-epe], node C 285 allocates the following BGP Peering Segments 286 ([I-D.ietf-spring-segment-routing]): 288 o A PeerNode segment for each of its defined peer (D, E and F). 290 o A PeerAdj segment for each recursing interface to a multi-hop peer 291 (e.g.: the upper and lower interfaces from C to F in figure 1). 293 o A PeerSet segment to the set of peers (E and F). 295 C programs its forwarding table accordingly: 297 Incoming Outgoing 298 Label Operation Interface 299 ------------------------------------ 300 1012 POP link to D 301 1022 POP link to E 302 1032 POP upper link to F 303 1042 POP lower link to F 304 1052 POP load balance on any link to F 305 1060 POP load balance on any link to E or to F 307 C signals the related BGP-LS NLRI's to the BGP-PE controller. Each 308 such BGP-LS route is described in the following subsections according 309 to the encoding details defined in 310 [I-D.ietf-idr-bgpls-segment-routing-epe]. 312 3.1. BGP-PE Router advertising the Peer D and its PeerNode SID 314 Descriptors: 316 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 318 o Peer Descriptors (peer ASN): AS2 320 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 321 198.51.100.1, 198.51.100.2 323 Attributes: 325 o PeerNode-SID: 1012 327 3.2. BGP-PE Router advertising the Peer E and its PeerNode SID 329 Descriptors: 331 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 333 o Peer Descriptors (peer ASN): AS3 335 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 336 198.51.100.5, 198.51.100.6 338 Attributes: 340 o PeerNode-SID: 1022 342 o PeerSetSID: 1060 344 o Link Attributes: see section 3.3.2 of [RFC7752] 346 3.3. BGP-PE Router advertising the Peer F and its PeerNode SID 348 Descriptors: 350 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 352 o Peer Descriptors (peer ASN): AS3 354 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 355 203.0.113.3, 192.0.2.2 357 Attributes: 359 o PeerNode-SID: 1052 361 o PeerSetSID: 1060 363 3.4. BGP-PE Router advertising a first PeerAdj to Peer F 365 Descriptors: 367 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 369 o Peer Descriptors (peer ASN): AS3 371 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 372 198.51.100.9, 198.51.100.10 374 Attributes: 376 o PeerAdj-SID: 1032 378 o LinkAttributes: see section 3.3.2 of [RFC7752] 380 3.5. BGP-PE Router advertising a second PeerAdj to Peer F 382 Descriptors: 384 o Node Descriptors (router-ID, ASN): 203.0.113.3 , AS1 385 o Peer Descriptors (peer ASN): AS3 387 o Link Descriptors (IPv4 interface address, neighbor IPv4 address): 388 198.51.100.13, 198.51.100.14 390 Attributes: 392 o PeerAdj-SID: 1042 394 o LinkAttributes: see section 3.3.2 of [RFC7752] 396 3.6. Fast Reroute (FRR) 398 An BGP-PE enabled border router should allocate a FRR backup entry on 399 a per BGP Peering SID basis: 401 o PeerNode SID 403 1. If multi-hop, backup via the remaining PeerADJ SIDs to the 404 same peer. 406 2. Else backup via local PeerNode SID to the same AS. 408 3. Else pop the PeerNode SID and perform an IP lookup. 410 o PeerAdj SID 412 1. If to a multi-hop peer, backup via the remaining PeerADJ SIDs 413 to the same peer. 415 2. Else backup via PeerNode SID to the same AS. 417 3. Else pop the PeerNode SID and perform an IP lookup. 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. 425 We illustrate the different types of possible backups using the 426 reference diagram and considering the Peering SIDs 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 dependent 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 overrules the default behavior which would have preferred F as 456 a backup for E. 458 4. BGP-PE Controller 460 In this section, we provide a non-exhaustive set of inputs that an 461 BGP-PE controller would likely collect such as to perform the BGP-PE 462 policy decision. 464 The exhaustive definition is outside the scope of this document. 466 4.1. Valid Paths From Peers 468 The BGP-PE controller should collect all the paths advertised by all 469 the engineered peers. 471 This could be realized by setting an iBGP session with the BGP-PE 472 enabled border router, with "add-path all" and the original next-hop 473 preserved. 475 In this case, C would advertise the following Internet routes to the 476 BGP-PE controller: 478 o NLRI , nhop 198.51.100.2, AS Path {AS 2, 4} 479 * X (i.e.: the BGP-PE controller) knows that C receives a path to 480 L/8 via neighbor 198.51.100.2 of AS2. 482 o NLRI , nhop 198.51.100.6, AS Path {AS 3, 4} 484 * X knows that C receives a path to L/8 via neighbor 198.51.100.6 485 of AS2. 487 o NLRI , nhop 192.0.2.2, AS Path {AS 3, 4} 489 * X knows that C has an eBGP path to L/8 via AS3 via neighbor 490 192.0.2.2 492 An alternative option would be for an BGP-PE collector to use BGP 493 Monitoring Protocol (BMP) to track the Adj-RIB-In of BGP-PE enabled 494 border routers. 496 4.2. Intra-Domain Topology 498 The BGP-PE controller should collect the internal topology and the 499 related IGP SIDs. 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 (BGP-LS advertisements), the BGP-PE controller is able to maintain an 508 accurate description of the egress topology of node C. Furthermore, 509 the BGP-PE controller is able to associate BGP Peering SIDs to the 510 various components of the external topology. 512 4.4. SLA characteristics of each peer 514 The BGP-PE controller might collect SLA characteristics across peers. 515 This requires an BGP-PE solution as the SLA probes need to be steered 516 via non-best-path peers. 518 Unidirectional SLA monitoring of the desired path is likely required. 519 This might be possible when the application is controlled at the 520 source and the receiver side. Unidirectional monitoring dissociates 521 the SLA characteristic of the return path (which cannot usually be 522 controlled) from the forward path (the one of interest for pushing 523 content from a source to a consumer and the one which can be 524 controlled). 526 Alternatively, Extended Metrics, as defined in [RFC7810] could also 527 be advertised using new BGP-LS attributes. 529 4.5. Traffic Matrix 531 The BGP-PE controller might collect the traffic matrix to its peers 532 or the final destinations. IPFIX is a likely option. 534 An alternative option consists in collecting the link utilization 535 statistics of each of the internal and external links, also available 536 in the current definition of [RFC7752]. 538 4.6. Business Policies 540 The BGP-PE controller should collect business policies. 542 4.7. BGP-PE Policy 544 On the basis of all these inputs (and likely others), the BGP-PE 545 Controller decides to steer some demands away from their best BGP 546 path. 548 The BGP-PE policy is likely expressed as a two-entry segment list 549 where the first element is the IGP prefix SID of the selected egress 550 border router and the second element is a BGP Peering SID at the 551 selected egress border router. 553 A few examples are provided hereafter: 555 o Prefer egress PE C and peer AS AS2: {64, 1012}. 557 o Prefer egress PE C and peer AS AS3 via eBGP peer 198.51.100.6: 558 {64, 1022}. 560 o Prefer egress PE C and peer AS AS3 via eBGP peer 192.0.2.2: {64, 561 1052}. 563 o Prefer egress PE C and peer AS AS3 via interface 198.51.100.14 of 564 multi-hop eBGP peer 192.0.2.2: {64, 1042}. 566 o Prefer egress PE C and any interface to any peer in the group 567 1060: {64, 1060}. 569 Note that the first SID could be replaced by a list of segments. 570 This is useful when an explicit path within the domain is required 571 for traffic-engineering purposes. For example, if the Prefix SID of 572 node B is 60 and the BGP-PE controller would like to steer the 573 traffic from A to C via B then through the external link to peer D 574 then the segment list would be {60, 64, 1012}. 576 5. Programming an input policy 578 The detailed/exhaustive description of all the means to implement an 579 BGP-PE policy are outside the scope of this document. A few examples 580 are provided in this section. 582 5.1. At a Host 584 A static IP/MPLS route can be programmed at the host H. The static 585 route would define a destination prefix, a next-hop and a label stack 586 to push. The global property of the IGP Prefix SID is particularly 587 convenient: the same policy could be programmed across hosts 588 connected to different routers. 590 5.2. At a router - SR Traffic Engineering tunnel 592 The BGP-PE controller can configure the ingress border router with an 593 SR traffic engineering tunnel T1 and a steering-policy S1 which 594 causes a certain class of traffic to be mapped on the tunnel T1. 596 The tunnel T1 would be configured to push the required segment list. 598 The tunnel and the steering policy could be configured via PCEP 599 according to [I-D.ietf-pce-segment-routing] and 600 [I-D.ietf-pce-pce-initiated-lsp] or via Netconf ([RFC6241]). 602 Example: at A 604 Tunnel T1: push {64, 1042} 605 IP route L/8 set nhop T1 607 5.3. At a Router - RFC3107 policy route 609 The BGP-PE Controller could build a RFC3107 ([RFC3107]) route (from 610 scratch) and send it to the ingress router: 612 o NLRI: the destination prefix to engineer: e.g., L/8. 614 o Next-Hop: the selected egress border router: C. 616 o Label: the selected egress peer: 1042. 618 o AS path: reflecting the selected valid AS path. 620 o Some BGP policy to ensure it will be selected as best by the 621 ingress router. 623 This RFC3107 policy route "overwrites" an equivalent or less-specific 624 "best path". As the best-path is changed, this EPE input policy 625 option influences the path propagated to the upstream peer/customers. 627 5.4. At a Router - VPN policy route 629 The EPE Controller could build a VPNv4 route (from scratch) and send 630 it to the ingress router: 632 o NLRI: the destination prefix to engineer: e.g., L/8. 634 o Next-Hop: the selected egress border router: C. 636 o Label: the selected egress peer: 1042. 638 o Route-Target: selecting the appropriate VRF at the ingress router. 640 o AS path: reflecting the selected valid AS path. 642 o Some BGP policy to ensure it will be selected as best by the 643 ingress router in the related VRF. 645 The related VRF must be preconfigured. A VRF fallback to the main 646 FIB might be beneficial to avoid replicating all the "normal" 647 Internet paths in each VRF. 649 5.5. At a Router - Flowspec route 651 An EPE Controller builds a FlowSpec route and sends it to the ingress 652 router to engineer: 654 o Dissemination of Flow Specification Rules ([RFC5575]. 656 o Destination/Source IP Addresses, IP Protocol, Destination/Source 657 port (+1 component). 659 o ICMP Type/Code, TCP Flags, Packet length, DSCP, Fragment. 661 6. IPv6 663 The described solution is applicable to IPv6, either with MPLS-based 664 or IPv6-Native segments. In both cases, the same three steps of the 665 solution are applicable: 667 o BGP-LS-based signaling of the external topology and BGP Peering 668 Segments to the BGP-PE controller. 670 o Collection of various inputs by the BGP-PE controller to come up 671 with a policy decision. 673 o Programming at an ingress router or source host of the desired 674 BGP-PE policy which consists in a list of segments to push on a 675 defined traffic class. 677 7. Benefits 679 The BGP-PE solutions described in this document have the following 680 benefits: 682 o No assumption on the iBGP design within AS1. 684 o Next-Hop-Self on the Internet routes propagated to the ingress 685 border routers is possible. This is a common design rule to 686 minimize the number of IGP routes and to avoid importing external 687 churn into the internal routing domain. 689 o Consistent support for traffic-engineering within the domain and 690 at the external edge of the domain. 692 o Support both host and ingress border router BGP-PE policy 693 programming. 695 o BGP-PE functionality is only required on the BGP-PE enabled egress 696 border router and the BGP-PE 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 (avail the global property of IGP prefix SIDs). 703 8. IANA Considerations 705 This document does not request any IANA allocations. 707 9. Manageability Considerations 709 TBD 711 10. Security Considerations 713 TBD 715 11. Contributors 717 Daniel Ginsburg substantially contributed to the content of this 718 document. 720 12. Acknowledgements 722 The authors would like to thank Acee Lindem for his comments and 723 contribution. 725 13. References 727 13.1. Normative References 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, 731 DOI 10.17487/RFC2119, March 1997, 732 . 734 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 735 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 736 . 738 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 739 and D. McPherson, "Dissemination of Flow Specification 740 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 741 . 743 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 744 and A. Bierman, Ed., "Network Configuration Protocol 745 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 746 . 748 13.2. Informative References 750 [I-D.ietf-idr-bgpls-segment-routing-epe] 751 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 752 and M. Chen, "Segment Routing BGP Egress Peer Engineering 753 BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- 754 epe-06 (work in progress), November 2016. 756 [I-D.ietf-isis-segment-routing-extensions] 757 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 758 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 759 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 760 segment-routing-extensions-09 (work in progress), October 761 2016. 763 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 764 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 765 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 766 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 767 segment-routing-extensions-07 (work in progress), October 768 2016. 770 [I-D.ietf-ospf-segment-routing-extensions] 771 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 772 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 773 Extensions for Segment Routing", draft-ietf-ospf-segment- 774 routing-extensions-10 (work in progress), October 2016. 776 [I-D.ietf-pce-pce-initiated-lsp] 777 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 778 Extensions for PCE-initiated LSP Setup in a Stateful PCE 779 Model", draft-ietf-pce-pce-initiated-lsp-07 (work in 780 progress), July 2016. 782 [I-D.ietf-pce-segment-routing] 783 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 784 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 785 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 786 ietf-pce-segment-routing-08 (work in progress), October 787 2016. 789 [I-D.ietf-spring-segment-routing] 790 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 791 and R. Shakir, "Segment Routing Architecture", draft-ietf- 792 spring-segment-routing-10 (work in progress), November 793 2016. 795 [I-D.ietf-spring-segment-routing-mpls] 796 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 797 Litkowski, S., Horneffer, M., Shakir, R., 798 jefftant@gmail.com, j., and E. Crabbe, "Segment Routing 799 with MPLS data plane", draft-ietf-spring-segment-routing- 800 mpls-05 (work in progress), July 2016. 802 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 803 S. Ray, "North-Bound Distribution of Link-State and 804 Traffic Engineering (TE) Information Using BGP", RFC 7752, 805 DOI 10.17487/RFC7752, March 2016, 806 . 808 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 809 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 810 RFC 7810, DOI 10.17487/RFC7810, May 2016, 811 . 813 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 814 Litkowski, S., Horneffer, M., and R. Shakir, "Source 815 Packet Routing in Networking (SPRING) Problem Statement 816 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 817 2016, . 819 Authors' Addresses 821 Clarence Filsfils (editor) 822 Cisco Systems, Inc. 823 Brussels 824 BE 826 Email: cfilsfil@cisco.com 828 Stefano Previdi (editor) 829 Cisco Systems, Inc. 830 Via Del Serafico, 200 831 Rome 00142 832 Italy 834 Email: sprevidi@cisco.com 836 Ebben Aries 837 Juniper Networks 838 1133 Innovation Way 839 Sunnyvale CA 94089 840 US 842 Email: exa@juniper.net 843 Dmitry Afanasiev 844 Yandex 845 RU 847 Email: fl0w@yandex-team.ru