idnits 2.17.1 draft-ietf-idr-bgp-optimal-route-reflection-23.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2021) is 1080 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 (~~), 2 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 NTT Network Innovations 4 Intended status: Standards Track C. Cassar 5 Expires: November 13, 2021 Tesla 6 E. Aman 8 B. Decraene, Ed. 9 Orange 10 K. Wang 11 Juniper Networks 12 May 12, 2021 14 BGP Optimal Route Reflection (BGP-ORR) 15 draft-ietf-idr-bgp-optimal-route-reflection-23 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 route from the standpoint of their clients, rather than from the 22 standpoint of the route reflectors. Depending on the scaling and 23 precision requirements, route selection can be specific for one 24 client, common for a set of clients or common for all clients of a 25 route reflector. This solution is particularly applicable in 26 deployments using centralized route reflectors, where choosing the 27 best route based on the route reflector's IGP location is suboptimal. 28 This 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. BGP Route Selection is 33 performed in the route reflectors based on the IGP cost from 34 configured locations 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 November 13, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Modifications to BGP Route Selection . . . . . . . . . . . . 4 73 3.1. Route Selection from a different IGP location . . . . . . 5 74 3.1.1. Restriction when BGP next hop is a BGP prefix . . . . 6 75 3.2. Multiple Route Selections . . . . . . . . . . . . . . . . 6 76 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 9.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 There are three types of BGP deployments within Autonomous Systems 89 today: full mesh, confederations and route reflection. BGP route 90 reflection [RFC4456] is the most popular way to distribute BGP routes 91 between BGP speakers belonging to the same Autonomous System. 92 However, in some situations, this method suffers from non-optimal 93 path selection. 95 [RFC4456] asserts that, because the IGP cost to a given point in the 96 network will vary across routers, "the route reflection approach may 97 not yield the same route selection result as that of the full IBGP 98 mesh approach." One practical implication of this assertion is that 99 the deployment of route reflection may thwart the ability to achieve 100 hot potato routing. Hot potato routing attempts to direct traffic to 101 the closest AS exit point in cases where no higher priority policy 102 dictates otherwise. As a consequence of the route reflection method, 103 the choice of exit point for a route reflector and its clients will 104 be the exit point that is optimal for the route reflector - not 105 necessarily the one that is optimal for its clients. 107 Section 11 of [RFC4456] describes a deployment approach and a set of 108 constraints which, if satisfied, would result in the deployment of 109 route reflection yielding the same results as the IBGP full mesh 110 approach. This deployment approach makes route reflection compatible 111 with the application of hot potato routing policy. In accordance 112 with these design rules, route reflectors have often been deployed in 113 the forwarding path and carefully placed on the POP to core 114 boundaries. 116 The evolving model of intra-domain network design has enabled 117 deployments of route reflectors outside of the forwarding path. 118 Initially this model was only employed for new services, e.g. IP 119 VPNs [RFC4364], however it has been gradually extended to other BGP 120 services including IPv4 and IPv6 Internet. In such environments, hot 121 potato routing policy remains desirable. 123 Route reflectors outside of the forwarding path can be placed on the 124 POP to core boundaries, but they are often placed in arbitrary 125 locations in the core of large networks. 127 Such deployments suffer from a critical drawback in the context of 128 BGP Route Selection: A route reflector with knowledge of multiple 129 paths for a given prefix will typically pick its best path and only 130 advertise that best path to its clients. If the best path for a 131 prefix is selected on the basis of an IGP tie-break, the path 132 advertised will be the exit point closest to the route reflector. 133 However, the clients are in a different place in the network topology 134 than the route reflector. In networks where the route reflectors are 135 not in the forwarding path, this difference will be even more acute. 137 In addition, there are deployment scenarios where service providers 138 want to have more control in choosing the exit points for clients 139 based on other factors, such as traffic type, traffic load, etc. 140 This further complicates the issue and makes it less likely for the 141 route reflector to select the best path from the client's 142 perspective. It follows that the best path chosen by the route 143 reflector is not necessarily the same as the path which would have 144 been chosen by the client if the client had considered the same set 145 of candidate paths as the route reflector. 147 2. Terminology 149 This memo makes use of the terms defined in [RFC4271] and [RFC4456]. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Modifications to BGP Route Selection 159 The core of this solution is the ability for an operator to specify 160 the IGP location for which the route reflector calculates interior 161 cost for the NEXT_HOP. The IGP location is defined as a node in the 162 IGP topology and may be configured on a per route reflector basis, 163 per set of clients, or per client basis. This ability enables the 164 route reflector to send to a given set of clients routes with 165 shortest distance to the next hops from the position of the selected 166 IGP location. This provides for freedom of route reflector physical 167 location, and allows transient or permanent migration of this network 168 control plane function to an arbitrary location. 170 The choice of specific granularity (route reflector, set of clients, 171 or client) is configured by the network operator. An implementation 172 is considered compliant with this document if it supports at least 173 one listed grouping of IGP location. 175 For purposes of route selection, the perspective of a client can 176 differ from that of a route reflector or another client in two 177 distinct ways: 179 o it has a different position in the IGP topology, and 181 o it can have a different routing policy. 183 These factors correspond to the issues described earlier. 185 This document defines, for BGP Route Reflectors [RFC4456], two 186 changes to the BGP Route Selection algorithm: 188 o The first change, introduced in Section 3.1, is related to the IGP 189 cost to the BGP Next Hop in the BGP decision process. The change 190 consists in using the IGP cost from a different IGP location than 191 the route reflector itself. 193 o The second change, introduced in Section 3.2, is to extend the 194 granularity of the BGP decision process, to allow for running 195 multiple decisions processes using different perspective or 196 policies. 198 A significant advantage of these approaches is that the route 199 reflector clients do not need to be modified. 201 3.1. Route Selection from a different IGP location 203 In this approach, optimal refers to the decision where the interior 204 cost of a route is determined during step e) of [RFC4271] section 205 9.1.2.2 "Breaking Ties (Phase 2)". It does not apply to path 206 selection preference based on other policy steps and provisions. 208 In addition to the change specified in [RFC4456] section 9, [RFC4271] 209 section 9.1.2.2 is modified as follows. 211 The below text in step e) 213 e) Remove from consideration any routes with less-preferred 214 interior cost. The interior cost of a route is determined by 215 calculating the metric to the NEXT_HOP for the route using the 216 Routing Table. 218 ...is replaced by this new text: 220 e) Remove from consideration any routes with less-preferred 221 interior cost. The interior cost of a route is determined by 222 calculating the metric from the selected IGP location to the 223 NEXT_HOP for the route using the shortest IGP path tree rooted at 224 the selected IGP location. 226 In order to be able to compute the shortest path tree rooted at the 227 selected IGP locations, knowledge of the IGP topology for the area/ 228 level that includes each of those locations is needed. This 229 knowledge can be gained with the use of the link state IGP such as 230 IS-IS [ISO10589] or OSPF [RFC2328] [RFC5340] or via BGP-LS [RFC7752]. 232 The way the IGP location is configured is outside the scope of this 233 document. The operator may configure it manually, an implementation 234 may automate it based on heuristics, or it can be computed centrally 235 and configured by an external system. One or more backup locations 236 SHOULD be allowed to be specified for redundancy. 238 3.1.1. Restriction when BGP next hop is a BGP prefix 240 In situations where the BGP next hop is a BGP prefix itself, the IGP 241 metric of a route used for its resolution SHOULD be the final IGP 242 cost to reach such next hop. Implementations which can not inform 243 BGP of the final IGP metric to a recursive next hop MUST treat such 244 paths as least preferred during next hop metric comparison. However 245 such paths MUST still be considered valid for BGP Phase 2 Route 246 Selection. 248 3.2. Multiple Route Selections 250 BGP Route Reflector as per [RFC4456] runs a single BGP Decision 251 Process. Optimal route reflection may require multiple BGP Decision 252 Processes or subsets of the Decision Process in order to consider 253 different IGP locations or BGP policies for different sets of 254 clients. 256 If the required routing optimization is limited to the IGP cost to 257 the BGP Next-Hop, only step e) and below as defined [RFC4271] section 258 9.1.2.2, needs to be run multiple times. 260 If the routing optimization requires the use of different BGP 261 policies for different sets of clients, a larger part of the decision 262 process needs to be run multiple times, up to the whole decision 263 process as defined in section 9.1 of [RFC4271]. This is for example 264 the case when there is a need to use different policies to compute 265 different degree of preference during Phase 1. This is needed for 266 use cases involving traffic engineering or dedicating certain exit 267 points for certain clients. In the latter case, the user may specify 268 and apply a general policy on the route reflector for a set of 269 clients. Regular path selection, including IGP perspective for a set 270 of clients as per Section 3.1, is then applied to the candidate paths 271 to select the final paths to advertise to the clients. 273 A route reflector can implement either or both of the modifications 274 in 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 4. Deployment Considerations 280 BGP Optimal Route Reflection provides a model for integrating the 281 client perspective into the BGP Route Selection decision function for 282 route reflectors. More specifically, the choice of BGP path factors 283 in either the IGP cost between the client and the NEXT_HOP (rather 284 than the IGP cost from the route reflector to the NEXT_HOP) or other 285 user configured policies. 287 The achievement of optimal routing between clients of different 288 clusters relies upon all route reflectors learning all paths that are 289 eligible for consideration. In order to satisfy this requirement, 290 BGP add-path [RFC7911] needs to be deployed between route reflectors. 292 This solution can be deployed in traditional hop-by-hop forwarding 293 networks as well as in end-to-end tunneled environments. In networks 294 where there are multiple route reflectors and hop-by-hop forwarding 295 without encapsulation, such optimizations SHOULD be enabled in a 296 consistent way on all route reflectors. Otherwise, clients may 297 receive an inconsistent view of the network, in turn leading to 298 intra-domain forwarding loops. 300 As discussed in section 11 of [RFC4456], the IGP locations of BGP 301 route reflectors is important and has routing implications. This 302 equally applies to the choice of the IGP locations configured on 303 optimal route reflectors. After selecting suitable IGP locations, an 304 operator may let one or multiple route reflectors handle route 305 selection for all of them. The operator may alternatively deploy one 306 or multiple route reflector for each IGP location or create any 307 design in between. This choice may depend on operational model 308 (centralized vs per region), acceptable blast radius in case of 309 failure, acceptable number of IBGP sessions for the mesh between the 310 route reflectors, performance and configuration granularity of the 311 equipment. 313 With this approach, an ISP can effect a hot potato routing policy 314 even if route reflection has been moved out of the forwarding plane, 315 and hop-by-hop switching has been replaced by end-to-end MPLS or IP 316 encapsulation. Compared with a deployment of ADD-PATH on all 317 routers, BGP ORR reduces the amount of state which needs to be pushed 318 to the edge of the network in order to perform hot potato routing. 320 Modifying the IGP location of BGP ORR does not interfere with 321 policies enforced before IGP tie-breaking (step e) in the BGP 322 Decision Process Route. 324 Calculating routes for different IGP locations requires multiple SPF 325 calculations and multiple (subsets of) BGP Decision Processes, which 326 requires more computing resources. This document allows for 327 different granularity such as one Decision Process per route 328 reflector, per set of clients or per client. A more fine grained 329 granularity may translate into more optimal hot potato routing at the 330 cost of more computing power. The ability to run fine grained 331 computations depends on the platform/hardware deployed, the number of 332 clients, the number of BGP routes and the size of the IGP topology. 333 In essence, sizing considerations are similar to the deployments of 334 BGP Route Reflector. 336 5. Security Considerations 338 Similarly to [RFC4456], this extension to BGP does not change the 339 underlying security issues inherent in the existing IBGP. 341 This document does not introduce requirements for any new protection 342 measures. 344 6. IANA Considerations 346 This document does not request any IANA allocations. 348 7. Acknowledgments 350 Authors would like to thank Keyur Patel, Eric Rosen, Clarence 351 Filsfils, Uli Bornhauser, Russ White, Jakob Heitz, Mike Shand, Jon 352 Mitchell, John Scudder, Jeff Haas, Martin Djernaes, Daniele 353 Ceccarelli, Kieran Milne, Job Snijders and Randy Bush for their 354 valuable input. 356 8. Contributors 358 Following persons substantially contributed to the current format of 359 the document: 361 Stephane Litkowski 362 Cisco System 364 slitkows.ietf@gmail.com 366 Adam Chappell 367 GTT Communications, Inc. 368 Aspira Business Centre 369 Bucharova 2928/14a 370 158 00 Prague 13 Stodulky 371 Czech Republic 373 adam.chappell@gtt.net 375 9. References 377 9.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 385 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 386 DOI 10.17487/RFC4271, January 2006, 387 . 389 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 390 Reflection: An Alternative to Full Mesh Internal BGP 391 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 392 . 394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 396 May 2017, . 398 9.2. Informative References 400 [ISO10589] 401 International Organization for Standardization, 402 "Intermediate system to Intermediate system intra-domain 403 routeing information exchange protocol for use in 404 conjunction with the protocol for providing the 405 connectionless-mode Network Service (ISO 8473)", ISO/ 406 IEC 10589:2002, Second Edition, Nov 2002. 408 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 409 DOI 10.17487/RFC2328, April 1998, 410 . 412 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 413 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 414 2006, . 416 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 417 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 418 . 420 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 421 S. Ray, "North-Bound Distribution of Link-State and 422 Traffic Engineering (TE) Information Using BGP", RFC 7752, 423 DOI 10.17487/RFC7752, March 2016, 424 . 426 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 427 "Advertisement of Multiple Paths in BGP", RFC 7911, 428 DOI 10.17487/RFC7911, July 2016, 429 . 431 Authors' Addresses 433 Robert Raszuk (editor) 434 NTT Network Innovations 436 Email: robert@raszuk.net 438 Christian Cassar 439 Tesla 440 43 Avro Way 441 Weybridge KT13 0XY 442 UK 444 Email: ccassar@tesla.com 446 Erik Aman 448 Email: erik.aman@aman.se 450 Bruno Decraene (editor) 451 Orange 453 Email: bruno.decraene@orange.com 455 Kevin Wang 456 Juniper Networks 457 10 Technology Park Drive 458 Westford, MA 01886 459 USA 461 Email: kfwang@juniper.net