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

Versions: 00 01 02 03 04 05 RFC 5004

Network Working Group                                         Enke Chen
Internet Draft                                         Redback Networks
Expiration Date: December 2004                        Srihari R. Sangli
                                                       Procket Networks


      Avoid BGP Best Path Transitions from One External to Another


                 draft-ietf-idr-avoid-transition-00.txt


1. 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
   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 propose a revision to the BGP route selection
   rules that would avoid unnecessary best path transitions between
   external paths under certain conditions. The proposed revision would
   help the overall network stability, and more importantly, would
   eliminate certain BGP route oscillations in which more than one
   external paths from one router contribute to the churn.









Chen & Sangli                                                   [Page 1]

Internet Draft   draft-ietf-idr-avoid-transition-00.txt         May 2004


3. Introduction

   The last two steps of the BGP route selection (Sect. 9.1.2.2, [1])
   involve comparing the BGP identifiers and the peering addresses. The
   BGP identifier, (treated either as an IP address, or just an integer
   [2]) for a BGP speaker is allocated by the AS to which the speaker
   belongs. As a result, for a local BGP speaker, the BGP identifier of
   a route received from an external peer is just an random number. When
   routes under consideration are from external peers, the result from
   the last two steps of the route selection is therefore "random" as
   far as the local BGP speaker is concerned.

   It is based on this observation that we propose a revision to the BGP
   route selection rules that would avoid unnecessary best path
   transitions between external paths under certain conditions. The
   proposed revision would help the overall network stability, and more
   importantly, would eliminate certain BGP route oscillations in which
   more than one external paths from one router contribute to the churn.


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 [5].


5. The Algorithm

   Consider the case in which the existing best path A is from an
   external peer, and another external path B is then selected as the
   new best path by the route selection algorithm described in [1].
   When neither Path A nor Path B is eliminated by the route selection
   algorithm prior to Step f) - BGP identifier comparison (Sect. 9.1.2.2
   [1]), we propose that the existing best path (Path A) be kept as the
   best path (thus avoiding switching the best path to Path B).

   This algorithm SHOULD NOT be applied when either path is from a BGP
   Confederation peer.

   In addition, the algorithm SHOULD NOT be applied when both paths are
   from peers with identical BGP identifier (i.e., there exist parallel
   BGP sessions between two routers). As the peering addresses for the
   parallel sessions are typically allocated by one AS (possibly with
   route selection considerations), the algorithm (if applied) could
   impact the existing routing setup. Furthermore, by not applying the
   algorithm, the allocation of peering addresses would remain as a
   simple and effective tool in influencing route selection when



Chen & Sangli                                                   [Page 2]

Internet Draft   draft-ietf-idr-avoid-transition-00.txt         May 2004


   parallel BGP sessions exist.


6. The Benefits

   The proposed revision to the BGP route selection rules avoids
   unnecessary best path transitions between external paths under
   certain conditions. Clearly the revision would help reduce routing
   and forwarding changes in a network, thus help the overall network
   stabilities.

   More importantly, as shown in the following example, the proposed
   revision can be used to eliminate certain BGP route oscillations in
   which more than one external paths from one router contribute to the
   churn.  Note however, that there are permanent BGP route oscillation
   scenarios [3] that the mechanism described in this document does not
   eliminate.

   Consider the example in Fig. 1 where

      o R1, R2, R3 and R4 belong to one AS
      o R1 is a route reflector with R3 as its client.
      o R2 is a route reflector with R4 as its client.
      o The IGP metrics are as listed.
      o External paths (a), (b) and (c) are as described in Fig. 2.


                  +----+      40      +----+
                  | R1 |--------------| R2 |
                  +----+              +----+
                     |                   |
                     |                   |
                     | 10                | 10
                     |                   |
                     |                   |
                  +----+              +----+
                  | R3 |              | R4 |
                  +----+              +----+
                 /      \                |
                /        \               |
              (a)        (b)            (c)

                          Figure 1


                Path    AS     MED   Identifier
                 a       1       0        2
                 b       2      20        1



Chen & Sangli                                                   [Page 3]

Internet Draft   draft-ietf-idr-avoid-transition-00.txt         May 2004


                 c       2      10        5

                          Figure 2


   Due to the interaction of route reflection [4] and MEDs, the best
   path on R1 keeps churning between (a) and (c), and the best path on
   R3 keeps churning between (a) and (b).

   With the proposed algorithm R3 would not switch the best path from
   (a) to (b) even after R1 withdraws (c) toward its clients, and that
   is enough to stop the route oscillation.

   Although this type of route oscillations can also be eliminated by
   other route reflection enhancements being developed, the proposed
   algorithm is very simple and can be deployed immediately.


7. Remarks

   The proposed algorithm is backward-compatible, and can be deployed on
   a per-node basis. The deployment of the algorithm is highly
   recommended on a router with multiple external BGP peers (especially
   the ones connecting to an inter-exchange point).

   Compared to the existing behavior, the proposed algorithm may
   introduce some "non-determinism" in the BGP route selection -
   although one can argue that the BGP Identifier comparison in the
   existing route selection has already introduced some "randomness" as
   described in the introduction section.  Such "non-determinism" or
   "randomness" has not been shown to be detrimental in practice, and
   can be completely eliminated by using the existing mechanisms (such
   as setting LOCAL_PREF or MED) if so desired.


8. Security Considerations

   This extension does not introduce any security issues.













Chen & Sangli                                                   [Page 4]

Internet Draft   draft-ietf-idr-avoid-transition-00.txt         May 2004


9. Acknowledgments

   The idea presented was inspired by a route oscillation case observed
   on the BBN/Genuity backbone in 1998 while both authors were at Cisco
   Systems. The algorithm was also implemented at that time.

   The authors would like to thank Yakov Rekhter and Ravi Chandra for
   their comments on the initial idea.


10. References

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

   [2] E. Chen and J. Yuan, "AS-wide Unique BGP Identifier for BGP-4",
   <draft-ietf-idr-bgp-identifier-03.txt>, December 2003.

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

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

   [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.


11. Author Information

   Enke Chen
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134
   e-mail: enke@redback.com

   Srihari R. Sangli
   Procket Networks, Inc.
   1100 Cadillac Court
   Milpitas, CA 95035
   e-mail: srihari@procket.com









Chen & Sangli                                                   [Page 5]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/