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-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 This document proposes a simple revision to Route Reflection that allows a Route Reflector to advertise the best path from its clients to other clusters when the overall best path for the RR differs. The availability of the routing information to other clusters helps achieve stable route selection, and moves route reflection closer to IBGP full-mesh equivalence in terms of routing information. It has been shown that the proposed mechanism eliminates a number of persistent route oscillation cases involving Route Reflection. Chen [Page 1] Internet Draft draft-chen-rr-oscillation-reduce-00.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 advertise the best path from its clients to other clusters when the overall best path for the RR differs. The availability of the routing information to other clusters helps achieve stable route selection, and moves route reflection closer to IBGP full-mesh equivalence in terms of routing information. It has been shown that the proposed mechanism eliminates a number of persistent route oscillation cases 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 to a non-client IBGP peer and be considered in route selection. The following modification is proposed for a RR: In addition to calculating the overall best path among all the received paths, a RR could also calculate a best path (termed "client best path") among all the paths received from its clients. 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 client best path was advertised to the peer previously. It is noted that the advertisement of the client best path is not useful and should not be sent when the overall best path wins over the client best path prior to (and including) the Chen [Page 2] Internet Draft draft-chen-rr-oscillation-reduce-00.txt June 2002 step of MED comparison in the route selection procedure [3, Sect. 9.1]. As a result of this modification, the client best path (when exists and if necessary) can be advertised to other clusters, and be considered in their route selection. 5. Remarks The proposed mechanism alleviates to some degree, but does not resolve the concern of routing information reduction with Route Reflection. The proposed mechanism may still 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. 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. Chen [Page 3] Internet Draft draft-chen-rr-oscillation-reduce-00.txt June 2002 8. Acknowledgments The author would like to thank Naiming Shen and Jenny Yuan for review and comment. 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. 10. Author Information Enke Chen Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 Email: enke@redback.com Chen [Page 4]