idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-21.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 2 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 (June 16, 2020) is 1403 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) == Missing Reference: 'RFC4364' is mentioned on line 109, but not defined == Missing Reference: 'RFC 4271' is mentioned on line 126, but not defined == Unused Reference: 'RFC4360' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC1998' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC4384' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC5283' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC5668' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 596, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 3 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: December 18, 2020 Tesla 6 E. Aman 7 Telia Company 8 B. Decraene, Ed. 9 Orange 10 K. Wang 11 Juniper Networks 12 June 16, 2020 14 BGP Optimal Route Reflection (BGP-ORR) 15 draft-ietf-idr-bgp-optimal-route-reflection-21 17 Abstract 19 This document defines an extension to BGP route reflectors. On route 20 reflectors, BGP route selection is modified in order to choose the 21 best path for their clients standpoint, rather than from the route 22 reflectors standpoint. Multiple type of granularity are proposed, 23 from a per client BGP route selection or to a per peer group, 24 depending on the scaling and precision requirements on route 25 selection. This solution is particularly applicable in deployments 26 using centralized route reflectors, where choosing the best route 27 based on the Route Reflector IGP location is suboptimal. This 28 facilitates, for example, best exit point policy (hot potato 29 routing). 31 The solution relies upon all route reflectors learning all paths 32 which are eligible for consideration. Best path selection is 33 performed in each route reflector based on the IGP cost from a 34 selected location in the link state IGP. 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 https://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 December 18, 2020. 53 Copyright Notice 55 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . 3 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Modifications to BGP Best Path selection . . . . . . . . . . 5 73 3.1. IGP Based Best Path Selection from a different SPT root . 6 74 3.1.1. Restriction when BGP next hop is BGP prefix . . . . . 7 75 3.2. Best Path Selections granularity . . . . . . . . . . . . 7 76 4. Solution Interactions . . . . . . . . . . . . . . . . . . . . 8 77 4.1. IGP and policy based optimal route refresh . . . . . . . 8 78 4.2. Add-paths plus IGP and policy optimal route refresh . . . 8 79 4.3. Likely Deployments and need for backup . . . . . . . . . 8 80 5. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 9 81 6. Advantages and Deployment Considerations . . . . . . . . . . 10 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 85 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 11.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Appendix A. Appendix: alternative solutions with limited 90 applicability . . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Definitions of Terms Used in This Memo 95 NLRI - Network Layer Reachability Information. 97 RIB - Routing Information Base. 99 AS - Autonomous System number. 101 VRF - Virtual Routing and Forwarding instance. 103 PE - Provider Edge router 105 RR - Route Reflector 107 POP - Point Of Presence 109 L3VPN - Layer 3 Virtual Private Networks [RFC4364] 111 6PE - IPv6 Provider Edge Router 113 IGP - Interior Gateway Protocol 115 SPT - Shortest Path Tree 117 best path - the route chosen by the decision process detailed in 118 [RFC 4271] section 9.1.2 and its subsections 120 best path computation - the decision process detailed in [RFC 4271] 121 section 9.1.2 and its subsections 123 best path algorithm - the decision process detailed in [RFC 4271] 124 section 9.1.2 and its subsections 126 best path selection - the decision process detailed in [RFC 4271] 127 section 9.1.2 and its subsections 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2. Introduction 137 There are three types of BGP deployments within Autonomous Systems 138 today: full mesh, confederations and route reflection. BGP route 139 reflection [RFC4456] is the most popular way to distribute BGP routes 140 between BGP speakers belonging to the same Autonomous System. 142 However, in some situations, this method suffers from non-optimal 143 path selection. 145 [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) 146 cost to a given point in the network will vary across routers, "the 147 route reflection approach may not yield the same route selection 148 result as that of the full IBGP mesh approach." One practical 149 implication of this assertion is that the deployment of route 150 reflection may thwart the ability to achieve hot potato routing. Hot 151 potato routing attempts to direct traffic to the best AS exit point 152 in cases where no higher priority policy dictates otherwise. As a 153 consequence of the route reflection method, the choice of exit point 154 for a route reflector and its clients will be the exit point best for 155 the route reflector - not necessarily the one best for the route 156 reflector clients. 158 Section 11 of [RFC4456] describes a deployment approach and a set of 159 constraints which, if satisfied, would result in the deployment of 160 route reflection yielding the same results as the iBGP full mesh 161 approach. This deployment approach makes route reflection compatible 162 with the application of hot potato routing policy. In accordance 163 with these design rules, route reflectors have traditionally often 164 been deployed in the forwarding path and carefully placed on the POP 165 to core boundaries. 167 The evolving model of intra-domain network design has enabled 168 deployments of route reflectors outside of the forwarding path. 169 Initially this model was only employed for new address families, e.g. 170 L3VPNs and L2VPNs, however it has been gradually extended to other 171 BGP address families including IPv4 and IPv6 Internet using either 172 native routing or 6PE. In such environments, hot potato routing 173 policy remains desirable. 175 Route reflectors outside of the forwarding path can be placed on the 176 POP to core boundaries, but they are often placed in arbitrary 177 locations in the core of large networks. 179 Such deployments suffer from a critical drawback in the context of 180 best path selection: A route reflector with knowledge of multiple 181 paths for a given prefix will typically pick its best path and only 182 advertise that best path to its clients. If the best path for a 183 prefix is selected on the basis of an IGP tie break, the path 184 advertised will be the exit point closest to the route reflector. 185 However, the clients are in a different place in the network topology 186 than the route reflector. In networks where the route reflectors are 187 not in the forwarding path, this difference will be even more acute. 189 In addition, there are deployment scenarios where service providers 190 want to have more control in choosing the exit points for clients 191 based on other factors, such as traffic type, traffic load, etc. 192 This further complicates the issue and makes it less likely for the 193 route reflector to select the best path from the client's 194 perspective. It follows that the best path chosen by the route 195 reflector is not necessarily the same as the path which would have 196 been chosen by the client if the client had considered the same set 197 of candidate paths as the route reflector. 199 3. Modifications to BGP Best Path selection 201 The core of this solution is the ability for an operator to specify 202 on a per route reflector basis, or per peer/update group basis, or 203 per peer basis the IGP location of the route reflector. This core 204 ability enables the route reflector to send to a given group of 205 clients routes with shortest distance to the next hops from the 206 position of the selected IGP location. This core ability provides 207 for freedom of route reflector physical location, and allows 208 transient or permanent migration of this network control plane 209 function to an arbitrary location. 211 The choice of specific granularity (route reflector basis, peer/ 212 update group basis, or peer peer basis) is configured by the network 213 operator. An implementation is considered compliant with the 214 document if it supports at least one listed grouping of IGP location. 216 For purposes of route selection, the perspective of a client can 217 differ from that of a route reflector or another client in two 218 distinct ways: 220 it can, and usually will, have a different position in the IGP 221 topology, and 223 it can have a different routing policy. 225 These factors correspond to the issues described earlier. 227 This document defines, on BGP Route Reflectors [RFC4456], two changes 228 to the BGP Best Path selection algorithm: 230 The first change is related to the IGP cost to the BGP Next Hop, 231 which is done in the step e) in the BGP decision process. The 232 change consists in using the IGP cost from a different source than 233 the route reflector itself. 235 The second change is the granularity of the BGP decision process, 236 to allow for running multiple decisions process using different 237 perspective or policies. 239 A route reflector can implement either or both of the modifications 240 in order to allow it to choose the best path for its clients that the 241 clients themselves would have chosen given the same set of candidate 242 paths. 244 Both modifications rely upon all route reflectors learning all paths 245 that are eligible for consideration. In order to satisfy this 246 requirement, path diversity enhancing mechanisms such as add-path may 247 need to be deployed between route reflectors. 249 A significant advantage of these approaches is that the route 250 reflector clients do not need to run new software or hardware. 252 3.1. IGP Based Best Path Selection from a different SPT root 254 In this approach, optimal refers to the decision made during best 255 path selection at the IGP metric to BGP next hop comparison step. 256 This approach does not apply to path selection preference based on 257 other policy steps and provisions. 259 In addition to the change specified in [RFC4456] section 9, the BGP 260 Decision Process Tie Breaking rules ([RFC4271] Sect. 9.1.2.2) are 261 modified as follows. 263 The below text in step e) 265 e) Remove from consideration any routes with less-preferred 266 interior cost. The interior cost of a route is determined by 267 calculating the metric to the NEXT_HOP for the route using the 268 Routing Table. 270 ...is replaced by this new text: 272 e) Remove from consideration any routes with less-preferred 273 interior cost. The interior cost of a route is determined by 274 calculating the metric from the selected IGP location to the 275 NEXT_HOP for the route using the shortest IGP path tree rooted on 276 the selected IGP location. 278 This extension requires the knowledge of the IGP topology in order to 279 be able to compute the shortest path tree rooted on any location and 280 in particular on the selected IGP locations. This knowledge can be 281 gained with the use of the link state IGP such as IS-IS [ISO10589] or 282 OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752]. If an IGP is used, 283 the selected IGP location MUST to be within the area/level of the 284 IGP. 286 The configuration of the IGP location is outside of the scope of this 287 document. The operator may configure it manually, implementation may 288 automate it based on heuristics, or it can be computed centrally and 289 configured by an external system. 291 This solution does not require any change (BGP or IGP) on the 292 clients, as all required changes are limited to the route reflector. 294 This solution applies to NLRIs of all address families, that can be 295 route reflected. 297 3.1.1. Restriction when BGP next hop is BGP prefix 299 In situations where the BGP next hop is a BGP prefix itself the IGP 300 metric of a route used for its resolution SHOULD be the final IGP 301 cost to reach such next hop. Implementations which can not inform 302 BGP of the final IGP metric to a recursive next hop SHOULD treat such 303 paths as least preferred during next hop metric comparison. However 304 such paths SHOULD still be considered valid for best path selection. 306 3.2. Best Path Selections granularity 308 BGP Route Reflector as per [RFC4456] runs the usual single Best Path 309 Selection used to compute the node's routing table. This may be 310 suboptimal or even not usuable when the Route Reflector clients has 311 significantly different IGP locations or BGP policies. In some 312 cases, there is a need to compute the Best Path Selection with an 313 increased granularity, such as per peer/update group or per client 314 basis. 316 This requires running multiple best path selections or multiple 317 subset of the best path selection. If the required routing 318 optimization is limited to the IGP cost to the BGP Next-Hop, which is 319 typical if the goal is hot potato routing or a routing (more) similar 320 to the one resulting from an iBGP full mesh between clients, only the 321 step e) as defined [RFC4271] Sect. 9.1.2.2, needs to be duplicated 322 on a per granularity basis. If the routing routing optimization 323 requires the use of different BGP policy for each element (e.g. 324 peer), the a larger part of the decision process needs to be 325 duplicated, up to the whole decision process as defined in section 326 9.1 of [RFC4271]. This is for example the case when there is a need 327 to use different policies to compute different degree of preference 328 during Pahse 1. This nedded for use cases involved traffic 329 engineering perspective, or dedicating certain exit points for 330 certain clients points. 332 In the latter case, the user MAY specify and apply a general policy 333 on the route reflector to select a subset of exit points as the 334 candidate exit points for its clients. For a given client, the 335 policy SHOULD also allow the operator to select different candidate 336 exit points for different address families. Regular path selection, 337 including client's perspective IGP based best path selection stated 338 above, will be applied to the candidate paths to select the final 339 paths to advertise to the clients. 341 4. Solution Interactions 343 4.1. IGP and policy based optimal route refresh 345 Depending on the actual deployment scenarios, service providers may 346 configure IGP based optimal route reflection or policy based optimal 347 route reflection. It is also possible to configure both approaches 348 together. In cases where both are configured together, policy based 349 optimal route reflection MUST be applied first to select the 350 candidate paths, then IGP based optimal route reflection can be 351 applied on top of the candidate paths to select the final path to 352 advertise to the client. 354 The expected use case for optimal route reflection is to avoid 355 reflecting all paths to the client because the client either: does 356 not support add-paths or does not have the capacity to process all of 357 the paths. Typically the route reflector would just reflect a single 358 optimal route to the client. However, the solutions MUST NOT prevent 359 reflecting more than one optimal path to the client as path diversity 360 may be desirable for load balancing or fast restoration. In cases 361 where add-path and optimal route reflection are configured together, 362 the route reflector MUST reflect n optimal paths to a client, where n 363 is the add-path count. 365 4.2. Add-paths plus IGP and policy optimal route refresh 367 The most complicated scenario is where add-path is configured 368 together with both IGP based and policy based optimal route 369 reflection. In this scenario, the policy based optimal route 370 reflection MUST be applied first to select the candidate paths (from 371 add-path). Subsequently, IGP based optimal route reflection will be 372 applied on top of the candidate paths to select the best n paths to 373 advertise to the client. 375 4.3. Likely Deployments and need for backup 377 With IGP based optimal route reflection, even though the IGP location 378 could be specified on a per route reflector basis or per peer/update 379 group basis or per peer basis, in reality, it's most likely to be 380 specified per peer/update group basis. All clients with the same or 381 similar IGP location can be grouped into the same peer/update group. 382 An IGP location is then specified for the peer/update group. The 383 location is usually specified as the location of one of the clients 384 from the peer group or an ABR to the area where clients are located. 385 Also, one or more backup locations SHOULD be allowed to be specified 386 for redundancy. Implementations may wish to take advantage of peer 387 group mechanisms in order to provide for better scalability of 388 optimal route reflector client groups with similar properties. 390 5. CPU and Memory Scalability 392 For IGP based optimal route reflection, determining the shortest path 393 and associated cost between any two arbitrary points in a network 394 based on the IGP topology learned by a router is expected to add some 395 extra cost in terms of CPU resources. However, current SPF tree 396 generation code is implemented efficiently in a number of 397 implementations, and therefore this is not expected to be a major 398 drawback. The number of SPTs computed is expected to be of the order 399 of the number of clients of a route reflector whenever a topology 400 change is detected. Advanced optimizations like partial and 401 incremental SPF may also be exploited. The number of SPTs computed 402 is expected to be higher but comparable to some existing deployed 403 features such as (Remote) Loop Free Alternate which computes a (r)SPT 404 per IGP neighbor. 406 For policy based optimal route reflection, there will be some 407 overhead to apply the policy to select the candidate paths. This 408 overhead is comparable to existing BGP export policies and therefore 409 should be manageable. 411 By the nature of route reflection, the number of clients can be split 412 arbitrarily by the deployment of more route reflectors for a given 413 number of clients. While this is not expected to be necessary in 414 existing networks with best in class route reflectors available 415 today, this avenue to scaling up the route reflection infrastructure 416 is available. 418 If we consider the overall network wide cost/benefit factor, the only 419 alternative to achieve the same level of optimality would require 420 significantly increasing state on the edges of the network. This 421 will consume CPU and memory resources on all BGP speakers in the 422 network. Building this client perspective into the route reflectors 423 seems appropriate. 425 6. Advantages and Deployment Considerations 427 The solutions described provide a model for integrating the client 428 perspective into the best path computation for route reflectors. 429 More specifically, the choice of BGP path factors in either the IGP 430 cost between the client and the nexthop (rather than the IGP cost 431 from the route reflector to the nexthop) or other user configured 432 policies. 434 Implementations considered compliant with this document allow the 435 configuration of a logical location from which the best path will be 436 computed, on the basis of either a peer, a peer group, or an entire 437 routing instance. 439 These solutions can be deployed in traditional hop-by-hop forwarding 440 networks as well as in end-to-end tunneled environments. In networks 441 where there are multiple route reflectors and hop-by-hop forwarding 442 without encapsulation, such optimizations SHOULD be enabled in a 443 consistent way on all route reflectors. Otherwise, clients may 444 receive an inconsistent view of the network, in turn leading to 445 intra-domain forwarding loops. 447 With this approach, an ISP can effect a hot potato routing policy 448 even if route reflection has been moved out of the forwarding plane, 449 and hop-by-hop switching has been replaced by end-to-end MPLS or IP 450 encapsulation. 452 As per above, these approaches reduce the amount of state which needs 453 to be pushed to the edge of the network in order to perform hot 454 potato routing. The memory and CPU resources required at the edge of 455 the network to provide hot potato routing using these approaches is 456 lower than what would be required to achieve the same level of 457 optimality by pushing and retaining all available paths (potentially 458 10s) per each prefix at the edge. 460 The solutions above allow for a fast and safe transition to a BGP 461 control plane using centralized route reflection, without 462 compromising an operator's closest exit operational principle. This 463 enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and 464 IPv6 prefixes. 466 Regarding the client's IGP best-path selection, it should be self 467 evident that this solution does not interfere with policies enforced 468 above IGP tie breaking in the BGP best path algorithm. 470 7. Security Considerations 472 Similarly to [RFC4456], this extension to BGP does not change the 473 underlying security issues inherent in the existing IBGP [RFC4456]. 475 It however enables the deployment of base BGP Route Reflection as 476 described in [RFC4456] to be possible using virtual compute 477 environments without any negative consequence on the BGP routing path 478 optimality. 480 This document does not introduce requirements for any new protection 481 measures, but it also does not relax best operational practices for 482 keeping the IGP network stable or to pace rate of policy based IGP 483 cost to next hops such that it does not have any substantial effect 484 on BGP path changes and their propagation to route reflection 485 clients. 487 8. IANA Considerations 489 This document does not request any IANA allocations. 491 9. Acknowledgments 493 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 494 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 495 Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele 496 Ceccarelli, Kieran Milne, Job Snijders and Randy Bush for their 497 valuable input. 499 10. Contributors 501 Following persons substantially contributed to the current format of 502 the document: 504 Stephane Litkowski 505 Orange 506 9 rue du chene germain 507 Cesson Sevigne, 35512 508 France 510 stephane.litkowski@orange.com 511 Adam Chappell 512 Interoute Communications 513 31st Floor 514 25 Canada Square 515 London, E14 5LQ 516 United Kingdom 518 adam.chappell@interoute.com 520 11. References 522 11.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, 526 DOI 10.17487/RFC2119, March 1997, 527 . 529 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 530 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 531 DOI 10.17487/RFC4271, January 2006, 532 . 534 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 535 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 536 February 2006, . 538 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 539 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 540 2009, . 542 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 543 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 544 May 2017, . 546 11.2. Informative References 548 [ISO10589] 549 International Organization for Standardization, 550 "Intermediate system to Intermediate system intra-domain 551 routeing information exchange protocol for use in 552 conjunction with the protocol for providing the 553 connectionless-mode Network Service (ISO 8473)", ISO/ 554 IEC 10589:2002, Second Edition, Nov 2002. 556 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 557 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 558 . 560 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 561 Community Attribute in Multi-home Routing", RFC 1998, 562 DOI 10.17487/RFC1998, August 1996, 563 . 565 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 566 DOI 10.17487/RFC2328, April 1998, 567 . 569 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 570 RFC 4384, DOI 10.17487/RFC4384, February 2006, 571 . 573 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 574 Reflection: An Alternative to Full Mesh Internal BGP 575 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 576 . 578 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 579 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 580 . 582 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 583 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 584 DOI 10.17487/RFC5283, July 2008, 585 . 587 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 588 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 589 . 591 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 592 Specific BGP Extended Community", RFC 5668, 593 DOI 10.17487/RFC5668, October 2009, 594 . 596 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 597 RFC 5714, DOI 10.17487/RFC5714, January 2010, 598 . 600 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 601 and K. Kumaki, "Distribution of Diverse BGP Paths", 602 RFC 6774, DOI 10.17487/RFC6774, November 2012, 603 . 605 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 606 S. Ray, "North-Bound Distribution of Link-State and 607 Traffic Engineering (TE) Information Using BGP", RFC 7752, 608 DOI 10.17487/RFC7752, March 2016, 609 . 611 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 612 "Advertisement of Multiple Paths in BGP", RFC 7911, 613 DOI 10.17487/RFC7911, July 2016, 614 . 616 Appendix A. Appendix: alternative solutions with limited applicability 618 One possible valid solution or workaround to the best path selection 619 problem requires sending all domain external paths from the route 620 reflector to all its clients. This approach suffers the significant 621 drawback of pushing a large amount of BGP state and churn to all edge 622 routers. Many networks receive full Internet routing information in 623 a large number of locations. This could easily result in tens of 624 paths for each prefix that would need to be distributed to clients. 626 Notwithstanding this drawback, there are a number of reasons for 627 sending more than just the single best path to the clients. Improved 628 path diversity at the edge is a requirement for fast connectivity 629 restoration, and a requirement for effective BGP level load 630 balancing. 632 In practical terms, add/diverse path deployments [RFC7911] [RFC6774] 633 are expected to result in the distribution of 2, 3, or n (where n is 634 a small number) good paths rather than all domain external paths. 635 When the route reflector chooses one set of n paths and distributes 636 them to all its route reflector clients, those n paths may not be the 637 right n paths for all clients. In the context of the problem 638 described above, those n paths will not necessarily include the 639 closest exit point out of the network for each route reflector 640 client. The mechanisms proposed in this document are likely to be 641 complementary to mechanisms aimed at improving path diversity. 643 Another possibility to optimize exit point selection is the 644 implementation of distributed route reflector functionality at key 645 IGP locations in order to ensure that these locations see their 646 viewpoints respected in exit selection. Typically, however, this 647 requires the installation of physical nodes to implement the 648 reflection, and if exit policy subsequently changes, the reflector 649 placement and position can become inappropriate. 651 To counter the burden of physical installation, it is possible to 652 build a logical overlay of tunnels with appropriate IGP metrics in 653 order to simulate closeness to key locations required to implement 654 exit policy. There is significant complexity overhead in this 655 approach, however, enough so to typically make it undesirable. 657 Trends in control plane decoupling are causing a shift from 658 traditional routers to compute virtualization platforms, or even 659 third-party cloud platforms. As a result, without this proposal, 660 operators are left with a difficult choice for the distribution and 661 reflection of address families with significant exit diversity: 663 o centralized path selection, and tolerate the associated suboptimal 664 paths, or 666 o defer selection to end clients, but lose potential route scale 667 capacity 669 The latter can be a viable option, but it is clearly a decision that 670 needs to be made on an application and address family basis, with 671 strong consideration for the number of available paths per prefix 672 (which may even vary per prefix range, depending on peering policy, 673 e.g. consider bilateral peerings versus onward transit arrangements) 675 Authors' Addresses 677 Robert Raszuk (editor) 678 Bloomberg LP 679 731 Lexington Ave 680 New York City, NY 10022 681 USA 683 Email: robert@raszuk.net 685 Christian Cassar 686 Tesla 687 43 Avro Way 688 Weybridge KT13 0XY 689 UK 691 Email: ccassar@tesla.com 693 Erik Aman 694 Telia Company 695 Solna SE-169 94 696 Sweden 698 Email: erik.aman@teliacompany.com 699 Bruno Decraene (editor) 700 Orange 702 Email: bruno.decraene@orange.com 704 Kevin Wang 705 Juniper Networks 706 10 Technology Park Drive 707 Westford, MA 01886 708 USA 710 Email: kfwang@juniper.net