One document matched: draft-walton-bgp-route-oscillation-stop-00.txt

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]