draft-ietf-idr-aggregation-framework-01.txt   draft-ietf-idr-aggregation-framework-02.txt 
INTERNET-DRAFT Enke Chen / Cisco INTERNET-DRAFT Enke Chen
<draft-ietf-idr-aggregation-framework-01.txt> John W. Stewart, III / ISI <draft-ietf-idr-aggregation-framework-02.txt> Cisco
July 1997 John W. Stewart, III
Juniper
March 1998
A Framework for Inter-Domain Route Aggregation A Framework for Inter-Domain Route Aggregation
<draft-ietf-idr-aggregation-framework-01.txt> <draft-ietf-idr-aggregation-framework-02.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 line 29 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 "implement" 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.
Chen & Stewart [Page 1]
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 - Formulation and implementation of IP address allocation policies by
by the top registries that conform to the CIDR principles. [1] the top registries that conform to the CIDR principles. [1] This
This policy work is the cornerstone which makes efficient route policy work is the cornerstone which makes efficient route aggrega-
aggregation 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 date, the largest reductions in the size of the routing table have
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 However, the ability of various levels of the global routing system to
to implement efficient aggregation schemes varies widely. As a implement efficient aggregation schemes varies widely. As a result, the
result, the size and growth rate of the Internet routing table, as size and growth rate of the Internet routing table, as well as the asso-
well as the associated route computation required, remain major ciated route computation required, remain major issues today. To sup-
issues today. To support Internet growth, it is important to maxim- port Internet growth, it is important to maximize the efficiency of
ize the efficiency of aggregation at all levels in the routing sys- aggregation at all levels in the routing system.
tem.
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 defined framework in which scaleable inter-domain route aggregation can
can be realized. The framework described in this document emphasizes be realized. The framework described in this document emphasizes the
the philosophy of aggregation by the source, both within routing philosophy of aggregation by the source, both within routing domains as
domains as well as towards upstream providers. The framework also well as towards upstream providers. The framework also strongly encour-
strongly encourages the use of the "no-export" BGP community to bal- ages the use of the "no-export" BGP community to balance the provider-
ance the provider-subscriber need for more granular routing informa- subscriber need for more granular routing information with the Inter-
tion with the Internet's need for scalable inter-domain routing. The net's need for scalable inter-domain routing. The advantages of this
advantages of this framework include the following: framework include the following:
- Route aggregation is done in a distributed fashion. The Inter- - Route aggregation is done in a distributed fashion. The Internet
net is too large and too distributed for aggregation to be per- is too large and too distributed for aggregation to be performed
formed successfully by anyone other than the party injecting the successfully by anyone other than the party injecting the aggregat-
aggregatable routing information into the global mesh. able routing information into the global mesh.
Chen & Stewart [Page 2] - 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 ular routing information to an adjacent domain to control the
granular routing information to an adjacent domain to control resulting traffic patterns, without having an impact on the global
the resulting traffic patterns, without having an impact on the routing system.
global routing system.
In addition to describing the philosophy, we illustrate it by In addition to describing the philosophy, we illustrate it by presenting
presenting sample configurations. IPv4 prefixes, BGP4 and ASs are sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam-
used in examples, though the principles are applicable to inter- ples, though the principles are applicable to inter-domain route aggre-
domain route aggregation 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, references section contains pointers to relevant documents. [8, 9, 11,
11, 12] 12]
2. Route Aggregation Framework 2. Route Aggregation Framework
The framework of inter-domain route aggregation we are proposing can The framework of inter-domain route aggregation we are proposing can be
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 the BGP routes originated by itself, by dedicated AS and by pri-
private-ASs. [10] ("Routes originated by an AS" refers to vate-ASs. [10] ("Routes originated by an AS" refers to routes
routes which have that AS first in the AS path attribute. For which have that AS first in the AS path attribute. For example,
example, routes statically configured and injected into BGP fall routes statically configured and injected into BGP fall into this
into this category.) category.)
In general no "proxy aggregation" (i.e., aggregation of a route In general no "proxy aggregation" (i.e., aggregation of a route by
by an AS other than the originating AS) shall be performed. an AS other than the originating AS) shall be performed. This pre-
This preserves the capability of a multi-homed site to control serves the capability of a multi-homed site to control the granu-
the granularity of routing information injected into the global larity of routing information injected into the global routing sys-
routing system. Successful proxy aggregation requires coordina- tem. Proxy aggregation may be appropriate on a small scale where
tion on a very large scale (i.e., between potentially many pro- the necessary coordination is tractable. However, on a large
viders and subscribers) and experience has shown that this is scale, experience has shown that proxy aggregation is problematic
nearly impossible to achieve, so to date little aggregation has because the coordination is intractable.
been achieved with proxy aggregation.
An AS shall always originate via a stable mechanism (e.g., An AS shall always originate via a stable mechanism (e.g., static
static route configuration) the BGP routes for the large aggre- route configuration) the BGP routes for the large aggregates from
gates from which it allocates addresses to customers. This which it allocates addresses to customers. This ensures that it is
ensures that it is safe for its customers to use BGP "no- safe for its customers to use BGP "no-export".
export".
Chen & Stewart [Page 3]
- 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,
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).
That is, in its route announcements toward its upstream pro- This framework is illustrated in Figure 1. A "Tier 1" provider does not
vider, an AS tags the BGP community "no-export" to routes it use "no-export" in its announcement as it does not have an upstream
originates that do not need to be propagated beyond its upstream provider. However, it shall aggregate the routes it originates in its
provider (e.g., prefixes allocated by the upstream provider). outbound announcements towards both peer providers and customers. An AS
with an upstream provider shall aggregate the routes it originates and
This framework is illustrated in Figure 1. A "Tier 1" provider does use "no-export" toward its upstream provider for routes that do not need
not use "no-export" in its announcement as it does not have an to be propagated beyond its provider's AS. This recursion shall apply
upstream provider. However, it shall aggregate the routes it ori- to all levels of the routing hierarchy.
ginates 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 hierar-
chy.
Tier 1 Tier 1
+-- Provider <--+ +-- Provider <--+
| | | |
o aggregates routes | | o announces customer routes o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates it originates | | o aggregates routes it originates
| ^ o uses "no-export" if appropriate | ^ o uses "no-export" if appropriate
| |
+---> Tier 2 <--+ +---> Tier 2 <--+
Provider | Provider |
skipping to change at line 173 skipping to change at page 4, line 38
| | | |
o aggregates routes | | o announces customer routes o aggregates routes | | o announces customer routes
it originates | | o aggregates routes it originates it originates | | o aggregates routes it originates
| | o uses "no-export" if appropriate | | o uses "no-export" if appropriate
| | | |
| ^ | ^
-> Customer AS -> Customer AS
Figure 1 Figure 1
This framework scales well as aggregation is done at all levels of This framework scales well as aggregation is done at all levels of the
the routing system. It is flexible because the originating AS con- routing system. It is flexible because the originating AS controls
trols whether routes of finer granularity are injected to, and/or whether routes of finer granularity are injected to, and/or propagated
propagated by, its upstream provider. It facilitates multi-homing by, its upstream provider. It facilitates multi-homing without compro-
mising route aggregation.
Chen & Stewart [Page 4]
without compromising 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 It has been well recognized that address allocation and address renum-
renumbering are keys to containing the growth of the Internet routing bering are keys to containing the growth of the Internet routing table.
table. [1, 2, 8, 9, 11, 12] [1, 2, 8, 9, 11, 12]
Although the strategies discussed in this document do not assume a Although the strategies discussed in this document do not assume a per-
perfect address allocation, it is strongly urged that an AS receive fect address allocation, it is strongly urged that an AS receive alloca-
allocation 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:
- Carry in its BGP table the large route block allocated from its - Carry in its BGP table the large route block allocated from its
upstream provider or an address registry (e.g., InterNIC, RIPE, upstream provider or an address registry (e.g., InterNIC, RIPE,
APNIC). This can be done by either static configuration of the APNIC). This can be done by either static configuration of the
large block or by aggregating more specific BGP routes. The large block or by aggregating more specific BGP routes. The former
former is recommended as it does not depend on other routes. is recommended as it does not depend on other routes.
- Allocate sub-blocks to the access routers where further alloca- - Allocate sub-blocks to the access routers where further allocation
tion is done. That is, the address allocation shall be done is done. That is, the address allocation shall be done such that
such that only a few, less specific routes (instead of many only a few, less specific routes (instead of many more, specific
more, specific ones) need to be known to the other routers ones) need to be known to the other routers within the AS.
within the AS.
For example, a prefix of /17 can be further allocated to dif- For example, a prefix of /17 can be further allocated to different
ferent access routers as /20s which can then be allocated to access routers as /20s which can then be allocated to customers
customers connected to different interfaces on that router (as connected to different interfaces on that router (as shown in Fig-
shown in Figure 2). Then in general only the /20 needs to be ure 2). Then in general only the /20 needs to be injected into the
injected into the whole AS. Exceptions need to be made for whole AS. Exceptions need to be made for multi-homed static routes.
multi-homed static routes.
Chen & Stewart [Page 5]
access router access router
+------------+ +------------+
| x.x.x.x/20 | | x.x.x.x/20 |
+------------+ +------------+
| | | | | |
| | | | | |
/24 /22 /25 /24 /22 /25
Figure 2 Figure 2
It is noted that rehoming of customers without renumbering even It is noted that rehoming of customers without renumbering even within
within the same AS may lead to injection of more specific routes. the same AS may lead to injection of more specific routes. However, in
However, in general the more-specifics do not need to be advertised general the more-specifics do not need to be advertised outside of that
outside of that AS. Such routes can either be tagged with the BGP AS. Such routes can either be tagged with the BGP community "no-export"
community "no-export" or filtered out by a prefix-based filter to or filtered out by a prefix-based filter to prevent them from being
prevent them from being advertised out. advertised out.
3.2 Inter-Domain Aggregation 3.2 Inter-Domain Aggregation
There are at least two types of routes that need to be advertised by There are at least two types of routes that need to be advertised by an
an AS: routes originated by the AS and routes originated by its BGP AS: routes originated by the AS and routes originated by its BGP cus-
customers. An AS may need to advertise full routes to certain BGP tomers. An AS may need to advertise full routes to certain BGP cus-
customers, in which case the routing announcements include routes tomers, in which case the routing announcements include routes origi-
originated by non-customer ASs. Clearly an AS can, and should, nated by non-customer ASs. Clearly an AS can, and should, safely aggre-
safely aggregate the routes originated by itself and by its BGP cus- gate the routes originated by itself and by its BGP customers multi-
tomers multi-homed only to it (using, e.g., the dedicated-AS and by homed only to it (using, e.g., the dedicated-AS and by the private-AS
the private-AS mechanism [10]) in its outbound announcement. But it mechanism [10]) in its outbound announcement. But it is far more dan-
is far more dangerous to aggregate routes originated by customer ASs gerous to aggregate routes originated by customer ASs due to multi-hom-
due to multi-homing. ing.
However, there are several cases in which a route originated by a BGP 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 customer (other than using the dedicated AS or private AS) does not need
need 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 However, the customer is either singly homed; or its connection to
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 custo- - The more-specifics of a larger block are announced by the customer
mer in order to balance traffic over the multiple links to the in order to balance traffic over the multiple links to the upstream
upstream provider. provider.
One approach to suppress such routes is to aggregate them even though One approach to suppress such routes is to aggregate them even though
they are originated by other ASs (termed "proxy aggregation"). However,
Chen & Stewart [Page 6] due to the legitimate need for injecting more-specifics for multi-hom-
they are originated by other ASs (termed "proxy aggregation"). How- ing, proxy aggregation needs to be done with special coordination and
ever, due to the legitimate need for injecting more-specifics for care. The coordination work involved is non-trivial in a large environ-
multi-homing, proxy aggregation needs to be done with special coordi- ment, and as a result, little aggregation savings have been achieved
nation and care. The coordination work involved is non-trivial in a with proxy aggregation to date.
large environment, 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 Instead of "proxy aggregation," our approach for dealing with these
cases is to give control to the ASs that originate the more-specifics 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 commun- (as seen by its upstream providers) and let them tag the BGP community
ity "no-export" to the appropriate routes. "no-export" to the appropriate routes.
The BGP community "no-export" is a well known BGP community [6, 7]. The BGP community "no-export" is a well known BGP community [6, 7]. A
A route with this attribute is not propagated beyond an AS boundary. route with this attribute is not propagated beyond an AS boundary. So,
So, if a route is tagged with this community in its announcement to
an upstream provider and is accepted by the upstream provider, the if a route is tagged with this community in its announcement to an
route will not be announced beyond the upstream provider's AS. This upstream provider and is accepted by the upstream provider, the route
achieves the goal of suppressing the more-specifics in the upstream will not be announced beyond the upstream provider's AS. This achieves
provider's outbound announcement. 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 In this framework, the BGP community "no-export" shall be tagged to
routes that are to be advertized to, but not propagated by, its routes that are to be advertized to, but not propagated by, its upstream
upstream provider. They may include routes allocated out of its provider. They may include routes allocated out of its upstream
upstream provider's block or the more specific routes announced to provider's block or the more specific routes announced to its upstream
its upstream provider for the purpose of load balancing. This aggre- provider for the purpose of load balancing. This aggregation strategy
gation strategy can be implemented via prefix-based filtering as can be implemented via prefix-based filtering as shown in the example of
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 outbound routing announcement and aggregation policy can be expressed as
as follows: follows:
For routes originated by itself/dedicated-AS/private-AS: For routes originated by itself/dedicated-AS/private-AS:
tag with "no-export" when appropriate, and advertise the tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics large block and suppress the more-specifics
For routes originated by customer ASs: For routes originated by customer ASs:
advertise to upstream ASs advertise to upstream ASs
For any other routes: For any other routes:
do not advertise to upstream ASs do not advertise to upstream ASs
This approach is flexible and scales well as it gives control to the This approach is flexible and scales well as it gives control to the
party with the special needs, distributes the workload and avoids the party with the special needs, distributes the workload and avoids the
coordination overhead required by proxy aggregation. coordination overhead required by proxy aggregation.
Chen & Stewart [Page 7]
4. Aggregation by a Provider 4. Aggregation by a Provider
A provider shall aggregate all the routes it originates, as docu- A provider shall aggregate all the routes it originates, as documented
mented in Section 3. The only difference is that the provider may be in Section 3. The only difference is that the provider may be providing
providing full routes to certain BGP customers where no outbound full routes to certain BGP customers where no outbound filtering is
filtering is presently in place. Experience has shown that incon- presently in place. Experience has shown that inconsistent route
sistent route announcement (e.g., aggregate at the interconnects but announcement (e.g., aggregate at the interconnects but not toward cer-
not toward certain customers) can cause serious routing problems for tain customers) can cause serious routing problems for the Internet as a
the Internet as a whole because of longest-match routing. In certain whole because of longest-match routing. In certain cases announcing the
cases announcing the more-specifics to customers might provide for more-specifics to customers might provide for more accurate IGP metrics
more accurate IGP metrics and could be useful for better load- and could be useful for better load-balancing. However, the potential
balancing. However, the potential risk seems to outweigh the bene- risk seems to outweigh the benefit, especially given the increasing com-
fit, especially given the increasing complexity of connectivity that plexity of connectivity that a customer may have. As a result, every
a customer may have. As a result, every effort shall be made to effort shall be made to ensure consistent route aggregation for all BGP
ensure consistent route aggregation for all BGP peers. This means
deploying filters for the BGP peers which receive full routes. peers. This means deploying filters for the BGP peers which receive
full routes.
In summary, the aggregation strategy for a provider shall be: In summary, the aggregation strategy for a provider shall be:
- In announcing customer routes: - In announcing customer routes:
For routes originated by itself/dedicated-AS/private-AS: For routes originated by itself/dedicated-AS/private-AS:
tag with "no-export" when appropriate, and advertise the tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics large block and suppress the more-specifics
For routes originated by other customer ASs: For routes originated by other customer ASs:
skipping to change at line 355 skipping to change at page 8, line 34
For routes originated by itself/dedicated-AS/private-AS: For routes originated by itself/dedicated-AS/private-AS:
tag with "no-export" when appropriate, and advertise the tag with "no-export" when appropriate, and advertise the
large block and suppress the more-specifics large block and suppress the more-specifics
For any other routes: For any other routes:
advertise advertise
5. An Example 5. An Example
Consider the example shown in Figure 3 where AS 1000 is a "Tier 1" 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, provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16, and
and AS 2000 is a customer of AS 1000 with a "portable address" AS 2000 is a customer of AS 1000 with a "portable address" 160.75.0.0/16
160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000. 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 AS 1000.
Chen & Stewart [Page 8]
Assume that 208.128.0.0/19 does not need to be propagated beyond AS
1000.
+----------------+ +----------------+
| AS 1000 | | AS 1000 |
| 208.128.0.0/12 | | 208.128.0.0/12 |
| 166.55.0.0/16 | | 166.55.0.0/16 |
+----------------+ +----------------+
| |
| BGP | BGP
| |
| |
skipping to change at line 392 skipping to change at page 9, line 34
- 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.70.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 - advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS
AS 1000 and suppress the more specifics originated by 1000 and suppress the more specifics originated by itself/private-
itself/private-AS/dedicated-AS, taggin the route 208.128.0.0/19 AS/dedicated-AS, taggin the route 208.128.0.0/19 with "no-export"
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 custo- itself/private-AS/dedicated-AS, plus any other routes the customers
mers may desire to receive may desire to receive
The sample configuration which implement these policies (in Cisco
syntax) is given in Appendix A.
Chen & Stewart [Page 9] The sample configuration which implement these policies (in Cisco syn-
tax) is given in Appendix A.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Roy Alcala of MCI for a number of The authors would like to thank Roy Alcala of MCI for a number of inter-
interesting hallway discussions related to this work. The IETF's IDR esting hallway discussions related to this work. The IETF's IDR Working
Working Group also provided many helpful comments and suggestions. Group also provided many helpful comments and suggestions.
7. References 7. References
[1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation [1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with
with CIDR", RFC 1518, September 1993. CIDR", RFC 1518, September 1993.
[2] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- [2] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation Stra- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy",
tegy", RFC 1519, September 1993. RFC 1519, September 1993.
[3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC1771, March 1995.
[4] Rekhter, Y., and Gross, P., "Application of the Border Gateway [4] Rekhter, Y., and Gross, P., "Application of the Border Gateway Pro-
Protocol in the Internet", RFC1772, March 1995. tocol in the Internet", RFC1772, March 1995.
[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, [5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April
April 1995. 1995.
[6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute", [6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute",
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 [9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
1997.
[10] Stewart, J., and Chen, E., "Using BGP Without Consuming a Unique [10] Stewart, J., and Chen, E., "Using BGP Without Consuming a Unique
ASN", Internet-Draft, January 1997 (expires July 1997), <draft- ASN", Internet-Draft, January 1997 (expires July 1997), <draft-stewart-
stewart-bgp-multiprotocol-00.txt>. bgp-multiprotocol-00.txt>.
[11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address [11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour
Behaviour Today", Internet-Draft, October 1996 (expires April 1997), Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-
<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 [13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Con-
figuration Guide (Addendum), May 1995.
Chen & Stewart [Page 10]
Configuration Guide (Addendum), May 1995.
8. Authors' Addresses 8. Authors' Addresses
Enke Chen Enke Chen
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
Phone: +1 408 527 4652 Phone: +1 408 527 4652
email: enkechen@cisco.com email: enkechen@cisco.com
John W. Stewart, III John W. Stewart, III
USC/ISI Juniper Networks, Inc.
4350 North Fairfax Drive 385 Ravendale Drive
Suite 620 Mountain View, CA 94043
Arlington, VA 22203 phone: +1 650 526 8000
phone: +1 703 807 0132 email: jstewart@juniper.net
email: jstewart@isi.edu
Chen & Stewart [Page 11]
A. Appendix A: Example Cisco Configuration A. Appendix A: Example Cisco Configuration
This appendix lists the Cisco configurations for AS 2000 of the exam- This appendix lists the Cisco configurations for AS 2000 of the examples
ples presented in Section 5. The configuration here uses the AS- presented in Section 5. The configuration here uses the AS-path for
path for outbound filtering although it can also be based on BGP com- outbound filtering although it can also be based on BGP community. Sev-
munity. Several route-maps are defined that can be used for peering eral route-maps are defined that can be used for peering with the
with the upstream provider, and for peering with customers (announc- upstream provider, and for peering with customers (announcing full
ing full routes or customer routes). routes or customer routes).
Chen & Stewart [Page 12]
!!# inject aggregates !!# inject aggregates
ip route 160.75.0.0 255.255.0.0 Null0 254 ip route 160.75.0.0 255.255.0.0 Null0 254
ip route 208.128.0.0 255.255.224.0 Null0 254 ip route 208.128.0.0 255.255.224.0 Null0 254
! !
router bgp 2000 router bgp 2000
network 160.75.0.0 mask 255.255.0.0 network 160.75.0.0 mask 255.255.0.0
network 208.128.0.0 mask 255.255.224.0 network 208.128.0.0 mask 255.255.224.0
neighbor x.x.x.x remote-as 1000 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 route-map export-routes-to-provider out
neighbor x.x.x.x send-community neighbor x.x.x.x send-community
skipping to change at line 535 skipping to change at page 13, line 52
match ip address 102 match ip address 102
route-map export-routes-to-provider permit 30 route-map export-routes-to-provider permit 30
match as-path 20 match as-path 20
! !
!!# route-map with BGP customers that desire only customer routes !!# route-map with BGP customers that desire only customer routes
route-map export-customer-routes permit 10 route-map export-customer-routes permit 10
match as-path 10 match as-path 10
match ip address 102 match ip address 102
route-map export-customer-routes permit 20 route-map export-customer-routes permit 20
match as-path 20 match as-path 20
Chen & Stewart [Page 13]
! !
!!# route-map with BGP customers that desire full routes !!# route-map with BGP customers that desire full routes
route-map export-full-routes permit 10 route-map export-full-routes permit 10
match as-path 10 match as-path 10
match ip address 102 match ip address 102
route-map export-full-routes permit 20 route-map export-full-routes permit 20
match as-path 1 match as-path 1
! !
Chen & Stewart [Page 14]
 End of changes. 

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