[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 draft-ietf-idr-route-oscillation-stop

Network Working Group                                     Daniel Walton
Internet Draft                                            Alvaro Retana
Expiration Date: January 2006                                 Enke Chen
                                                          Cisco Systems



               BGP Persistent Route Oscillation Solution

             draft-walton-bgp-route-oscillation-stop-01.txt


1. Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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
   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."

   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.


2. 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-type 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 set, involves the neighbor-AS based Group Best
   Paths, and would be sufficient to eliminate the MED-type route
   oscillations (subject to certain commonly adopted topological
   constrains).




Walton, et al         Expiration Date January 2006              [Page 1]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


3. Introduction

   As documented in [4], the routing information reduction by BGP Route
   Reflection [2] or BGP Confederation [3] 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 [1] 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-type route oscillation" hereafter to refer to a
   persistent IBGP route oscillation in which the MED plays a role.

   In order to eliminate the MED-type 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
   paths for an address prefix that needs to be advertised by a route
   reflector or a confederation ASBR.

   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-type 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 set of the first set, involves the neighbor-AS based Group Best
   Paths, and would be sufficient to eliminate the MED-type route
   oscillations (subject to certain commonly adopted topological
   constrains).

   These paths can be advertised using the mechanism described in [5]
   for advertising multiple paths.  The deployment of the mechanisms
   requires only minor software changes for the vast majority of the BGP
   speakers in a network.


4. 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 RFC 2119 [7].












Walton, et al         Expiration Date January 2006              [Page 2]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


5. Advertise 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-type 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
   full IBGP mesh in a network.

   This approach can be implemented using the mechanism described in [5]
   for advertising multiple paths, and in this case the path identifier
   of a path would be the BGP Identifier of the BGP speaker that
   originates the route in the AS (or the Confederation).


6. 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 [1], and Section 7.2 of [3].  By
   definition the MED is comparable only among routes with the same
   neighbor-AS.  As a result, the route selection procedures specified
   in [1] would conceptually involve two steps: first organize the paths
   for an address prefix into groups according to their respective
   neighbor-AS‚ÇÖs, and calculate the most preferred one (termed "Group
   Best Path") for each of the groups; Then calculate the overall best
   path among all the Group Best Paths.

   As a generally recommended [2, 3] and widely adopted practice, 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 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.

   Observe also that in a network that maintains full IBGP mesh only the
   paths that survive the (Local_Pref, AS-PATH Length, Origin, MED)
   comparisons [1] would contribute to the route selection in the
   network.

   When the aforementioned practice for devising a route reflection
   cluster or confederation sub-AS is followed in a network, we claim
   that the advertisement of all the Group Best Paths by a route



Walton, et al         Expiration Date January 2006              [Page 3]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


   reflector or a confederation ASBR is sufficient to eliminate the MED-
   type route oscillations in the network.  This claim can be validated
   as the following.

       Consider a route reflection cluster that sources one or more
       paths that would survive the (Local_Pref, AS-PATH Length, Origin,
       MED) comparisons among all the paths in the network.  One of
       these surviving paths would be selected as the Group Best Path by
       the route reflector in the cluster.  Due to the constrain on the
       IGP metrics as described previously, this path would remain as
       the Group Best Path and would be advertised to all other clusters
       even after a path is received from another cluster.

       On the other hand, when no path in a route reflection cluster
       would survive the (Local_Pref, AS-PATH Length, Origin, MED)
       comparisons among all the paths in the network, the Group Best
       Path (when exists) for a route reflector would be from another
       cluster. Clearly the advertise of the Group Best Path by the
       route reflector to the clients only depends on the paths received
       from other clusters.

       Therefore there is no MED-type route oscillation in the network
       as the advertisement of a Group Best Path to a peer does not
       depend on the paths received from that peer.

   The claim for the confederation can be validated similarly.

   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 [5]
   for advertising multiple paths, and in this case the path identifier
   of a path would be the neighbor-AS 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-type 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.








Walton, et al         Expiration Date January 2006              [Page 4]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


7. Route Reflection and Confederation

   To allow a a route reflector or a confederation ASBR to advertise
   either the Available Paths or Group Best Paths using the mechanism
   described in [5], the following revisions are proposed for BGP route
   reflection and BGP Confederation.


7.1. Route Reflection

   Depending on the configuration a route reflector SHOULD include the
   <AFI, SAFI, Path Identifier Type> for a particular <AFI, SAFI> in the
   ADD-PATH Capability [5] advertised to an IBGP peer.  The Path
   Identifier Type could either be "AS Number Based", or "BGP Identifier
   Based".

   A route reflector SHOULD advertise to its clients the Group Best
   Paths (or the Available Paths) received from its non-client IBGP
   peers.

   A route reflector SHOULD advertise to its non-client IBGP peers the
   Group Best Paths (or the Available Paths) received from its clients.

   A route reflector MAY also advertise to its clients the Group Best
   Paths (or the Available Paths) received from its clients.


7.2. Confederation

   Depending on the configuration a confederation ASBR SHOULD include
   the <AFI, SAFI, Path Identifier Type> for a particular <AFI, SAFI> in
   the ADD-PATH Capability [5] advertised to an IBGP peer.  The Path
   Identifier Type could either be "AS Number Based", or "BGP Identifier
   Based".

   A confederation ASBR SHOULD advertise to its IBGP peers the Group
   Best Paths (or the Available Paths) received from its confederation
   external peers.

   A confederation ASBR SHOULD advertise to confederation external peers
   the Group Best Paths (or the Available Paths) received from its IBGP
   peers.









Walton, et al         Expiration Date January 2006              [Page 5]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


8. Deployment Considerations

   Some route oscillations, once detected, can be eliminated by simple
   configuration workarounds. As carrying additional paths impacts the
   memory usage and routing convergence in a network, it is recommended
   that the impact be evaluated and the approach of using a
   configuration workaround be considered in deciding whether to deploy
   the proposed mechanism in a network.

   While the route reflectors or confederation ASBRs in a network need
   to advertise the Group Best Paths or Available Paths, the vast
   majority of the BGP speakers in the network only need to receive the
   Group Best Paths or Available Paths, which would involve just minor
   software changes:

       - Advertise the ADD-PATH Capability [5] without any <AFI, SAFI>.

       - Process received UPDATE messages based on the address prefix
         and the path identifier.

   To deploy the mechanism of advertising multiple paths in a network,
   it is recommended that the BGP speakers (one at a time) be first
   upgraded to a software version that supports the new capability, and
   be configured to advertise the new capability without any <AFI,
   SAFI>.  Then on a per route reflection cluster or confederation sub-
   AS basis, the route reflectors or the confederation ASBRs are re-
   configured to include the appropriate <AFI, SAFI> in the capability
   advertised.

   It should be emphasized that in order to eliminate the MED-type route
   oscillations in a network using the approach of advertising the Group
   Best Paths, the recommended practice for devising a route reflection
   cluster or confederation sub-AS with respect to the IGP metrics [2,
   3] should be followed.

   It is expected that the approach of advertising the Group Best Paths
   would be adequate to achieve consistent routing for the vast majority
   of the networks.  For a network that has large number of alternate
   paths, the approach should be a good choice as the number of paths
   advertised by a reflector or a confederation ASBR is bounded by the
   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



Walton, et al         Expiration Date January 2006              [Page 6]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


   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.  In
   general this approach would result in larger number of paths to be
   advertised, and may require per-path states to be maintained.  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.


9. Security Considerations

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP [6].


10. Acknowledgments

   This document combines prior work on "BGP Persistent Route
   Oscillation Solution" by Daniel Walton, David Cook, Alvaro Retana,
   and John Scudder, with prior work on "Advertisement of the Group Best
   Paths" by Enke Chen, and Naiming Shen. The current authors wish to
   thank all these authors for their contribution.


11. References

   [1]  Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 4
        (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.

   [2]  Bates, T., R. Chandra, and E. Chen "BGP Route Reflection - An
        Alternative to Full Mesh IBGP", RFC 2796, April 2000.

   [3]  Traina, P., D. McPherson, and J. Scudder, "Autonomous System
        Confederations for BGP", RFC 3065, February 2001.

   [4]  D. McPherson, V, Gill, D. Walton, and A. Retana, "Border Gateway
        Protocol (BGP) Persistent Route Oscillation Condition",
        RFC 3345, August 2002.

   [5]  D. Walton, A. Retana, and E. Chen, "Advertisement of Multiple
        Paths in BGP", draft-walton-bgp-add-path-03.txt, July 2005.

   [6]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
        Signature Option", RFC 2385, August 1998.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement



Walton, et al         Expiration Date January 2006              [Page 7]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


        Levels", BCP 14, RFC 2119, March 1997.


12. 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

   Enke Chen
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134
   Email: enkechen@cisco.com


13. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.




Walton, et al         Expiration Date January 2006              [Page 8]


             draft-walton-bgp-route-oscillation-stop-01.txt    July 2005


14. Full Copyright Notice

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




































Walton, et al         Expiration Date January 2006              [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/