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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/