idnits 2.17.1 draft-walton-bgp-route-oscillation-stop-09.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 1 instance 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2014) is 3470 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) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: April 27, 2015 E. Chen 6 Cisco Systems, Inc. 7 J. Scudder 8 Juniper Networks 9 October 24, 2014 11 BGP Persistent Route Oscillation Solutions 12 draft-walton-bgp-route-oscillation-stop-09 14 Abstract 16 In this document we present two sets of paths for an address prefix 17 that can be advertised by a BGP route reflector or confederation ASBR 18 to eliminate the MED-induced route oscillations in a network. The 19 first set involves all the available paths, and would achieve the 20 same routing consistency as the full IBGP mesh. The second set, 21 which is a subset of the first one, involves the neighbor-AS based 22 Group Best Paths, and would be sufficient to eliminate the MED- 23 induced route oscillations (subject to certain commonly adopted 24 topological constrains). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 27, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 3. Advertise the Available Paths . . . . . . . . . . . . . . . . 3 63 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 64 5. Route Reflection and Confederation . . . . . . . . . . . . . 4 65 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5 66 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 10.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 As documented in [RFC3345], the routing information reduction by BGP 80 Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result 81 in persistent IBGP route oscillations with certain routing setup and 82 network topologies. Except for a couple artificially engineered 83 network topologies, the MED attribute [RFC4271] has played a pivotal 84 role in virtually all of the known persistent IBGP route 85 oscillations. For the sake of brevity, we use the term "MED-induced 86 route oscillation" hereafter to refer to a persistent IBGP route 87 oscillation in which the MED plays a role. 89 In order to eliminate the MED-induced route oscillations and to 90 achieve consistent routing in a network, clearly a route reflector or 91 a confederation ASBR needs to advertise more than just the best path 92 for an address prefix. Our goal is to identify the "right" set of 93 paths for an address prefix that needs to be advertised by a route 94 reflector or a confederation ASBR. 96 In this document we present two sets of paths for an address prefix 97 that can be advertised by a BGP route reflector or confederation ASBR 98 to eliminate the MED-induced route oscillations in a network. The 99 first set involves all the available paths, and would achieve the 100 same routing consistency as the full IBGP mesh. The second set, 101 which is a subset of the first one, involves the neighbor-AS based 102 Group Best Paths, and would be sufficient to eliminate the MED- 103 induced route oscillations (subject to certain commonly adopted 104 topological constrains). 106 These paths can be advertised using the mechanism described in ADD- 107 PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Advertise the Available Paths 117 Observe that in a network that maintains a full IBGP mesh all the BGP 118 speakers have consistent and equivalent routing information. Such a 119 network is thus free of the MED-induced route oscillations and other 120 routing inconsistencies such as forwarding loops. 122 Therefore one approach is to allow a route reflector or a 123 confederation ASBR to advertise all the available paths for an 124 address prefix. Clearly this approach would yield the same amount of 125 routing information and achieve the same routing consistency as the 126 full IBGP mesh in a network. 128 This approach can be implemented using the mechanism described in 129 ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths for 130 certain prefixes. 132 For the sake of scalability the advertisement of multiple paths 133 should be limited to those prefixes which are affected by MED-induced 134 route oscillation in a network carrying a large number of alternate 135 paths. 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 Sect. 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 the IGP metrics for links within a cluster (or 153 confederation sub-AS) are much smaller than the IGP metrics for the 154 links between the clusters (or confederation sub-AS). This practice 155 helps achieve consistent routing within a route reflection cluster or 156 a confederation sub-AS. 158 When the aforementioned practice for devising a route reflection 159 cluster or confederation sub-AS is followed in a network, we claim 160 that the advertisement of all the Group Best Paths by a route 161 reflector or a confederation ASBR is sufficient to eliminate the MED- 162 induced route oscillations in the network. This claim is validated 163 in Appendix A. 165 Note that a Group Best Path for an address prefix can be identified 166 by the combination of the address prefix and the neighbor-AS. Thus 167 this approach can be implemented using the mechanism described in 168 ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths, and 169 in this case the neighbor-AS of a path may be used as the path 170 identifier of the path. 172 It should be noted that the approach of advertising the Group Best 173 Paths requires certain topological constrains to be satisfied in 174 order to eliminate the MED-induced route oscillation. In addition, 175 the BGP speakers still depend on the route selection by the route 176 reflector or the confederation ASBR. As the route selection involves 177 the comparison of the nexthop's IGP metrics which are specific to a 178 particular BGP speaker, the routing information advertised by a route 179 reflector or a confederation ASBR may still be inadequate to avoid 180 other routing inconsistencies such as forwarding loops in certain 181 networks. 183 5. Route Reflection and Confederation 185 To allow a route reflector or a confederation ASBR to advertise 186 either the Available Paths or Group Best Paths using the mechanism 187 described in ADD-PATH [I-D.ietf-idr-add-paths], the following 188 revisions are proposed for BGP route reflection and BGP 189 Confederation. 191 5.1. Route Reflection 193 Depending on the configuration, for a particular a route 194 reflector SHOULD include the with the "Send/Receive" 195 field set to 2 or 3 in the ADD-PATH Capability 196 [I-D.ietf-idr-add-paths] advertised to an IBGP peer. When the ADD- 197 PATH Capability is also received from the IBGP peer with the "Send/ 198 Receive" field set to 1 or 3 for the same , then the 199 following procedures shall be followed: 201 If the peer is a route reflection client, the route reflector SHOULD 202 advertise to the peer the Group Best Paths (or the Available Paths) 203 received from its non-client IBGP peers. Depending on the 204 configuration, the route reflector MAY also advertise to the peer the 205 Group Best Paths (or the Available Paths) received from its clients. 207 If the peer is a non-client, the route reflector SHOULD advertise to 208 the peer the Group Best Paths (or the Available Paths) received from 209 its clients. 211 5.2. Confederation 213 Depending on the configuration, for a particular a 214 confederation ASBR SHOULD include the with the "Send/ 215 Receive" field set to 2 or 3 in the ADD-PATH Capability 216 [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a 217 confederation external peer. When the ADD-PATH Capability is also 218 received from the IBGP peer or the confederation external peer with 219 the "Send/Receive" field set to 1 or 3 for the same , then 220 the following procedures shall be followed: 222 If the peer is internal, the confederation ASBR SHOULD advertise to 223 the peer the Group Best Paths (or the Available Paths) received from 224 its confederation external peers. 226 If the peer is confederation external, the confederation ASBR SHOULD 227 advertise to the peer the Group Best Paths (or the Available Paths) 228 received from its IBGP peers. 230 6. Deployment Considerations 232 Some route oscillations, once detected, can be eliminated by simple 233 configuration workarounds. As carrying additional paths impacts the 234 memory usage and routing convergence in a network, it is recommended 235 that the impact be evaluated and the approach of using a 236 configuration workaround be considered in deciding whether to deploy 237 the proposed mechanism in a network. In addition, the advertisement 238 of multiple paths should be limited to those prefixes which are 239 affected by MED-induced route oscillation. 241 While the route reflectors or confederation ASBRs in a network need 242 to advertise the Group Best Paths or Available Paths, the vast 243 majority of the BGP speakers in the network only need to receive the 244 Group Best Paths or Available Paths, which would involve only minor 245 software changes. 247 It should be emphasized that in order to eliminate the MED-induced 248 route oscillations in a network using the approach of advertising the 249 Group Best Paths, the recommended practice for devising a route 250 reflection cluster or confederation sub-AS with respect to the IGP 251 metrics ([RFC4456], [RFC5065]) should be followed. 253 It is expected that the approach of advertising the Group Best Paths 254 would be adequate to achieve consistent routing for the vast majority 255 of the networks. For a network that has large number of alternate 256 paths, the approach should be a good choice as the number of paths 257 advertised by a reflector or a confederation ASBR is bounded by the 258 number of the neighbor-AS's for a particular address prefix. The 259 additional states for an address prefix would also be per neighbor-AS 260 based rather than per path based. The number of the neighbor-AS's 261 for a particular address prefix is typically small because of the 262 limited number of upstream providers for a customer and the nature of 263 advertising only customer routes at the inter-exchange points. 265 The approach of advertising the Group Best Paths, however, may still 266 be inadequate for certain networks to avoid other routing 267 inconsistencies such as forwarding loops. The required topological 268 constrains could also be operationally challenging. In these cases 269 the approach of advertising the Available Paths may be used, but 270 should be limited to those prefixes which are affected by MED-induced 271 route oscillation in a network carrying a large number of alternate 272 paths. Note that the number of paths that need to be maintained and 273 advertised can be greatly reduced by accepting the IGP metric based 274 MEDs from other peering networks. 276 7. IANA Considerations 278 This memo includes no request to IANA. 280 8. Security Considerations 282 This extension to BGP does not change the underlying security issues 283 inherent in the existing BGP [RFC4271]. 285 9. Acknowledgements 287 We would like to thank David Cook and Naiming Shen for their 288 contributions to the design and development of the solutions. 290 10. References 292 10.1. Normative References 294 [I-D.ietf-idr-add-paths] 295 Walton, D., Retana, A., Chen, E., and J. Scudder, 296 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 297 add-paths-10 (work in progress), October 2014. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 303 Protocol 4 (BGP-4)", RFC 4271, January 2006. 305 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 306 Reflection: An Alternative to Full Mesh Internal BGP 307 (IBGP)", RFC 4456, April 2006. 309 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 310 System Confederations for BGP", RFC 5065, August 2007. 312 10.2. Informative References 314 [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, 315 "Border Gateway Protocol (BGP) Persistent Route 316 Oscillation Condition", RFC 3345, August 2002. 318 Appendix A. Why the Group Best Paths Are Adequate? 320 It is assumed that the following common practice is followed. A 321 route reflection cluster or a confederation sub-AS should be designed 322 such that the IGP metrics for links within a cluster (or 323 confederation sub-AS) are much smaller than the IGP metrics for the 324 links between the clusters (or confederation sub-AS). This practice 325 helps achieve consistent routing within a route reflection cluster or 326 a confederation sub-AS. 328 Observe that in a network that maintains full IBGP mesh only the 329 paths that survive the (Local_Pref, AS-PATH Length, Origin, MED) 330 comparisons [RFC4271] would contribute to the route selection in the 331 network. 333 Consider a route reflection cluster that sources one or more paths 334 that would survive the (Local_Pref, AS-PATH Length, Origin, MED) 335 comparisons among all the paths in the network. One of these 336 surviving paths would be selected as the Group Best Path by the route 337 reflector in the cluster. Due to the constrain on the IGP metrics as 338 described previously, this path would remain as the Group Best Path 339 and would be advertised to all other clusters even after a path is 340 received from another cluster. 342 On the other hand, when no path in a route reflection cluster would 343 survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons 344 among all the paths in the network, the Group Best Path (when exists) 345 for a route reflector would be from another cluster. Clearly the 346 advertise of the Group Best Path by the route reflector to the 347 clients only depends on the paths received from other clusters. 349 Therefore there is no MED-induced route oscillation in the network as 350 the advertisement of a Group Best Path to a peer does not depend on 351 the paths received from that peer. 353 The claim for the confederation can be validated similarly. 355 Authors' Addresses 357 Daniel Walton 358 Cumulus Networks 359 140C S. Whisman Rd. 360 Mountain View, CA 94041 361 USA 363 Email: dwalton@cumulusnetworks.com 365 Alvaro Retana 366 Cisco Systems, Inc. 367 7025 Kit Creek Rd. 368 Research Triangle Park, NC 27709 369 USA 371 Email: aretana@cisco.com 372 Enke Chen 373 Cisco Systems, Inc. 374 170 W. Tasman Dr. 375 San Jose, CA 95134 376 USA 378 Email: enkechen@cisco.com 380 John Scudder 381 Juniper Networks 382 1194 N. Mathilda Ave 383 Sunnyvale, CA 94089 384 USA 386 Email: jgs@juniper.net