idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-11.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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 8, 2016) is 3031 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: 'RFC2119' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 403, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-add-paths' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC1998' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC4384' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC4893' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC5283' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC5668' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RFC5714' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC6774' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-13 -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 16 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, 2016 Cisco Systems 6 E. Aman 7 TeliaSonera 8 B. Decraene 9 S. Litkowski 10 Orange 11 K. Wang 12 Juniper Networks 13 January 8, 2016 15 BGP Optimal Route Reflection (BGP-ORR) 16 draft-ietf-idr-bgp-optimal-route-reflection-11 18 Abstract 20 This document proposes a solution for BGP route reflectors to allow 21 them to choose the best path their clients would have chosen under 22 the same conditions, without requiring further state or any new 23 features to be placed on the clients. This facilitates, for example, 24 best exit point policy (hot potato routing). This solution is 25 primarily applicable in deployments using centralized route 26 reflectors. 28 The solution relies upon all route reflectors learning all paths 29 which are eligible for consideration. Best path selection is 30 performed in each route reflector based on a configured virtual 31 location in the IGP. The location can be the same for all clients or 32 different per peer/update group or per peer. Best path selection can 33 also be performed based on user configured policies in each route 34 reflector. 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 http://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 11, 2016. 53 Copyright Notice 55 Copyright (c) 2016 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 72 1.2. Existing/Alternative Solutions . . . . . . . . . . . . . 4 73 2. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Client's Perspective IGP Based Best Path Selection . . . 5 75 2.2. Client's Perspective Policy Based Best Path Selection . . 6 76 2.3. Solution Interactions . . . . . . . . . . . . . . . . . . 6 77 3. CPU and Memory Scalability . . . . . . . . . . . . . . . . . 7 78 4. Advantages and Deployment Considerations . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 There are three types of BGP deployments within Autonomous Systems 90 today: full mesh, confederations and route reflection. BGP route 91 reflection [RFC4456] is the most popular way to distribute BGP routes 92 between BGP speakers belonging to the same Autonomous System. In 93 some situations, this method suffers from non-optimal path selection. 95 1.1. Problem Statement 97 [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) 98 cost to a given point in the network will vary across routers, "the 99 route reflection approach may not yield the same route selection 100 result as that of the full IBGP mesh approach." One practical 101 implication of this assertion is that the deployment of route 102 reflection may thwart the ability to achieve hot potato routing. Hot 103 potato routing attempts to direct traffic to the best AS exit point 104 in cases where no higher priority policy dictates otherwise. As a 105 consequence of the route reflection method, the choice of exit point 106 for a route reflector and its clients will be the exit point best for 107 the route reflector - not necessarily the one best for the RR 108 clients. 110 Section 11 of [RFC4456] describes a deployment approach and a set of 111 constraints which, if satisfied, would result in the deployment of 112 route reflection yielding the same results as the iBGP full mesh 113 approach. This deployment approach makes route reflection compatible 114 with the application of hot potato routing policy. In accordance 115 with these design rules, route reflectors have traditionally often 116 been deployed in the forwarding path and carefully placed on the POP 117 to core boundaries. 119 The evolving model of intra-domain network design has enabled 120 deployments of route reflectors outside of the forwarding path. 121 Initially this model was only employed for new address families, e.g. 122 L3VPNs and L2VPNs. This model has been gradually extended to other 123 BGP address families including IPv4 and IPv6 Internet using either 124 native routing or 6PE. In such environments, hot potato routing 125 policy remains desirable. 127 Route reflectors outside of the forwarding path can be placed on the 128 POP to core boundaries, but they are often placed in arbitrary 129 locations in the core of large networks. 131 Such deployments suffer from a critical drawback in the context of 132 best path selection: A route reflector with knowledge of multiple 133 paths for a given prefix will typically pick its best path and only 134 advertise that best path to its clients. If the best path for a 135 prefix is selected on the basis of an IGP tie break, the path 136 advertised will be the exit point closest to the route reflector. 137 But the clients will be in a different place in the network topology 138 than the route reflector. In networks where the route reflectors are 139 not in the forwarding path, this difference will be even more acute. 140 Beside this, there are also deployment scenarios where service 141 providers want to have more control of choosing the exit points for 142 clients based on other factors like traffic type, traffic load, etc. 144 This further complicated the issue and makes it less likely for the 145 route reflector to select the best path from the client's 146 perspective. It follows that the best path chosen by the route 147 reflector is not necessarily the same as the path which would have 148 been chosen by the client if the client had considered the same set 149 of candidate paths as the route reflector. 151 1.2. Existing/Alternative Solutions 153 One possible valid solution or workaround to the best path selection 154 problem requires sending all domain external paths from the RR to all 155 its clients. This approach suffers the significant drawback of 156 pushing a large amount of BGP state to all edge routers. Many 157 networks receive full Internet routing information in a large number 158 of locations. This could easily result in tens of paths for each 159 prefix that would need to be distributed to clients. 161 Notwithstanding this drawback, there are a number of reasons for 162 sending more than just the single best path to the clients. Improved 163 path diversity at the edge is a requirement for fast connectivity 164 restoration, and a requirement for effective BGP level load 165 balancing. 167 In practical terms, add/diverse path deployments are expected to 168 result in the distribution of 2, 3 or n (where n is a small number) 169 'good' paths rather than all domain external paths. While the route 170 reflector chooses one set of n paths and distributes those same n 171 paths to all its route reflector clients, those n paths may not be 172 the right n paths for all clients. In the context of the problem 173 described above, those n paths will not necessarily include the best 174 exit point out of the network for each route reflector client. The 175 mechanisms proposed in this document are likely to be complementary 176 to mechanisms aimed at improving path diversity. 178 2. Proposed Solutions 180 The goal of this document is to allow a route reflector to choose the 181 best path the client would have chosen had the client considered the 182 same set of candidate paths the reflector has available. For 183 purposes of route selection, the perspective of a client can differ 184 from that of a route reflector or another client in two distinct 185 ways: it can, and usually will, have a different position in the IGP 186 topology, and it can have a different routing policy. These 187 correspond to the issues described earlier. Accordingly, we propose 188 two distinct modifications to the best path algorithm, to address 189 these two distinct factors. A route reflector can implement either 190 or both of the modifications, as needed in order to allow it to 191 choose the best path the client would have chosen had the client 192 considered the same set of candidate paths. 194 Both modifications rely upon all route reflectors learning all paths 195 which are eligible for consideration. In order to satisfy this 196 requirement, path diversity enhancing mechanisms such as ADD-PATH/ 197 diverse paths may need to be deployed between route reflectors. 199 A significant advantage of these approaches is that the RR clients do 200 not need to run new software or hardware. 202 2.1. Client's Perspective IGP Based Best Path Selection 204 The core of this solution is the ability for an operator to specify 205 on a per route reflector basis or per peer/update group basis or per 206 peer basis the virtual IGP location placement of the route reflector. 207 This enables having a given group of clients receive routes with 208 optimal distance to the next hops from the position of the configured 209 virtual IGP location. This also provides for freedom of route 210 reflector location and allows transient or permanent migration of 211 such network control plane function to optimal location. 213 The choice of specific granularity is left to the implementation 214 decision. An implementation is considered compliant with the 215 document if it supports at least one listed grouping of virtual IGP 216 placement. 218 In this document we refer to optimal as the decision made during best 219 path selection at the IGP metric to BGP next hop comparison step. 220 This approach does not apply to path selection preference based other 221 policy steps and provisions. 223 The computation of the virtual IGP location with any of the above 224 described granularity is outside of the scope of this document. The 225 operator may configure it manually, implementation may automate it 226 based on specified heuristic or it can be computed centrally and 227 configured by an external system. 229 The solution does not require any BGP or IGP protocol changes as 230 required changes are contained within the RR implementation. 232 The solution applies to NLRIs of all address families which can be 233 route reflected. 235 2.2. Client's Perspective Policy Based Best Path Selection 237 Optimal route reflection based on virtual IGP location could reflect 238 the best path to the client from IGP cost perspective. However, 239 there are also cases where the client might want best path from 240 perspectives beyond IGP cost. Examples include, but not limited to: 242 o Select the best path for the clients from a traffic engineering 243 perspective. 245 o Dedicate certain exit points for certain ingress points. 247 The solution proposed here is to allow the user to apply a general 248 policy to select a subset of exit points as the candidate exit points 249 for its clients. For a given client, the policy should also allow 250 service providers to select different candidate exit points for 251 different address families. Regular path selection, including 252 client's perspective IGP based best path selection stated above, will 253 be applied to the candidate paths to select the final paths to 254 advertise to the clients. 256 The policy is applied on the route reflector on behalf of its 257 clients. This way, the route reflector will be able to reflect only 258 the optimal paths to the clients. An additional advantage of this 259 approach is that configuration need only be done on a small number of 260 route reflectors rather than a significantly larger number of 261 clients. 263 2.3. Solution Interactions 265 Depending on the actual deployment scenarios, service providers may 266 configure IGP based optimal route reflection or policy based optimal 267 route reflection. It's also possible to configure both approaches 268 together. In that case, policy based optimal route reflection will 269 be applied first to select the candidate paths. Subsequently, IGP 270 based optimal route reflection will be applied on top of the 271 candidate paths to select the final path to advertise to the client. 273 The expected use case for optimal route reflection is to avoid 274 reflecting all paths to the client because the client either does not 275 support add-paths or does not have the capacity to process all of the 276 paths. Typically the route reflector would just reflect a single 277 optimal route to the client. However, the solutions MUST NOT prevent 278 reflecting more than one optimal path to the client; the client may 279 want path diversity for load balancing or fast restoration. In case 280 add-path and optimal route reflection are configured together, the 281 route reflector MUST reflect n optimal paths to a client, where n is 282 the add-path count. 284 The most complicated scenario is where add-path is configured 285 together with both IGP based and policy based optimal route 286 reflection. In this scenario, the policy based optimal route 287 reflection will be applied first to select the candidate paths. 288 Subsequently, IGP based optimal route reflection will be applied on 289 top of the candidate paths to select the best n paths to advertise to 290 the client. 292 In IGP based optimal route reflection, even though the virtual IGP 293 location could be specified on a per route reflector basis or per 294 peer group basis or per peer basis, in reality, it's most likely to 295 be specified per peer group basis. All clients with the same or 296 similar IGP location can be grouped into the same peer group. A 297 virtual IGP location is then specified for the peer group. The 298 virtual location is usually specified as the location of one of the 299 clients from the peer group or an ABR to the area where clients are 300 located. Also, one or more backup virtual location SHOULD be allowed 301 to be specified for redundancy. Implementations may wish to take 302 advantage of peer group mechanisms in order to provide for better 303 scalability of optimal route reflector client groups with similar 304 properties. 306 3. CPU and Memory Scalability 308 For IGP based optimal route reflection, determining the shortest path 309 and associated cost between any two arbitrary points in a network 310 based on the IGP topology learned by a router is expected to add some 311 extra cost in terms of CPU resources. However SPF tree generation 312 code is now implemented efficiently in a number of implementations, 313 and therefore this is not expected to be a major drawback. The 314 number of SPTs computed is expected to be of the order of the number 315 of clients of an RR whenever a topology change is detected. Advanced 316 optimizations like partial and incremental SPF may also be exploited. 317 The number of SPTs computed is expected to be higher but comparable 318 to some existing deployed features such as (Remote) Loop Free 319 Alternate which computes a (r)SPT per IGP neighbor. 321 For policy based optimal route reflection, there will be some 322 overhead to apply the policy to select the candidate paths. This 323 overhead is comparable to existing BGP export policies therefore 324 should be manageable. 326 By the nature of route reflection, the number of clients can be split 327 arbitrarily by the deployment of more route reflectors for a given 328 number of clients. While this is not expected to be necessary in 329 existing networks with best in class route reflectors available 330 today, this avenue to scaling up the route reflection infrastructure 331 would be available. 333 If we consider the overall network wide cost/benefit factor, the only 334 alternative to achieve the same level of optimality would require 335 significantly increasing state on the edges of the network. This 336 will consume CPU and memory resources on all BGP speakers in the 337 network. Building this client perspective into the route reflectors 338 seems appropriate. 340 4. Advantages and Deployment Considerations 342 The solutions described provide a model for integrating the client 343 perspective into the best path computation for RRs. More 344 specifically, the choice of BGP path factors in either the IGP cost 345 between the client and the nexthop (rather than the distance from the 346 RR to the nexthop) or user configured policies. 348 These solutions can be deployed in traditional hop-by-hop forwarding 349 networks as well as in end-to-end tunneled environments. In the 350 networks where there are multiple route reflectors and hop-by-hop 351 forwarding without encapsulation, such optimizations should be 352 enabled in a consistent way on all route reflectors. Otherwise 353 clients may receive an inconsistent view of the network and in turn 354 lead to intra-domain forwarding loops. 356 With this approach, an ISP can effect a hot potato routing policy 357 even if route reflection has been moved from the forwarding plane and 358 hop-by-hop switching has been replaced by end-to-end MPLS or IP 359 encapsulation. 361 As per above, these approaches reduce the amount of state which needs 362 to be pushed to the edge of the network in order to perform hot 363 potato routing. The memory and CPU resource required at the edge of 364 the network to provide hot potato routing using these approaches is 365 lower than what would be required in order to achieve the same level 366 of optimality by pushing and retaining all available paths 367 (potentially 10s) per each prefix at the edge. 369 The proposals allow for a fast and safe transition to a BGP control 370 plane with centralized route reflection without compromising an 371 operator's closest exit operational principle. This enables edge-to- 372 edge LSP/IP encapsulation for traffic to IPv4 and IPv6 prefixes. 374 Regarding the client's IGP best-path selection, it should be self 375 evident that this solution does not interfere with policies enforced 376 above IGP tie breaking in the BGP best path algorithm. 378 5. Security Considerations 380 No new security issues are introduced to the BGP protocol by this 381 specification. 383 6. IANA Considerations 385 This document does not request any IANA allocations. 387 7. Acknowledgments 389 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 390 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 391 Mitchell, John Scudder, Jeff Haas, and Martin Djernaes for their 392 valuable input. 394 8. References 396 8.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 404 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 405 DOI 10.17487/RFC4271, January 2006, 406 . 408 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 409 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 410 February 2006, . 412 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 413 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 414 2009, . 416 8.2. Informative References 418 [I-D.ietf-idr-add-paths] 419 Walton, D., Retana, A., Chen, E., and J. Scudder, 420 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 421 add-paths-13 (work in progress), December 2015. 423 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 424 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 425 . 427 [RFC1998] Chen, E. and T. Bates, "An Application of the BGP 428 Community Attribute in Multi-home Routing", RFC 1998, 429 DOI 10.17487/RFC1998, August 1996, 430 . 432 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 433 RFC 4384, DOI 10.17487/RFC4384, February 2006, 434 . 436 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 437 Reflection: An Alternative to Full Mesh Internal BGP 438 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 439 . 441 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 442 Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, 443 . 445 [RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension 446 for Inter-Area Label Switched Paths (LSPs)", RFC 5283, 447 DOI 10.17487/RFC5283, July 2008, 448 . 450 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 451 Specific BGP Extended Community", RFC 5668, 452 DOI 10.17487/RFC5668, October 2009, 453 . 455 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", 456 RFC 5714, DOI 10.17487/RFC5714, January 2010, 457 . 459 [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., 460 and K. Kumaki, "Distribution of Diverse BGP Paths", 461 RFC 6774, DOI 10.17487/RFC6774, November 2012, 462 . 464 Authors' Addresses 466 Robert Raszuk (editor) 467 Bloomberg LP 468 731 Lexington Ave 469 New York City, NY 10022 470 USA 472 Email: robert@raszuk.net 473 Christian Cassar 474 Cisco Systems 475 10 New Square Park 476 Bedfont Lakes, FELTHAM TW14 8HA 477 UK 479 Email: ccassar@cisco.com 481 Erik Aman 482 TeliaSonera 483 Marbackagatan 11 484 Farsta SE-123 86 485 Sweden 487 Email: erik.aman@teliasonera.com 489 Bruno Decraene 490 Orange 491 38-40 rue du General Leclerc 492 Issy les Moulineaux cedex 9 92794 493 France 495 Email: bruno.decraene@orange.com 497 Stephane Litkowski 498 Orange 499 9 rue du chene germain 500 Cesson Sevigne 35512 501 France 503 Email: stephane.litkowski@orange.com 505 Kevin Wang 506 Juniper Networks 507 10 Technology Park Drive 508 Westford, MA 01886 509 USA 511 Email: kfwang@juniper.net