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