Network Working Group Daniel Walton Internet Draft Alvaro Retana Expiration Date: January 2006 Enke Chen Cisco Systems BGP Persistent Route Oscillation Solution draft-walton-bgp-route-oscillation-stop-01.txt 1. Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-type route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first set, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED-type route oscillations (subject to certain commonly adopted topological constrains). Walton, et al Expiration Date January 2006 [Page 1] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 3. Introduction As documented in [4], the routing information reduction by BGP Route Reflection [2] or BGP Confederation [3] can result in persistent IBGP route oscillations with certain routing setup and network topologies. Except for a couple artificially engineered network topologies, the MED attribute [1] has played a pivotal role in virtually all of the known persistent IBGP route oscillations. For the sake of brevity, we use the term "MED-type route oscillation" hereafter to refer to a persistent IBGP route oscillation in which the MED plays a role. In order to eliminate the MED-type route oscillations and to achieve consistent routing in a network, clearly a route reflector or a confederation ASBR needs to advertise more than just the best path for an address prefix. Our goal is to identify the "right" set of paths for an address prefix that needs to be advertised by a route reflector or a confederation ASBR. In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-type route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a set of the first set, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED-type route oscillations (subject to certain commonly adopted topological constrains). These paths can be advertised using the mechanism described in [5] for advertising multiple paths. The deployment of the mechanisms requires only minor software changes for the vast majority of the BGP speakers in a network. 4. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. Walton, et al Expiration Date January 2006 [Page 2] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 5. Advertise the Available Paths Observe that in a network that maintains a full IBGP mesh all the BGP speakers have consistent and equivalent routing information. Such a network is thus free of the MED-type route oscillations and other routing inconsistencies such as forwarding loops. Therefore one approach is to allow a route reflector or a confederation ASBR to advertise all the available paths for an address prefix. Clearly this approach would yield the same amount of routing information and achieve the same routing consistency as the full IBGP mesh in a network. This approach can be implemented using the mechanism described in [5] for advertising multiple paths, and in this case the path identifier of a path would be the BGP Identifier of the BGP speaker that originates the route in the AS (or the Confederation). 6. Advertise the Group Best Paths The term neighbor-AS for a route refers to the neighboring AS from which the route was received. The calculation of the neighbor-AS is specified in Sect. 9.1.2.2 of [1], and Section 7.2 of [3]. By definition the MED is comparable only among routes with the same neighbor-AS. As a result, the route selection procedures specified in [1] would conceptually involve two steps: first organize the paths for an address prefix into groups according to their respective neighbor-ASどヨs, and calculate the most preferred one (termed "Group Best Path") for each of the groups; Then calculate the overall best path among all the Group Best Paths. As a generally recommended [2, 3] and widely adopted practice, a route reflection cluster or a confederation sub-AS should be designed such that the IGP metrics for links within a cluster (or confederation sub-AS) are smaller than the IGP metrics for the links between the clusters (or confederation sub-AS). This practice helps achieve consistent routing within a route reflection cluster or a confederation sub-AS. Observe also that in a network that maintains full IBGP mesh only the paths that survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons [1] would contribute to the route selection in the network. When the aforementioned practice for devising a route reflection cluster or confederation sub-AS is followed in a network, we claim that the advertisement of all the Group Best Paths by a route Walton, et al Expiration Date January 2006 [Page 3] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 reflector or a confederation ASBR is sufficient to eliminate the MED- type route oscillations in the network. This claim can be validated as the following. Consider a route reflection cluster that sources one or more paths that would survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons among all the paths in the network. One of these surviving paths would be selected as the Group Best Path by the route reflector in the cluster. Due to the constrain on the IGP metrics as described previously, this path would remain as the Group Best Path and would be advertised to all other clusters even after a path is received from another cluster. On the other hand, when no path in a route reflection cluster would survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons among all the paths in the network, the Group Best Path (when exists) for a route reflector would be from another cluster. Clearly the advertise of the Group Best Path by the route reflector to the clients only depends on the paths received from other clusters. Therefore there is no MED-type route oscillation in the network as the advertisement of a Group Best Path to a peer does not depend on the paths received from that peer. The claim for the confederation can be validated similarly. Note that a Group Best Path for an address prefix can be identified by the combination of the address prefix and the neighbor-AS. Thus this approach can be implemented using the mechanism described in [5] for advertising multiple paths, and in this case the path identifier of a path would be the neighbor-AS of the path. It should be noted that the approach of advertising the Group Best Paths requires certain topological constrains to be satisfied in order to eliminate the MED-type route oscillation. In addition, the BGP speakers still depend on the route selection by the route reflector or the confederation ASBR. As the route selection involves the comparison of the nexthopどヨs IGP metrics which are specific to a particular BGP speaker, the routing information advertised by a route reflector or a confederation ASBR may still be inadequate to avoid other routing inconsistencies such as forwarding loops in certain networks. Walton, et al Expiration Date January 2006 [Page 4] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 7. Route Reflection and Confederation To allow a a route reflector or a confederation ASBR to advertise either the Available Paths or Group Best Paths using the mechanism described in [5], the following revisions are proposed for BGP route reflection and BGP Confederation. 7.1. Route Reflection Depending on the configuration a route reflector SHOULD include the for a particular in the ADD-PATH Capability [5] advertised to an IBGP peer. The Path Identifier Type could either be "AS Number Based", or "BGP Identifier Based". A route reflector SHOULD advertise to its clients the Group Best Paths (or the Available Paths) received from its non-client IBGP peers. A route reflector SHOULD advertise to its non-client IBGP peers the Group Best Paths (or the Available Paths) received from its clients. A route reflector MAY also advertise to its clients the Group Best Paths (or the Available Paths) received from its clients. 7.2. Confederation Depending on the configuration a confederation ASBR SHOULD include the for a particular in the ADD-PATH Capability [5] advertised to an IBGP peer. The Path Identifier Type could either be "AS Number Based", or "BGP Identifier Based". A confederation ASBR SHOULD advertise to its IBGP peers the Group Best Paths (or the Available Paths) received from its confederation external peers. A confederation ASBR SHOULD advertise to confederation external peers the Group Best Paths (or the Available Paths) received from its IBGP peers. Walton, et al Expiration Date January 2006 [Page 5] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 8. Deployment Considerations Some route oscillations, once detected, can be eliminated by simple configuration workarounds. As carrying additional paths impacts the memory usage and routing convergence in a network, it is recommended that the impact be evaluated and the approach of using a configuration workaround be considered in deciding whether to deploy the proposed mechanism in a network. While the route reflectors or confederation ASBRs in a network need to advertise the Group Best Paths or Available Paths, the vast majority of the BGP speakers in the network only need to receive the Group Best Paths or Available Paths, which would involve just minor software changes: - Advertise the ADD-PATH Capability [5] without any . - Process received UPDATE messages based on the address prefix and the path identifier. To deploy the mechanism of advertising multiple paths in a network, it is recommended that the BGP speakers (one at a time) be first upgraded to a software version that supports the new capability, and be configured to advertise the new capability without any . Then on a per route reflection cluster or confederation sub- AS basis, the route reflectors or the confederation ASBRs are re- configured to include the appropriate in the capability advertised. It should be emphasized that in order to eliminate the MED-type route oscillations in a network using the approach of advertising the Group Best Paths, the recommended practice for devising a route reflection cluster or confederation sub-AS with respect to the IGP metrics [2, 3] should be followed. It is expected that the approach of advertising the Group Best Paths would be adequate to achieve consistent routing for the vast majority of the networks. For a network that has large number of alternate paths, the approach should be a good choice as the number of paths advertised by a reflector or a confederation ASBR is bounded by the number of the neighbor-ASどヨs for a particular address prefix. The additional states for an address prefix would also be per neighbor-AS based rather than per path based. The number of the neighbor-ASどヨs for a particular address prefix is typically small because of the limited number of upstream providers for a customer and the nature of advertising only customer routes at the inter-exchange points. The approach of advertising the Group Best Paths, however, may still Walton, et al Expiration Date January 2006 [Page 6] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 be inadequate for certain networks to avoid other routing inconsistencies such as forwarding loops. The required topological constrains could also be operationally challenging. In these cases the approach of advertising the Available Paths may be used. In general this approach would result in larger number of paths to be advertised, and may require per-path states to be maintained. Note that the number of paths that need to be maintained and advertised can be greatly reduced by accepting the IGP metric based MEDs from other peering networks. 9. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing BGP [6]. 10. Acknowledgments This document combines prior work on "BGP Persistent Route Oscillation Solution" by Daniel Walton, David Cook, Alvaro Retana, and John Scudder, with prior work on "Advertisement of the Group Best Paths" by Enke Chen, and Naiming Shen. The current authors wish to thank all these authors for their contribution. 11. References [1] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. [2] Bates, T., R. Chandra, and E. Chen "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [3] Traina, P., D. McPherson, and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001. [4] D. McPherson, V, Gill, D. Walton, and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002. [5] D. Walton, A. Retana, and E. Chen, "Advertisement of Multiple Paths in BGP", draft-walton-bgp-add-path-03.txt, July 2005. [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Walton, et al Expiration Date January 2006 [Page 7] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 Levels", BCP 14, RFC 2119, March 1997. 12. Authorsどヨ Addresses Daniel Walton Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Email: dwalton@cisco.com Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Email: aretana@cisco.com Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 Email: enkechen@cisco.com 13. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Walton, et al Expiration Date January 2006 [Page 8] draft-walton-bgp-route-oscillation-stop-01.txt July 2005 14. Full Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Walton, et al Expiration Date January 2006 [Page 9]