Internet DRAFT - draft-chen-rr-oscillation-reduce
draft-chen-rr-oscillation-reduce
Network Working Group Enke Chen
Internet Draft Redback Networks
Expiration Date: December 2002
BGP Route Oscillation Reduction with Route Reflection
draft-chen-rr-oscillation-reduce-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
This document proposes a simple revision to Route Reflection that
allows a Route Reflector to send a route advertisement (instead of a
route withdraw) in certain cases. The route advertisement helps
narrow the gap between Route Reflection and IBGP full-mesh in terms
of routing information. It has been shown that the proposed mechanism
helps achieve stable route selection and eliminate a number of
persistent route oscillations involving Route Reflection.
Chen [Page 1]
Internet Draft draft-chen-rr-oscillation-reduce-01.txt June 2002
3. Introduction
As documented in [1], the routing information reduction by BGP Route
Reflection [2] can result in persistent route oscillations with
certain routing setup and network topologies.
This document proposes a simple revision to Route Reflection that
allows a Route Reflector to send a route advertisement (instead of a
route withdraw) in certain cases. The route advertisement helps
narrow the gap between Route Reflection and IBGP full-mesh in terms
of routing information. It has been shown that the proposed mechanism
helps achieve stable route selection and eliminate a number of
persistent route oscillations involving Route Reflection.
The proposed mechanism works within the current BGP protocol [3] that
limits route advertisement to only one path per prefix. In addition,
only the Route Reflectors need to be upgraded. One can upgrade one
router at a time when required, and then immediately benefit from the
route oscillation reduction or elimination.
4. Modification to Route Reflection
Currently a Route Reflector (RR) follows the basic BGP principle that
only the best path is advertised to a BGP peer. Therefore when the
overall best path for a RR is from a non-client IBGP peer, none of
the paths from its clients would be advertised by the RR to a non-
client IBGP peer and be considered in route selection. Similarly
when the the overall best path for a RR is from a client, none of the
paths from other clusters would be advertised by the RR to its
clients and be considered in route selection.
In order to increase the routing information advertised by a RR, the
following modification is proposed:
In addition to calculating the overall best path among all the
received paths, a RR may also calculate a best path (termed
"client best path") among all the paths received from its
clients. It may also calculate a best path (termed "non-client
best path") among all the paths received from non-client IBGP
peers.
When the client best path for a RR exists, and the overall
best path for the RR is from a non-client IBGP peer, the RR
may advertise the client best path to all non-client IBGP
peers. When the client best path becomes non-existence, or
when it should no longer be advertised, a replacement path or
route withdraw must be sent to a non-client IBGP peer if a
Chen [Page 2]
Internet Draft draft-chen-rr-oscillation-reduce-01.txt June 2002
client best path was advertised to the peer previously.
Consider the case in which the clients of a RR maintain full
IBGP mesh, and the RR does not reflect routes among the client.
When the non-client best path for the RR exists, and the overall
best path for the RR is from a client, the RR may advertise
the non-client best path to all clients. When the non-client
best path becomes non-existence, or when it should no longer be
advertised, a replacement path or route withdraw must be sent to
a client if a non-client best path was advertised to the peer
previously.
It is noted that the advertisement of the client best path (or
the non-client best path) is not useful and should not be sent
when the overall best path wins over the client best path (or
the non-client best path) prior to (and including) the step of
MED comparison in the route selection procedure [3, Sect. 9.1].
As a result of this modification, the additional routing information
(when exists and if necessary) can be advertised by a RR, and be
considered in route selection.
5. Remarks
The proposed mechanism alleviates to some degree, but does not fully
resolve the concern of routing information reduction by Route
Reflection. It is possible that the proposed mechanism may not be
adequate for certain persistent route oscillation cases in which the
advertisement of multiple paths for a prefix (as proposed in [4]) may
be required for their resolution.
It should be noted that compared to the existing mechanism of Route
Reflection, the proposed revision may cause memory usage in a network
to increase due to the advertisement of additional routing
information. The memory usage, however, should be no more than the
usage with doing closest-exit-routing in a network.
Chen [Page 3]
Internet Draft draft-chen-rr-oscillation-reduce-01.txt June 2002
6. Intellectual Property Considerations
Redback Networks, Inc. may seek patent protection on some of the
technology described in this Internet Draft. If technology in this
document is adopted as a standard, Redback Networks agrees to
license, on reasonable and non-discriminatory terms, any patent
rights it obtains covering such technology to the extent necessary to
comply with the standard.
7. Security Considerations
This document introduces no new security concerns to BGP or other
specifications referenced in this document.
8. Acknowledgments
The author would like to thank Naiming Shen, Jenny Yuan, and Pedro
Marques for their review and comments.
9. References
[1] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent
Route Oscillation Condition", Work in Progress (draft-ietf-idr-
route-oscillation-01), February 2002.
[2] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Work in Progress (draft-ietf-idr-bgp4-17), January 2002
[4] Walton, D., Cook, D., Retana, A., Scudder, J., "Advertisement of
Multiple Paths in BGP", Work in Progress (draft-walton-bgp-add-
paths-00), May 2002.
Chen [Page 4]
Internet Draft draft-chen-rr-oscillation-reduce-01.txt June 2002
10. Author Information
Enke Chen
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
Email: enke@redback.com
Chen [Page 5]
