As per Relevance of the word aggregation, we have this rfc below:
Network Working Group E.
Request for Comments: 2519
Category: Informational J.
February 1999
A Framework for Inter-Domain Route
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document presents a framework for inter-domain route
and shows an example router configuration which 'implements'
framework. This framework is flexible and scales well as
emphasizes the philosophy of aggregation by the source, both
routing domains as well as towards upstream providers, and it
strongly encourages the use of the 'no-export' BGP community
balance the provider-subscriber need for more granular
information with the Internet's need for scalable inter-
routing
1.
The need for route aggregation has long been recognized.
aggregation is good as it reduces the size, and slows the growth,
the Internet routing table. Thus, the amount of resources (e.g.,
and memory) required to process routing information is reduced
route calculation is sped up. Another benefit of route
is that route flaps are limited in number, frequency and scope,
saves resources and makes the global Internet routing system
stable
Since CIDR (Classless Inter-Domain Routing) [2] was introduced
significant progress has been made on route aggregation,
in the following two areas
- Formulation and implementation of IP address allocation
by the top registries that conform to the CIDR principles [1].
Chen & Stewart Informational [Page 1]
RFC 2519 Inter-Domain Route Aggregation February 1999
This policy work is the cornerstone which makes efficient
aggregation technically possible
- Route aggregation by large (especially "Tier 1") providers.
date, the largest reductions in the size of the routing
have resulted from efficient aggregation by large providers
However, the ability of various levels of the global routing
to implement efficient aggregation schemes varies widely. As
result, the size and growth rate of the Internet routing table,
well as the associated route computation required, remain
issues today. To support Internet growth, it is important
maximize the efficiency of aggregation at all levels in the
system
Because of the current size of the routing system and its
nature, the first step towards this goal is to establish a
defined framework in which scaleable inter-domain route
can be realized. The framework described in this document is
on the predominant and current experience in the Internet.
emphasizes the philosophy of aggregation by the source, both
routing domains as well as towards upstream providers. The
also strongly encourages the use of the "no-export" BGP community
balance the providersubscriber need for more granular
information with the Internet's need for scalable inter-
routing. The advantages of this framework include the following
- Route aggregation is done in a distributed fashion,
emphasis on aggregation by the party or parties injecting
aggregatable routing information into the global mesh
- The flexibility of a routing domain to be able to inject
granular routing information to an adjacent domain to
the resulting traffic patterns, without having an impact on
global routing system
In addition to describing the philosophy, we illustrate it
presenting sample configurations. IPv4 prefixes, BGP4 and
are used in examples, though the principles are applicable
inter-domain route aggregation in general
Address allocation policies and technologies to renumber
networks, while very relevant to the realization of
and sustained inter-domain routing, are not the focus of
document. The references section contains pointers to
documents [8, 9, 11, 12].
Chen & Stewart Informational [Page 2]
RFC 2519 Inter-Domain Route Aggregation February 1999
2. Route Aggregation
The framework of inter-domain route aggregation we are proposing
be summarized as follows
- Aggregation from the originating
That is, in its outbound route announcements, each AS
the BGP routes originated by itself, by dedicated AS and
private-ASs [10]. ("Routes originated by an AS" refers
routes which have that AS first in the AS path attribute.
example, routes statically configured and injected into BGP
into this category.)
This framework does not depend on "proxy aggregation"
refers to route aggregation done by an AS other than
originating AS. This preserves the capability of a multi-
site to control the granularity of routing information
into the global routing system. Since proxy aggregation
coordination among multiple organizations, the complexity
doing proxy aggregation increases with the number of
involved in the coordination. The complexity, in turn,
the practicality of proxy aggregation
An AS shall always originate via a stable mechanism (e.g.,
static route configuration) the BGP routes for the
aggregates from which it allocates addresses to customers.
ensures that it is safe for its customers to use BGP "no
export".
- Using BGP community "no-export" toward upstream
That is, in its route announcements toward its
provider, an AS tags the BGP community "no-export" to routes
originates that do not need to be propagated beyond its
provider (e.g., prefixes allocated by the upstream provider).
This framework is illustrated in Figure 1. A "Tier 1" provider
not use "no-export" in its announcement as it does not have
upstream provider. However, it shall aggregate the routes
originates in its outbound announcements towards both peer
and customers. An AS with an upstream provider shall aggregate
routes it originates and use "no-export" toward its upstream
for routes that do not need to be propagated beyond its provider'
AS. This recursion shall apply to all levels of the
hierarchy
Chen & Stewart Informational [Page 3]
RFC 2519 Inter-Domain Route Aggregation February 1999
Tier 1
+-- Provider <--+
| |
o aggregates routes | | o announces customer
it originates | | o aggregates routes it
| ^ o uses "no-export" if
|
+---> Tier 2 <--+
Provider |
V |
| |
o aggregates routes | | o announces customer
it originates | | o aggregates routes it
| | o uses "no-export" if
| |
| ^
-> Customer
Figure 1
This framework scales well as aggregation is done at all levels
the routing system. It is flexible because the originating
controls whether routes of finer granularity are injected to, and/
propagated by, its upstream provider. It facilitates multi-
without compromising route aggregation
This framework is detailed in the following sections
3. Aggregation from the Originating
It has been well recognized that address allocation and
renumbering are keys to containing the growth of the Internet
table [1, 2, 8, 9, 11, 12].
Although the strategies discussed in this document do not assume
perfect address allocation, it is strongly urged that an AS
allocation from its upstream service providers' address block
3.1 Intra-Domain
To reduce the number of routes that need to be injected into an AS
there are a couple of principles that shall be followed
Chen & Stewart Informational [Page 4]
RFC 2519 Inter-Domain Route Aggregation February 1999
- Carry in its BGP table the large route block allocated from
upstream provider or an address registry (e.g., InterNIC, RIPE
APNIC). This can be done by either static configuration of
large block or by aggregating more specific BGP routes.
former is recommended as it does not depend on other routes
- Allocate sub-blocks to the access routers where
allocation is done. That is, the address allocation shall
done such that only a few, less specific routes (instead of
more, specific ones) need to be known to the other
within the AS
For example, a prefix of /17 can be further allocated
different access routers as /20s which can then be allocated
customers connected to different interfaces on that router (
shown in Figure 2). Then in general only the /20 needs to
injected into the whole AS. Exceptions need to be made
multi-homed static routes
access
+------------+
| x.x.x.x/20 |
+------------+
| | |
| | |
/24 /22 /25
Figure 2
It is noted that rehoming of customers without renumbering
within the same AS may lead to injection of more specific routes
However, in general the more-specifics do not need to be
outside of that AS. Such routes can either be tagged with the
community "no-export" or filtered out by a prefix-based filter
prevent them from being advertised out
3.2 Inter-Domain
There are at least two types of routes that need to be advertised
an AS: routes originated by the AS and routes originated by its
customers. An AS may need to advertise full routes to certain
customers, in which case the routing announcements include
originated by non-customer ASs. Clearly an AS can, and should
safely aggregate the routes originated by itself and by its
customers multi-homed only to it (using, e.g., the dedicated-AS
Chen & Stewart Informational [Page 5]
RFC 2519 Inter-Domain Route Aggregation February 1999
by the private-AS mechanism [10]) in its outbound announcement.
it is far more dangerous to aggregate routes originated by
ASs due to multi-homing
However, there are several cases in which a route originated by a
customer (other than using the dedicated AS or private AS) does
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
to this particular upstream provider is used for backup only
- The more-specifics of a larger block are announced by
customer in order to balance traffic over the multiple links
the upstream provider
Our approach to suppress such routes is to give control to the
that originate the more-specifics (as seen by its upstream providers
and let them tag the BGP community "no-export" to the
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
an upstream provider and is accepted by the upstream provider,
route will not be announced beyond the upstream provider's AS.
achieves the goal of suppressing the more-specifics in the
provider's outbound announcement
In this framework, the BGP community "no-export" shall be tagged
routes that are to be advertized to, but not propagated by,
upstream provider. They may include routes allocated out of
upstream provider's block or the more specific routes announced
its upstream provider for the purpose of load balancing.
aggregation strategy can be implemented via prefix-based filtering
shown in the example of Section 5.
For its own protection, a downstream AS shall announce only its
routes and its customer routes to its upstream providers. Thus,
outbound routing announcement and aggregation policy can be
as follows
For routes originated by itself/dedicated-AS/private-AS
tag with "no-export" when appropriate, and advertise
large block and suppress the more-
For routes originated by customer ASs
advertise to upstream
Chen & Stewart Informational [Page 6]
RFC 2519 Inter-Domain Route Aggregation February 1999
For any other routes
do not advertise to upstream
This approach is flexible and scales well as it gives control to
party with the special needs, distributes the workload and avoids
coordination overhead required by proxy aggregation
4. Aggregation by a
A provider shall aggregate all the routes it originates,
documented in Section 3. The only difference is that the
may be providing full routes to certain BGP customers where
outbound filtering is presently in place. Experience has shown
inconsistent route announcement (e.g., aggregate at the
but not toward certain customers) can cause serious routing
for the Internet as a whole because of longest-match routing.
certain cases announcing the more-specifics to customers
provide for more accurate IGP metrics and could be useful for
load-balancing. However, the potential risk seems to outweigh
benefit, especially given the increasing complexity of
that a customer may have. As a result, every effort shall be made
ensure consistent route aggregation for all BGP peers. This
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
large block and suppress the more-
For routes originated by other customer ASs
For any other routes
do not
- In announcing full routes
For routes originated by itself/dedicated-AS/private-AS
tag with "no-export" when appropriate, and advertise
large block and suppress the more-
For any other routes
Chen & Stewart Informational [Page 7]
RFC 2519 Inter-Domain Route Aggregation February 1999
5. An
Consider the example shown in Figure 3 where AS 1000 is a "Tier 1"
provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16,
and AS 2000 is a customer of AS 1000 with a "portable address
160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000.
Assume that 208.128.0.0/19 does not need to be propagated beyond
1000.
+----------------+
| AS 1000 |
| 208.128.0.0/12 |
| 166.55.0.0/16 |
+----------------+
|
|
|
|
+----------------+
| AS 2000 |
| 208.128.0.0/19 |
| 160.75.0.0/16 |
+----------------+
Figure 3
Then, based on the framework presented, AS 1000
- originate and advertise the BGP routes 208.128.0.0/12
166.55.0.0/16, and suppress more-specifics originated
itself/private-ASs/dedicated-
- advertise the routes received from the customer AS 2000
and AS 2000
- 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
AS 1000 and suppress the more specifics originated
itself/private-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
customers (if any) and suppress the more-specifics originated
itself/private-AS/dedicated-AS, plus any other routes
customers may desire to
Chen & Stewart Informational [Page 8]
RFC 2519 Inter-Domain Route Aggregation February 1999
The sample configuration which implement these policies (in
syntax) is given in Appendix A
6.
The authors would like to thank Roy Alcala of MCI for a number
interesting hallway discussions related to this work. The IETF's
Working Group also provided many helpful comments and suggestions
7.
[1] Rekhter, Y. and T. Li, "An Architecture for IP Address
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
Strategy", RFC 1519, September 1993.
[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[4] Rekhter, Y. and P., Gross, "Application of the Border
Protocol in the Internet", RFC 1772, March 1995.
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
April 1995.
[6] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute",
RFC 1997, August 1996.
[7] Chen, E. and T. Bates, "An Application of the BGP
Attribute in Multi-home Routing", RFC 1998, August 1996.
[8] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
would I want it and what is it anyway?", RFC 2071, January 1997.
[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072,
1997.
[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using
Dedicated AS for Sites Homed to a Single Provider", RFC 2270,
January 1998.
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Behaviour Today", RFC 2101, February 1997.
[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
1900, February 1996.
Chen & Stewart Informational [Page 9]
RFC 2519 Inter-Domain Route Aggregation February 1999
[13] Cisco systems, Cisco IOS Software Version 10.3 Router
Configuration Guide (Addendum), May 1995.
8. Authors'
Enke
Cisco
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 527 4652
EMail: enkechen@cisco.
John W. Stewart,
Juniper Networks, Inc
385 Ravendale
Mountain View, CA 94043
Phone: +1 650 526 8000
EMail: jstewart@juniper.
Chen & Stewart Informational [Page 10]
RFC 2519 Inter-Domain Route Aggregation February 1999
A. Appendix A: Example Cisco
This appendix lists the Cisco configurations for AS 2000 of
examples presented in Section 5. The configuration here uses
AS-path for outbound filtering although it can also be based on
community. Several route-maps are defined that can be used
peering with the upstream provider, and for peering with
(announcing full routes or customer routes).
!!# inject
ip route 160.75.0.0 255.255.0.0 Null0 254
ip route 208.128.0.0 255.255.224.0 Null0 254
router bgp 2000
network 160.75.0.0 mask 255.255.0.0
network 208.128.0.0 mask 255.255.224.0
neighbor x.x.x.x remote-as 1000
neighbor x.x.x.x route-map export-routes-to-provider
neighbor x.x.x.x send-
!!# match
ip as-path access-list 1 permit .*
!!# List of internal AS and private ASs that are safe to
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
ip as-path access-list 20 permit ^3000_
!!# List of prefixes to be tagged with "no-export
access-list 101 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0
!!# Filter out the more specifics of large aggregates, and permit the
access-list 102 permit ip 160.75.0.0 0.0.0.0 255.255.0.0 0.0.0.0
access-list 102 deny ip 160.75.0.0 0.0.255.255 255.255.128.0 0.0.127.255
access-list 102 permit ip 208.128.0.0 0.0.0.0 255.255.224.0 0.0.0.0
access-list 102 deny ip 208.128.0.0 0.0.31.255 255.255.240.0 0.0.16.255
access-list 102 permit ip any
!!# route-map with the upstream
route-map export-routes-to-provider permit 10
match ip address 101
set community no-
route-map export-routes-to-provider permit 20
match as-path 10
match ip address 102
Chen & Stewart Informational [Page 11]
RFC 2519 Inter-Domain Route Aggregation February 1999
route-map export-routes-to-provider permit 30
match as-path 20
!!# route-map with BGP customers that desire only customer
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
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
Chen & Stewart Informational [Page 12]
RFC 2519 Inter-Domain Route Aggregation February 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Chen & Stewart Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
