Network Working Group Enke Chen Internet Draft Jenny Yuan Expiration Date: August 2004 Redback Networks Deterministic Route Redistribution into BGP draft-chen-bgp-redist-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 In this document we propose an enhancement to the BGP route selection algorithm that would make the interaction of redistributed routes and other BGP routes deterministic, thus facilitating the deployment of various routing requirements. The proposed enhancement is backward compatible. Chen & Yuan [Page 1] Internet Draft draft-chen-bgp-redist-00.txt February 2004 3. Introduction A routing protocol usually downloads its best (or active) routes to the RIB, which in turn selects the best routes to program the forwarding engine. When comparing routes from different protocols, RIB typically uses an "admin distance" (or "protocol preference") as the tie breaker. The "admin distance" is a value assigned to each route being downloaded to RIB, and it is a local matter how the values are assigned and compared. On the other hand, the BGP route selection algorithm (as specified in [1]) involves comparing the LOCAL_PREF, AS_PATH, MED, IGP Metric and other parameters of all the paths involved. The BGP best path usually becomes the candidate for downloading to the RIB, and for advertising to BGP peers. It is common to redistribute routes from other routing protocols (such as RIP and static routing) into BGP in order to implement various routing policies. A redistributed route typically has empty AS_PATH attribute, and zero IGP metric. As detailed in the following section, the interaction of redistributed routes and other BGP routes are sometimes order dependent, and the BGP best path selected can thus be non- deterministic. Consequently, complicated configurations are sometimes required in order to deploy simple routing requirements (such as primary and backup). In this document we propose an enhancement to the BGP route selection algorithm that would make the interaction of redistributed routes and other BGP routes deterministic, thus facilitating the deployment of various routing requirements. The proposed enhancement is backward compatible. 4. The Problem One common routing setup for a multi-homed customer is to treat one connection as the primary, and another as the backup. Consider the following example in which there are two customer connections, the primary path A and the backup path B. Routers R1, R2 and R3 are part of a provider network and IBGP sessions are maintained among them. The customer route X is statically routed on R1 and R2, and is redistributed into BGP. On R2, the backup path for X is configured with a less preferred "admin distance" than any other path for X. Chen & Yuan [Page 2] Internet Draft draft-chen-bgp-redist-00.txt February 2004 +----+ | R3 | +----+ / \ / ibgp \ +----+ +----+ | R1 |----------| R2 | +----+ +----+ || | A || | B || | X X Let us take a look at the BGP table and RIB on R2. There are potentially two BGP paths for X, one locally redistributed due to path B, and one learned from R1. Depending on the order of arrival of these two paths, the routing behavior may differ: (1) When the IBGP path from R1 gets into the BGP table first, it would be selected as the best path, and then downloaded to the RIB. Due to the more preferred value of the "admin distance", the IBGP path would be selected as the best path in RIB, and the local path B would serve as a backup and would not be redistributed into BGP (assuming that only the active path in RIB is redistributed into BGP). As a result, R1, R2, R3 and the rest of the network would converge to the primary path on R1. (2) When the IBGP path from R1 gets into the BGP table later than the locally redistributed route does, then the two paths in the BGP table need to be compared for route selection. By default the LOCAL_PREF, AS-PATH, and MED are the same. Due to its IGP metric, the locally redistributed route would be selected as the best path, and thus propagated to other IBGP peers. In this scenario the intended backup path B is selected as the primary path on R2, and some portions of the network (like R3) may converge to use the path from R2 as well. To eliminate the non-deterministic routing behavior in this case, one approach is to configure lower LOCAL_PREF (and modify any other vendor specific route selection criteria preceding the LOCAL_PREF comparison) for the redistributed route. However, like all route- specific BGP configurations, this approach tend to increase the operational complexity and cost. An alternative solution is proposed in the next section that does not require any route-specific BGP configurations. Chen & Yuan [Page 3] Internet Draft draft-chen-bgp-redist-00.txt February 2004 5. The Proposed Solution We propose that the following step be added as the first step in the BGP route selection: When comparing a locally redistributed route with one that is received from a BGP peer, favor the one with a more preferred "admin distance". The "admin distance" for a BGP route is obtained as follows: For a locally redistributed route, the "admin distance" is inherited from the route being redistributed from RIB. For a route received from a BGP peer, the "admin distance" is the same as the "admin distance" assigned to the route for the purpose of RIB downloading (regardless of whether it is actually downloaded). The proposed revision is backward compatible. It is noted that the proposed algorithm is generally applicable when a route is redistributed from one protocol into another protocol. 6. Security Considerations This extension does not introduce any security issues. 7. Intellectual Property Considerations Redback Networks may have intellectual property rights claimed in regard to some of the specification contained in this document. 8. Acknowledgments The authors would like to thank Naiming Shen and Acee Lindem for their inputs and review. Chen & Yuan [Page 4] Internet Draft draft-chen-bgp-redist-00.txt February 2004 9. References [1] Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-23.txt, November 2003. 10. Author Information Enke Chen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 e-mail: enke@redback.com Jenny Yuan Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 e-mail: jenny@redback.com Chen & Yuan [Page 5]