draft-ietf-idr-aggregation-framework-04.txt		rfc2519.txt
	INTERNET-DRAFT Enke Chen		Network Working Group E. Chen
	<draft-ietf-idr-aggregation-framework-04.txt> Cisco		Request for Comments: 2519 Cisco
	John W. Stewart, III		Category: Informational J. Stewart
	Juniper		Juniper
	December 1998		February 1999
	A Framework for Inter-Domain Route Aggregation		A Framework for Inter-Domain Route Aggregation
	<draft-ietf-idr-aggregation-framework-04.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This memo provides information for the Internet community. It does
	documents of the Internet Engineering Task Force (IETF), its areas,		not specify an Internet standard of any kind. Distribution of this
	and its working groups. Note that other groups may also distribute		memo is unlimited.
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Copyright Notice
	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		Copyright (C) The Internet Society (1999). All Rights Reserved.
	directory to learn the current status of this or any other Internet-
	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 'implements' this		and shows an example router configuration which 'implements' this
	framework. This framework is flexible and scales well as it		framework. This framework is flexible and scales well as it
	emphasizes the philosophy of aggregation by the source, both within		emphasizes the philosophy of aggregation by the source, both within
	routing domains as well as towards upstream providers, and it also		routing domains as well as towards upstream providers, and it also
	strongly encourages the use of the 'no-export' BGP community to		strongly encourages the use of the 'no-export' BGP community to
	balance the provider-subscriber need for more granular routing		balance the provider-subscriber need for more granular routing
	skipping to change at page 2, line 20		skipping to change at page 1, line 48
	and memory) required to process routing information is reduced and		and memory) required to process routing information is reduced and
	route calculation is sped up. Another benefit of route aggregation		route calculation is sped up. Another benefit of route aggregation
	is that route flaps are limited in number, frequency and scope, which		is that route flaps are limited in number, frequency and scope, which
	saves resources and makes the global Internet routing system more		saves resources and makes the global Internet routing system more
	stable.		stable.
	Since CIDR (Classless Inter-Domain Routing) [2] was introduced,		Since CIDR (Classless Inter-Domain Routing) [2] was introduced,
	significant progress has been made on route aggregation, particularly		significant progress has been made on route aggregation, particularly
	in the following two areas:		in the following two areas:
	- Formulation and implementation of IP address allocation policies by		- Formulation and implementation of IP address allocation policies
	the top registries that conform to the CIDR principles [1]. This		by the top registries that conform to the CIDR principles [1].
	policy work is the cornerstone which makes efficient route aggrega-
	tion technically possible.
	- Route aggregation by large (especially "Tier 1") providers. To		This policy work is the cornerstone which makes efficient route
	date, the largest reductions in the size of the routing table have		aggregation technically possible.
	resulted from efficient aggregation by large providers.
	However, the ability of various levels of the global routing system to		- Route aggregation by large (especially "Tier 1") providers. To
	implement efficient aggregation schemes varies widely. As a result, the		date, the largest reductions in the size of the routing table
	size and growth rate of the Internet routing table, as well as the asso-		have resulted from efficient aggregation by large providers.
	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		However, the ability of various levels of the global routing system
	nature, the first step towards this goal is to establish a clearly-		to implement efficient aggregation schemes varies widely. As a
	defined framework in which scaleable inter-domain route aggregation can		result, the size and growth rate of the Internet routing table, as
	be realized. The framework described in this document is based on the		well as the associated route computation required, remain major
	predominant and current experience in the Internet. It emphasizes the		issues today. To support Internet growth, it is important to
	philosophy of aggregation by the source, both within routing domains as		maximize the efficiency of aggregation at all levels in the routing
	well as towards upstream providers. The framework also strongly encour-		system.
	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, with emphasis		Because of the current size of the routing system and its dynamic
	on aggregation by the party or parties injecting the aggregatable		nature, the first step towards this goal is to establish a clearly
	routing information into the global mesh.		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 encourages the use of the "no-export" BGP community to
			balance the providersubscriber need for more granular routing
			information with the Internet's need for scalable inter-domain
			routing. The advantages of this framework include the following:
	- The flexibility of a routing domain to be able to inject more gran-		- Route aggregation is done in a distributed fashion, with
	ular routing information to an adjacent domain to control the		emphasis on aggregation by the party or parties injecting the
	resulting traffic patterns, without having an impact on the global		aggregatable routing information into the global mesh.
	routing system.
	In addition to describing the philosophy, we illustrate it by presenting		- The flexibility of a routing domain to be able to inject more
	sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam-		granular routing information to an adjacent domain to control
	ples, though the principles are applicable to inter-domain route aggre-		the resulting traffic patterns, without having an impact on the
	gation in general.		global routing system.
	Address allocation policies and technologies to renumber entire net-		In addition to describing the philosophy, we illustrate it by
	works, while very relevant to the realization of successful and sus-		presenting sample configurations. IPv4 prefixes, BGP4 and ASs
	tained inter-domain routing, are not the focus of this document. The		are used in examples, though the principles are applicable to
	references section contains pointers to relevant documents [8, 9, 11,		inter-domain route aggregation in general.
	12].
			Address allocation policies and technologies to renumber entire
			networks, while very relevant to the realization of successful
			and sustained inter-domain routing, are not the focus of this
			document. The references section contains pointers to relevant
			documents [8, 9, 11, 12].
	2. Route Aggregation Framework		2. Route Aggregation Framework
	The framework of inter-domain route aggregation we are proposing can be		The framework of inter-domain route aggregation we are proposing can
	summarized as follows:		be summarized as follows:
	- Aggregation from the originating AS		- Aggregation from the originating AS
	That is, in its outbound route announcements, each AS aggregates		That is, in its outbound route announcements, each AS aggregates
	the BGP routes originated by itself, by dedicated AS and by pri-		the BGP routes originated by itself, by dedicated AS and by
	vate-ASs [10]. ("Routes originated by an AS" refers to routes		private-ASs [10]. ("Routes originated by an AS" refers to
	which have that AS first in the AS path attribute. For example,		routes which have that AS first in the AS path attribute. For
	routes statically configured and injected into BGP fall into this		example, routes statically configured and injected into BGP fall
	category.)		into this category.)
	This framework does not depend on "proxy aggregation" which refers		This framework does not depend on "proxy aggregation" which
	to route aggregation done by an AS other than the originating AS.		refers to route aggregation done by an AS other than the
	This preserves the capability of a multi-homed site to control the		originating AS. This preserves the capability of a multi-homed
	granularity of routing information injected into the global routing		site to control the granularity of routing information injected
	system. Since proxy aggregation involves coordination among multiple		into the global routing system. Since proxy aggregation involves
	organizations, the complexity of doing proxy aggregation increases		coordination among multiple organizations, the complexity of
	with the number of parties involved in the coordination. The		doing proxy aggregation increases with the number of parties
	complexity, in turn, impacts the practicality of proxy aggregation.		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		An AS shall always originate via a stable mechanism (e.g.,
	route configuration) the BGP routes for the large aggregates from		static route configuration) the BGP routes for the large
	which it allocates addresses to customers. This ensures that it is		aggregates from which it allocates addresses to customers. This
	safe for its customers to use BGP "no-export".		ensures that it is 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,
	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		That is, in its route announcements toward its upstream
	use "no-export" in its announcement as it does not have an upstream		provider, an AS tags the BGP community "no-export" to routes it
	provider. However, it shall aggregate the routes it originates in its		originates that do not need to be propagated beyond its upstream
	outbound announcements towards both peer providers and customers. An AS		provider (e.g., prefixes allocated by the upstream provider).
	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		This framework is illustrated in Figure 1. A "Tier 1" provider does
	+-- Provider <--+		not use "no-export" in its announcement as it does not have an
	| |		upstream provider. However, it shall aggregate the routes it
	o aggregates routes | | o announces customer routes		originates in its outbound announcements towards both peer providers
	it originates | | o aggregates routes it originates		and customers. An AS with an upstream provider shall aggregate the
	| ^ o uses "no-export" if appropriate		routes it originates and use "no-export" toward its upstream provider
	|		for routes that do not need to be propagated beyond its provider's
	+---> Tier 2 <--+		AS. This recursion shall apply to all levels of the routing
	Provider |		hierarchy.
	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		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
	This framework scales well as aggregation is done at all levels of the		Figure 1
	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.		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 compromising route aggregation.
			This framework is detailed in the following sections.
	3. Aggregation from the Originating AS		3. Aggregation from the Originating AS
	It has been well recognized that address allocation and address renum-		It has been well recognized that address allocation and address
	bering are keys to containing the growth of the Internet routing table		renumbering are keys to containing the growth of the Internet routing
	[1, 2, 8, 9, 11, 12].		table [1, 2, 8, 9, 11, 12].
	Although the strategies discussed in this document do not assume a per-		Although the strategies discussed in this document do not assume a
	fect address allocation, it is strongly urged that an AS receive alloca-		perfect address allocation, it is strongly urged that an AS receive
	tion from its upstream service providers' address block.		allocation 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 former		large block or by aggregating more specific BGP routes. The
	is recommended as it does not depend on other routes.		former is recommended as it does not depend on other routes.
	- Allocate sub-blocks to the access routers where further allocation		- Allocate sub-blocks to the access routers where further
	is done. That is, the address allocation shall be done such that		allocation is done. That is, the address allocation shall be
	only a few, less specific routes (instead of many more, specific		done such that only a few, less specific routes (instead of many
	ones) need to be known to the other routers within the AS.		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		For example, a prefix of /17 can be further allocated to
	access routers as /20s which can then be allocated to customers		different access routers as /20s which can then be allocated to
	connected to different interfaces on that router (as shown in Fig-		customers connected to different interfaces on that router (as
	ure 2). Then in general only the /20 needs to be injected into the		shown in Figure 2). Then in general only the /20 needs to be
	whole AS. Exceptions need to be made for multi-homed static routes.		injected into the whole AS. Exceptions need to be made for
			multi-homed static routes.
	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 within		It is noted that rehoming of customers without renumbering even
	the same AS may lead to injection of more specific routes. However, in		within the same AS may lead to injection of more specific routes.
	general the more-specifics do not need to be advertised outside of that		However, in general the more-specifics do not need to be advertised
	AS. Such routes can either be tagged with the BGP community "no-export"		outside of that AS. Such routes can either be tagged with the BGP
	or filtered out by a prefix-based filter to prevent them from being		community "no-export" or filtered out by a prefix-based filter to
	advertised out.		prevent them from being 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 an		There are at least two types of routes that need to be advertised by
	AS: routes originated by the AS and routes originated by its BGP cus-		an AS: routes originated by the AS and routes originated by its BGP
	tomers. An AS may need to advertise full routes to certain BGP cus-		customers. An AS may need to advertise full routes to certain BGP
	tomers, in which case the routing announcements include routes origi-		customers, in which case the routing announcements include routes
	nated by non-customer ASs. Clearly an AS can, and should, safely aggre-		originated by non-customer ASs. Clearly an AS can, and should,
	gate the routes originated by itself and by its BGP customers multi-		safely aggregate the routes originated by itself and by its BGP
	homed only to it (using, e.g., the dedicated-AS and by the private-AS		customers multi-homed only to it (using, e.g., the dedicated-AS and
	mechanism [10]) in its outbound announcement. But it is far more dan-		by the private-AS mechanism [10]) in its outbound announcement. But
	gerous to aggregate routes originated by customer ASs due to multi-hom-		it is far more dangerous to aggregate routes originated by customer
	ing.		ASs due to multi-homing.
	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 need		customer (other than using the dedicated AS or private AS) does not
	to be advertised out by its upstream providers. For example,		need 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
	this particular upstream provider is used for backup only.		to 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
	in order to balance traffic over the multiple links to the upstream		customer in order to balance traffic over the multiple links to
	provider.		the upstream provider.
	Our approach to suppress such routes is to give control to the ASs that		Our approach to suppress such routes is to give control to the ASs
	originate the more-specifics (as seen by its upstream providers) and let		that originate the more-specifics (as seen by its upstream providers)
	them tag the BGP community "no-export" to the appropriate routes.		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].
	route with this attribute is not propagated beyond an AS boundary. So,		A route with this attribute is not propagated beyond an AS boundary.
	if a route is tagged with this community in its announcement to an		So, if a route is tagged with this community in its announcement to
	upstream provider and is accepted by the upstream provider, the route		an upstream provider and is accepted by the upstream provider, the
	will not be announced beyond the upstream provider's AS. This achieves		route will not be announced beyond the upstream provider's AS. This
	the goal of suppressing the more-specifics in the upstream provider's		achieves the goal of suppressing the more-specifics in the upstream
	outbound announcement.		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 upstream		routes that are to be advertized to, but not propagated by, its
	provider. They may include routes allocated out of its upstream		upstream provider. They may include routes allocated out of its
	provider's block or the more specific routes announced to its upstream		upstream provider's block or the more specific routes announced to
	provider for the purpose of load balancing. This aggregation strategy		its upstream provider for the purpose of load balancing. This
	can be implemented via prefix-based filtering as shown in the example of		aggregation strategy can be implemented via prefix-based filtering as
	Section 5.		shown in the example of 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
	follows:		as 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.
	4. Aggregation by a Provider		4. Aggregation by a Provider
	A provider shall aggregate all the routes it originates, as documented		A provider shall aggregate all the routes it originates, as
	in Section 3. The only difference is that the provider may be providing		documented in Section 3. The only difference is that the provider
	full routes to certain BGP customers where no outbound filtering is		may be providing full routes to certain BGP customers where no
	presently in place. Experience has shown that inconsistent route		outbound filtering is presently in place. Experience has shown that
	announcement (e.g., aggregate at the interconnects but not toward cer-		inconsistent route announcement (e.g., aggregate at the interconnects
	tain customers) can cause serious routing problems for the Internet as a		but not toward certain customers) can cause serious routing problems
	whole because of longest-match routing. In certain cases announcing the		for the Internet as a whole because of longest-match routing. In
	more-specifics to customers might provide for more accurate IGP metrics		certain cases announcing the more-specifics to customers might
	and could be useful for better load-balancing. However, the potential		provide for more accurate IGP metrics and could be useful for better
	risk seems to outweigh the benefit, especially given the increasing com-		load-balancing. However, the potential risk seems to outweigh the
	plexity of connectivity that a customer may have. As a result, every		benefit, especially given the increasing complexity of connectivity
	effort shall be made to ensure consistent route aggregation for all BGP		that a customer may have. As a result, every effort shall be made to
	peers. This means deploying filters for the BGP peers which receive		ensure consistent route aggregation for all BGP peers. This means
	full routes.		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:
	advertise		advertise
	For any other routes:		For any other routes:
	do not advertise		do not advertise
	- In announcing full routes:		- In announcing full 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 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, and		provider with two large aggregates 208.128.0.0/12 and 166.55.0.0/16,
	AS 2000 is a customer of AS 1000 with a "portable address" 160.75.0.0/16		and AS 2000 is a customer of AS 1000 with a "portable address"
	and an address 208.128.0.0/19 allocated from AS 1000. Assume that		160.75.0.0/16 and an address 208.128.0.0/19 allocated from AS 1000.
	208.128.0.0/19 does not need to be propagated beyond AS 1000.		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
	|		|
	|		|
	+----------------+		+----------------+
	| AS 2000 |		| AS 2000 |
	| 208.128.0.0/19 |		| 208.128.0.0/19 |
	| 160.75.0.0/16 |		| 160.75.0.0/16 |
	+----------------+		+----------------+
	Figure 3		Figure 3
	Then, based on the framework presented, AS 1000 would		Then, based on the framework presented, AS 1000 would
	- originate and advertise the BGP routes 208.128.0.0/12 and		- originate and advertise the BGP routes 208.128.0.0/12 and
	166.55.0.0/16, and suppress more-specifics originated by		166.55.0.0/16, and suppress more-specifics originated by
	itself/private-ASs/dedicated-ASs		itself/private-ASs/dedicated-ASs
	- advertise the routes received from the customer AS 2000		- advertise the routes received from the customer AS 2000
	and AS 2000 would		and AS 2000 would
	- originate BGP route 208.128.0.0/19 and 160.75.0.0/16		- originate BGP route 208.128.0.0/19 and 160.75.0.0/16
	- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider AS		- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its provider
	1000 and suppress the more specifics originated by itself/private-		AS 1000 and suppress the more specifics originated by
	AS/dedicated-AS, tagging the route 208.128.0.0/19 with "no-export"		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 BGP cus-		- advertise both 160.75.0.0/16 and 208.128.0.0/19 to its BGP
	tomers (if any) and suppress the more-specifics originated by		customers (if any) and suppress the more-specifics originated by
	itself/private-AS/dedicated-AS, plus any other routes the customers		itself/private-AS/dedicated-AS, plus any other routes the
	may desire to receive		customers may desire to receive
	The sample configuration which implement these policies (in Cisco syn-		The sample configuration which implement these policies (in Cisco
	tax) is given in Appendix A.		syntax) is given in Appendix A.
	6. Acknowledgments		6. Acknowledgments
	The authors would like to thank Roy Alcala of MCI for a number of inter-		The authors would like to thank Roy Alcala of MCI for a number of
	esting hallway discussions related to this work. The IETF's IDR Working		interesting hallway discussions related to this work. The IETF's IDR
	Group also provided many helpful comments and suggestions.		Working Group also provided many helpful comments and suggestions.
	7. References		7. References
	[1] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with		[1] Rekhter, Y. and T. Li, "An Architecture for IP Address Allocation
	CIDR", RFC 1518, September 1993.		with 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 Strategy",		Domain Routing (CIDR): an Address Assignment and Aggregation
	RFC 1519, September 1993.		Strategy", RFC 1519, September 1993.
	[3] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",		[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
	RFC1771, March 1995.		RFC 1771, March 1995.
	[4] Rekhter, Y., and Gross, P., "Application of the Border Gateway Pro-		[4] Rekhter, Y. and P., Gross, "Application of the Border Gateway
	tocol in the Internet", RFC1772, March 1995.		Protocol in the Internet", RFC 1772, March 1995.
	[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, April		[5] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787,
	1995.		April 1995.
	[6] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute",		[6] Chandra, R., Traina, P. and T. Li, "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 T. Bates, "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. and H. Berkowitz, "Network Renumbering Overview: Why
	would I want it and what is it anyway?", RFC 2071, January 1997.		would I want it and what is it anyway?", RFC 2071, January 1997.
	[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.		[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January
			1997.
	[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a		[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a
	Dedicated AS for Sites Homed to a Single Provider", RFC2270, January,		Dedicated AS for Sites Homed to a Single Provider", RFC 2270,
	1998.		January 1998.
	[11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour		[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
	Today", RFC 2101, February 1997.		Behaviour Today", RFC 2101, February 1997.
	[12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900,		[12] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
	February 1996.		1900, 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
	figuration Guide (Addendum), May 1995.		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
	email: enkechen@cisco.com		Phone: +1 408 527 4652
			EMail: enkechen@cisco.com
			John W. Stewart, III
			Juniper Networks, Inc.
			385 Ravendale Drive
			Mountain View, CA 94043
			Phone: +1 650 526 8000
			EMail: jstewart@juniper.net
	John W. Stewart, III
	Juniper Networks, Inc.
	385 Ravendale Drive
	Mountain View, CA 94043
	phone: +1 650 526 8000
	email: jstewart@juniper.net
	A. Appendix A: Example Cisco Configuration		A. Appendix A: Example Cisco Configuration
	This appendix lists the Cisco configurations for AS 2000 of the examples		This appendix lists the Cisco configurations for AS 2000 of the
	presented in Section 5. The configuration here uses the AS-path for		examples presented in Section 5. The configuration here uses the
	outbound filtering although it can also be based on BGP community. Sev-		AS-path for outbound filtering although it can also be based on BGP
	eral route-maps are defined that can be used for peering with the		community. Several route-maps are defined that can be used for
	upstream provider, and for peering with customers (announcing full		peering with the upstream provider, and for peering with customers
	routes or customer routes).		(announcing full routes or customer routes).
	!!# 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
	skipping to change at line 503		skipping to change at page 13, line 4
	route-map export-customer-routes permit 20		route-map export-customer-routes permit 20
	match as-path 20		match as-path 20
	!		!
	!!# 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
	!		!
			Full Copyright Statement
			Copyright (C) The Internet Society (1999). All Rights Reserved.
			This document and translations of it may be copied and furnished to
			others, and derivative works that comment on or otherwise explain it
			or assist in its implementation may be prepared, copied, published
			and distributed, in whole or in part, without restriction of any
			kind, provided that the above copyright notice and this paragraph are
			included on all such copies and derivative works. However, this
			document itself may not be modified in any way, such as by removing
			the copyright notice or references to the Internet Society or other
			Internet organizations, except as needed for the purpose of
			developing Internet standards in which case the procedures for
			copyrights defined in the Internet Standards process must be
			followed, or as required to translate it into languages other than
			English.
			The limited permissions granted above are perpetual and will not be
			revoked by the Internet Society or its successors or assigns.
			This document and the information contained herein is provided on an
			"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
			TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
			BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
			HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
			MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 80 change blocks.
	292 lines changed or deleted		299 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/