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