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]