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 described in the Simplified BSD License.

Table of Contents

1.  Requirements Language
2.  Introduction
3.  Modifications to BGP Route Reflection
4.  Security Considerations
5.  Acknowledgements
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

Route-reflection[RFC4456] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.) 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] (McPherson, D., Gill, V., Walton, D., and A. Retana, “Border Gateway Protocol (BGP) Persistent Route Oscillation Condition,” August 2002.).

This document follows from the work of [Flavel, Roughan] (Flavel, A. and M. Roughan, “Stable and flexible iBGP,” 2009.) 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] (Sobrinho, J., “An algebraic theory of dynamic network routing,” 2005.). 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] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.) introduces a CLUSTER_LIST attribute, to record which route-reflectors a route passes through. Further, [RFC4456] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.) modifies the route decision process described in [RFC4271] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) 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] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.). 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] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) 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 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] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.) describes a new step to be added to the [RFC4271] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) 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] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.) is modified such that the step above is instead inserted between steps b and c of [RFC4271] (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.).

Implementations SHOULD provide a means to allow the operator to configure whether to use this behaviour, or that of [RFC4456] (Bates, T., Chen, E., and R. Chandra, “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” April 2006.).

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

6.2. Informative References

Authors' Addresses