--- 1/draft-ietf-idr-route-oscillation-stop-02.txt 2016-04-30 20:15:56.074373066 -0700 +++ 2/draft-ietf-idr-route-oscillation-stop-03.txt 2016-04-30 20:15:56.098373653 -0700 @@ -1,127 +1,126 @@ Network Working Group D. Walton Internet-Draft Cumulus Networks Intended status: Standards Track A. Retana -Expires: October 13, 2016 E. Chen +Expires: November 1, 2016 E. Chen Cisco Systems, Inc. J. Scudder Juniper Networks - April 11, 2016 + April 30, 2016 BGP Persistent Route Oscillation Solutions - draft-ietf-idr-route-oscillation-stop-02 + draft-ietf-idr-route-oscillation-stop-03 Abstract This document presents 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-induced route - oscillations (subject to certain commonly adopted topological - constrains). + oscillations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 October 13, 2016. + This Internet-Draft will expire on November 1, 2016. Copyright Notice Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . 4 + 3. Advertise All the Available Paths . . . . . . . . . . . . . . 3 + 4. Advertise the Group Best Paths . . . . . . . . . . . . . . . 3 5. Route Reflection and Confederation . . . . . . . . . . . . . 4 - 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 5 + 5.1. Route Reflection . . . . . . . . . . . . . . . . . . . . 4 5.2. Confederation . . . . . . . . . . . . . . . . . . . . . . 5 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Why the Group Best Paths Are Adequate? . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction As documented in [RFC3345], the routing information reduction by BGP Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result in persistent IBGP route oscillations with certain routing setup and network topologies. Except for a couple artificially engineered network topologies, the MED attribute [RFC4271] has played a pivotal role in virtually all of the known persistent IBGP route oscillations. For the sake of brevity, we use the term "MED-induced route oscillation" hereafter to refer to a persistent IBGP route oscillation in which the MED plays a role. In order to eliminate the MED-induced route oscillations and to - achieve consistent routing in a network, clearly a route reflector or - a confederation ASBR needs to advertise more than just the best path - for an address prefix. Our goal is to identify the "right" set of + achieve consistent routing in a network, a route reflector or a + confederation ASBR needs to advertise more than just the best path + for an address prefix. Our goal is to identify the necessary set of paths for an address prefix that needs to be advertised by a route - reflector or a confederation ASBR. + reflector or a confederation ASBR to prevent the condition. - In this document we present two sets of paths for an address prefix + In this document we describe 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- induced route oscillations (subject to certain commonly adopted - topological constrains). + topological constraints). These paths can be advertised using the mechanism described in ADD- PATH [I-D.ietf-idr-add-paths] for advertising multiple paths. No other assumptions in functionality beyond the base BGP specification - [RFC4271] is assumed. + [RFC4271] are made. 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 +3. Advertise All the Available Paths Observe that in a network that maintains a full IBGP mesh all the BGP speakers have consistent and equivalent routing information. Such a network is thus free of the MED-induced route oscillations and other routing inconsistencies such as forwarding loops. Therefore one approach is to allow a route reflector or a confederation ASBR to advertise all the available paths for an address prefix. Clearly this approach would yield the same amount of routing information and achieve the same routing consistency as the @@ -167,21 +167,21 @@ in Appendix A. 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 + Paths requires certain topological constraints to be satisfied in 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. @@ -258,42 +258,43 @@ number of the neighbor-AS's for a particular address prefix. The additional states for an address prefix would also be per neighbor-AS based rather than per path based. The number of the neighbor-AS's for a particular address prefix is typically small because of the limited number of upstream providers for a customer and the nature of 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 + constraints 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 MEDs from other - peering networks. + paths. 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]. 9. Acknowledgements We would like to thank David Cook and Naiming Shen for their contributions to the design and development of the solutions. + Many thanks to Tony Przygienda, Sue Hares and Jon Mitchel for their + helpful suggestions. + 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-13 (work in progress), December 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate