idnits 2.17.1 draft-ietf-idr-route-oscillation-stop-04.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 (August 8, 2016) is 2818 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Walton 3 Internet-Draft Cumulus Networks 4 Intended status: Standards Track A. Retana 5 Expires: February 9, 2017 E. Chen 6 Cisco Systems, Inc. 7 J. Scudder 8 Juniper Networks 9 August 8, 2016 11 BGP Persistent Route Oscillation Solutions 12 draft-ietf-idr-route-oscillation-stop-04 14 Abstract 16 The routing information reduction by BGP Route Reflection or 17 Confederation can result in persistent internal BGP route 18 oscillations with certain routing setup and network topologies. This 19 document specifies two sets of additional paths that can be used to 20 eliminate these route oscillations in a network. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 9, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Advertise All the Available Paths . . . . . . . . . . . . . . 3 59 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 60 5. Route Reflection and Confederation . . . . . . . . . . . . . 4 61 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 4 62 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 10.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 As documented in [RFC3345], the routing information reduction by BGP 76 Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result 77 in persistent IBGP route oscillations with certain routing setup and 78 network topologies. Except for a couple artificially engineered 79 network topologies, the MULTI_EXIT_DISC attribute (MED) [RFC4271] has 80 played a pivotal role in virtually all of the known persistent IBGP 81 route oscillations. For the sake of brevity, we use the term "MED- 82 induced route oscillation" hereafter to refer to a persistent IBGP 83 route oscillation in which the MED plays a role. 85 In order to eliminate the MED-induced route oscillations and to 86 achieve consistent routing in a network, a route reflector or a 87 confederation ASBR needs to advertise more than just the best path 88 for an address prefix. Our goal is to identify the necessary set of 89 paths for an address prefix that needs to be advertised by a route 90 reflector or a confederation ASBR to prevent the condition. 92 In this document we describe two sets of paths for an address prefix 93 that can be advertised by a BGP route reflector or confederation ASBR 94 to eliminate the MED-induced route oscillations in a network. The 95 first set involves all the available paths, and would achieve the 96 same routing consistency as the full IBGP mesh. The second set, 97 which is a subset of the first one, involves the neighbor-AS based 98 Group Best Paths, and would be sufficient to eliminate the MED- 99 induced route oscillations (subject to certain commonly adopted 100 topological constraints). 102 These paths can be advertised using the mechanism described in ADD- 103 PATH [RFC7911] for advertising multiple paths. No other assumptions 104 in functionality beyond the base BGP specification [RFC4271] are 105 made. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Advertise All the Available Paths 115 Observe that in a network that maintains a full IBGP mesh all the BGP 116 speakers have consistent and equivalent routing information. Such a 117 network is thus free of the MED-induced route oscillations and other 118 routing inconsistencies such as forwarding loops. 120 Therefore one approach is to allow a route reflector or a 121 confederation ASBR to advertise all the available paths for an 122 address prefix. Clearly this approach would yield the same amount of 123 routing information and achieve the same routing consistency as the 124 full IBGP mesh in a network. 126 This approach can be implemented using the mechanism described in 127 ADD-PATH [RFC7911] for advertising multiple paths for certain 128 prefixes. 130 For the sake of scalability the advertisement of multiple paths 131 should be limited to those prefixes which are affected by MED-induced 132 route oscillation in a network carrying a large number of alternate 133 paths. A detailed description of how these oscillations can occur 134 can be found in [RFC3345]; the description of how a node would 135 locally detect such condition is outside the scope of this document. 137 4. Advertise the Group Best Paths 139 The term neighbor-AS for a route refers to the neighboring AS from 140 which the route was received. The calculation of the neighbor-AS is 141 specified in Section 9.1.2.2 of [RFC4271], and Section 7.2 of 142 [RFC5065]. By definition the MED is comparable only among routes 143 with the same neighbor-AS. Thus the route selection procedures 144 specified in [RFC4271] would conceptually involve two steps: first 145 organize the paths for an address prefix into groups according to 146 their respective neighbor-AS's, and calculate the most preferred one 147 (termed "Group Best Path") for each of the groups; Then calculate the 148 overall best path among all the Group Best Paths. 150 As a generally recommended ([RFC4456], [RFC5065]) and widely adopted 151 practice, a route reflection cluster or a confederation sub-AS should 152 be designed such that BGP routes from within the cluster (or 153 confederation sub-AS) are preferred over routes from other clusters 154 (or confederation sub-AS) when the decision is based on the IGP cost 155 to the BGP NEXT_HOP. This is typically done by setting IGP metrics 156 for links within a cluster (or confederation sub-AS) to be much 157 smaller than the IGP metrics for the links between the clusters (or 158 confederation sub-AS). This practice helps achieve consistent 159 routing within a route reflection cluster or a confederation sub-AS. 161 When the aforementioned practice for devising a route reflection 162 cluster or confederation sub-AS is followed in a network, we claim 163 that the advertisement of all the Group Best Paths by a route 164 reflector or a confederation ASBR is sufficient to eliminate the MED- 165 induced route oscillations in the network. This claim is validated 166 in Appendix A. 168 Note that a Group Best Path for an address prefix can be identified 169 by the combination of the address prefix and the neighbor-AS. Thus 170 this approach can be implemented using the mechanism described in 171 ADD-PATH [RFC7911] for advertising multiple paths, and in this case 172 the neighbor-AS of a path may be used as the path identifier of the 173 path. 175 It should be noted that the approach of advertising the Group Best 176 Paths requires certain topological constraints to be satisfied in 177 order to eliminate the MED-induced route oscillation. Specific 178 topological considerations are described in [RFC3345]. 180 5. Route Reflection and Confederation 182 To allow a route reflector or a confederation ASBR to advertise 183 either the Available Paths or Group Best Paths using the mechanism 184 described in ADD-PATH [RFC7911], the following revisions are proposed 185 for BGP route reflection and BGP Confederation. 187 5.1. Route Reflection 189 For a particular a route reflector MUST include the with the "Send/Receive" field set to 2 (send multiple paths) or 191 3 (send/receive multiple paths) in the ADD-PATH Capability [RFC7911] 192 advertised to an IBGP peer. When the ADD-PATH Capability is also 193 received from the IBGP peer with the "Send/Receive" field set to 1 194 (receive multiple paths) or 3 (send/receive multiple paths) for the 195 same , then the following procedures apply: 197 If the peer is a route reflection client, the route reflector MUST 198 advertise to the peer the Group Best Paths (or the Available Paths) 199 received from its non-client IBGP peers. The route reflector MAY 200 also advertise to the peer the Group Best Paths (or the Available 201 Paths) received from its clients. 203 If the peer is a non-client, the route reflector MUST advertise to 204 the peer the Group Best Paths (or the Available Paths) received from 205 its clients. 207 5.2. Confederation 209 For a particular a confederation ASBR MUST include the 210 with the "Send/Receive" field set to 2 (send multiple 211 paths) or 3 (send/receive multiple paths) in the ADD-PATH Capability 212 [RFC7911] advertised to an IBGP peer, and to a confederation external 213 peer. When the ADD-PATH Capability is also received from the IBGP 214 peer or the confederation external peer with the "Send/Receive" field 215 set to 1 (receive multiple paths) or 3 (send/receive multiple paths) 216 for the same , then the following procedures apply: 218 If the peer is internal, the confederation ASBR MUST advertise to the 219 peer the Group Best Paths (or the Available Paths) received from its 220 confederation external peers. 222 If the peer is confederation external, the confederation ASBR MUST 223 advertise to the peer the Group Best Paths (or the Available Paths) 224 received from its IBGP peers. 226 6. Deployment Considerations 228 Some route oscillations, once detected, can be eliminated by simple 229 configuration workarounds. As carrying additional paths impacts the 230 memory usage and routing convergence in a network, it is recommended 231 that the impact be evaluated and the approach of using a 232 configuration workaround be considered in deciding whether to deploy 233 the proposed mechanism in a network. In addition, the advertisement 234 of multiple paths should be limited to those prefixes which are 235 affected by MED-induced route oscillation. 237 While the route reflectors or confederation ASBRs in a network need 238 to advertise the Group Best Paths or Available Paths, the vast 239 majority of the BGP speakers in the network only need to receive the 240 Group Best Paths or Available Paths, which would involve only minor 241 software changes. 243 It should be emphasized that in order to eliminate the MED-induced 244 route oscillations in a network using the approach of advertising the 245 Group Best Paths, the recommended practice for devising a route 246 reflection cluster or confederation sub-AS with respect to the IGP 247 metrics ([RFC4456], [RFC5065]) should be followed. 249 It is expected that the approach of advertising the Group Best Paths 250 would be adequate to achieve consistent routing for the vast majority 251 of the networks. For a network that has large number of alternate 252 paths, the approach should be a good choice as the number of paths 253 advertised by a reflector or a confederation ASBR is bounded by the 254 number of the neighbor-AS's for a particular address prefix. The 255 additional states for an address prefix would also be per neighbor-AS 256 based rather than per path based. The number of the neighbor-AS's 257 for a particular address prefix is typically small because of the 258 limited number of upstream providers for a customer and the nature of 259 advertising only customer routes at the inter-exchange points. 261 The approach of advertising the Group Best Paths, however, may still 262 be inadequate for certain networks to avoid other routing 263 inconsistencies such as forwarding loops. The required topological 264 constraints could also be operationally challenging. In these cases 265 the approach of advertising the Available Paths may be used, but 266 should be limited to those prefixes which are affected by MED-induced 267 route oscillation in a network carrying a large number of alternate 268 paths. 270 7. IANA Considerations 272 This memo includes no request to IANA. 274 8. Security Considerations 276 This extension to BGP does not change the underlying security issues 277 inherent in the existing BGP [RFC4271]. 279 9. Acknowledgements 281 We would like to thank David Cook and Naiming Shen for their 282 contributions to the design and development of the solutions. 284 Many thanks to Tony Przygienda, Sue Hares, Jon Mitchell and Paul 285 Kyzivat for their helpful suggestions. 287 10. References 289 10.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 297 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 298 DOI 10.17487/RFC4271, January 2006, 299 . 301 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 302 Reflection: An Alternative to Full Mesh Internal BGP 303 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 304 . 306 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 307 System Confederations for BGP", RFC 5065, 308 DOI 10.17487/RFC5065, August 2007, 309 . 311 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 312 "Advertisement of Multiple Paths in BGP", RFC 7911, 313 DOI 10.17487/RFC7911, July 2016, 314 . 316 10.2. Informative References 318 [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, 319 "Border Gateway Protocol (BGP) Persistent Route 320 Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, 321 August 2002, . 323 Appendix A. Why the Group Best Paths Are Adequate? 325 It is assumed that the following common practice is followed. A 326 route reflection cluster or a confederation sub-AS should be designed 327 such that the IGP metrics for links within a cluster (or 328 confederation sub-AS) are much smaller than the IGP metrics for the 329 links between the clusters (or confederation sub-AS). This practice 330 helps achieve consistent routing within a route reflection cluster or 331 a confederation sub-AS. 333 Observe that in a network that maintains full IBGP mesh only the 334 paths that survive the (Local_Pref, AS-PATH Length, Origin, MED) 335 comparisons [RFC4271] would contribute to the route selection in the 336 network. 338 Consider a route reflection cluster that sources one or more paths 339 that would survive the (Local_Pref, AS-PATH Length, Origin, MED) 340 comparisons among all the paths in the network. One of these 341 surviving paths would be selected as the Group Best Path by the route 342 reflector in the cluster. Due to the constrain on the IGP metrics as 343 described previously, this path would remain as the Group Best Path 344 and would be advertised to all other clusters even after a path is 345 received from another cluster. 347 On the other hand, when no path in a route reflection cluster would 348 survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons 349 among all the paths in the network, the Group Best Path (when exists) 350 for a route reflector would be from another cluster. Clearly the 351 advertise of the Group Best Path by the route reflector to the 352 clients only depends on the paths received from other clusters. 354 Therefore there is no MED-induced route oscillation in the network as 355 the advertisement of a Group Best Path to a peer does not depend on 356 the paths received from that peer. 358 The claim for the confederation can be validated similarly. 360 Authors' Addresses 362 Daniel Walton 363 Cumulus Networks 364 140C S. Whisman Rd. 365 Mountain View, CA 94041 366 USA 368 Email: dwalton@cumulusnetworks.com 370 Alvaro Retana 371 Cisco Systems, Inc. 372 7025 Kit Creek Rd. 373 Research Triangle Park, NC 27709 374 USA 376 Email: aretana@cisco.com 377 Enke Chen 378 Cisco Systems, Inc. 379 170 W. Tasman Dr. 380 San Jose, CA 95134 381 USA 383 Email: enkechen@cisco.com 385 John Scudder 386 Juniper Networks 387 1194 N. Mathilda Ave 388 Sunnyvale, CA 94089 389 USA 391 Email: jgs@juniper.net