idnits 2.17.1 draft-ietf-idr-aggregation-framework-01.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-26) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 a Security Considerations section. ** 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. ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 1997) is 9782 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) == Unused Reference: '3' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 414, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 440, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '1') ** Obsolete normative reference: RFC 1519 (ref. '2') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1998 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 2071 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 2072 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 18 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Enke Chen / Cisco 3 John W. Stewart, III / ISI 4 July 1997 6 A Framework for Inter-Domain Route Aggregation 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the abstract listing contained in each Internet-Draft 23 directory to learn the current status of this or any other Internet- 24 Draft. 26 Abstract 28 This document presents a framework for inter-domain route aggregation 29 and shows an example router configuration which 'implement' this 30 framework. This framework is flexible and scales well as it 31 emphasizes the philosophy of aggregation by the source, both within 32 routing domains as well as towards upstream providers, and it also 33 strongly encourages the use of the 'no-export' BGP community to 34 balance the provider-subscriber need for more granular routing 35 information with the Internet's need for scalable inter-domain 36 routing. 38 1. Introduction 40 The need for route aggregation has long been recognized. Route 41 aggregation is good as it reduces the size, and slows the growth, of 42 the Internet routing table. Thus, the amount of resources (e.g., CPU 43 and memory) required to process routing information is reduced and 44 route calculation is sped up. Another benefit of route aggregation 45 is that route flaps are limited in number, frequency and scope, which 46 saves resources and makes the global Internet routing system more 47 stable. 49 Since CIDR (Classless Inter-Domain Routing) [2] was introduced, 50 significant progress has been made on route aggregation, particularly 51 in the following two areas: 53 - Formulation and implementation of IP address allocation policies 54 by the top registries that conform to the CIDR principles. [1] 55 This policy work is the cornerstone which makes efficient route 56 aggregation technically possible. 58 - Route aggregation by large (especially "Tier 1") providers. To 59 date, the largest reductions in the size of the routing table 60 have resulted from efficient aggregation by large providers. 62 However, the ability of various levels of the global routing system 63 to implement efficient aggregation schemes varies widely. As a 64 result, the size and growth rate of the Internet routing table, as 65 well as the associated route computation required, remain major 66 issues today. To support Internet growth, it is important to maxim- 67 ize the efficiency of aggregation at all levels in the routing sys- 68 tem. 70 Because of the current size of the routing system and its dynamic 71 nature, the first step towards this goal is to establish a clearly- 72 defined framework in which scaleable inter-domain route aggregation 73 can be realized. The framework described in this document emphasizes 74 the philosophy of aggregation by the source, both within routing 75 domains as well as towards upstream providers. The framework also 76 strongly encourages the use of the "no-export" BGP community to bal- 77 ance the provider-subscriber need for more granular routing informa- 78 tion with the Internet's need for scalable inter-domain routing. The 79 advantages of this framework include the following: 81 - Route aggregation is done in a distributed fashion. The Inter- 82 net is too large and too distributed for aggregation to be per- 83 formed successfully by anyone other than the party injecting the 84 aggregatable routing information into the global mesh. 86 - The flexibility of a routing domain to be able to inject more 87 granular routing information to an adjacent domain to control 88 the resulting traffic patterns, without having an impact on the 89 global routing system. 91 In addition to describing the philosophy, we illustrate it by 92 presenting sample configurations. IPv4 prefixes, BGP4 and ASs are 93 used in examples, though the principles are applicable to inter- 94 domain route aggregation in general. 96 Address allocation policies and technologies to renumber entire net- 97 works, while very relevant to the realization of successful and sus- 98 tained inter-domain routing, are not the focus of this document. The 99 references section contains pointers to relevant documents. [8, 9, 100 11, 12] 102 2. Route Aggregation Framework 104 The framework of inter-domain route aggregation we are proposing can 105 be summarized as follows: 107 - Aggregation from the originating AS 109 That is, in its outbound route announcements, each AS aggregates 110 the BGP routes originated by itself, by dedicated AS and by 111 private-ASs. [10] ("Routes originated by an AS" refers to 112 routes which have that AS first in the AS path attribute. For 113 example, routes statically configured and injected into BGP fall 114 into this category.) 116 In general no "proxy aggregation" (i.e., aggregation of a route 117 by an AS other than the originating AS) shall be performed. 118 This preserves the capability of a multi-homed site to control 119 the granularity of routing information injected into the global 120 routing system. Successful proxy aggregation requires coordina- 121 tion on a very large scale (i.e., between potentially many pro- 122 viders and subscribers) and experience has shown that this is 123 nearly impossible to achieve, so to date little aggregation has 124 been achieved with proxy aggregation. 126 An AS shall always originate via a stable mechanism (e.g., 127 static route configuration) the BGP routes for the large aggre- 128 gates from which it allocates addresses to customers. This 129 ensures that it is safe for its customers to use BGP "no- 130 export". 132 - Using BGP community "no-export" toward upstream providers 134 That is, in its route announcements toward its upstream pro- 135 vider, an AS tags the BGP community "no-export" to routes it 136 originates that do not need to be propagated beyond its upstream 137 provider (e.g., prefixes allocated by the upstream provider). 139 This framework is illustrated in Figure 1. A "Tier 1" provider does 140 not use "no-export" in its announcement as it does not have an 141 upstream provider. However, it shall aggregate the routes it ori- 142 ginates in its outbound announcements towards both peer providers and 143 customers. An AS with an upstream provider shall aggregate the 144 routes it originates and use "no-export" toward its upstream provider 145 for routes that do not need to be propagated beyond its provider's 146 AS. This recursion shall apply to all levels of the routing hierar- 147 chy. 149 Tier 1 150 +-- Provider <--+ 151 | | 152 o aggregates routes | | o announces customer routes 153 it originates | | o aggregates routes it originates 154 | ^ o uses "no-export" if appropriate 155 | 156 +---> Tier 2 <--+ 157 Provider | 158 V | 159 | | 160 o aggregates routes | | o announces customer routes 161 it originates | | o aggregates routes it originates 162 | | o uses "no-export" if appropriate 163 | | 164 | ^ 165 -> Customer AS 167 Figure 1 169 This framework scales well as aggregation is done at all levels of 170 the routing system. It is flexible because the originating AS con- 171 trols whether routes of finer granularity are injected to, and/or 172 propagated by, its upstream provider. It facilitates multi-homing 173 without compromising route aggregation. 175 This framework is detailed in the following sections. 177 3. Aggregation from the Originating AS 179 It has been well recognized that address allocation and address 180 renumbering are keys to containing the growth of the Internet routing 181 table. [1, 2, 8, 9, 11, 12] 183 Although the strategies discussed in this document do not assume a 184 perfect address allocation, it is strongly urged that an AS receive 185 allocation from its upstream service providers' address block. 187 3.1 Intra-Domain Aggregation 189 To reduce the number of routes that need to be injected into an AS, 190 there are a couple of principles that shall be followed: 192 - Carry in its BGP table the large route block allocated from its 193 upstream provider or an address registry (e.g., InterNIC, RIPE, 194 APNIC). This can be done by either static configuration of the 195 large block or by aggregating more specific BGP routes. The 196 former is recommended as it does not depend on other routes. 198 - Allocate sub-blocks to the access routers where further alloca- 199 tion is done. That is, the address allocation shall be done 200 such that only a few, less specific routes (instead of many 201 more, specific ones) need to be known to the other routers 202 within the AS. 204 For example, a prefix of /17 can be further allocated to dif- 205 ferent access routers as /20s which can then be allocated to 206 customers connected to different interfaces on that router (as 207 shown in Figure 2). Then in general only the /20 needs to be 208 injected into the whole AS. Exceptions need to be made for 209 multi-homed static routes. 211 access router 212 +------------+ 213 | x.x.x.x/20 | 214 +------------+ 215 | | | 216 | | | 217 /24 /22 /25 219 Figure 2 221 It is noted that rehoming of customers without renumbering even 222 within the same AS may lead to injection of more specific routes. 223 However, in general the more-specifics do not need to be advertised 224 outside of that AS. Such routes can either be tagged with the BGP 225 community "no-export" or filtered out by a prefix-based filter to 226 prevent them from being advertised out. 228 3.2 Inter-Domain Aggregation 230 There are at least two types of routes that need to be advertised by 231 an AS: routes originated by the AS and routes originated by its BGP 232 customers. An AS may need to advertise full routes to certain BGP 233 customers, in which case the routing announcements include routes 234 originated by non-customer ASs. Clearly an AS can, and should, 235 safely aggregate the routes originated by itself and by its BGP cus- 236 tomers multi-homed only to it (using, e.g., the dedicated-AS and by 237 the private-AS mechanism [10]) in its outbound announcement. But it 238 is far more dangerous to aggregate routes originated by customer ASs 239 due to multi-homing. 241 However, there are several cases in which a route originated by a BGP 242 customer (other than using the dedicated AS or private AS) does not 243 need to be advertised out by its upstream providers. For example, 245 - The route is a more-specific of the upstream provider's block. 246 However, the customer is either singly homed; or its connection 247 to this particular upstream provider is used for backup only. 249 - The more-specifics of a larger block are announced by the custo- 250 mer in order to balance traffic over the multiple links to the 251 upstream provider. 253 One approach to suppress such routes is to aggregate them even though 254 they are originated by other ASs (termed "proxy aggregation"). How- 255 ever, due to the legitimate need for injecting more-specifics for 256 multi-homing, proxy aggregation needs to be done with special coordi- 257 nation and care. The coordination work involved is non-trivial in a 258 large environment, and as a result, little aggregation savings have 259 been achieved with proxy aggregation to date. 261 Instead of "proxy aggregation," our approach for dealing with these 262 cases is to give control to the ASs that originate the more-specifics 263 (as seen by its upstream providers) and let them tag the BGP commun- 264 ity "no-export" to the appropriate routes. 266 The BGP community "no-export" is a well known BGP community [6, 7]. 267 A route with this attribute is not propagated beyond an AS boundary. 268 So, if a route is tagged with this community in its announcement to 269 an upstream provider and is accepted by the upstream provider, the 270 route will not be announced beyond the upstream provider's AS. This 271 achieves the goal of suppressing the more-specifics in the upstream 272 provider's outbound announcement. 274 In this framework, the BGP community "no-export" shall be tagged to 275 routes that are to be advertized to, but not propagated by, its 276 upstream provider. They may include routes allocated out of its 277 upstream provider's block or the more specific routes announced to 278 its upstream provider for the purpose of load balancing. This aggre- 279 gation strategy can be implemented via prefix-based filtering as 280 shown in the example of Section 5. 282 For its own protection, a downstream AS shall announce only its own 283 routes and its customer routes to its upstream providers. Thus, the 284 outbound routing announcement and aggregation policy can be expressed 285 as follows: 287 For routes originated by itself/dedicated-AS/private-AS: 288 tag with "no-export" when appropriate, and advertise the 289 large block and suppress the more-specifics 291 For routes originated by customer ASs: 292 advertise to upstream ASs 294 For any other routes: 295 do not advertise to upstream ASs 297 This approach is flexible and scales well as it gives control to the 298 party with the special needs, distributes the workload and avoids the 299 coordination overhead required by proxy aggregation. 301 4. Aggregation by a Provider 303 A provider shall aggregate all the routes it originates, as docu- 304 mented in Section 3. The only difference is that the provider may be 305 providing full routes to certain BGP customers where no outbound 306 filtering is presently in place. Experience has shown that incon- 307 sistent route announcement (e.g., aggregate at the interconnects but 308 not toward certain customers) can cause serious routing problems for 309 the Internet as a whole because of longest-match routing. In certain 310 cases announcing the more-specifics to customers might provide for 311 more accurate IGP metrics and could be useful for better load- 312 balancing. However, the potential risk seems to outweigh the bene- 313 fit, especially given the increasing complexity of connectivity that 314 a customer may have. As a result, every effort shall be made to 315 ensure consistent route aggregation for all BGP peers. This means 316 deploying filters for the BGP peers which receive full routes. 318 In summary, the aggregation strategy for a provider shall be: 320 - In announcing customer routes: 322 For routes originated by itself/dedicated-AS/private-AS: 323 tag with "no-export" when appropriate, and advertise the 324 large block and suppress the more-specifics 326 For routes originated by other customer ASs: 327 advertise 329 For any other routes: 330 do not advertise 332 - In announcing full routes: 334 For routes originated by itself/dedicated-AS/private-AS: 335 tag with "no-export" when appropriate, and advertise the 336 large block and suppress the more-specifics 338 For any other routes: 339 advertise 341 5. An Example 343 Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" 344 provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, 345 and AS 2000 is a customer of AS 1000 with a "portable address" 346 160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000. 348 Assume that 208.128.0.0/19 does not need to be propagated beyond AS 349 1000. 351 +----------------+ 352 | AS 1000 | 353 | 208.128.0.0/12 | 354 | 166.55.0.0/16 | 355 +----------------+ 356 | 357 | BGP 358 | 359 | 360 +----------------+ 361 | AS 2000 | 362 | 208.128.0.0/19 | 363 | 160.75.0.0/16 | 364 +----------------+ 366 Figure 3 368 Then, based on the framework presented, AS 1000 would 370 - originate and advertise the BGP routes 208.128.0.0/12 and 371 166.70.0.0/16, and suppress more-specifics originated by 372 itself/private-ASs/dedicated-ASs 374 - advertise the routes received from the customer AS 2000 376 and AS 2000 would 378 - originate BGP route 208.128.0.0/19 and 160.75.0.0/16 380 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider 381 AS 1000 and suppress the more specifics originated by 382 itself/private-AS/dedicated-AS, taggin the route 208.128.0.0/19 383 with "no-export" 385 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP cus- 386 tomers (if any) and suppress the more-specifics originated by 387 itself/private-AS/dedicated-AS, plus any other routes the custo- 388 mers may desire to receive 390 The sample configuration which implement these policies (in Cisco 391 syntax) is given in Appendix A. 393 6. Acknowledgments 395 The authors would like to thank Roy Alcala of MCI for a number of 396 interesting hallway discussions related to this work. The IETF's IDR 397 Working Group also provided many helpful comments and suggestions. 399 7. References 401 [1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation 402 with CIDR", RFC 1518, September 1993. 404 [2] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 405 Domain Routing (CIDR): an Address Assignment and Aggregation Stra- 406 tegy", RFC 1519, September 1993. 408 [3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 409 RFC1771, March 1995. 411 [4] Rekhter, Y., and Gross, P., "Application of the Border Gateway 412 Protocol in the Internet", RFC1772, March 1995. 414 [5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 415 April 1995. 417 [6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute", 418 RFC 1997, August 1996. 420 [7] Chen, E., and Bates, T., "An Application of the BGP Community 421 Attribute in Multi-home Routing", RFC 1998, August 1996. 423 [8] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why 424 would I want it and what is it anyway?", RFC 2071, January 1997. 426 [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 427 1997. 429 [10] Stewart, J., and Chen, E., "Using BGP Without Consuming a Unique 430 ASN", Internet-Draft, January 1997 (expires July 1997), . 433 [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address 434 Behaviour Today", Internet-Draft, October 1996 (expires April 1997), 435 . 437 [12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900, 438 February 1996. 440 [13] Cisco systems, Cisco IOS Software Version 10.3 Router Products 441 Configuration Guide (Addendum), May 1995. 443 8. Authors' Addresses 445 Enke Chen 446 Cisco Systems 447 170 West Tasman Drive 448 San Jose, CA 95134-1706 449 Phone: +1 408 527 4652 450 email: enkechen@cisco.com 452 John W. Stewart, III 453 USC/ISI 454 4350 North Fairfax Drive 455 Suite 620 456 Arlington, VA 22203 457 phone: +1 703 807 0132 458 email: jstewart@isi.edu 459 A. Appendix A: Example Cisco Configuration 461 This appendix lists the Cisco configurations for AS 2000 of the exam- 462 ples presented in Section 5. The configuration here uses the AS- 463 path for outbound filtering although it can also be based on BGP com- 464 munity. Several route-maps are defined that can be used for peering 465 with the upstream provider, and for peering with customers (announc- 466 ing full routes or customer routes). 468 !!# inject aggregates 469 ip route 160.75.0.0 255.255.0.0 Null0 254 470 ip route 208.128.0.0 255.255.224.0 Null0 254 471 ! 472 router bgp 2000 473 network 160.75.0.0 mask 255.255.0.0 474 network 208.128.0.0 mask 255.255.224.0 475 neighbor x.x.x.x remote-as 1000 476 neighbor x.x.x.x route-map export-routes-to-provider out 477 neighbor x.x.x.x send-community 478 ! 479 !!# match all 480 ip as-path access-list 1 permit .* 481 ! 482 !!# List of internal AS and private ASs that are safe to aggregate 483 ip as-path access-list 10 permit ^$ 484 ip as-path access-list 10 permit ^64999_ 485 ip as-path access-list 10 deny .* 486 ! 487 !!# list of other customer ASs 488 ip as-path access-list 20 permit ^3000_ 490 !!# List of prefixes to be tagged with "no-export" 491 access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 492 !!# Filter out the more specifics of large aggregates, and permit the rest 493 access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 494 access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255 495 access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 496 access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255 497 access-list 102 permit ip any any 498 ! 499 !!# route-map with the upstream provider 500 route-map export-routes-to-provider permit 10 501 match ip address 101 502 set community no-export 503 route-map export-routes-to-provider permit 20 504 match as-path 10 505 match ip address 102 506 route-map export-routes-to-provider permit 30 507 match as-path 20 508 ! 509 !!# route-map with BGP customers that desire only customer routes 510 route-map export-customer-routes permit 10 511 match as-path 10 512 match ip address 102 513 route-map export-customer-routes permit 20 514 match as-path 20 515 ! 516 !!# route-map with BGP customers that desire full routes 517 route-map export-full-routes permit 10 518 match as-path 10 519 match ip address 102 520 route-map export-full-routes permit 20 521 match as-path 1 522 !