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


      Avoid BGP Best Path Transition from One External to Another


                 draft-chen-bgp-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 an algorithm that would help improve the
   overall network stability by avoiding BGP best path transition from
   one external to another (under certain conditions).












Chen & Sangli                                                   [Page 1]





Internet Draft   draft-chen-bgp-avoid-transition-00.txt        June 2003


3. Introduction

   The last two steps of BGP route selection [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 paths
   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 speaker is concerned.

   It is based on this observation that we propose an algorithm that
   would help improve the overall network stability by avoiding BGP best
   path transition from one external to another (under certain
   conditions).


4. The Algorithm

   Consider the case in which the existing best path is from an external
   peer, and another external path is then selected as the new best path
   by the route selection algorithm described in [1].  When neither path
   is eliminated by the route selection algorithm prior to the step of
   BGP identifier comparison, we propose that the existing best path be
   kept as the best path (thus avoiding the best path transition).

   This algorithm is not applicable 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
   parallel BGP sessions exist.












Chen & Sangli                                                   [Page 2]





Internet Draft   draft-chen-bgp-avoid-transition-00.txt        June 2003


5. The Benefits

   The algorithm helps improve the overall network stability in the
   following aspects.


5.1. Favor a Stable Path

   The algorithm helps select a stable external path by avoiding the
   best path transition.


5.2. Reduce Route Oscillation

   The algorithm helps reduce the level of BGP dynamics. As a result, it
   can be used as a simple and efficient tool to eliminate certain
   permanent ibgp route oscillation [3].

   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 External paths (a), (b) and (c) are as described in Fig. 2.


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

                          Figure 1


                Path    AS     MED   Identifier
                 a       1       0        2
                 b       2      20        1
                 c       2      10        5



Chen & Sangli                                                   [Page 3]





Internet Draft   draft-chen-bgp-avoid-transition-00.txt        June 2003


                          Figure 2

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


6. Security Considerations

   This extension does not introduce any security issues.


7. Acknowledgments

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

   The authors would like to thank Yakov Rekhter for his comment on the
   initial idea.


8. References

   [1] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4
   (BGP-4)", draft-ietf-idr-bgp4-20.txt, 03/03

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

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


9. Author Information

   Enke Chen
   Redback Networks, Inc.
   350 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 4]





Internet Draft   draft-chen-bgp-avoid-transition-00.txt        June 2003





















































Chen & Sangli                                                   [Page 5]