INTERNET-DRAFT                                         Enke Chen
<draft-ietf-idr-aggregation-framework-02.txt> / Cisco
<draft-ietf-idr-aggregation-framework-03.txt>                      Cisco
                                                    John W. Stewart, III
                                                             August 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
   other documents at any time. It is not appropriate to use Internet-
   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-


   This document presents a framework for inter-domain route aggregation
   and shows an example router configuration which "implement" 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
   balance the provider-subscriber need for more granular routing
   information with the Internet's need for scalable inter-domain

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

   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
     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-
ciated route computation required, remain major issues today.  To sup-
port Internet growth, it is important to maximize the efficiency of
aggregation at all levels in the routing system.

Because of the current size of the routing system and its dynamic
nature, the first step towards this goal is to establish a clearly-
defined framework in which scaleable inter-domain route aggregation can
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
well as towards upstream providers.  The framework also strongly encour-
ages the use of the "no-export" BGP community to balance the provider-
subscriber need for more granular routing information with the Inter-
net's need for scalable inter-domain routing.  The advantages of this
framework include the following:

-    Route aggregation is done in a distributed fashion.  The Internet
     is too large and too distributed for fashion, with emphasis
     on aggregation to be performed
     successfully by anyone other than the party or parties injecting the aggregat-
     able aggregatable
     routing information into the global mesh.

-    The flexibility of a routing domain to be able to inject more gran-
     ular routing information to an adjacent domain to control the
     resulting traffic patterns, without having an impact on the global
     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,

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
     which have that AS first in the AS path attribute.  For example,
     routes statically configured and injected into BGP fall into this

     In general no

     This framework does not depend on "proxy aggregation" (i.e., aggregation of a which refers
     to route aggregation done by an AS other than the originating AS) shall be performed. AS.
     This pre-
     serves preserves the capability of a multi-homed site to control the granu-
     granularity of routing information injected into the global routing sys-
     tem.  Proxy
     system. Since proxy aggregation may be appropriate on a small scale where
     the necessary involves coordination is tractable.  However, on a large
     scale, experience has shown that among multiple
     organizations, the complexity of doing proxy aggregation is problematic
     because increases
     with the coordination is intractable. number of parties involved in the coordination. The
     complexity, in turn, impacts the practicality of proxy aggregation.

     An AS shall always originate via a stable mechanism (e.g., static
     route configuration) the BGP routes for the large aggregates from
     which it allocates addresses to customers.  This ensures that it is
     safe for its customers to use BGP "no-export".

-    Using BGP community "no-export" toward upstream providers
     That is, in its route announcements toward its upstream provider,
     an AS tags the BGP community "no-export" to routes it originates
     that do not need to be propagated beyond its upstream provider
     (e.g., prefixes allocated by the upstream provider).

This framework is illustrated in Figure 1. A "Tier 1" provider does not
use "no-export" in its announcement as it does not have an upstream
provider.  However, it shall aggregate the routes it originates in its
outbound announcements towards both peer providers and customers.  An AS
with an upstream provider shall aggregate the routes it originates and
use "no-export" toward its upstream provider for routes that do not need
to be propagated beyond its provider's AS.   This recursion shall apply
to all levels of the routing hierarchy.

                           Tier 1
                      +-- Provider <--+
                      |               |
  o aggregates routes |               |  o announces customer routes
    it originates     |               |  o aggregates routes it originates
                      |               ^  o uses "no-export" if appropriate
                      +---> Tier 2 <--+
                          Provider    |
                      V               |
                      |               |
  o aggregates routes |               |  o announces customer routes
    it originates     |               |  o aggregates routes it originates
                      |               |  o uses "no-export" if appropriate
                      |               |
                      |               ^
                      -> Customer AS

                          Figure 1

This framework scales well as aggregation is done at all levels of the
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]

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:

-    Carry in its BGP table the large route block allocated from its
     upstream provider or an address registry (e.g., InterNIC, RIPE,
     APNIC).  This can be done by either static configuration of the
     large block or by aggregating more specific BGP routes.  The former
     is recommended as it does not depend on other routes.

