--- 1/draft-ietf-idr-aggregation-framework-03.txt 2006-02-04 23:29:06.000000000 +0100 +++ 2/draft-ietf-idr-aggregation-framework-04.txt 2006-02-04 23:29:06.000000000 +0100 @@ -1,19 +1,19 @@ -INTERNET-DRAFT Enke Chen / Cisco - Cisco +INTERNET-DRAFT Enke Chen + Cisco John W. Stewart, III Juniper - August 1998 + December 1998 A Framework for Inter-Domain Route Aggregation - + Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced or obsoleted by @@ -21,46 +21,46 @@ Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the abstract listing contained in each Internet-Draft directory to learn the current status of this or any other Internet- Draft. Abstract This document presents a framework for inter-domain route aggregation - and shows an example router configuration which "implement" this + and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also - strongly encourages the use of the "no-export" BGP community to + strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. 1. Introduction The need for route aggregation has long been recognized. Route aggregation is good as it reduces the size, and slows the growth, of the Internet routing table. Thus, the amount of resources (e.g., CPU and memory) required to process routing information is reduced and route calculation is sped up. Another benefit of route aggregation is that route flaps are limited in number, frequency and scope, which saves resources and makes the global Internet routing system more stable. Since CIDR (Classless Inter-Domain Routing) [2] was introduced, significant progress has been made on route aggregation, particularly in the following two areas: - Formulation and implementation of IP address allocation policies by - the top registries that conform to the CIDR principles. [1] This + the top registries that conform to the CIDR principles [1]. This policy work is the cornerstone which makes efficient route aggrega- tion technically possible. - Route aggregation by large (especially "Tier 1") providers. To date, the largest reductions in the size of the routing table have resulted from efficient aggregation by large providers. However, the ability of various levels of the global routing system to implement efficient aggregation schemes varies widely. As a result, the size and growth rate of the Internet routing table, as well as the asso- @@ -90,33 +90,33 @@ routing system. In addition to describing the philosophy, we illustrate it by presenting sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam- ples, though the principles are applicable to inter-domain route aggre- gation in general. Address allocation policies and technologies to renumber entire net- works, while very relevant to the realization of successful and sus- tained inter-domain routing, are not the focus of this document. The -references section contains pointers to relevant documents. [8, 9, 11, -12] +references section contains pointers to relevant documents [8, 9, 11, +12]. 2. Route Aggregation Framework The framework of inter-domain route aggregation we are proposing can be summarized as follows: - Aggregation from the originating AS That is, in its outbound route announcements, each AS aggregates the BGP routes originated by itself, by dedicated AS and by pri- - vate-ASs. [10] ("Routes originated by an AS" refers to routes + vate-ASs [10]. ("Routes originated by an AS" refers to routes which have that AS first in the AS path attribute. For example, routes statically configured and injected into BGP fall into this category.) This framework does not depend on "proxy aggregation" which refers to route aggregation done by an AS other than the originating AS. This preserves the capability of a multi-homed site to control the granularity of routing information injected into the global routing system. Since proxy aggregation involves coordination among multiple organizations, the complexity of doing proxy aggregation increases @@ -167,22 +167,22 @@ routing system. It is flexible because the originating AS controls whether routes of finer granularity are injected to, and/or propagated by, its upstream provider. It facilitates multi-homing without compro- mising route aggregation. This framework is detailed in the following sections. 3. Aggregation from the Originating AS It has been well recognized that address allocation and address renum- -bering are keys to containing the growth of the Internet routing table. -[1, 2, 8, 9, 11, 12] +bering are keys to containing the growth of the Internet routing table +[1, 2, 8, 9, 11, 12]. Although the strategies discussed in this document do not assume a per- fect address allocation, it is strongly urged that an AS receive alloca- tion from its upstream service providers' address block. 3.1 Intra-Domain Aggregation To reduce the number of routes that need to be injected into an AS, there are a couple of principles that shall be followed: @@ -347,32 +347,32 @@ | AS 2000 | | 208.128.0.0/19 | | 160.75.0.0/16 | +----------------+ Figure 3 Then, based on the framework presented, AS 1000 would - originate and advertise the BGP routes 208.128.0.0/12 and - 166.70.0.0/16, and suppress more-specifics originated by + 166.55.0.0/16, and suppress more-specifics originated by itself/private-ASs/dedicated-ASs - advertise the routes received from the customer AS 2000 and AS 2000 would - originate BGP route 208.128.0.0/19 and 160.75.0.0/16 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS 1000 and suppress the more specifics originated by itself/private- - AS/dedicated-AS, taggin the route 208.128.0.0/19 with "no-export" + AS/dedicated-AS, tagging the route 208.128.0.0/19 with "no-export" - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP cus- tomers (if any) and suppress the more-specifics originated by itself/private-AS/dedicated-AS, plus any other routes the customers may desire to receive The sample configuration which implement these policies (in Cisco syn- tax) is given in Appendix A. 6. Acknowledgments @@ -408,22 +408,21 @@ [8] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a Dedicated AS for Sites Homed to a Single Provider", RFC2270, January, 1998. [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour -Today", Internet-Draft, October 1996 (expires April 1997), . +Today", RFC 2101, February 1997. [12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900, February 1996. [13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Con- figuration Guide (Addendum), May 1995. 8. Authors' Addresses Enke Chen