idnits 2.17.1 draft-scudder-idr-ebgp-rr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4456, updated by this document, for RFC5378 checks: 2004-04-14) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2012) is 4180 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Scudder 3 Internet-Draft Juniper Networks 4 Updates: 4456 (if approved) October 18, 2012 5 Intended status: Standards Track 6 Expires: April 21, 2013 8 Considerations for Route Reflection and EBGP 9 draft-scudder-idr-ebgp-rr-02 11 Abstract 13 Although originally conceived of as a purely IBGP device, in some 14 cases a route reflector may function as an EBGP speaker in addition 15 to its role as envisioned in RFC 4456. When it does so, just like 16 any other EBGP speaker it must advertise its routes to its IBGP 17 peers. This document updates RFC 4456 by explaining what behavior is 18 required of a route reflector that also functions as an EBGP speaker. 19 It also clarifies the use of the ORIGINATOR_ID and CLUSTER_LIST 20 attributes in this environment. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 Although originally conceived of as a purely IBGP device, in some 57 cases a BGP [RFC4271] route reflector may function as an EBGP speaker 58 in addition to its role as envisioned in [RFC4456]. When it does so, 59 just like any other EBGP speaker it must advertise its routes to its 60 IBGP peers. This document updates RFC 4456 by explaining what 61 behavior is required of a route reflector that also functions as an 62 EBGP speaker. It also clarifies the use of the ORIGINATOR_ID and 63 CLUSTER_LIST attributes in this environment. 65 The cardinal observation is that the functions outlined in [RFC4456] 66 apply exclusively to "reflected" routes, that is, IBGP routes that 67 are propagated to IBGP peers. 69 1.1. Requirements Language 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 2. Terminology 77 In addition to the terms defined in [RFC4271] Section 1.1 and in 78 [RFC4456], this document makes use of the following: 80 ASBR: Autonomous System Border Router. See EBGP Speaker. 82 RR: Route Reflector. 84 Redundant Route Reflector (or Redundant RR): Another route 85 reflector in the same cluster as the route reflector under 86 consideration, when both route reflectors are configured with the 87 same CLUSTER_ID. 89 EBGP Speaker: A BGP speaker that has one or more EBGP peerings, 90 and thereby learns one or more EBGP routes. (If no routes are 91 learned it is still an EBGP Speaker, but this is a case of "a tree 92 falling in a forest with no one to hear it.") ASBRs are EBGP 93 speakers, although not all EBGP speakers are ASBRs. 95 3. Updates to RFC 4456 97 When deciding how a route reflector that is also an EBGP speaker 98 should propagate EBGP routes into IBGP, the key observation is that 99 [RFC4456] deals only with "reflected" routes, i.e. IBGP routes that 100 are propagated into IBGP. For EBGP-learned routes, the BGP speaker 101 is the only source of routes for its AS. For this reason, the 102 restrictions and assumptions that apply to reflected routes do not 103 apply to EBGP-learned routes. For the purposes of such routes, the 104 BGP speaker functions as a normal IBGP router. For example, the 105 [RFC4456] stricture against modifying the NEXT_HOP, AS_PATH, 106 LOCAL_PREF, and MED attributes does not apply to EBGP-learned routes 107 that are propagated into IBGP. 109 Specific updates to [RFC4456] are: 111 o The speaker MUST NOT add a CLUSTER_LIST to EBGP-learned routes 112 when advertising them into IBGP. 114 o The attributes ORIGINATOR_ID and CLUSTER_LIST MUST NOT be sent to 115 EBGP peers. If received from an EBGP peer, these attributes MUST 116 be ignored and not propagated further; an error message MAY be 117 logged. 119 4. Deployment Considerations 121 If route reflectors are deployed in an Autonomous System such that no 122 two route reflectors have the same CLUSTER_ID, then there are no 123 "redundant route reflectors" (as the term is used herein) and thus, 124 the considerations regarding redundant RRs below are moot. 126 A RR that serves as an EBGP speaker SHOULD have an IBGP peering with 127 any redundant RR. It SHOULD advertise the same EBGP-learned routes 128 over this peering that it advertises to any other IBGP peer. It MAY 129 suppress reflection of any IBGP-learned routes to the redundant RR. 130 (Recall that according to [RFC4456] Section 8, such routes would be 131 ignored by the redundant RR anyway due to a loop in the 132 CLUSTER_LIST.) The peering MAY be omitted if the route reflectors in 133 question are control plane-only devices not in the forwarding path of 134 any traffic, or if the network in question uses some form of tunneled 135 or label-switched forwarding. The cost of omitting the peering is 136 that certain low-probability failure modes may cause unnecessary 137 unreachability -- specifically, if the EBGP-speaking RR were to lose 138 its session to one or more of its RR clients, reachability to the 139 EBGP-learned routes would be preserved if a session remained up to 140 its redundant RR peer. (Similar considerations apply even to route 141 reflectors which do not have a collocated EBGP speaker function, but 142 such are beyond the scope of this document.) 144 5. IANA Considerations 146 This document makes no request of IANA. 148 6. Security Considerations 150 This clarification to BGP does not change the underlying security 151 issues. 153 7. Acknowledgements 155 The author would like to thank Serpil Bayraktar, Jeff Haas, Senad 156 Palislamovic, Yakov Rekhter, Jim Uttaro and Kaliraj Vairavakkalai for 157 their input. 159 8. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, March 1997. 164 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 165 Protocol 4 (BGP-4)", RFC 4271, January 2006. 167 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 168 Reflection: An Alternative to Full Mesh Internal BGP 169 (IBGP)", RFC 4456, April 2006. 171 Author's Address 173 John Scudder 174 Juniper Networks 176 Email: jgs@juniper.net