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]