--- 1/draft-ietf-idr-route-oscillation-stop-00.txt 2015-10-07 13:15:05.045333759 -0700 +++ 2/draft-ietf-idr-route-oscillation-stop-01.txt 2015-10-07 13:15:05.069334338 -0700 @@ -1,22 +1,22 @@ Network Working Group D. Walton Internet-Draft Cumulus Networks Intended status: Standards Track A. Retana -Expires: August 6, 2015 E. Chen +Expires: April 9, 2016 E. Chen Cisco Systems, Inc. J. Scudder Juniper Networks - February 2, 2015 + October 7, 2015 BGP Persistent Route Oscillation Solutions - draft-ietf-idr-route-oscillation-stop-00 + draft-ietf-idr-route-oscillation-stop-01 Abstract In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 6, 2015. + This Internet-Draft will expire on April 9, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,21 +53,21 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Advertise the Available Paths . . . . . . . . . . . . . . . . 3 - 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 + 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 4 5. Route Reflection and Confederation . . . . . . . . . . . . . 4 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 @@ -97,21 +97,23 @@ that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). These paths can be advertised using the mechanism described in ADD- - PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. + PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. No + other assumptions in functionality beyond the base BGP specification + [RFC4271] is assumed. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Advertise the Available Paths Observe that in a network that maintains a full IBGP mesh all the BGP @@ -125,21 +127,23 @@ routing information and achieve the same routing consistency as the full IBGP mesh in a network. This approach can be implemented using the mechanism described in ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths for certain prefixes. For the sake of scalability the advertisement of multiple paths should be limited to those prefixes which are affected by MED-induced route oscillation in a network carrying a large number of alternate - paths. + paths. A detailed description of how these oscillations can occur + can be found in [RFC3345]; the description of how a node would + locally detect such condition is outside the scope of this document. 4. Advertise the Group Best Paths The term neighbor-AS for a route refers to the neighboring AS from which the route was received. The calculation of the neighbor-AS is specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of [RFC5065]. By definition the MED is comparable only among routes with the same neighbor-AS. Thus the route selection procedures specified in [RFC4271] would conceptually involve two steps: first organize the paths for an address prefix into groups according to @@ -164,28 +168,22 @@ Note that a Group Best Path for an address prefix can be identified by the combination of the address prefix and the neighbor-AS. Thus this approach can be implemented using the mechanism described in ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths, and in this case the neighbor-AS of a path may be used as the path identifier of the path. It should be noted that the approach of advertising the Group Best Paths requires certain topological constrains to be satisfied in - order to eliminate the MED-induced route oscillation. In addition, - the BGP speakers still depend on the route selection by the route - reflector or the confederation ASBR. As the route selection involves - the comparison of the nexthop's IGP metrics which are specific to a - particular BGP speaker, the routing information advertised by a route - reflector or a confederation ASBR may still be inadequate to avoid - other routing inconsistencies such as forwarding loops in certain - networks. + order to eliminate the MED-induced route oscillation. Specific + topological considerations are described in [RFC3345]. 5. Route Reflection and Confederation To allow a route reflector or a confederation ASBR to advertise either the Available Paths or Group Best Paths using the mechanism described in ADD-PATH [I-D.ietf-idr-add-paths], the following revisions are proposed for BGP route reflection and BGP Confederation. 5.1. Route Reflection @@ -263,22 +261,22 @@ advertising only customer routes at the inter-exchange points. The approach of advertising the Group Best Paths, however, may still be inadequate for certain networks to avoid other routing inconsistencies such as forwarding loops. The required topological constrains could also be operationally challenging. In these cases the approach of advertising the Available Paths may be used, but should be limited to those prefixes which are affected by MED-induced route oscillation in a network carrying a large number of alternate paths. Note that the number of paths that need to be maintained and - advertised can be greatly reduced by accepting the IGP metric based - MEDs from other peering networks. + advertised can be greatly reduced by accepting MEDs from other + peering networks. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP [RFC4271]. @@ -290,37 +288,45 @@ 10. References 10.1. Normative References [I-D.ietf-idr-add-paths] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", draft-ietf-idr- add-paths-10 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . - [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway - Protocol 4 (BGP-4)", RFC 4271, January 2006. + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP - (IBGP)", RFC 4456, April 2006. + (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, + . [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous - System Confederations for BGP", RFC 5065, August 2007. + System Confederations for BGP", RFC 5065, + DOI 10.17487/RFC5065, August 2007, + . 10.2. Informative References [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route - Oscillation Condition", RFC 3345, August 2002. + Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, + August 2002, . Appendix A. Why the Group Best Paths Are Adequate? It is assumed that the following common practice is followed. A route reflection cluster or a confederation sub-AS should be designed such that the IGP metrics for links within a cluster (or confederation sub-AS) are much smaller than the IGP metrics for the links between the clusters (or confederation sub-AS). This practice helps achieve consistent routing within a route reflection cluster or a confederation sub-AS.