Internet DRAFT - draft-chen-bgp-avoid-transition
draft-chen-bgp-avoid-transition
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",
<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.
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]