-    Allocate sub-blocks to the access routers where further allocation
     is done.  That is, the address allocation shall be done such that
     only a few, less specific routes (instead of many more, specific
     ones) need to be known to the other routers within the AS.

     For example, a prefix of /17 can be further allocated to different
     access routers as /20s which can then be allocated to customers
     connected to different interfaces on that router (as shown in Fig-
     ure 2).  Then in general only the /20 needs to be injected into the
     whole AS. Exceptions need to be made for multi-homed static routes.

                         access router
                        | x.x.x.x/20 |
                         |     |    |
                         |     |    |
                         /24   /22  /25

                           Figure 2

It is noted that rehoming of customers without renumbering even within

the same AS may lead to injection of more specific routes.  However, in
general the more-specifics do not need to be advertised outside of that
AS. Such routes can either be tagged with the BGP community "no-export"
or filtered out by a prefix-based filter to prevent them from being
advertised out.

3.2 Inter-Domain Aggregation

There are at least two types of routes that need to be advertised by an
AS: routes originated by the AS and routes originated by its BGP cus-
tomers.  An AS may need to advertise full routes to certain BGP cus-
tomers, in which case the routing announcements include routes origi-
nated by non-customer ASs.  Clearly an AS can, and should, safely aggre-
gate the routes originated by itself and by its BGP customers multi-
homed only to it (using, e.g., the dedicated-AS and by the private-AS
mechanism [10]) in its outbound announcement.  But it is far more dan-
gerous to aggregate routes originated by customer ASs due to multi-hom-

However, there are several cases in which a route originated by a BGP
customer (other than using the dedicated AS or private AS) does not need
to be advertised out by its upstream providers.  For example,

-    The route is a more-specific of the upstream provider's block.
     However, the customer is either singly homed; or its connection to
     this particular upstream provider is used for backup only.

-    The more-specifics of a larger block are announced by the customer
     in order to balance traffic over the multiple links to the upstream


Our approach to suppress such routes is to aggregate them even though
they are originated by other ASs (termed "proxy aggregation").  However,
due to the legitimate need for injecting more-specifics for multi-hom-
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
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
upstream provider and is accepted by the upstream provider, the route
will not be announced beyond the upstream provider's AS. This achieves
the goal of suppressing the more-specifics in the upstream provider's
outbound announcement.

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
provider.  They may include routes allocated out of its upstream

provider's block or the more specific routes announced to its upstream
provider for the purpose of load balancing. This aggregation strategy
can be implemented via prefix-based filtering as shown in the example of
Section 5.

For its own protection, a downstream AS shall announce only its own
routes and its customer routes to its upstream providers.  Thus, the
outbound routing announcement and aggregation policy can be expressed as

   For routes originated by itself/dedicated-AS/private-AS:
      tag with "no-export" when appropriate, and advertise the
      large block and suppress the more-specifics

   For routes originated by customer ASs:
      advertise to upstream ASs

   For any other routes:
      do not advertise to upstream ASs

This approach is flexible and scales well as it gives control to the
party with the special needs, distributes the workload and avoids the
coordination overhead required by proxy aggregation.

4. Aggregation by a Provider

A provider shall aggregate all the routes it originates, as documented
in Section 3.  The only difference is that the provider may be providing
full routes to certain BGP customers where no outbound filtering is
presently in place.  Experience has shown that inconsistent route
announcement (e.g., aggregate at the interconnects but not toward cer-
tain customers) can cause serious routing problems for the Internet as a
whole because of longest-match routing.  In certain cases announcing the
more-specifics to customers might provide for more accurate IGP metrics
and could be useful for better load-balancing.  However, the potential
risk seems to outweigh the benefit, especially given the increasing com-
plexity of connectivity that a customer may have.  As a result, every
effort shall be made to ensure consistent route aggregation for all BGP
peers.  This means deploying filters for the BGP peers which receive
full routes.

In summary, the aggregation strategy for a provider shall be:

