idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-22.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 15, 2021) is 1195 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) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 NTT Network Innovations 4 Intended status: Standards Track C. Cassar 5 Expires: July 19, 2021 Tesla 6 E. Aman 8 B. Decraene, Ed. 9 Orange 10 K. Wang 11 Juniper Networks 12 January 15, 2021 14 BGP Optimal Route Reflection (BGP-ORR) 15 draft-ietf-idr-bgp-optimal-route-reflection-22 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 from the standpoint of their clients, rather than from the 22 standpoint of the route reflectors. Multiple types of granularity 23 are proposed, from a per client BGP route selection or to a per peer 24 group, 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 July 19, 2021. 53 Copyright Notice 55 Copyright (c) 2021 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 . . . . . . . . . . . 2 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Modifications to BGP Best Path selection . . . . . . . . . . 5 73 3.1. Best Path Selection from a different IGP location . . . . 6 74 3.1.1. Restriction when BGP next hop is BGP prefix . . . . . 7 75 3.2. Multiple Best Path Selections . . . . . . . . . . . . . . 7 76 4. Implementation considerations . . . . . . . . . . . . . . . . 7 77 4.1. Likely Deployments and need for backup . . . . . . . . . 7 78 5. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 8 79 6. Advantages and Deployment Considerations . . . . . . . . . . 8 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 86 11.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Appendix A. Appendix: alternative solutions with limited 88 applicability . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Definitions of Terms Used in This Memo 93 NLRI - Network Layer Reachability Information 95 RIB - Routing Information Base 96 AS - Autonomous System number 98 VRF - Virtual Routing and Forwarding instance 100 PE - Provider Edge router 102 RR - Route Reflector 104 POP - Point Of Presence 106 L3VPN - Layer 3 Virtual Private Network [RFC4364] 108 6PE - IPv6 Provider Edge [RFC4798] 110 IGP - Interior Gateway Protocol 112 SPT - Shortest Path Tree 114 best path - the route chosen by the decision process detailed in 115 [RFC4271] section 9.1.2 and its subsections 117 best path computation - the decision process detailed in [RFC4271] 118 section 9.1.2 and its subsections 120 best path algorithm - the decision process detailed in [RFC4271] 121 section 9.1.2 and its subsections 123 best path selection - the decision process detailed in [RFC4271] 124 section 9.1.2 and its subsections 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 2. Introduction 134 There are three types of BGP deployments within Autonomous Systems 135 today: full mesh, confederations and route reflection. BGP route 136 reflection [RFC4456] is the most popular way to distribute BGP routes 137 between BGP speakers belonging to the same Autonomous System. 138 However, in some situations, this method suffers from non-optimal 139 path selection. 141 [RFC4456] asserts that, because the IGP cost to a given point in the 142 network will vary across routers, "the route reflection approach may 143 not yield the same route selection result as that of the full IBGP 144 mesh approach." One practical implication of this assertion is that 145 the deployment of route reflection may thwart the ability to achieve 146 hot potato routing. Hot potato routing attempts to direct traffic to 147 the closest AS exit point in cases where no higher priority policy 148 dictates otherwise. As a consequence of the route reflection method, 149 the choice of exit point for a route reflector and its clients will 150 be the exit point that is optimal for the route reflector - not 151 necessarily the one that is optimal for its clients. 153 Section 11 of [RFC4456] describes a deployment approach and a set of 154 constraints which, if satisfied, would result in the deployment of 155 route reflection yielding the same results as the IBGP full mesh 156 approach. This deployment approach makes route reflection compatible 157 with the application of hot potato routing policy. In accordance 158 with these design rules, route reflectors have traditionally often 159 been deployed in the forwarding path and carefully placed on the POP 160 to core boundaries. 162 The evolving model of intra-domain network design has enabled 163 deployments of route reflectors outside of the forwarding path. 164 Initially this model was only employed for new address families, e.g. 165 L3VPNs and L2VPNs, however it has been gradually extended to other 166 BGP address families including IPv4 and IPv6 Internet using either 167 native routing or 6PE. In such environments, hot potato routing 168 policy remains desirable. 170 Route reflectors outside of the forwarding path can be placed on the 171 POP to core boundaries, but they are often placed in arbitrary 172 locations in the core of large networks. 174 Such deployments suffer from a critical drawback in the context of 175 best path selection: A route reflector with knowledge of multiple 176 paths for a given prefix will typically pick its best path and only 177 advertise that best path to its clients. If the best path for a 178 prefix is selected on the basis of an IGP tie-break, the path 179 advertised will be the exit point closest to the route reflector. 180 However, the clients are in a different place in the network topology 181 than the route reflector. In networks where the route reflectors are 182 not in the forwarding path, this difference will be even more acute. 184 In addition, there are deployment scenarios where service providers 185 want to have more control in choosing the exit points for clients 186 based on other factors, such as traffic type, traffic load, etc. 187 This further complicates the issue and makes it less likely for the 188 route reflector to select the best path from the client's 189 perspective. It follows that the best path chosen by the route 190 reflector is not necessarily the same as the path which would have 191 been chosen by the client if the client had considered the same set 192 of candidate paths as the route reflector. 194 3. Modifications to BGP Best Path selection 196 The core of this solution is the ability for an operator to specify 197 the IGP location for which the route reflector should calculate 198 routes. This can be done on a per route reflector basis, per peer/ 199 update group basis, or per peer basis. This ability enables the 200 route reflector to send to a given set of clients routes with 201 shortest distance to the next hops from the position of the selected 202 IGP location. This provides for freedom of route reflector physical 203 location, and allows transient or permanent migration of this network 204 control plane function to an arbitrary location. 206 The choice of specific granularity (route reflector, peer/update 207 group, or peer) is configured by the network operator. An 208 implementation is considered compliant with this document if it 209 supports at least one listed grouping of IGP location. 211 For purposes of route selection, the perspective of a client can 212 differ from that of a route reflector or another client in two 213 distinct ways: 215 o it can, and usually will, have a different position in the IGP 216 topology, and 218 o it can have a different routing policy. 220 These factors correspond to the issues described earlier. 222 This document defines, on BGP Route Reflectors [RFC4456], two changes 223 to the BGP Best Path selection algorithm: 225 o The first change, introduced in Section 3.1, is related to the IGP 226 cost to the BGP Next Hop in the BGP decision process. The change 227 consists in using the IGP cost from a different IGP location than 228 the route reflector itself. 230 o The second change, introduced in Section 3.2, is to extend the 231 granularity of the BGP decision process, to allow for running 232 multiple decisions process using different perspective or 233 policies. 235 A route reflector can implement either or both of the modifications 236 in order to allow it to choose the best path for its clients that the 237 clients themselves would have chosen given the same set of candidate 238 paths. 240 A significant advantage of these approaches is that the route 241 reflector clients do not need to run new software or hardware. 243 3.1. Best Path Selection from a different IGP location 245 In this approach, optimal refers to the decision made during best 246 path selection at the IGP metric to BGP next hop comparison step. It 247 does not apply to path selection preference based on other policy 248 steps and provisions. 250 In addition to the change specified in [RFC4456] section 9, the BGP 251 Decision Process tie-breaking rules ([RFC4271] section 9.1.2.2) are 252 modified as follows. 254 The below text in step e) 256 e) Remove from consideration any routes with less-preferred 257 interior cost. The interior cost of a route is determined by 258 calculating the metric to the NEXT_HOP for the route using the 259 Routing Table. 261 ...is replaced by this new text: 263 e) Remove from consideration any routes with less-preferred 264 interior cost. The interior cost of a route is determined by 265 calculating the metric from the selected IGP location to the 266 NEXT_HOP for the route using the shortest IGP path tree rooted at 267 the selected IGP location. 269 In order to be able to compute the shortest path tree rooted at the 270 selected IGP locations, knowledge of the IGP topology for the area/ 271 level that includes each of those locations is needed. This 272 knowledge can be gained with the use of the link state IGP such as 273 IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752]. 275 The configuration of the IGP location is outside of the scope of this 276 document. The operator may configure it manually, an implementation 277 may automate it based on heuristics, or it can be computed centrally 278 and configured by an external system. 280 This solution does not require any change (BGP or IGP) on the 281 clients, as all required changes are limited to the route reflector. 283 This solution applies to NLRIs of all address families that can be 284 route reflected. 286 3.1.1. Restriction when BGP next hop is BGP prefix 288 In situations where the BGP next hop is a BGP prefix itself, the IGP 289 metric of a route used for its resolution SHOULD be the final IGP 290 cost to reach such next hop. Implementations which can not inform 291 BGP of the final IGP metric to a recursive next hop SHOULD treat such 292 paths as least preferred during next hop metric comparison. However 293 such paths SHOULD still be considered valid for best path selection. 295 3.2. Multiple Best Path Selections 297 BGP Route Reflector as per [RFC4456] runs a single best path 298 selection. Optimal route reflection may require calculation of 299 multiple best path selections or subsets of best path selection in 300 order to consider different IGP locations or BGP policies for 301 different sets of clients. 303 If the required routing optimization is limited to the IGP cost to 304 the BGP Next-Hop, only step e) as defined [RFC4271] section 9.1.2.2, 305 needs to be duplicated. 307 If the routing optimization requires the use of different BGP 308 policies for different sets of clients, a larger part of the decision 309 process needs to be duplicated, up to the whole decision process as 310 defined in section 9.1 of [RFC4271]. This is for example the case 311 when there is a need to use different policies to compute different 312 degree of preference during Phase 1. This is needed for use cases 313 involving traffic engineering or dedicating certain exit points for 314 certain clients. In the latter case, the user MAY specify and apply 315 a general policy on the route reflector for a set of clients. For a 316 given set of clients, the policy SHOULD in that case allow the 317 operator to select different candidate exit points for different 318 address families. Regular path selection, including IGP perspective 319 for a set of clients as per Section 3.1, is then applied to the 320 candidate paths to select the final paths to advertise to the 321 clients. 323 4. Implementation considerations 325 4.1. Likely Deployments and need for backup 327 With IGP based optimal route reflection, even though the IGP location 328 could be specified on a per route reflector basis or per peer/update 329 group basis or per peer basis, in reality, it's most likely to be 330 specified per peer/update group basis. All clients with the same or 331 similar IGP location can be grouped into the same peer/update group. 332 An IGP location is then specified for the peer/update group. The 333 location is usually specified as the location of one of the clients 334 from the peer group or an ABR to the area where clients are located. 335 Also, one or more backup locations SHOULD be allowed to be specified 336 for redundancy. Implementations may wish to take advantage of peer 337 group mechanisms in order to provide for better scalability of 338 optimal route reflector client groups with similar properties. 340 5. CPU and Memory Scalability 342 For IGP based optimal route reflection, determining the shortest path 343 and associated cost between any two arbitrary points in a network 344 based on the IGP topology learned by a router is expected to add some 345 extra cost in terms of CPU resources. However, current SPF tree 346 generation code is implemented efficiently in a number of 347 implementations, and therefore this is not expected to be a major 348 drawback. The number of SPTs computed is expected to be of the order 349 of the number of clients of a route reflector whenever a topology 350 change is detected. It is expected to be higher but comparable to 351 some existing deployed features such as (Remote) Loop Free Alternate 352 which computes a (r)SPT per IGP neighbor. 354 For policy based optimal route reflection, there will be some 355 overhead to apply the policy to select the candidate paths. This 356 overhead is comparable to existing BGP export policies and therefore 357 should be manageable. 359 By the nature of route reflection, the number of clients can be split 360 arbitrarily by the deployment of more route reflectors for a given 361 number of clients. While this is not expected to be necessary in 362 existing networks with best in class route reflectors available 363 today, this avenue to scaling up the route reflection infrastructure 364 is available. 366 If we consider the overall network wide cost/benefit factor, the only 367 alternative to achieve the same level of optimality would require 368 significantly increasing state on the edges of the network. This 369 will consume CPU and memory resources on all BGP speakers in the 370 network. Building this client perspective into the route reflectors 371 seems appropriate. 373 6. Advantages and Deployment Considerations 375 The solutions described provide a model for integrating the client 376 perspective into the best path computation for route reflectors. 377 More specifically, the choice of BGP path factors in either the IGP 378 cost between the client and the nexthop (rather than the IGP cost 379 from the route reflector to the nexthop) or other user configured 380 policies. 382 The achievement of optimal routing relies upon all route reflectors 383 learning all paths that are eligible for consideration. In order to 384 satisfy this requirement, path diversity enhancing mechanisms such as 385 BGP add-path [RFC7911] may need to be deployed between route 386 reflectors. 388 Implementations considered compliant with this document allow the 389 configuration of a logical location from which the best path will be 390 computed, on the basis of either a peer, a peer group, or an entire 391 routing instance. 393 These solutions can be deployed in traditional hop-by-hop forwarding 394 networks as well as in end-to-end tunneled environments. In networks 395 where there are multiple route reflectors and hop-by-hop forwarding 396 without encapsulation, such optimizations SHOULD be enabled in a 397 consistent way on all route reflectors. Otherwise, clients may 398 receive an inconsistent view of the network, in turn leading to 399 intra-domain forwarding loops. 401 With this approach, an ISP can effect a hot potato routing policy 402 even if route reflection has been moved out of the forwarding plane, 403 and hop-by-hop switching has been replaced by end-to-end MPLS or IP 404 encapsulation. 406 As per above, these approaches reduce the amount of state which needs 407 to be pushed to the edge of the network in order to perform hot 408 potato routing. The memory and CPU resources required at the edge of 409 the network to provide hot potato routing using these approaches is 410 lower than what would be required to achieve the same level of 411 optimality by pushing and retaining all available paths (potentially 412 10s) per each prefix at the edge. 414 The solutions above allow for a fast and safe transition to a BGP 415 control plane using centralized route reflection, without 416 compromising an operator's closest exit operational principle. This 417 enables edge-to-edge LSP/IP encapsulation for traffic to IPv4 and 418 IPv6 prefixes. 420 Regarding Best Path Selection from a different IGP location, it 421 should be self evident that this solution does not interfere with 422 policies enforced above IGP tie-breaking in the BGP best path 423 algorithm. 425 7. Security Considerations 427 Similarly to [RFC4456], this extension to BGP does not change the 428 underlying security issues inherent in the existing IBGP [RFC4456]. 430 It however enables the deployment of base BGP Route Reflection as 431 described in [RFC4456] to be possible using virtual compute 432 environments without any negative consequence on the BGP routing path 433 optimality. 435 This document does not introduce requirements for any new protection 436 measures, but it also does not relax best operational practices for 437 keeping the IGP network stable or to pace rate of policy based IGP 438 cost to next hops such that it does not have any substantial effect 439 on BGP path changes and their propagation to route reflection 440 clients. 442 8. IANA Considerations 444 This document does not request any IANA allocations. 446 9. Acknowledgments 448 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 449 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 450 Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele 451 Ceccarelli, Kieran Milne, Job Snijders and Randy Bush for their 452 valuable input. 454 10. Contributors 456 Following persons substantially contributed to the current format of 457 the document: 459 Stephane Litkowski 460 Cisco System 462 slitkows.ietf@gmail.com 464 Adam Chappell 465 GTT Communications, Inc. 466 Aspira Business Centre 467 Bucharova 2928/14a 468 158 00 Prague 13 Stodulky 469 Czech Republic 471 adam.chappell@gtt.net 473 11. References 475 11.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 483 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 484 DOI 10.17487/RFC4271, January 2006, 485 . 487 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 488 Reflection: An Alternative to Full Mesh Internal BGP 489 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 490 . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 11.2. Informative References 498 [ISO10589] 499 International Organization for Standardization, 500 "Intermediate system to Intermediate system intra-domain 501 routeing information exchange protocol for use in 502 conjunction with the protocol for providing the 503 connectionless-mode Network Service (ISO 8473)", ISO/ 504 IEC 10589:2002, Second Edition, Nov 2002. 506 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 507 DOI 10.17487/RFC2328, April 1998, 508 . 510 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 511 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 512 2006, . 514 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 515 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 516 Provider Edge Routers (6PE)", RFC 4798, 517 DOI 10.17487/RFC4798, February 2007, 518 . 520 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 521 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 522 . 524 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 525 and K. Kumaki, "Distribution of Diverse BGP Paths", 526 RFC 6774, DOI 10.17487/RFC6774, November 2012, 527 . 529 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 530 S. Ray, "North-Bound Distribution of Link-State and 531 Traffic Engineering (TE) Information Using BGP", RFC 7752, 532 DOI 10.17487/RFC7752, March 2016, 533 . 535 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 536 "Advertisement of Multiple Paths in BGP", RFC 7911, 537 DOI 10.17487/RFC7911, July 2016, 538 . 540 Appendix A. Appendix: alternative solutions with limited applicability 542 One possible valid solution or workaround to the best path selection 543 problem requires sending all domain external paths from the route 544 reflector to all its clients. This approach suffers the significant 545 drawback of pushing a large amount of BGP state and churn to all edge 546 routers. Many networks receive full Internet routing information in 547 a large number of locations. This could easily result in tens of 548 paths for each prefix that would need to be distributed to clients. 550 Notwithstanding this drawback, there are a number of reasons for 551 sending more than just the single best path to the clients. Improved 552 path diversity at the edge is a requirement for fast connectivity 553 restoration, and a requirement for effective BGP level load 554 balancing. 556 In practical terms, add/diverse path deployments [RFC7911] [RFC6774] 557 are expected to result in the distribution of 2, 3, or n (where n is 558 a small number) good paths rather than all domain external paths. 559 When the route reflector chooses one set of n paths and distributes 560 them to all its route reflector clients, those n paths may not be the 561 right n paths for all clients. In the context of the problem 562 described above, those n paths will not necessarily include the 563 closest exit point out of the network for each route reflector 564 client. The mechanisms proposed in this document are likely to be 565 complementary to mechanisms aimed at improving path diversity. 567 Another possibility to optimize exit point selection is the 568 implementation of distributed route reflector functionality at key 569 IGP locations in order to ensure that these locations see their 570 viewpoints respected in exit selection. Typically, however, this 571 requires the installation of physical nodes to implement the 572 reflection, and if exit policy subsequently changes, the reflector 573 placement and position can become inappropriate. 575 To counter the burden of physical installation, it is possible to 576 build a logical overlay of tunnels with appropriate IGP metrics in 577 order to simulate closeness to key locations required to implement 578 exit policy. There is significant complexity overhead in this 579 approach, however, enough so to typically make it undesirable. 581 Trends in control plane decoupling are causing a shift from 582 traditional routers to compute virtualization platforms, or even 583 third-party cloud platforms. As a result, without this proposal, 584 operators are left with a difficult choice for the distribution and 585 reflection of address families with significant exit diversity: 587 o centralized path selection, and tolerate the associated suboptimal 588 paths, or 590 o defer selection to end clients, but lose potential route scale 591 capacity 593 The latter can be a viable option, but it is clearly a decision that 594 needs to be made on an application and address family basis, with 595 strong consideration for the number of available paths per prefix 596 (which may even vary per prefix range, depending on peering policy, 597 e.g. consider bilateral peerings versus onward transit arrangements) 599 Authors' Addresses 601 Robert Raszuk (editor) 602 NTT Network Innovations 604 Email: robert@raszuk.net 606 Christian Cassar 607 Tesla 608 43 Avro Way 609 Weybridge KT13 0XY 610 UK 612 Email: ccassar@tesla.com 613 Erik Aman 615 Email: erik.aman@aman.se 617 Bruno Decraene (editor) 618 Orange 620 Email: bruno.decraene@orange.com 622 Kevin Wang 623 Juniper Networks 624 10 Technology Park Drive 625 Westford, MA 01886 626 USA 628 Email: kfwang@juniper.net