draft-ietf-idr-aggregation-framework-02.txt   draft-ietf-idr-aggregation-framework-03.txt 
INTERNET-DRAFT Enke Chen INTERNET-DRAFT Enke Chen / Cisco
<draft-ietf-idr-aggregation-framework-02.txt> Cisco <draft-ietf-idr-aggregation-framework-03.txt> Cisco
John W. Stewart, III John W. Stewart, III
Juniper Juniper
March 1998 August 1998
A Framework for Inter-Domain Route Aggregation A Framework for Inter-Domain Route Aggregation
<draft-ietf-idr-aggregation-framework-02.txt> <draft-ietf-idr-aggregation-framework-03.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 2, line 39 skipping to change at page 2, line 39
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-
ciated route computation required, remain major issues today. To sup- ciated route computation required, remain major issues today. To sup-
port Internet growth, it is important to maximize the efficiency of port Internet growth, it is important to maximize the efficiency of
aggregation at all levels in the routing system. aggregation at all levels in the routing system.
Because of the current size of the routing system and its dynamic Because of the current size of the routing system and its dynamic
nature, the first step towards this goal is to establish a clearly- nature, the first step towards this goal is to establish a clearly-
defined framework in which scaleable inter-domain route aggregation can defined framework in which scaleable inter-domain route aggregation can
be realized. The framework described in this document emphasizes the be realized. The framework described in this document is based on the
predominant and current experience in the Internet. It emphasizes the
philosophy of aggregation by the source, both within routing domains as philosophy of aggregation by the source, both within routing domains as
well as towards upstream providers. The framework also strongly encour- well as towards upstream providers. The framework also strongly encour-
ages the use of the "no-export" BGP community to balance the provider- ages the use of the "no-export" BGP community to balance the provider-
subscriber need for more granular routing information with the Inter- subscriber need for more granular routing information with the Inter-
net's need for scalable inter-domain routing. The advantages of this net's need for scalable inter-domain routing. The advantages of this
framework include the following: framework include the following:
- Route aggregation is done in a distributed fashion. The Internet - Route aggregation is done in a distributed fashion, with emphasis
is too large and too distributed for aggregation to be performed on aggregation by the party or parties injecting the aggregatable
successfully by anyone other than the party injecting the aggregat- routing information into the global mesh.
able routing information into the global mesh.
- The flexibility of a routing domain to be able to inject more gran- - The flexibility of a routing domain to be able to inject more gran-
ular routing information to an adjacent domain to control the ular routing information to an adjacent domain to control the
resulting traffic patterns, without having an impact on the global resulting traffic patterns, without having an impact on the global
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.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
- 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.)
In general no "proxy aggregation" (i.e., aggregation of a route by This framework does not depend on "proxy aggregation" which refers
an AS other than the originating AS) shall be performed. This pre- to route aggregation done by an AS other than the originating AS.
serves the capability of a multi-homed site to control the granu- This preserves the capability of a multi-homed site to control the
larity of routing information injected into the global routing sys- granularity of routing information injected into the global routing
tem. Proxy aggregation may be appropriate on a small scale where system. Since proxy aggregation involves coordination among multiple
the necessary coordination is tractable. However, on a large organizations, the complexity of doing proxy aggregation increases
scale, experience has shown that proxy aggregation is problematic with the number of parties involved in the coordination. The
because the coordination is intractable. complexity, in turn, impacts the practicality of proxy aggregation.
An AS shall always originate via a stable mechanism (e.g., static An AS shall always originate via a stable mechanism (e.g., static
route configuration) the BGP routes for the large aggregates from route configuration) the BGP routes for the large aggregates from
which it allocates addresses to customers. This ensures that it is which it allocates addresses to customers. This ensures that it is
safe for its customers to use BGP "no-export". safe for its customers to use BGP "no-export".
- Using BGP community "no-export" toward upstream providers - Using BGP community "no-export" toward upstream providers
That is, in its route announcements toward its upstream provider, That is, in its route announcements toward its upstream provider,
an AS tags the BGP community "no-export" to routes it originates an AS tags the BGP community "no-export" to routes it originates
that do not need to be propagated beyond its upstream provider that do not need to be propagated beyond its upstream provider
skipping to change at page 6, line 37 skipping to change at page 6, line 36
to be advertised out by its upstream providers. For example, to be advertised out by its upstream providers. For example,
- The route is a more-specific of the upstream provider's block. - The route is a more-specific of the upstream provider's block.
However, the customer is either singly homed; or its connection to However, the customer is either singly homed; or its connection to
this particular upstream provider is used for backup only. this particular upstream provider is used for backup only.
- The more-specifics of a larger block are announced by the customer - The more-specifics of a larger block are announced by the customer
in order to balance traffic over the multiple links to the upstream in order to balance traffic over the multiple links to the upstream
provider. provider.
One approach to suppress such routes is to aggregate them even though Our approach to suppress such routes is to give control to the ASs that
they are originated by other ASs (termed "proxy aggregation"). However, originate the more-specifics (as seen by its upstream providers) and let
due to the legitimate need for injecting more-specifics for multi-hom- them tag the BGP community "no-export" to the appropriate routes.
ing, proxy aggregation needs to be done with special coordination and
care. The coordination work involved is non-trivial in a large environ-
ment, and as a result, little aggregation savings have been achieved
with proxy aggregation to date.
Instead of "proxy aggregation," our approach for dealing with these
cases is to give control to the ASs that originate the more-specifics
(as seen by its upstream providers) and let them tag the BGP community
"no-export" to the appropriate routes.
The BGP community "no-export" is a well known BGP community [6, 7]. A The BGP community "no-export" is a well known BGP community [6, 7]. A
route with this attribute is not propagated beyond an AS boundary. So, route with this attribute is not propagated beyond an AS boundary. So,
if a route is tagged with this community in its announcement to an if a route is tagged with this community in its announcement to an
upstream provider and is accepted by the upstream provider, the route upstream provider and is accepted by the upstream provider, the route
will not be announced beyond the upstream provider's AS. This achieves will not be announced beyond the upstream provider's AS. This achieves
the goal of suppressing the more-specifics in the upstream provider's the goal of suppressing the more-specifics in the upstream provider's
outbound announcement. outbound announcement.
In this framework, the BGP community "no-export" shall be tagged to In this framework, the BGP community "no-export" shall be tagged to
routes that are to be advertized to, but not propagated by, its upstream routes that are to be advertized to, but not propagated by, its upstream
provider. They may include routes allocated out of its upstream provider. They may include routes allocated out of its upstream
provider's block or the more specific routes announced to its upstream provider's block or the more specific routes announced to its upstream
provider for the purpose of load balancing. This aggregation strategy provider for the purpose of load balancing. This aggregation strategy
can be implemented via prefix-based filtering as shown in the example of can be implemented via prefix-based filtering as shown in the example of
Section 5. Section 5.
For its own protection, a downstream AS shall announce only its own For its own protection, a downstream AS shall announce only its own
routes and its customer routes to its upstream providers. Thus, the routes and its customer routes to its upstream providers. Thus, the
outbound routing announcement and aggregation policy can be expressed as outbound routing announcement and aggregation policy can be expressed as
follows: follows:
skipping to change at page 10, line 40 skipping to change at page 10, line 13
RFC 1997, August 1996. RFC 1997, August 1996.
[7] Chen, E., and Bates, T., "An Application of the BGP Community [7] Chen, E., and Bates, T., "An Application of the BGP Community
Attribute in Multi-home Routing", RFC 1998, August 1996. Attribute in Multi-home Routing", RFC 1998, August 1996.
[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., and Chen, E., "Using BGP Without Consuming a Unique [10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a
ASN", Internet-Draft, January 1997 (expires July 1997), <draft-stewart- Dedicated AS for Sites Homed to a Single Provider", RFC2270, January,
bgp-multiprotocol-00.txt>. 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", Internet-Draft, October 1996 (expires April 1997), <draft-iab-
ip-ad-today-01.txt>. 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.
 End of changes. 

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