Inter-Domain Routing Working Group P. Jakma, Ed. Internet-Draft Uni. of Glasgow Updates: 4456 (if approved) A. Flavel Intended status: Standards Track AT&T Labs Expires: May 19, 2011 M. Roughan Uni. of Adelaide November 15, 2010 Stable iBGP Decision Process with Route-Reflection draft-jakma-idr-stable-bgp-rr-00 Abstract This document describes a simple modification to the BGP decision process, which solves the issue of oscillation in iBGP seen when route-reflection is used. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 19, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Jakma, et al. Expires May 19, 2011 [Page 1] Internet-Draft Stable iBGP Route-Reflection November 2010 described in the Simplified BSD License. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Modifications to BGP Route Reflection . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Jakma, et al. Expires May 19, 2011 [Page 2] Internet-Draft Stable iBGP Route-Reflection November 2010 1. Requirements Language 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 [RFC2119]. 2. Introduction Route-reflection[RFC4456] is commonly used to enhance the scalability of iBGP, by reducing full-meshing requirements. It is well-known that its use can introduce convergence problems, particularly oscillations. Even with coherent intra-AS policy and IGP configuration such problems can occur due to the effect of the MED attribute[RFC3345]. This document follows from the work of [Flavel, Roughan] which shows iBGP oscillations can be solved by a slight modification to the iBGP route selection process, and provably so by the application of the routing algebra of [Sobrinho]. Indeed, where iBGP follows the underlying topology, (that is, iBGP sessions never transit through other iBGP routers) with this modification iBGP provably converges on optimal routes. [RFC4456] introduces a CLUSTER_LIST attribute, to record which route- reflectors a route passes through. Further, [RFC4456] modifies the route decision process described in [RFC4271] to consider the CLUSTER_LIST length in between steps f) and g). The suggested solution is to instead insert the CLUSTER_LIST tie- break step in between b) and c) of [RFC4271]. That is, the iBGP hop- count - which CLUSTER_LIST reflects - is used to select between routes before considering MEDs. This ensures that routes are ordered such that iBGP will converge, rather than oscillate. The semantics of the MED obviously then are weakened as it now can be overridden by details of the iBGP topology. As a consequence different speakers within an AS may select different routes to a neighbouring AS, where normal [RFC4271] speakers would select the same route based on MED values. This is perhaps a small price to pay for having a convergent iBGP, and the preferable outcome for most. Further, RR hierarchies can already cause MEDs to be ignored in such a way. In practical terms, this means MED can no longer can be used where ASes wish to distinguish between primary and solely secondary, backup links with a neighbour, such that the backup link should normally never be used. Instead, some other mechanism must be used, such as Jakma, et al. Expires May 19, 2011 [Page 3] Internet-Draft Stable iBGP Route-Reflection November 2010 community-based preference adjustments. This proposal would also affect any cases where MEDs are set on ingress as an intra-AS metric for routes with equal AS_PATH lengths # to steer traffic to preferred egress points. Such scenarios would imply always comparing MED values, regardless of which neighbouring AS a route was received from. In such cases, presuming MED values are never reset when routes are propagated, it is safe to instead put the CLUSTER_LIST length check after the MED check. Safer still would be to define a specific attribute to carry an interior egress preference metric, to be evaluated after the AS_PATH length and defined to be monotonic. 3. Modifications to BGP Route Reflection Section 9 of [RFC4456] describes a new step to be added to the [RFC4271] route decision process as follows: a BGP Speaker SHOULD prefer a route with the shorter CLUSTER_LIST length. The CLUSTER_LIST length is zero if a route does not carry the CLUSTER_LIST attribute. [RFC4456] is modified such that the step above is instead inserted between steps b and c of [RFC4271]. Implementations SHOULD provide a means to allow the operator to configure whether to use this behaviour, or that of [RFC4456]. 4. Security Considerations No new considerations are raised by this document. 5. Acknowledgements The editor would like to thank Stephen Strowes and Martin Ellis for their comments. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Jakma, et al. Expires May 19, 2011 [Page 4] Internet-Draft Stable iBGP Route-Reflection November 2010 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. 6.2. Informative References [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002. [Flavel, Roughan] Flavel, A. and M. Roughan, "Stable and flexible iBGP", Proc. of the ACM SIGCOMM 2009 pages 183-194, 2009, . [Sobrinho] Sobrinho, J., "An algebraic theory of dynamic network routing", IEEE/ACM Trans. Netw. vol 13, num 5, pages 1160- 1173, 2005, . [Griffin, Wilfong] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", Proc. of the ACM SIGCOMM 2002 pages 17-29, 2002, . Authors' Addresses Paul Jakma (editor) University of Glasgow School of Computing Science Lilybank Gardens Glasgow G12 8QQ Scotland Email: paulj@dcs.gla.ac.uk Jakma, et al. Expires May 19, 2011 [Page 5] Internet-Draft Stable iBGP Route-Reflection November 2010 Ashley Flavel AT&T Labs Middletown New Jersey 07748 USA Email: ashley.flavel@gmail.com Matthew Roughan University of Adelaide School of Mathematical Sciences Adelaide Australia Email: matthew.roughan@adelaide.edu.au Jakma, et al. Expires May 19, 2011 [Page 6]