Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: July 2004 Srihari R. Sangli Procket Networks Avoid BGP Best Path Transition from One External to Another draft-chen-bgp-avoid-transition-01.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-01.txt January 2004 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-01.txt January 2004 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-01.txt January 2004 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 and Ravi Chandra for their comments on the initial idea. 8. 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", , December 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-01.txt January 2004 Chen & Sangli [Page 5]