idnits 2.17.1 draft-ietf-idr-route-reflect-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2,3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 36 has weird spacing: '...as been well ...' -- 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 (April 1996) is 10235 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) ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 1863 (ref. '2') (Obsoleted by RFC 4223) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Tony Bates 3 MCI 4 Ravi Chandra 5 cisco Systems 6 April 1996 8 BGP Route Reflection 9 An alternative to full mesh IBGP 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 Please check the I-D abstract listing contained in each Internet 26 Draft directory to learn the current status of this or any other 27 Internet Draft. 29 Abstract 31 The Border Gateway Protocol [1] is an inter-autonomous system routing 32 protocol designed for TCP/IP internets. BGP deployments are 33 configured such that that all BGP speakers within a single AS must be 34 fully meshed so that any external routing information must be re- 35 distributed to all other routers within that AS. This represents a 36 serious scaling problem that has been well documented with several 37 alternatives proposed [2,3]. 39 This document describes the use and design of a method known as 40 "Route Reflection" to alleviate the the need for "full mesh" IBGP. 42 1. Introduction 44 Currently in the Internet, BGP deployments are configured such that 45 that all BGP speakers within a single AS must be fully meshed and any 46 external routing information must be re-distributed to all other 47 routers within that AS. This "full mesh" requirement clearly does not 48 scale when there are a large number of IBGP speakers as is common in 49 many of todays internet networks. 51 For n BGP speakers within an AS you must maintain n*(n-1)/2 unique 52 IBGP sessions. With finite resources in both bandwidth and router CPU 53 this clearly does not scale. 55 This scaling problem has been well documented and a number of 56 proposals have been made to alleviate this [2,3]. This document 57 represents another alternative in alleviating the need for a "full 58 mesh" and is known as "Route Reflection". It represents a change in 59 the commonly understood concept of IBGP and the addition of two new 60 optional transitive BGP attributes. 62 2. Design Criteria 64 Route Reflection was designed to satisfy the following criteria. 66 o Simplicity 68 Any alternative must be both simple to configure as well 69 as understand. 71 o Easy Migration 73 It must be possible to migrate from a full mesh 74 configuration without the need to change either topology 75 or AS. This is an unfortunate management overhead of the 76 technique proposed in [3]. 78 o Compatibility 80 It must be possible for non compliant IBGP peers 81 to continue be part of the original AS or domain 82 without any loss of BGP routing information. 84 These criteria were motivated by operational experiences of a very 85 large and topology rich network with many external connections. 87 3. Route Reflection 89 The basic idea of Route Reflection is very simple. Let us consider 90 the simple example depicted in Figure 1 below. 92 +------ + +-------+ 93 | | IBGP | | 94 | RTR-A |--------| RTR-B | 95 | | | | 96 +-------+ +-------+ 97 \ / 98 IBGP \ ASX / IBGP 99 \ / 100 +-------+ 101 | | 102 | RTR-C | 103 | | 104 +-------+ 106 Figure 1: Full Mesh IBGP 108 In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR- 109 C). With the existing BGP model, if RTR-A receives an external route 110 and it is selected as the best path it must advertise the external 111 route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers) 112 will not re-advertise these IBGP learned routes to other IBGP 113 speakers. 115 If this rule is relaxed and RTR-C is allowed to reflect IBGP learned 116 routes, then it could re-advertise (or reflect) the IBGP routes 117 learned from RTR-A to RTR-B and vice versa. This would eliminate the 118 need for the IBGP session between RTR-A and RTR-B as shown in Figure 119 2 below. 121 +------ + +-------+ 122 | | | | 123 | RTR-A | | RTR-B | 124 | | | | 125 +-------+ +-------+ 126 \ / 127 IBGP \ ASX / IBGP 128 \ / 129 +-------+ 130 | | 131 | RTR-C | 132 | | 133 +-------+ 135 Figure 2: Route Reflection IBGP 137 The Route Reflection scheme is based upon this basic principle. 139 4. Terminology and Concepts 141 We use the term "Route Reflector" (RR) to represent an IBGP speaker 142 that participates in the reflection. The internal peers of a RR are 143 divided into two groups: 145 1) Client Peers 147 2) Non-Client Peers 149 A RR reflects routes between these groups. A RR along with its 150 client peers form a Cluster. The Non-Client peer must be fully meshed 151 but the Client peers need not be fully meshed. The Client peers 152 should not peer with internal speakers outside of their cluster. 153 Figure 3 depicts a simple example outlining the basic RR components 154 using the terminology noted above. 156 / - - - - - - - - - - - - - -\ 157 | Cluster | 158 +-------+ +-------+ 159 | | | | | | 160 | RTR-A | | RTR-B | 161 | |Client | |Client | | 162 +-------+ +-------+ 163 | \ / | 164 IBGP \ / IBGP 165 | \ / | 166 +-------+ 167 | | | | 168 | RTR-C | 169 | | RR | | 170 +-------+ 171 | / \ | 172 \ - - - - -/- - -\- - - - - - / 173 IBGP / \ IBGP 174 +-------+ +-------+ 175 | RTR-D | IBGP | RTR-E | 176 | Non- |---------| Non- | 177 |Client | |Client | 178 +-------+ +-------+ 180 Figure 3: RR Components 182 5. Operation 184 When a route is received by a RR, it selects the best path based on 185 its path selection rule. After the best path is selected, it must do 186 the following depending on the type of the peer it is receiving the 187 best path from: 189 1) A Route from a Non-Client peer 191 Reflect to all other Clients. 193 2) A Route from a Client peer 195 Reflect to all the Non-Client peers and also to the 196 Client peers other than the originator. (Hence the 197 Client peers are not required to be fully meshed). 199 3) Route from an EBGP peer 201 Send to all the Client and Non-Client Peers. 203 An Autonomous System could have many RRs. A RR treats other RRs just 204 like any other internal BGP speakers. A RR could be configured to 205 have other RRs in a Client group or Non-client group. 207 In a simple configuration the backbone could be divided into many 208 clusters. Each RR would be configured with other RRs as Non-Client 209 peers (thus all the RRs will be fully meshed.). The Clients will be 210 configured to maintain IBGP session only with the RR in their 211 cluster. Due to route reflection, all the IBGP speakers will receive 212 reflected routing information. 214 It is normal in a Autonomous System to have BGP speakers that do not 215 understand the concept of Route-Reflectors (let us call them 216 conventional BGP speakers). The Route-Reflector Scheme allows such 217 conventional BGP speakers to co-exist. Conventional BGP speakers 218 could be either members of a Non-Client group or a Client group. This 219 allows for an easy and gradual migration from the current IBGP model 220 to the Route Reflection model. One could start creating clusters by 221 configuring a single router as the designated RR and configuring 222 other RRs and their clients as normal IBGP peers. Additional clusters 223 can be created gradually. 225 6. Redundant RRs 227 Usually a cluster of clients will have a single RR. In that case, the 228 cluster will be identified by the ROUTER_ID of the RR. However, this 229 represents a single point of failure so to make it possible to have 230 multiple RRs in the same cluster, all RRs in the same cluster must be 231 configured with a 4-byte CLUSTER_ID so that an RR can discern routes 232 from other RRs in the same cluster. 234 7. Avoiding Routing Information Loops 236 As IBGP learned routes are reflected, it is possible through mis- 237 configuration to form route re-distribution loops. The Route 238 Reflection method defines the following attributes to detect and 239 avoid routing information loops. 241 ORIGINATOR_ID 243 ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type 244 code 9. This attribute is 4 bytes long and it will be created by a 245 RR. This attribute will carry the ROUTER_ID of the originator of the 246 route in the local AS. A BGP speaker should not create an 247 ORIGINATOR_ID attribute if one already exists. A route reflector 248 must never send routing information back to the router specified in 249 ORIGINATOR_ID. 251 CLUSTER_LIST 253 Cluster-list is a new optional, non-transitive BGP attribute of Type 254 code 10. It is a sequence of CLUSTER_ID values representing the 255 reflection path that the route has passed. It is encoded as follows: 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Attr. Flags |Attr. Type Code| Length | value ... 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Where Length is the number of octets. 264 When a RR reflects a route from its Clients to a Non-Client peer, it 265 must append the local CLUSTER_ID to the CLUSTER_LIST. If the 266 CLUSTER_LIST is empty, it must create a new one. Using this attribute 267 an RR can identify if the routing information is looped back to the 268 same cluster due to mis-configuration. If the local CLUSTER_ID is 269 found in the cluster-list, the advertisement will be ignored. 271 8. Implementation and Configuration Considerations 273 Care should be taken to make sure that none of the BGP path 274 attributes defined above can be modified through configuration when 275 exchanging internal routing information between RRs and Clients and 276 Non-Clients. This could result is looping of routes. 278 In some implementations, modification of the BGP path attribute, 279 NEXT_HOP is possible. For example, there could be a need for a RR to 280 modify NEXT_HOP for EBGP learned routes sent to its internal peers. 281 However, it must not be possible for an RR to set on reflected IBGP 282 routes as this breaks the basic principle of Route Reflection and 283 will result in potential black holeing of traffic. 285 An RR should not modify any AS-PATH attributes (i.e. LOCAL_PREF, MED, 286 DPA)that could change consistent route selection. This could result 287 in potential loops. 289 The BGP protocol provides no way for a Client to identify itself 290 dynamically as a Client to an RR configured BGP speaker and the 291 simplest way to achieve this is by manual configuration. 293 9. Security 295 Security considerations are not discussed in this memo. 297 10. Acknowledgments 299 The authors would like to thank Dennis Ferguson, Enke Chen, John 300 Scudder, Paul Traina and Tony Li for the many discussions resulting 301 in this work. This idea was developed from an earlier discussion 302 between Tony Li and Dimitri Haskin. 304 11. References 306 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 307 RFC1771, March 1995. 309 [2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh 310 routing", RFC1863, October 1995. 312 [3] Traina, P. "Limited Autonomous System Confederations for BGP", 313 INTERNET-DRAFT, , April 1995. 315 12. Author's Addresses 317 Tony Bates 318 MCI 319 2100 Reston Parkway 320 Reston, VA 22091 322 phone: +1 703 715 7521 323 email: Tony.Bates@mci.net 325 Ravishanker Chandrasekeran 326 (Ravi Chandra) 327 cisco Systems 328 170 West Tasman Drive 329 San Jose, CA 95134 331 email: rchandra@cisco.com