idnits 2.17.1 draft-walton-bgp-route-oscillation-stop-03.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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 (May 10, 2010) is 5099 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 information found for draft-ietf-idr-add-path - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ADD-PATH' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Walton 3 Internet Draft A. Retana 4 Expiration Date: November 12, 2010 E. Chen 5 Cisco Systems 6 J. Scudder 7 Juniper Networks 8 May 10, 2010 10 BGP Persistent Route Oscillation Solutions 11 draft-walton-bgp-route-oscillation-stop-03.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on November 12, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 49 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Abstract 56 In this document we present two sets of paths for an address prefix 57 that can be advertised by a BGP route reflector or confederation ASBR 58 to eliminate the MED-induced route oscillations in a network. The 59 first set involves all the available paths, and would achieve the 60 same routing consistency as the full IBGP mesh. The second set, 61 which is a subset of the first one, involves the neighbor-AS based 62 Group Best Paths, and would be sufficient to eliminate the MED- 63 induced route oscillations (subject to certain commonly adopted 64 topological constrains). 66 1. Introduction 68 As documented in [RFC3345], the routing information reduction by BGP 69 Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result 70 in persistent IBGP route oscillations with certain routing setup and 71 network topologies. Except for a couple artificially engineered 72 network topologies, the MED attribute [RFC4271] has played a pivotal 73 role in virtually all of the known persistent IBGP route 74 oscillations. For the sake of brevity, we use the term "MED-induced 75 route oscillation" hereafter to refer to a persistent IBGP route 76 oscillation in which the MED plays a role. 78 In order to eliminate the MED-induced route oscillations and to 79 achieve consistent routing in a network, clearly a route reflector or 80 a confederation ASBR needs to advertise more than just the best path 81 for an address prefix. Our goal is to identify the "right" set of 82 paths for an address prefix that needs to be advertised by a route 83 reflector or a confederation ASBR. 85 In this document we present two sets of paths for an address prefix 86 that can be advertised by a BGP route reflector or confederation ASBR 87 to eliminate the MED-induced route oscillations in a network. The 88 first set involves all the available paths, and would achieve the 89 same routing consistency as the full IBGP mesh. The second set, 90 which is a subset of the first one, involves the neighbor-AS based 91 Group Best Paths, and would be sufficient to eliminate the MED- 92 induced route oscillations (subject to certain commonly adopted 93 topological constrains). 95 These paths can be advertised using the mechanism described in [ADD- 96 PATH] for advertising multiple paths. 98 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 100 1.1. Specification of Requirements 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Advertise the Available Paths 108 Observe that in a network that maintains a full IBGP mesh all the BGP 109 speakers have consistent and equivalent routing information. Such a 110 network is thus free of the MED-induced route oscillations and other 111 routing inconsistencies such as forwarding loops. 113 Therefore one approach is to allow a route reflector or a 114 confederation ASBR to advertise all the available paths for an 115 address prefix. Clearly this approach would yield the same amount of 116 routing information and achieve the same routing consistency as the 117 full IBGP mesh in a network. 119 This approach can be implemented using the mechanism described in 120 [ADD-PATH] for advertising multiple paths for certain prefixes. 122 For the sake of scalability the advertisement of multiple paths 123 should be limited to those prefixes which are affected by MED-induced 124 route oscillation in a network carrying a large number of alternate 125 paths. 127 3. Advertise the Group Best Paths 129 The term neighbor-AS for a route refers to the neighboring AS from 130 which the route was received. The calculation of the neighbor-AS is 131 specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of 132 [RFC5065]. By definition the MED is comparable only among routes 133 with the same neighbor-AS. Thus the route selection procedures 134 specified in [RFC4271] would conceptually involve two steps: first 135 organize the paths for an address prefix into groups according to 136 their respective neighbor-AS's, and calculate the most preferred one 137 (termed "Group Best Path") for each of the groups; Then calculate the 138 overall best path among all the Group Best Paths. 140 As a generally recommended [RFC4456, RFC5065] and widely adopted 141 practice, a route reflection cluster or a confederation sub-AS should 142 be designed such that the IGP metrics for links within a cluster (or 143 confederation sub-AS) are much smaller than the IGP metrics for the 144 links between the clusters (or confederation sub-AS). This practice 145 helps achieve consistent routing within a route reflection cluster or 147 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 149 a confederation sub-AS. 151 When the aforementioned practice for devising a route reflection 152 cluster or confederation sub-AS is followed in a network, we claim 153 that the advertisement of all the Group Best Paths by a route 154 reflector or a confederation ASBR is sufficient to eliminate the 155 MED-induced route oscillations in the network. This claim is 156 validated in Appendix A. 158 Note that a Group Best Path for an address prefix can be identified 159 by the combination of the address prefix and the neighbor-AS. Thus 160 this approach can be implemented using the mechanism described in 161 [ADD-PATH] for advertising multiple paths, and in this case the 162 neighbor-AS of a path may be used as the path identifier of the path. 164 It should be noted that the approach of advertising the Group Best 165 Paths requires certain topological constrains to be satisfied in 166 order to eliminate the MED-induced route oscillation. In addition, 167 the BGP speakers still depend on the route selection by the route 168 reflector or the confederation ASBR. As the route selection involves 169 the comparison of the nexthop's IGP metrics which are specific to a 170 particular BGP speaker, the routing information advertised by a route 171 reflector or a confederation ASBR may still be inadequate to avoid 172 other routing inconsistencies such as forwarding loops in certain 173 networks. 175 4. Route Reflection and Confederation 177 To allow a route reflector or a confederation ASBR to advertise 178 either the Available Paths or Group Best Paths using the mechanism 179 described in [ADD-PATH], the following revisions are proposed for BGP 180 route reflection and BGP Confederation. 182 4.1. Route Reflection 184 Depending on the configuration, for a particular a route 185 reflector SHOULD include the with the "Send/Receive" 186 field set to 2 or 3 in the ADD-PATH Capability [ADD-PATH] advertised 187 to an IBGP peer. When the ADD-PATH Capability is also received from 188 the IBGP peer with the "Send/Receive" field set to 1 or 3 for the 189 same , then the following procedures shall be followed: 191 If the peer is a route reflection client, the route reflector SHOULD 192 advertise to the peer the Group Best Paths (or the Available Paths) 193 received from its non-client IBGP peers. Depending on the 194 configuration, the route reflector MAY also advertise to the peer the 196 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 198 Group Best Paths (or the Available Paths) received from its clients. 200 If the peer is a non-client, the route reflector SHOULD advertise to 201 the peer the Group Best Paths (or the Available Paths) received from 202 its clients. 204 4.2. Confederation 206 Depending on the configuration, for a particular a 207 confederation ASBR SHOULD include the with the 208 "Send/Receive" field set to 2 or 3 in the ADD-PATH Capability [ADD- 209 PATH] advertised to an IBGP peer, and to a confederation external 210 peer. When the ADD-PATH Capability is also received from the IBGP 211 peer or the confederation external peer with the "Send/Receive" field 212 set to 1 or 3 for the same , then the following procedures 213 shall be followed: 215 If the peer is internal, the confederation ASBR SHOULD advertise to 216 the peer the Group Best Paths (or the Available Paths) received from 217 its confederation external peers. 219 If the peer is confederation external, the confederation ASBR SHOULD 220 advertise to the peer the Group Best Paths (or the Available Paths) 221 received from its IBGP peers. 223 5. Deployment Considerations 225 Some route oscillations, once detected, can be eliminated by simple 226 configuration workarounds. As carrying additional paths impacts the 227 memory usage and routing convergence in a network, it is recommended 228 that the impact be evaluated and the approach of using a 229 configuration workaround be considered in deciding whether to deploy 230 the proposed mechanism in a network. In addition, the advertisement 231 of multiple paths should be limited to those prefixes which are 232 affected by MED-induced route oscillation 234 While the route reflectors or confederation ASBRs in a network need 235 to advertise the Group Best Paths or Available Paths, the vast 236 majority of the BGP speakers in the network only need to receive the 237 Group Best Paths or Available Paths, which would involve only minor 238 software changes. 240 It should be emphasized that in order to eliminate the MED-induced 241 route oscillations in a network using the approach of advertising the 242 Group Best Paths, the recommended practice for devising a route 243 reflection cluster or confederation sub-AS with respect to the IGP 245 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 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 for 257 a particular address prefix is typically small because of the limited 258 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 constrains 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. Note that the number of paths that need to be maintained and 269 advertised can be greatly reduced by accepting the IGP metric based 270 MEDs from other peering networks. 272 6. Security Considerations 274 This extension to BGP does not change the underlying security issues 275 inherent in the existing BGP [RFC4271]. 277 7. Acknowledgments 279 We would like to thank David Cook and Naiming Shen for their 280 contributions to the design and development of the solutions. 282 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 284 8. References 286 8.1. Normative References 288 [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway 289 Protocol 4 (BGP-4)," RFC 4271, January 2006. 291 [RFC4456] Bates, T., R. Chandra, and E. Chen "BGP Route Reflection - 292 An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 293 2006. 295 [RFC5065] Traina, P., D. McPherson, and J. Scudder, "Autonomous 296 System Confederations for BGP", RFC 5065, August 2007. 298 [ADD-PATH] Walton, D., A. Retana, E. Chen, and J. Scudder 299 "Advertisement of Multiple Paths in BGP", draft-ietf-idr-add-path- 300 03.txt, February 2010. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels," RFC 2119, BCP 14, March 1997. 305 8.2. Informative References 307 [RFC3345] McPherson, D., V. Gill, D. Walton, and A. Retana, "Border 308 Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 309 3345, August 2002. 311 Appendix A. Why the Group Best Paths Are Adequate? 313 It is assumed that the following common practice is followed. A 314 route reflection cluster or a confederation sub-AS should be designed 315 such that the IGP metrics for links within a cluster (or 316 confederation sub-AS) are much smaller than the IGP metrics for the 317 links between the clusters (or confederation sub-AS). This practice 318 helps achieve consistent routing within a route reflection cluster or 319 a confederation sub-AS. 321 Observe that in a network that maintains full IBGP mesh only the 322 paths that survive the (Local_Pref, AS-PATH Length, Origin, MED) 323 comparisons [RFC4271] would contribute to the route selection in the 324 network. 326 Consider a route reflection cluster that sources one or more paths 327 that would survive the (Local_Pref, AS-PATH Length, Origin, MED) 328 comparisons among all the paths in the network. One of these 330 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 332 surviving paths would be selected as the Group Best Path by the route 333 reflector in the cluster. Due to the constrain on the IGP metrics as 334 described previously, this path would remain as the Group Best Path 335 and would be advertised to all other clusters even after a path is 336 received from another cluster. 338 On the other hand, when no path in a route reflection cluster would 339 survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons 340 among all the paths in the network, the Group Best Path (when exists) 341 for a route reflector would be from another cluster. Clearly the 342 advertise of the Group Best Path by the route reflector to the 343 clients only depends on the paths received from other clusters. 345 Therefore there is no MED-induced route oscillation in the network as 346 the advertisement of a Group Best Path to a peer does not depend on 347 the paths received from that peer. 349 The claim for the confederation can be validated similarly. 351 Authors' Addresses 353 Daniel Walton 354 Cisco Systems, Inc. 355 7025 Kit Creek Rd. 356 Research Triangle Park, NC 27709 358 Email: dwalton@cisco.com 360 Alvaro Retana 361 Cisco Systems, Inc. 362 7025 Kit Creek Rd. 363 Research Triangle Park, NC 27709 365 Email: aretana@cisco.com 367 Enke Chen 368 Cisco Systems, Inc. 369 170 W. Tasman Dr. 370 San Jose, CA 95134 372 Email: enkechen@cisco.com 374 John Scudder 375 Juniper Networks 377 draft-walton-bgp-route-oscillation-stop-03.txt May 2010 379 Email: jgs@juniper.net