idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-20.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 date (January 8, 2020) is 1570 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 107, but not defined == Missing Reference: 'RFC 4271' is mentioned on line 124, but not defined == Unused Reference: 'RFC4271' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC1998' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC4384' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC5283' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC5668' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 603, 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 (~~), 13 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: July 11, 2020 Tesla 6 E. Aman 7 Telia Company 8 B. Decraene 9 Orange 10 K. Wang 11 Juniper Networks 12 January 8, 2020 14 BGP Optimal Route Reflection (BGP-ORR) 15 draft-ietf-idr-bgp-optimal-route-reflection-20 17 Abstract 19 This document proposes a solution for BGP route reflectors to allow 20 them to choose the best path for their clients that the clients 21 themselves would have chosen under the same conditions, without 22 requiring further state or any new features to be placed on the 23 clients. This facilitates, for example, best exit point policy (hot 24 potato routing). This solution is primarily applicable in 25 deployments using centralized route reflectors. 27 The solution relies upon all route reflectors learning all paths 28 which are eligible for consideration. Best path selection is 29 performed in each route reflector based on a configured virtual 30 location in the IGP. The location can be the same for all clients or 31 different per peer/update group or per peer. Best path selection can 32 also be performed based on user configured policies in each route 33 reflector. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on July 11, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Definitions of Terms Used in This Memo . . . . . . . . . . . 2 69 2. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Existing/Alternative Solutions . . . . . . . . . . . . . 5 73 4. Two Proposed Solutions . . . . . . . . . . . . . . . . . . . 6 74 4.1. Client's Perspective IGP Based Best Path Selection . . . 7 75 4.1.1. Restriction when BGP next hop is BGP prefix . . . . . 8 76 4.2. Client's Perspective Policy Based Best Path Selection . . 8 77 4.3. Solution Interactions . . . . . . . . . . . . . . . . . . 9 78 4.3.1. IGP and policy based optimal route refresh . . . . . 9 79 4.3.2. Add-paths plus IGP and policy optimal route refresh . 9 80 4.3.3. Likely Deployments and need for backup . . . . . . . 9 81 5. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 10 82 6. Advantages and Deployment Considerations . . . . . . . . . . 10 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 10.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Definitions of Terms Used in This Memo 93 NLRI - Network Layer Reachability Information. 95 RIB - Routing Information Base. 97 AS - Autonomous System number. 99 VRF - Virtual Routing and Forwarding instance. 101 PE - Provider Edge router 103 RR - Route Reflector 105 POP - Point Of Presence 107 L3VPN - Layer 3 Virtual Private Networks [RFC4364] 109 6PE - IPv6 Provider Edge Router 111 IGP - Interior Gateway Protocol 113 SPT - Shortest Path Tree 115 best path - the route chosen by the decision process detailed in 116 [RFC 4271] section 9.1.2 and its subsections 118 best path computation - the decision process detailed in [RFC 4271] 119 section 9.1.2 and its subsections 121 best path algorithm - the decision process detailed in [RFC 4271] 122 section 9.1.2 and its subsections 124 best path selection - the decision process detailed in [RFC 4271] 125 section 9.1.2 and its subsections 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Authors 135 Following authors substantially contributed to the current format of 136 the document: 138 Stephane Litkowski 139 Orange 140 9 rue du chene germain 141 Cesson Sevigne, 35512 142 France 144 stephane.litkowski@orange.com 145 Adam Chappell 146 Interoute Communications 147 31st Floor 148 25 Canada Square 149 London, E14 5LQ 150 United Kingdom 152 adam.chappell@interoute.com 154 3. Introduction 156 There are three types of BGP deployments within Autonomous Systems 157 today: full mesh, confederations and route reflection. BGP route 158 reflection [RFC4456] is the most popular way to distribute BGP routes 159 between BGP speakers belonging to the same Autonomous System. 160 However, in some situations, this method suffers from non-optimal 161 path selection. 163 3.1. Problem Statement 165 [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) 166 cost to a given point in the network will vary across routers, "the 167 route reflection approach may not yield the same route selection 168 result as that of the full IBGP mesh approach." One practical 169 implication of this assertion is that the deployment of route 170 reflection may thwart the ability to achieve hot potato routing. Hot 171 potato routing attempts to direct traffic to the best AS exit point 172 in cases where no higher priority policy dictates otherwise. As a 173 consequence of the route reflection method, the choice of exit point 174 for a route reflector and its clients will be the exit point best for 175 the route reflector - not necessarily the one best for the route 176 reflector clients. 178 Section 11 of [RFC4456] describes a deployment approach and a set of 179 constraints which, if satisfied, would result in the deployment of 180 route reflection yielding the same results as the iBGP full mesh 181 approach. This deployment approach makes route reflection compatible 182 with the application of hot potato routing policy. In accordance 183 with these design rules, route reflectors have traditionally often 184 been deployed in the forwarding path and carefully placed on the POP 185 to core boundaries. 187 The evolving model of intra-domain network design has enabled 188 deployments of route reflectors outside of the forwarding path. 189 Initially this model was only employed for new address families, e.g. 190 L3VPNs and L2VPNs, however it has been gradually extended to other 191 BGP address families including IPv4 and IPv6 Internet using either 192 native routing or 6PE. In such environments, hot potato routing 193 policy remains desirable. 195 Route reflectors outside of the forwarding path can be placed on the 196 POP to core boundaries, but they are often placed in arbitrary 197 locations in the core of large networks. 199 Such deployments suffer from a critical drawback in the context of 200 best path selection: A route reflector with knowledge of multiple 201 paths for a given prefix will typically pick its best path and only 202 advertise that best path to its clients. If the best path for a 203 prefix is selected on the basis of an IGP tie break, the path 204 advertised will be the exit point closest to the route reflector. 205 However, the clients are in a different place in the network topology 206 than the route reflector. In networks where the route reflectors are 207 not in the forwarding path, this difference will be even more acute. 209 In addition, there are deployment scenarios where service providers 210 want to have more control in choosing the exit points for clients 211 based on other factors, such as traffic type, traffic load, etc. 212 This further complicates the issue and makes it less likely for the 213 route reflector to select the best path from the client's 214 perspective. It follows that the best path chosen by the route 215 reflector is not necessarily the same as the path which would have 216 been chosen by the client if the client had considered the same set 217 of candidate paths as the route reflector. 219 3.2. Existing/Alternative Solutions 221 One possible valid solution or workaround to the best path selection 222 problem requires sending all domain external paths from the route 223 reflector to all its clients. This approach suffers the significant 224 drawback of pushing a large amount of BGP state to all edge routers. 225 Many networks receive full Internet routing information in a large 226 number of locations. This could easily result in tens of paths for 227 each prefix that would need to be distributed to clients. 229 Notwithstanding this drawback, there are a number of reasons for 230 sending more than just the single best path to the clients. Improved 231 path diversity at the edge is a requirement for fast connectivity 232 restoration, and a requirement for effective BGP level load 233 balancing. 235 In practical terms, add/diverse path deployments [RFC7911] [RFC6774] 236 are expected to result in the distribution of 2, 3, or n (where n is 237 a small number) good paths rather than all domain external paths. 238 When the route reflector chooses one set of n paths and distributes 239 them to all its route reflector clients, those n paths may not be the 240 right n paths for all clients. In the context of the problem 241 described above, those n paths will not necessarily include the 242 closest exit point out of the network for each route reflector 243 client. The mechanisms proposed in this document are likely to be 244 complementary to mechanisms aimed at improving path diversity. 246 Another possibility to optimize exit point selection is the 247 implementation of distributed route reflector functionality at key 248 IGP locations in order to ensure that these locations see their 249 viewpoints respected in exit selection. Typically, however, this 250 requires the installation of physical nodes to implement the 251 reflection, and if exit policy subsequently changes, the reflector 252 placement and position can become inappropriate. 254 To counter the burden of physical installation, it is possible to 255 build a logical overlay of tunnels with appropriate IGP metrics in 256 order to simulate closeness to key locations required to implement 257 exit policy. There is significant complexity overhead in this 258 approach, however, enough so to typically make it undesirable. 260 Trends in control plane decoupling are causing a shift from 261 traditional routers to compute virtualization platforms, or even 262 third-party cloud platforms. As a result, without this proposal, 263 operators are left with a difficult choice for the distribution and 264 reflection of address families with significant exit diversity: 266 o centralized path selection, and tolerate the associated suboptimal 267 paths, or 269 o defer selection to end clients, but lose potential route scale 270 capacity 272 The latter can be a viable option, but it is clearly a decision that 273 needs to be made on an application and address family basis, with 274 strong consideration for the number of available paths per prefix 275 (which may even vary per prefix range, depending on peering policy, 276 e.g. consider bilateral peerings versus onward transit arrangements) 278 4. Two Proposed Solutions 280 This document is describes two solution to allow a route reflector to 281 choose the best path for its clients that the clients themselves 282 would have chosen had they considered the same set of candidate 283 paths. 285 For purposes of route selection, the perspective of a client can 286 differ from that of a route reflector or another client in two 287 distinct ways: 289 it can, and usually will, have a different position in the IGP 290 topology, and 292 it can have a different routing policy. 294 These factors correspond to the issues described earlier. 295 Accordingly, this document specifies two distinct modifications to 296 the best path algorithm, to address these two distinct factors. A 297 route reflector can implement either or both of the modifications in 298 order to allow it to choose the best path for its clients that the 299 clients themselves would have chosen given the same set of candidate 300 paths. 302 Both modifications rely upon all route reflectors learning all paths 303 that are eligible for consideration. In order to satisfy this 304 requirement, path diversity enhancing mechanisms such as add-path/ 305 diverse paths may need to be deployed between route reflectors. 307 A significant advantage of these approaches is that the route 308 reflector clients do not need to run new software or hardware. 310 4.1. Client's Perspective IGP Based Best Path Selection 312 The core of this solution is the ability for an operator to specify 313 on a per route reflector basis, or per peer/update group basis, or 314 per peer basis the virtual IGP location placement of the route 315 reflector. This core ability enables the route reflector to send to 316 a given group of clients routes with shortest distance to the next 317 hops from the position of the configured virtual IGP location. This 318 core ability provides for freedom of route reflector location, and 319 allows transient or permanent migration of this network control plane 320 function to an arbitrary location. 322 The choice of specific granularity (route reflector basis, peer/ 323 update group basis, or peer peer basis) is left as an implementation 324 decision. An implementation is considered compliant with the 325 document if it supports at least one listed grouping of virtual IGP 326 location. 328 In this approach, optimal refers to the decision made during best 329 path selection at the IGP metric to BGP next hop comparison step. 330 This approach does not apply to path selection preference based on 331 other policy steps and provisions. 333 The computation of the virtual IGP location with any of the above 334 described granularity is outside of the scope of this document. The 335 operator may configure it manually, implementation may automate it 336 based on heuristics, or it can be computed centrally and configured 337 by an external system. 339 This solution does not require any BGP or IGP protocol changes, as 340 all required changes are contained within the route reflector 341 implementation. 343 This solution applies to NLRIs of all address families, that can be 344 route reflected. 346 4.1.1. Restriction when BGP next hop is BGP prefix 348 In situations where the BGP next hop is a BGP prefix itself the IGP 349 metric of a route used for its resolution SHOULD be the final IGP 350 cost to reach such next hop. Implementations which can not inform 351 BGP of the final IGP metric to a recursive next hop SHOULD treat such 352 paths as least preferred during next hop metric comparison. However 353 such paths SHOULD still be considered valid for best path selection. 355 4.2. Client's Perspective Policy Based Best Path Selection 357 Optimal route reflection based on virtual IGP location could reflect 358 the best path to the client from IGP cost perspective. However, 359 there are also cases where the client might want the best path based 360 on factors beyond IGP cost. Examples include, but not limited to: 362 o Selecting the best path for the clients from a traffic engineering 363 perspective. 365 o Dedicating certain exit points for certain ingress points. 367 The user MAY specify and apply a general policy on the route 368 reflector to select a subset of exit points as the candidate exit 369 points for its clients. For a given client, the policy SHOULD also 370 allow the operator to select different candidate exit points for 371 different address families. Regular path selection, including 372 client's perspective IGP based best path selection stated above, will 373 be applied to the candidate paths to select the final paths to 374 advertise to the clients. 376 Since the policy is applied on the route reflector on behalf of its 377 clients, the route reflector will be able to reflect only the optimal 378 paths to its clients. An additional advantage of this approach is 379 that configuration need only be done on a small number of route 380 reflectors, rather than on a significantly larger number of clients. 382 4.3. Solution Interactions 384 4.3.1. IGP and policy based optimal route refresh 386 Depending on the actual deployment scenarios, service providers may 387 configure IGP based optimal route reflection or policy based optimal 388 route reflection. It is also possible to configure both approaches 389 together. In cases where both are configured together, policy based 390 optimal route reflection MUST be applied first to select the 391 candidate paths, then IGP based optimal route reflection can be 392 applied on top of the candidate paths to select the final path to 393 advertise to the client. 395 The expected use case for optimal route reflection is to avoid 396 reflecting all paths to the client because the client either: does 397 not support add-paths or does not have the capacity to process all of 398 the paths. Typically the route reflector would just reflect a single 399 optimal route to the client. However, the solutions MUST NOT prevent 400 reflecting more than one optimal path to the client as path diversity 401 may be desirable for load balancing or fast restoration. In cases 402 where add-path and optimal route reflection are configured together, 403 the route reflector MUST reflect n optimal paths to a client, where n 404 is the add-path count. 406 4.3.2. Add-paths plus IGP and policy optimal route refresh 408 The most complicated scenario is where add-path is configured 409 together with both IGP based and policy based optimal route 410 reflection. In this scenario, the policy based optimal route 411 reflection MUST be applied first to select the candidate paths (from 412 add-path). Subsequently, IGP based optimal route reflection will be 413 applied on top of the candidate paths to select the best n paths to 414 advertise to the client. 416 4.3.3. Likely Deployments and need for backup 418 With IGP based optimal route reflection, even though the virtual IGP 419 location could be specified on a per route reflector basis or per 420 peer/update group basis or per peer basis, in reality, it's most 421 likely to be specified per peer/update group basis. All clients with 422 the same or similar IGP location can be grouped into the same peer/ 423 update group. A virtual IGP location is then specified for the peer/ 424 update group. The virtual location is usually specified as the 425 location of one of the clients from the peer group or an ABR to the 426 area where clients are located. Also, one or more backup virtual 427 locations SHOULD be allowed to be specified for redundancy. 428 Implementations may wish to take advantage of peer group mechanisms 429 in order to provide for better scalability of optimal route reflector 430 client groups with similar properties. 432 5. CPU and Memory Scalability 434 For IGP based optimal route reflection, determining the shortest path 435 and associated cost between any two arbitrary points in a network 436 based on the IGP topology learned by a router is expected to add some 437 extra cost in terms of CPU resources. However, current SPF tree 438 generation code is implemented efficiently in a number of 439 implementations, and therefore this is not expected to be a major 440 drawback. The number of SPTs computed is expected to be of the order 441 of the number of clients of a route reflector whenever a topology 442 change is detected. Advanced optimizations like partial and 443 incremental SPF may also be exploited. The number of SPTs computed 444 is expected to be higher but comparable to some existing deployed 445 features such as (Remote) Loop Free Alternate which computes a (r)SPT 446 per IGP neighbor. 448 For policy based optimal route reflection, there will be some 449 overhead to apply the policy to select the candidate paths. This 450 overhead is comparable to existing BGP export policies and therefore 451 should be manageable. 453 By the nature of route reflection, the number of clients can be split 454 arbitrarily by the deployment of more route reflectors for a given 455 number of clients. While this is not expected to be necessary in 456 existing networks with best in class route reflectors available 457 today, this avenue to scaling up the route reflection infrastructure 458 is available. 460 If we consider the overall network wide cost/benefit factor, the only 461 alternative to achieve the same level of optimality would require 462 significantly increasing state on the edges of the network. This 463 will consume CPU and memory resources on all BGP speakers in the 464 network. Building this client perspective into the route reflectors 465 seems appropriate. 467 6. Advantages and Deployment Considerations 469 The solutions described provide a model for integrating the client 470 perspective into the best path computation for route reflectors. 471 More specifically, the choice of BGP path factors in either the IGP 472 cost between the client and the nexthop (rather than the IGP cost 473 from the route reflector to the nexthop) or other user configured 474 policies. 476 Implementations considered compliant with this document allow the 477 configuration of a logical location from which the best path will be 478 computed, on the basis of either a peer, a peer group, or an entire 479 routing instance. 481 These solutions can be deployed in traditional hop-by-hop forwarding 482 networks as well as in end-to-end tunneled environments. In networks 483 where there are multiple route reflectors and hop-by-hop forwarding 484 without encapsulation, such optimizations SHOULD be enabled in a 485 consistent way on all route reflectors. Otherwise, clients may 486 receive an inconsistent view of the network, in turn leading to 487 intra-domain forwarding loops. 489 With this approach, an ISP can effect a hot potato routing policy 490 even if route reflection has been moved out of the forwarding plane, 491 and hop-by-hop switching has been replaced by end-to-end MPLS or IP 492 encapsulation. 494 As per above, these approaches reduce the amount of state which needs 495 to be pushed to the edge of the network in order to perform hot 496 potato routing. The memory and CPU resources required at the edge of 497 the network to provide hot potato routing using these approaches is 498 lower than what would be required to achieve the same level of 499 optimality by pushing and retaining all available paths (potentially 500 10s) per each prefix at the edge. 502 The solutions above allow for a fast and safe transition to a BGP 503 control plane using centralized route reflection, without 504 compromising an operator's closest exit operational principle. This 505 enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and 506 IPv6 prefixes. 508 Regarding the client's IGP best-path selection, it should be self 509 evident that this solution does not interfere with policies enforced 510 above IGP tie breaking in the BGP best path algorithm. 512 7. Security Considerations 514 This document does not introduce any new BGP functionality therefor 515 it does not change the underlying security issues inherent in the 516 existing IBGP path propagation when BGP Route Reflection [RFC4456] is 517 used. 519 It however enables the deployment of base BGP Route Reflection as 520 described in [RFC4456] to be possible using virtual compute 521 environments without any negative consequence on the BGP routing path 522 optimality. 524 This document does not introduce requirements for any new protection 525 measures, but it also does not relax best operational practices for 526 keeping the IGP network stable or to pace rate of policy based IGP 527 cost to next hops such that it does not have any substantial effect 528 on BGP path changes and their propagation to route reflection 529 clients. 531 8. IANA Considerations 533 This document does not request any IANA allocations. 535 9. Acknowledgments 537 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 538 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 539 Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele 540 Ceccarelli, Kieran Milne, Job Snijders and Randy Bush for their 541 valuable input. 543 10. References 545 10.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 553 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 554 DOI 10.17487/RFC4271, January 2006, 555 . 557 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 558 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 559 February 2006, . 561 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 562 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 563 2009, . 565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 567 May 2017, . 569 10.2. Informative References 571 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 572 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 573 . 575 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 576 Community Attribute in Multi-home Routing", RFC 1998, 577 DOI 10.17487/RFC1998, August 1996, 578 . 580 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 581 RFC 4384, DOI 10.17487/RFC4384, February 2006, 582 . 584 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 585 Reflection: An Alternative to Full Mesh Internal BGP 586 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 587 . 589 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 590 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 591 . 593 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 594 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 595 DOI 10.17487/RFC5283, July 2008, 596 . 598 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 599 Specific BGP Extended Community", RFC 5668, 600 DOI 10.17487/RFC5668, October 2009, 601 . 603 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 604 RFC 5714, DOI 10.17487/RFC5714, January 2010, 605 . 607 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 608 and K. Kumaki, "Distribution of Diverse BGP Paths", 609 RFC 6774, DOI 10.17487/RFC6774, November 2012, 610 . 612 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 613 "Advertisement of Multiple Paths in BGP", RFC 7911, 614 DOI 10.17487/RFC7911, July 2016, 615 . 617 Authors' Addresses 619 Robert Raszuk (editor) 620 Bloomberg LP 621 731 Lexington Ave 622 New York City, NY 10022 623 USA 625 Email: robert@raszuk.net 627 Christian Cassar 628 Tesla 629 43 Avro Way 630 Weybridge KT13 0XY 631 UK 633 Email: ccassar@tesla.com 635 Erik Aman 636 Telia Company 637 Solna SE-169 94 638 Sweden 640 Email: erik.aman@teliacompany.com 642 Bruno Decraene 643 Orange 644 38-40 rue du General Leclerc 645 Issy les Moulineaux cedex 9 92794 646 France 648 Email: bruno.decraene@orange.com 650 Kevin Wang 651 Juniper Networks 652 10 Technology Park Drive 653 Westford, MA 01886 654 USA 656 Email: kfwang@juniper.net