| Internet Engineering Task Force | J.S. Scudder |
| Internet-Draft | Juniper Networks |
| Updates: 4456 (if approved) | October 24, 2011 |
| Intended status: Standards Track | |
| Expires: April 26, 2012 |
Considerations for Route Reflection and EBGP
draft-scudder-idr-ebgp-rr-00
Although originally conceived of as a purely IBGP device, in some cases a route reflector may function as an EBGP speaker in addition to its role as envisioned in RFC 4456. When it does so, just like any other EBGP speaker it must advertise its routes to its IBGP peers. This document explains what behavior is required of a route reflector that also functions as an EBGP speaker. It also clarifies the use of the ORIGINATOR_ID and CLUSTER_LIST attributes in this environment.
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 April 26, 2012.
Copyright (c) 2011 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.
Although originally conceived of as a purely IBGP device, in some cases a BGP [RFC4271] route reflector may function as an EBGP speaker in addition to its role as envisioned in [RFC4456]. When it does so, just like any other EBGP speaker it must advertise its routes to its IBGP peers. This document explains what behavior is required of a route reflector that also functions as an EBGP speaker. It also clarifies the use of the ORIGINATOR_ID and CLUSTER_LIST attributes in this environment.
The cardinal observation is that the functions outlined in [RFC4456] apply exclusively to "reflected" routes, that is, IBGP routes that are propagated to IBGP peers.
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 [RFC2119].
In addition to the terms defined in [RFC4271] Section 1.1 and in [RFC4456], this document makes use of the following:
When deciding how a route reflector that is also an ASBR should propagate EBGP routes into IBGP, the key observation is that [RFC4456] deals only with "reflected" routes, i.e. IBGP routes that are propagated into IBGP. For EBGP-learned routes, the BGP speaker is the only source of routes for its AS. For this reason, the restrictions and assumptions that apply to reflected routes do not apply to EBGP-learned routes. For the purposes of such routes, the BGP speaker functions as a normal IBGP router. For example, the [RFC4456] stricture against modifying the NEXT_HOP, AS_PATH, LOCAL_PREF, and MED attributes does not apply to EBGP-learned routes that are propagated into IBGP.
Specific updates to [RFC4456] are:
If route reflectors are deployed in an Autonomous System such that no two route reflectors have the same CLUSTER_ID, then there are no "redundant route reflectors" (as the term is used herein) and thus, the considerations regarding redundant RRs in Section 3 as well as below are moot.
A RR that serves as an EBGP speaker SHOULD have an IBGP peering with any redundant RR. It SHOULD advertise the same EBGP-learned routes over this peering that it advertises to any other IBGP peer. It MAY suppress reflection of any IBGP-learned routes to the redundant RR. (Recall that according to [RFC4456] Section 8, such routes would be ignored by the redundant RR anyway due to a loop in the CLUSTER_LIST.) The peering MAY be omitted if the route reflectors in question are control plane-only devices not in the forwarding path of any traffic, or if the network in question uses some form of tunneled or label-switched forwarding. The cost of omitting the peering is that certain low-probability failure modes may cause unnecessary unreachability -- specifically, if the EBGP-speaking RR were to lose its session to one or more of its RR clients, reachability to the EBGP-learned routes would be preserved if a session remained up to its redundant RR peer. (Similar considerations apply even to route reflectors which do not have a collocated ASBR function, but such are beyond the scope of this document.)
This document makes no request of IANA.
This clarification to BGP does not change the underlying security issues.
The author would like to thank Serpil Bayraktar, Jeff Haas, Yakov Rekhter, Jim Uttaro and Kaliraj Vairavakkalai for their input.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [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. |