-    In announcing customer routes:

     For routes originated by itself/dedicated-AS/private-AS:
        tag with "no-export" when appropriate, and advertise the
        large block and suppress the more-specifics

     For routes originated by other customer ASs:

     For any other routes:
        do not advertise

-    In announcing full routes:

     For routes originated by itself/dedicated-AS/private-AS:
        tag with "no-export" when appropriate, and advertise the
        large block and suppress the more-specifics

     For any other routes:

5. An Example

Consider the example shown in Figure 3 where AS 1000 is a "Tier 1"
provider with two large aggregates and, and
AS 2000 is a customer of AS 1000 with a "portable address"
and an address allocated from AS 1000.  Assume that does not need to be propagated beyond AS 1000.

                             |    AS 1000     |
                             | |
                             |  |
                                     | BGP
                             |     AS 2000    |
                             | |
                             |  |

                                  Figure 3

Then, based on the framework presented, AS 1000 would

-    originate and advertise the BGP routes and, and suppress more-specifics originated by

-    advertise the routes received from the customer AS 2000

and AS 2000 would

-    originate BGP route and

-    advertise both and to its provider AS
     1000 and suppress the more specifics originated by itself/private-
     AS/dedicated-AS, taggin the route with "no-export"

-    advertise both and 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

The authors would like to thank Roy Alcala of MCI for a number of inter-
esting hallway discussions related to this work.  The IETF's IDR Working
Group also provided many helpful comments and suggestions.

7. References

[1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with
CIDR", RFC 1518, September 1993.

[2] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation Strategy",
RFC 1519, September 1993.

[3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995.

[4] Rekhter, Y., and Gross, P., "Application of the Border Gateway Pro-
tocol in the Internet", RFC1772, March 1995.

[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April

[6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute",
RFC 1997, August 1996.

[7] Chen, E., and Bates, T., "An Application of the BGP Community
Attribute in Multi-home Routing", RFC 1998, August 1996.

[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 BGP Without Consuming a Unique
ASN", Internet-Draft, January 1997 (expires July 1997), <draft-stewart-
Dedicated AS for Sites Homed to a Single Provider", RFC2270, January,

[11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour
Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-

[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
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134-1706
Phone: +1 408 527 4652

John W. Stewart, III
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA  94043
phone: +1 650 526 8000

A. Appendix A:  Example Cisco Configuration

This appendix lists the Cisco configurations for AS 2000 of the examples
presented in Section 5.   The configuration here uses the AS-path for
outbound filtering although it can also be based on BGP community.  Sev-
eral route-maps are defined that can be used for peering with the
upstream provider, and for peering with customers (announcing full
routes or customer routes).

!!# inject aggregates
ip route Null0 254
ip route Null0 254
router bgp 2000
network mask
network mask
neighbor x.x.x.x remote-as 1000
neighbor x.x.x.x route-map export-routes-to-provider out
neighbor x.x.x.x send-community
!!# match all
ip as-path access-list 1 permit .*
!!# List of internal AS and private ASs that are safe to aggregate
ip as-path access-list 10 permit ^$
ip as-path access-list 10 permit ^64999_
ip as-path access-list 10 deny .*
!!# list of other customer ASs
ip as-path access-list 20 permit ^3000_

!!# List of prefixes to be tagged with "no-export"
access-list 101 permit ip
!!# Filter out the more specifics of large aggregates, and permit the rest
access-list 102 permit ip
access-list 102 deny ip
access-list 102 permit ip
access-list 102 deny ip
access-list 102 permit ip any any

!!# route-map with the upstream provider
route-map export-routes-to-provider permit 10
match ip address 101
set community no-export
route-map export-routes-to-provider permit 20
match as-path 10
match ip address 102
route-map export-routes-to-provider permit 30
match as-path 20
!!# route-map with BGP customers that desire only customer routes
route-map export-customer-routes permit 10
match as-path 10
match ip address 102
route-map export-customer-routes permit 20
match as-path 20
!!# route-map with BGP customers that desire full routes
route-map export-full-routes permit 10
match as-path 10
match ip address 102
route-map export-full-routes permit 20
match as-path 1