Internet DRAFT - draft-scudder-idr-ebgp-rr
draft-scudder-idr-ebgp-rr
Internet Engineering Task Force J. Scudder
Internet-Draft Juniper Networks
Updates: 4456 (if approved) October 18, 2012
Intended status: Standards Track
Expires: April 21, 2013
Considerations for Route Reflection and EBGP
draft-scudder-idr-ebgp-rr-02
Abstract
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 updates RFC 4456 by explaining 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.
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 April 21, 2013.
Copyright Notice
Copyright (c) 2012 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
Scudder Expires April 21, 2013 [Page 1]
Internet-Draft RR and EBGP October 2012
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.
1. Introduction
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 updates RFC 4456 by explaining 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.
1.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 RFC 2119 [RFC2119].
2. Terminology
In addition to the terms defined in [RFC4271] Section 1.1 and in
[RFC4456], this document makes use of the following:
ASBR: Autonomous System Border Router. See EBGP Speaker.
RR: Route Reflector.
Redundant Route Reflector (or Redundant RR): Another route
reflector in the same cluster as the route reflector under
consideration, when both route reflectors are configured with the
same CLUSTER_ID.
EBGP Speaker: A BGP speaker that has one or more EBGP peerings,
and thereby learns one or more EBGP routes. (If no routes are
learned it is still an EBGP Speaker, but this is a case of "a tree
falling in a forest with no one to hear it.") ASBRs are EBGP
speakers, although not all EBGP speakers are ASBRs.
Scudder Expires April 21, 2013 [Page 2]
Internet-Draft RR and EBGP October 2012
3. Updates to RFC 4456
When deciding how a route reflector that is also an EBGP speaker
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:
o The speaker MUST NOT add a CLUSTER_LIST to EBGP-learned routes
when advertising them into IBGP.
o The attributes ORIGINATOR_ID and CLUSTER_LIST MUST NOT be sent to
EBGP peers. If received from an EBGP peer, these attributes MUST
be ignored and not propagated further; an error message MAY be
logged.
4. Deployment Considerations
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 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 EBGP speaker function, but
Scudder Expires April 21, 2013 [Page 3]
Internet-Draft RR and EBGP October 2012
such are beyond the scope of this document.)
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
This clarification to BGP does not change the underlying security
issues.
7. Acknowledgements
The author would like to thank Serpil Bayraktar, Jeff Haas, Senad
Palislamovic, Yakov Rekhter, Jim Uttaro and Kaliraj Vairavakkalai for
their input.
8. Normative References
[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.
Author's Address
John Scudder
Juniper Networks
Email: jgs@juniper.net
Scudder Expires April 21, 2013 [Page 4]
