idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2016) is 2842 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4271' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-add-paths' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC1998' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC4384' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC5283' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC5668' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC6774' is defined on line 505, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group R. Raszuk, Ed. 3 Internet-Draft Bloomberg LP 4 Intended status: Standards Track C. Cassar 5 Expires: January 9, 2017 Cisco Systems 6 E. Aman 7 TeliaSonera 8 B. Decraene 9 S. Litkowski 10 Orange 11 K. Wang 12 Juniper Networks 13 July 8, 2016 15 BGP Optimal Route Reflection (BGP-ORR) 16 draft-ietf-idr-bgp-optimal-route-reflection-12 18 Abstract 20 This document proposes a solution for BGP route reflectors to allow 21 them to choose the best path their clients would have chosen under 22 the same conditions, without requiring further state or any new 23 features to be placed on the clients. This facilitates, for example, 24 best exit point policy (hot potato routing). This solution is 25 primarily applicable in deployments using centralized route 26 reflectors. 28 The solution relies upon all route reflectors learning all paths 29 which are eligible for consideration. Best path selection is 30 performed in each route reflector based on a configured virtual 31 location in the IGP. The location can be the same for all clients or 32 different per peer/update group or per peer. Best path selection can 33 also be performed based on user configured policies in each route 34 reflector. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 9, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Definitions of Terms Used in This Memo . . . . . . . . . . . 2 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 73 2.2. Existing/Alternative Solutions . . . . . . . . . . . . . 4 74 3. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Client's Perspective IGP Based Best Path Selection . . . 6 76 3.2. Client's Perspective Policy Based Best Path Selection . . 6 77 3.3. Solution Interactions . . . . . . . . . . . . . . . . . . 7 78 4. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 8 79 5. Advantages and Deployment Considerations . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 9.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Definitions of Terms Used in This Memo 90 NLRI - Network Layer Reachability Information. 92 RIB - Routing Information Base. 94 AS - Autonomous System number. 96 VRF - Virtual Routing and Forwarding instance. 98 PE - Provider Edge router 100 POP - Point Of Presence 102 L3VPN - Layer 3 Virtual Private Networks RFC4364 104 6PE - IPv6 Provider Edge Router 106 IGP - Interior Gateway Protocol 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119] 112 2. Introduction 114 There are three types of BGP deployments within Autonomous Systems 115 today: full mesh, confederations and route reflection. BGP route 116 reflection [RFC4456] is the most popular way to distribute BGP routes 117 between BGP speakers belonging to the same Autonomous System. In 118 some situations, this method suffers from non-optimal path selection. 120 2.1. Problem Statement 122 [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) 123 cost to a given point in the network will vary across routers, "the 124 route reflection approach may not yield the same route selection 125 result as that of the full IBGP mesh approach." One practical 126 implication of this assertion is that the deployment of route 127 reflection may thwart the ability to achieve hot potato routing. Hot 128 potato routing attempts to direct traffic to the best AS exit point 129 in cases where no higher priority policy dictates otherwise. As a 130 consequence of the route reflection method, the choice of exit point 131 for a route reflector and its clients will be the exit point best for 132 the route reflector - not necessarily the one best for the RR 133 clients. 135 Section 11 of [RFC4456] describes a deployment approach and a set of 136 constraints which, if satisfied, would result in the deployment of 137 route reflection yielding the same results as the iBGP full mesh 138 approach. This deployment approach makes route reflection compatible 139 with the application of hot potato routing policy. In accordance 140 with these design rules, route reflectors have traditionally often 141 been deployed in the forwarding path and carefully placed on the POP 142 to core boundaries. 144 The evolving model of intra-domain network design has enabled 145 deployments of route reflectors outside of the forwarding path. 146 Initially this model was only employed for new address families, e.g. 147 L3VPNs and L2VPNs. This model has been gradually extended to other 148 BGP address families including IPv4 and IPv6 Internet using either 149 native routing or 6PE. In such environments, hot potato routing 150 policy remains desirable. 152 Route reflectors outside of the forwarding path can be placed on the 153 POP to core boundaries, but they are often placed in arbitrary 154 locations in the core of large networks. 156 Such deployments suffer from a critical drawback in the context of 157 best path selection: A route reflector with knowledge of multiple 158 paths for a given prefix will typically pick its best path and only 159 advertise that best path to its clients. If the best path for a 160 prefix is selected on the basis of an IGP tie break, the path 161 advertised will be the exit point closest to the route reflector. 162 But the clients will be in a different place in the network topology 163 than the route reflector. In networks where the route reflectors are 164 not in the forwarding path, this difference will be even more acute. 165 Beside this, there are also deployment scenarios where service 166 providers want to have more control of choosing the exit points for 167 clients based on other factors like traffic type, traffic load, etc. 168 This further complicated the issue and makes it less likely for the 169 route reflector to select the best path from the client's 170 perspective. It follows that the best path chosen by the route 171 reflector is not necessarily the same as the path which would have 172 been chosen by the client if the client had considered the same set 173 of candidate paths as the route reflector. 175 2.2. Existing/Alternative Solutions 177 One possible valid solution or workaround to the best path selection 178 problem requires sending all domain external paths from the RR to all 179 its clients. This approach suffers the significant drawback of 180 pushing a large amount of BGP state to all edge routers. Many 181 networks receive full Internet routing information in a large number 182 of locations. This could easily result in tens of paths for each 183 prefix that would need to be distributed to clients. 185 Notwithstanding this drawback, there are a number of reasons for 186 sending more than just the single best path to the clients. Improved 187 path diversity at the edge is a requirement for fast connectivity 188 restoration, and a requirement for effective BGP level load 189 balancing. 191 In practical terms, add/diverse path deployments are expected to 192 result in the distribution of 2, 3 or n (where n is a small number) 193 good paths rather than all domain external paths. While the route 194 reflector chooses one set of n paths and distributes those same n 195 paths to all its route reflector clients, those n paths may not be 196 the right n paths for all clients. In the context of the problem 197 described above, those n paths will not necessarily include the best 198 exit point out of the network for each route reflector client. The 199 mechanisms proposed in this document are likely to be complementary 200 to mechanisms aimed at improving path diversity. 202 Another possibility to optimize exit points would be installing 203 physical hardware at various IGP locations or what is quite unlikely 204 to attach Route Reflectors over manually created tunnels. 206 The paradigm of control plane is shifting from traditional routers to 207 x86 virtual space or even cloud. As result without this proposal 208 operators have choice of their route reflectors distributing 209 suboptimal paths or distributing all paths and in turn allowing 210 clients to make independent best path selection. 212 Now while the latter could be even an option in router's world more 213 and more BGP is being observed on the compute servers where sending 214 there all present in an AS BGP paths would be for one undesired as 215 well would require to run also IGP there. Let's also note that 216 number of paths per BGP prefix varies a lot. Depending on the 217 network it can be anywhere from few to few hundreds. 219 3. Proposed Solutions 221 The goal of this document is to allow a route reflector to choose the 222 best path the client would have chosen had the client considered the 223 same set of candidate paths the reflector has available. For 224 purposes of route selection, the perspective of a client can differ 225 from that of a route reflector or another client in two distinct 226 ways: it can, and usually will, have a different position in the IGP 227 topology, and it can have a different routing policy. These 228 correspond to the issues described earlier. Accordingly, we propose 229 two distinct modifications to the best path algorithm, to address 230 these two distinct factors. A route reflector can implement either 231 or both of the modifications, as needed in order to allow it to 232 choose the best path the client would have chosen had the client 233 considered the same set of candidate paths. 235 Both modifications rely upon all route reflectors learning all paths 236 which are eligible for consideration. In order to satisfy this 237 requirement, path diversity enhancing mechanisms such as ADD-PATH/ 238 diverse paths may need to be deployed between route reflectors. 240 A significant advantage of these approaches is that the RR clients do 241 not need to run new software or hardware. 243 3.1. Client's Perspective IGP Based Best Path Selection 245 The core of this solution is the ability for an operator to specify 246 on a per route reflector basis or per peer/update group basis or per 247 peer basis the virtual IGP location placement of the route reflector. 248 This enables having a given group of clients receive routes with 249 optimal distance to the next hops from the position of the configured 250 virtual IGP location. This also provides for freedom of route 251 reflector location and allows transient or permanent migration of 252 such network control plane function to optimal location. 254 The choice of specific granularity is left to the implementation 255 decision. An implementation is considered compliant with the 256 document if it supports at least one listed grouping of virtual IGP 257 placement. 259 In this document we refer to optimal as the decision made during best 260 path selection at the IGP metric to BGP next hop comparison step. 261 This approach does not apply to path selection preference based other 262 policy steps and provisions. 264 The computation of the virtual IGP location with any of the above 265 described granularity is outside of the scope of this document. The 266 operator may configure it manually, implementation may automate it 267 based on specified heuristic or it can be computed centrally and 268 configured by an external system. 270 The solution does not require any BGP or IGP protocol changes as 271 required changes are contained within the RR implementation. 273 The solution applies to NLRIs of all address families which can be 274 route reflected. 276 3.2. Client's Perspective Policy Based Best Path Selection 278 Optimal route reflection based on virtual IGP location could reflect 279 the best path to the client from IGP cost perspective. However, 280 there are also cases where the client might want best path from 281 perspectives beyond IGP cost. Examples include, but not limited to: 283 o Select the best path for the clients from a traffic engineering 284 perspective. 286 o Dedicate certain exit points for certain ingress points. 288 The solution proposed here is to allow the user to apply a general 289 policy to select a subset of exit points as the candidate exit points 290 for its clients. For a given client, the policy should also allow 291 service providers to select different candidate exit points for 292 different address families. Regular path selection, including 293 client's perspective IGP based best path selection stated above, will 294 be applied to the candidate paths to select the final paths to 295 advertise to the clients. 297 The policy is applied on the route reflector on behalf of its 298 clients. This way, the route reflector will be able to reflect only 299 the optimal paths to the clients. An additional advantage of this 300 approach is that configuration need only be done on a small number of 301 route reflectors rather than a significantly larger number of 302 clients. 304 3.3. Solution Interactions 306 Depending on the actual deployment scenarios, service providers may 307 configure IGP based optimal route reflection or policy based optimal 308 route reflection. It's also possible to configure both approaches 309 together. In that case, policy based optimal route reflection will 310 be applied first to select the candidate paths. Subsequently, IGP 311 based optimal route reflection will be applied on top of the 312 candidate paths to select the final path to advertise to the client. 314 The expected use case for optimal route reflection is to avoid 315 reflecting all paths to the client because the client either does not 316 support add-paths or does not have the capacity to process all of the 317 paths. Typically the route reflector would just reflect a single 318 optimal route to the client. However, the solutions MUST NOT prevent 319 reflecting more than one optimal path to the client; the client may 320 want path diversity for load balancing or fast restoration. In case 321 add-path and optimal route reflection are configured together, the 322 route reflector MUST reflect n optimal paths to a client, where n is 323 the add-path count. 325 The most complicated scenario is where add-path is configured 326 together with both IGP based and policy based optimal route 327 reflection. In this scenario, the policy based optimal route 328 reflection will be applied first to select the candidate paths. 329 Subsequently, IGP based optimal route reflection will be applied on 330 top of the candidate paths to select the best n paths to advertise to 331 the client. 333 In IGP based optimal route reflection, even though the virtual IGP 334 location could be specified on a per route reflector basis or per 335 peer group basis or per peer basis, in reality, it's most likely to 336 be specified per peer group basis. All clients with the same or 337 similar IGP location can be grouped into the same peer group. A 338 virtual IGP location is then specified for the peer group. The 339 virtual location is usually specified as the location of one of the 340 clients from the peer group or an ABR to the area where clients are 341 located. Also, one or more backup virtual location SHOULD be allowed 342 to be specified for redundancy. Implementations may wish to take 343 advantage of peer group mechanisms in order to provide for better 344 scalability of optimal route reflector client groups with similar 345 properties. 347 4. CPU and Memory Scalability 349 For IGP based optimal route reflection, determining the shortest path 350 and associated cost between any two arbitrary points in a network 351 based on the IGP topology learned by a router is expected to add some 352 extra cost in terms of CPU resources. However SPF tree generation 353 code is now implemented efficiently in a number of implementations, 354 and therefore this is not expected to be a major drawback. The 355 number of SPTs computed is expected to be of the order of the number 356 of clients of an RR whenever a topology change is detected. Advanced 357 optimizations like partial and incremental SPF may also be exploited. 358 The number of SPTs computed is expected to be higher but comparable 359 to some existing deployed features such as (Remote) Loop Free 360 Alternate which computes a (r)SPT per IGP neighbor. 362 For policy based optimal route reflection, there will be some 363 overhead to apply the policy to select the candidate paths. This 364 overhead is comparable to existing BGP export policies therefore 365 should be manageable. 367 By the nature of route reflection, the number of clients can be split 368 arbitrarily by the deployment of more route reflectors for a given 369 number of clients. While this is not expected to be necessary in 370 existing networks with best in class route reflectors available 371 today, this avenue to scaling up the route reflection infrastructure 372 would be available. 374 If we consider the overall network wide cost/benefit factor, the only 375 alternative to achieve the same level of optimality would require 376 significantly increasing state on the edges of the network. This 377 will consume CPU and memory resources on all BGP speakers in the 378 network. Building this client perspective into the route reflectors 379 seems appropriate. 381 5. Advantages and Deployment Considerations 383 The solutions described provide a model for integrating the client 384 perspective into the best path computation for RRs. More 385 specifically, the choice of BGP path factors in either the IGP cost 386 between the client and the nexthop (rather than the distance from the 387 RR to the nexthop) or user configured policies. 389 Implementation to be declared as complaint with this memo should 390 allow to configure per instance or per group of peers logical 391 location from which either for the entire instance or for set of 392 peers best path will be computed. 394 These solutions can be deployed in traditional hop-by-hop forwarding 395 networks as well as in end-to-end tunneled environments. In the 396 networks where there are multiple route reflectors and hop-by-hop 397 forwarding without encapsulation, such optimizations should be 398 enabled in a consistent way on all route reflectors. Otherwise 399 clients may receive an inconsistent view of the network and in turn 400 lead to intra-domain forwarding loops. 402 With this approach, an ISP can effect a hot potato routing policy 403 even if route reflection has been moved from the forwarding plane and 404 hop-by-hop switching has been replaced by end-to-end MPLS or IP 405 encapsulation. 407 As per above, these approaches reduce the amount of state which needs 408 to be pushed to the edge of the network in order to perform hot 409 potato routing. The memory and CPU resource required at the edge of 410 the network to provide hot potato routing using these approaches is 411 lower than what would be required in order to achieve the same level 412 of optimality by pushing and retaining all available paths 413 (potentially 10s) per each prefix at the edge. 415 The proposals allow for a fast and safe transition to a BGP control 416 plane with centralized route reflection without compromising an 417 operator's closest exit operational principle. This enables edge-to- 418 edge LSP/IP encapsulation for traffic to IPv4 and IPv6 prefixes. 420 Regarding the client's IGP best-path selection, it should be self 421 evident that this solution does not interfere with policies enforced 422 above IGP tie breaking in the BGP best path algorithm. 424 6. Security Considerations 426 No new security issues are introduced to the BGP protocol by this 427 specification. 429 7. IANA Considerations 431 This document does not request any IANA allocations. 433 8. Acknowledgments 435 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 436 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 437 Mitchell, John Scudder, Jeff Haas, Martin Djernaes and Daniele 438 Ceccarelli for their valuable input. 440 9. References 442 9.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 450 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 451 DOI 10.17487/RFC4271, January 2006, 452 . 454 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 455 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 456 February 2006, . 458 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 459 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 460 2009, . 462 9.2. Informative References 464 [I-D.ietf-idr-add-paths] 465 Walton, D., Retana, A., Chen, E., and J. Scudder, 466 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 467 add-paths-15 (work in progress), May 2016. 469 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 470 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 471 . 473 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 474 Community Attribute in Multi-home Routing", RFC 1998, 475 DOI 10.17487/RFC1998, August 1996, 476 . 478 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 479 RFC 4384, DOI 10.17487/RFC4384, February 2006, 480 . 482 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 483 Reflection: An Alternative to Full Mesh Internal BGP 484 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 485 . 487 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 488 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 489 . 491 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 492 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 493 DOI 10.17487/RFC5283, July 2008, 494 . 496 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 497 Specific BGP Extended Community", RFC 5668, 498 DOI 10.17487/RFC5668, October 2009, 499 . 501 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 502 RFC 5714, DOI 10.17487/RFC5714, January 2010, 503 . 505 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 506 and K. Kumaki, "Distribution of Diverse BGP Paths", 507 RFC 6774, DOI 10.17487/RFC6774, November 2012, 508 . 510 Authors' Addresses 512 Robert Raszuk (editor) 513 Bloomberg LP 514 731 Lexington Ave 515 New York City, NY 10022 516 USA 518 Email: robert@raszuk.net 519 Christian Cassar 520 Cisco Systems 521 10 New Square Park 522 Bedfont Lakes, FELTHAM TW14 8HA 523 UK 525 Email: ccassar@cisco.com 527 Erik Aman 528 TeliaSonera 529 Marbackagatan 11 530 Farsta SE-123 86 531 Sweden 533 Email: erik.aman@teliasonera.com 535 Bruno Decraene 536 Orange 537 38-40 rue du General Leclerc 538 Issy les Moulineaux cedex 9 92794 539 France 541 Email: bruno.decraene@orange.com 543 Stephane Litkowski 544 Orange 545 9 rue du chene germain 546 Cesson Sevigne 35512 547 France 549 Email: stephane.litkowski@orange.com 551 Kevin Wang 552 Juniper Networks 553 10 Technology Park Drive 554 Westford, MA 01886 555 USA 557 Email: kfwang@juniper.net