Network Working Group Daniel Walton Internet Draft David Cook Expiration Date: November 2002 Alvaro Retana File name: draft-walton-bgp-route-oscillation-stop-00.txt John Scudder Cisco Systems May 2002 BGP Persistent Route Oscillation Solution draft-walton-bgp-route-oscillation-stop-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents an application of the use of the advertisement of multiple paths [1] to solve the well known BGP persistent route oscillation [2,3] problem. Walton, et al [Page 1] INTERNET DRAFT BGP Persistent Oscillation Solution May 2002 1. Specification of Requirements 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 [5]. 2. Advertisement of Multiple Paths to eliminate BGP route oscillation Both types of route oscillation [2,3] are caused by the combination of two factors: 1 As a result of the reduction of the IBGP full mesh through the use of Route Reflectors [4] and Confederations [5], BGP speakers in an AS may only have a partial view of the available exit points into a neighboring AS. 2 Only comparing the MULTI_EXIT_DISC between routes learned from the same neighboring AS [6,7]. In order to prevent the oscillation, we must eliminate one of these two factors. The latter is easy to eliminate by always comparing the MULTI_EXIT_DISC regardless of the Neighbor AS. This is not accept- able for many BGP users because it will change the use of MED as defined by BGP [6,7]. To solve the former, a BGP speaker which is a route reflector [4] or a sub-AS border router in a BGP confederation [5] MUST advertise the following to its IBGP or confederation peers: o The best path for a prefix as defined by [6,7]; and o One "neighbor AS best path" per neighbor AS. A "neighbor AS best path" is the path that is considered best among all paths from the same neighbor AS, and is advertised using the mechanism described in [1]. Only "neighbor AS best paths" for which the tie breaker (when comparing the path to the best path) occurs after the MED is compared need to be propagated. The result is that for every n neighbor ASes which a route reflector or sub-AS border router has learned, it will advertise at most n-1 "neighbor AS best paths" to its non-EBGP peers. Notwithstanding the above, the BGP speaker MUST continue to follow the UPDATE propagation rules defined in the corresponding specifica- tions [4,5,6,7]. The "neighbor AS best paths" MUST be withdrawn if the actual best Walton, et al [Page 2] INTERNET DRAFT BGP Persistent Oscillation Solution May 2002 path is withdrawn and not replaced. I.e., a "neighbor AS best path" may only be announced as a supplement to an actual best path. Note that the BGP speaker MUST NOT advertise the normal best path as a "Neighbor AS best path"; i.e. the best path MUST only be advertised once and no additional paths SHOULD be advertised for the Neighbor AS from which the best path was selected. 3. Security Considerations This document introduces no new security concerns to BGP or other specifications referenced in this document. 4. Acknowledgments We would like to thank Bruce Cole, Chaitanya Kodeboyina, Dave Meyer, Srihari Ramachandra, Mark Turner and Blaine Christian for their com- ments and suggestions. 5. References [1] Walton, D., Cook, D., Retana, A., Scudder, J., "Advertisement of Multiple Paths in BGP", Work in Progress (draft-walton-bgp-add- paths-00), May 2002. [2] Cisco Systems, Inc., "Endless BGP Convergence Problem in Cisco IOS Software Releases" , FN, October 10, 2000. [3] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent Route Oscillation Condition", Work in Progress (draft-ietf-idr- route-oscillation-01), February 2002. [4] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [5] Traina, P., McPherson, D., Scudder, J.. "Autonomous System Con- federations for BGP", RFC 3065, February 2001. [6] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [7] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-17), January 2002. Walton, et al [Page 3] INTERNET DRAFT BGP Persistent Oscillation Solution May 2002 6. Authors' addresses Daniel Walton Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Email: dwalton@cisco.com Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Email: aretana@cisco.com David Cook Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Email: dacook@cisco.com John G. Scudder Cisco Systems, Inc. 100 S. Main Suite 200 Ann Arbor, MI 48104 Email: jgs@cisco.com Walton, et al [Page 4]