idnits 2.17.1 draft-ietf-idr-aggregation-framework-04.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-19) 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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 9) being 61 lines 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 6 instances of too long lines in the document, the longest one being 2 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 (December 1998) is 9257 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 391, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 397, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 421, 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') ** Downref: Normative reference to an Informational RFC: RFC 2270 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2101 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 20 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Enke Chen 3 Cisco 4 John W. Stewart, III 5 Juniper 6 December 1998 8 A Framework for Inter-Domain Route Aggregation 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 Please check the abstract listing contained in each Internet-Draft 25 directory to learn the current status of this or any other Internet- 26 Draft. 28 Abstract 30 This document presents a framework for inter-domain route aggregation 31 and shows an example router configuration which 'implements' this 32 framework. This framework is flexible and scales well as it 33 emphasizes the philosophy of aggregation by the source, both within 34 routing domains as well as towards upstream providers, and it also 35 strongly encourages the use of the 'no-export' BGP community to 36 balance the provider-subscriber need for more granular routing 37 information with the Internet's need for scalable inter-domain 38 routing. 40 1. Introduction 42 The need for route aggregation has long been recognized. Route 43 aggregation is good as it reduces the size, and slows the growth, of 44 the Internet routing table. Thus, the amount of resources (e.g., CPU 45 and memory) required to process routing information is reduced and 46 route calculation is sped up. Another benefit of route aggregation 47 is that route flaps are limited in number, frequency and scope, which 48 saves resources and makes the global Internet routing system more 49 stable. 51 Since CIDR (Classless Inter-Domain Routing) [2] was introduced, 52 significant progress has been made on route aggregation, particularly 53 in the following two areas: 55 - Formulation and implementation of IP address allocation policies by 56 the top registries that conform to the CIDR principles [1]. This 57 policy work is the cornerstone which makes efficient route aggrega- 58 tion technically possible. 60 - Route aggregation by large (especially "Tier 1") providers. To 61 date, the largest reductions in the size of the routing table have 62 resulted from efficient aggregation by large providers. 64 However, the ability of various levels of the global routing system to 65 implement efficient aggregation schemes varies widely. As a result, the 66 size and growth rate of the Internet routing table, as well as the asso- 67 ciated route computation required, remain major issues today. To sup- 68 port Internet growth, it is important to maximize the efficiency of 69 aggregation at all levels in the routing system. 71 Because of the current size of the routing system and its dynamic 72 nature, the first step towards this goal is to establish a clearly- 73 defined framework in which scaleable inter-domain route aggregation can 74 be realized. The framework described in this document is based on the 75 predominant and current experience in the Internet. It emphasizes the 76 philosophy of aggregation by the source, both within routing domains as 77 well as towards upstream providers. The framework also strongly encour- 78 ages the use of the "no-export" BGP community to balance the provider- 79 subscriber need for more granular routing information with the Inter- 80 net's need for scalable inter-domain routing. The advantages of this 81 framework include the following: 83 - Route aggregation is done in a distributed fashion, with emphasis 84 on aggregation by the party or parties injecting the aggregatable 85 routing information into the global mesh. 87 - The flexibility of a routing domain to be able to inject more gran- 88 ular routing information to an adjacent domain to control the 89 resulting traffic patterns, without having an impact on the global 90 routing system. 92 In addition to describing the philosophy, we illustrate it by presenting 93 sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam- 94 ples, though the principles are applicable to inter-domain route aggre- 95 gation in general. 97 Address allocation policies and technologies to renumber entire net- 98 works, while very relevant to the realization of successful and sus- 99 tained inter-domain routing, are not the focus of this document. The 100 references section contains pointers to relevant documents [8, 9, 11, 101 12]. 103 2. Route Aggregation Framework 105 The framework of inter-domain route aggregation we are proposing can be 106 summarized as follows: 108 - Aggregation from the originating AS 110 That is, in its outbound route announcements, each AS aggregates 111 the BGP routes originated by itself, by dedicated AS and by pri- 112 vate-ASs [10]. ("Routes originated by an AS" refers to routes 113 which have that AS first in the AS path attribute. For example, 114 routes statically configured and injected into BGP fall into this 115 category.) 117 This framework does not depend on "proxy aggregation" which refers 118 to route aggregation done by an AS other than the originating AS. 119 This preserves the capability of a multi-homed site to control the 120 granularity of routing information injected into the global routing 121 system. Since proxy aggregation involves coordination among multiple 122 organizations, the complexity of doing proxy aggregation increases 123 with the number of parties involved in the coordination. The 124 complexity, in turn, impacts the practicality of proxy aggregation. 126 An AS shall always originate via a stable mechanism (e.g., static 127 route configuration) the BGP routes for the large aggregates from 128 which it allocates addresses to customers. This ensures that it is 129 safe for its customers to use BGP "no-export". 131 - Using BGP community "no-export" toward upstream providers 132 That is, in its route announcements toward its upstream provider, 133 an AS tags the BGP community "no-export" to routes it originates 134 that do not need to be propagated beyond its upstream provider 135 (e.g., prefixes allocated by the upstream provider). 137 This framework is illustrated in Figure 1. A "Tier 1" provider does not 138 use "no-export" in its announcement as it does not have an upstream 139 provider. However, it shall aggregate the routes it originates in its 140 outbound announcements towards both peer providers and customers. An AS 141 with an upstream provider shall aggregate the routes it originates and 142 use "no-export" toward its upstream provider for routes that do not need 143 to be propagated beyond its provider's AS. This recursion shall apply 144 to all levels of the routing hierarchy. 146 Tier 1 147 +-- Provider <--+ 148 | | 149 o aggregates routes | | o announces customer routes 150 it originates | | o aggregates routes it originates 151 | ^ o uses "no-export" if appropriate 152 | 153 +---> Tier 2 <--+ 154 Provider | 155 V | 156 | | 157 o aggregates routes | | o announces customer routes 158 it originates | | o aggregates routes it originates 159 | | o uses "no-export" if appropriate 160 | | 161 | ^ 162 -> Customer AS 164 Figure 1 166 This framework scales well as aggregation is done at all levels of the 167 routing system. It is flexible because the originating AS controls 168 whether routes of finer granularity are injected to, and/or propagated 169 by, its upstream provider. It facilitates multi-homing without compro- 170 mising route aggregation. 172 This framework is detailed in the following sections. 174 3. Aggregation from the Originating AS 176 It has been well recognized that address allocation and address renum- 177 bering are keys to containing the growth of the Internet routing table 178 [1, 2, 8, 9, 11, 12]. 180 Although the strategies discussed in this document do not assume a per- 181 fect address allocation, it is strongly urged that an AS receive alloca- 182 tion from its upstream service providers' address block. 184 3.1 Intra-Domain Aggregation 186 To reduce the number of routes that need to be injected into an AS, 187 there are a couple of principles that shall be followed: 189 - Carry in its BGP table the large route block allocated from its 190 upstream provider or an address registry (e.g., InterNIC, RIPE, 191 APNIC). This can be done by either static configuration of the 192 large block or by aggregating more specific BGP routes. The former 193 is recommended as it does not depend on other routes. 195 - Allocate sub-blocks to the access routers where further allocation 196 is done. That is, the address allocation shall be done such that 197 only a few, less specific routes (instead of many more, specific 198 ones) need to be known to the other routers within the AS. 200 For example, a prefix of /17 can be further allocated to different 201 access routers as /20s which can then be allocated to customers 202 connected to different interfaces on that router (as shown in Fig- 203 ure 2). Then in general only the /20 needs to be injected into the 204 whole AS. Exceptions need to be made for multi-homed static routes. 206 access router 207 +------------+ 208 | x.x.x.x/20 | 209 +------------+ 210 | | | 211 | | | 212 /24 /22 /25 214 Figure 2 216 It is noted that rehoming of customers without renumbering even within 217 the same AS may lead to injection of more specific routes. However, in 218 general the more-specifics do not need to be advertised outside of that 219 AS. Such routes can either be tagged with the BGP community "no-export" 220 or filtered out by a prefix-based filter to prevent them from being 221 advertised out. 223 3.2 Inter-Domain Aggregation 225 There are at least two types of routes that need to be advertised by an 226 AS: routes originated by the AS and routes originated by its BGP cus- 227 tomers. An AS may need to advertise full routes to certain BGP cus- 228 tomers, in which case the routing announcements include routes origi- 229 nated by non-customer ASs. Clearly an AS can, and should, safely aggre- 230 gate the routes originated by itself and by its BGP customers multi- 231 homed only to it (using, e.g., the dedicated-AS and by the private-AS 232 mechanism [10]) in its outbound announcement. But it is far more dan- 233 gerous to aggregate routes originated by customer ASs due to multi-hom- 234 ing. 236 However, there are several cases in which a route originated by a BGP 237 customer (other than using the dedicated AS or private AS) does not need 238 to be advertised out by its upstream providers. For example, 240 - The route is a more-specific of the upstream provider's block. 241 However, the customer is either singly homed; or its connection to 242 this particular upstream provider is used for backup only. 244 - The more-specifics of a larger block are announced by the customer 245 in order to balance traffic over the multiple links to the upstream 246 provider. 248 Our approach to suppress such routes is to give control to the ASs that 249 originate the more-specifics (as seen by its upstream providers) and let 250 them tag the BGP community "no-export" to the appropriate routes. 252 The BGP community "no-export" is a well known BGP community [6, 7]. A 253 route with this attribute is not propagated beyond an AS boundary. So, 254 if a route is tagged with this community in its announcement to an 255 upstream provider and is accepted by the upstream provider, the route 256 will not be announced beyond the upstream provider's AS. This achieves 257 the goal of suppressing the more-specifics in the upstream provider's 258 outbound announcement. 260 In this framework, the BGP community "no-export" shall be tagged to 261 routes that are to be advertized to, but not propagated by, its upstream 262 provider. They may include routes allocated out of its upstream 263 provider's block or the more specific routes announced to its upstream 264 provider for the purpose of load balancing. This aggregation strategy 265 can be implemented via prefix-based filtering as shown in the example of 266 Section 5. 268 For its own protection, a downstream AS shall announce only its own 269 routes and its customer routes to its upstream providers. Thus, the 270 outbound routing announcement and aggregation policy can be expressed as 271 follows: 273 For routes originated by itself/dedicated-AS/private-AS: 274 tag with "no-export" when appropriate, and advertise the 275 large block and suppress the more-specifics 277 For routes originated by customer ASs: 278 advertise to upstream ASs 280 For any other routes: 281 do not advertise to upstream ASs 283 This approach is flexible and scales well as it gives control to the 284 party with the special needs, distributes the workload and avoids the 285 coordination overhead required by proxy aggregation. 287 4. Aggregation by a Provider 289 A provider shall aggregate all the routes it originates, as documented 290 in Section 3. The only difference is that the provider may be providing 291 full routes to certain BGP customers where no outbound filtering is 292 presently in place. Experience has shown that inconsistent route 293 announcement (e.g., aggregate at the interconnects but not toward cer- 294 tain customers) can cause serious routing problems for the Internet as a 295 whole because of longest-match routing. In certain cases announcing the 296 more-specifics to customers might provide for more accurate IGP metrics 297 and could be useful for better load-balancing. However, the potential 298 risk seems to outweigh the benefit, especially given the increasing com- 299 plexity of connectivity that a customer may have. As a result, every 300 effort shall be made to ensure consistent route aggregation for all BGP 301 peers. This means deploying filters for the BGP peers which receive 302 full routes. 304 In summary, the aggregation strategy for a provider shall be: 306 - In announcing customer routes: 308 For routes originated by itself/dedicated-AS/private-AS: 309 tag with "no-export" when appropriate, and advertise the 310 large block and suppress the more-specifics 312 For routes originated by other customer ASs: 313 advertise 315 For any other routes: 316 do not advertise 318 - In announcing full routes: 320 For routes originated by itself/dedicated-AS/private-AS: 321 tag with "no-export" when appropriate, and advertise the 322 large block and suppress the more-specifics 324 For any other routes: 325 advertise 327 5. An Example 329 Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" 330 provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, and 331 AS 2000 is a customer of AS 1000 with a "portable address" 160.75.0.0/16 332 and an address 208.128.0.0/19 allocated from AS 1000. Assume that 333 208.128.0.0/19 does not need to be propagated beyond AS 1000. 335 +----------------+ 336 | AS 1000 | 337 | 208.128.0.0/12 | 338 | 166.55.0.0/16 | 339 +----------------+ 340 | 341 | BGP 342 | 343 | 344 +----------------+ 345 | AS 2000 | 346 | 208.128.0.0/19 | 347 | 160.75.0.0/16 | 348 +----------------+ 350 Figure 3 352 Then, based on the framework presented, AS 1000 would 354 - originate and advertise the BGP routes 208.128.0.0/12 and 355 166.55.0.0/16, and suppress more-specifics originated by 356 itself/private-ASs/dedicated-ASs 358 - advertise the routes received from the customer AS 2000 360 and AS 2000 would 362 - originate BGP route 208.128.0.0/19 and 160.75.0.0/16 364 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS 365 1000 and suppress the more specifics originated by itself/private- 366 AS/dedicated-AS, tagging the route 208.128.0.0/19 with "no-export" 368 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP cus- 369 tomers (if any) and suppress the more-specifics originated by 370 itself/private-AS/dedicated-AS, plus any other routes the customers 371 may desire to receive 373 The sample configuration which implement these policies (in Cisco syn- 374 tax) is given in Appendix A. 376 6. Acknowledgments 378 The authors would like to thank Roy Alcala of MCI for a number of inter- 379 esting hallway discussions related to this work. The IETF's IDR Working 380 Group also provided many helpful comments and suggestions. 382 7. References 384 [1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with 385 CIDR", RFC 1518, September 1993. 387 [2] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 388 Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", 389 RFC 1519, September 1993. 391 [3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 392 RFC1771, March 1995. 394 [4] Rekhter, Y., and Gross, P., "Application of the Border Gateway Pro- 395 tocol in the Internet", RFC1772, March 1995. 397 [5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April 398 1995. 400 [6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute", 401 RFC 1997, August 1996. 403 [7] Chen, E., and Bates, T., "An Application of the BGP Community 404 Attribute in Multi-home Routing", RFC 1998, August 1996. 406 [8] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why 407 would I want it and what is it anyway?", RFC 2071, January 1997. 409 [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. 411 [10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a 412 Dedicated AS for Sites Homed to a Single Provider", RFC2270, January, 413 1998. 415 [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour 416 Today", RFC 2101, February 1997. 418 [12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900, 419 February 1996. 421 [13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Con- 422 figuration Guide (Addendum), May 1995. 424 8. Authors' Addresses 426 Enke Chen 427 Cisco Systems 428 170 West Tasman Drive 429 San Jose, CA 95134-1706 430 Phone: +1 408 527 4652 431 email: enkechen@cisco.com 433 John W. Stewart, III 434 Juniper Networks, Inc. 435 385 Ravendale Drive 436 Mountain View, CA 94043 437 phone: +1 650 526 8000 438 email: jstewart@juniper.net 439 A. Appendix A: Example Cisco Configuration 441 This appendix lists the Cisco configurations for AS 2000 of the examples 442 presented in Section 5. The configuration here uses the AS-path for 443 outbound filtering although it can also be based on BGP community. Sev- 444 eral route-maps are defined that can be used for peering with the 445 upstream provider, and for peering with customers (announcing full 446 routes or customer routes). 448 !!# inject aggregates 449 ip route 160.75.0.0 255.255.0.0 Null0 254 450 ip route 208.128.0.0 255.255.224.0 Null0 254 451 ! 452 router bgp 2000 453 network 160.75.0.0 mask 255.255.0.0 454 network 208.128.0.0 mask 255.255.224.0 455 neighbor x.x.x.x remote-as 1000 456 neighbor x.x.x.x route-map export-routes-to-provider out 457 neighbor x.x.x.x send-community 458 ! 459 !!# match all 460 ip as-path access-list 1 permit .* 461 ! 462 !!# List of internal AS and private ASs that are safe to aggregate 463 ip as-path access-list 10 permit ^$ 464 ip as-path access-list 10 permit ^64999_ 465 ip as-path access-list 10 deny .* 466 ! 467 !!# list of other customer ASs 468 ip as-path access-list 20 permit ^3000_ 470 !!# List of prefixes to be tagged with "no-export" 471 access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 472 !!# Filter out the more specifics of large aggregates, and permit the rest 473 access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0 474 access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255 475 access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0 476 access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255 477 access-list 102 permit ip any any 478 ! 479 !!# route-map with the upstream provider 480 route-map export-routes-to-provider permit 10 481 match ip address 101 482 set community no-export 483 route-map export-routes-to-provider permit 20 484 match as-path 10 485 match ip address 102 486 route-map export-routes-to-provider permit 30 487 match as-path 20 488 ! 489 !!# route-map with BGP customers that desire only customer routes 490 route-map export-customer-routes permit 10 491 match as-path 10 492 match ip address 102 493 route-map export-customer-routes permit 20 494 match as-path 20 495 ! 496 !!# route-map with BGP customers that desire full routes 497 route-map export-full-routes permit 10 498 match as-path 10 499 match ip address 102 500 route-map export-full-routes permit 20 501 match as-path 1 502 !