draft-ietf-idr-aggregation-framework-02.txt		draft-ietf-idr-aggregation-framework-03.txt
	INTERNET-DRAFT Enke Chen		INTERNET-DRAFT Enke Chen / Cisco
	<draft-ietf-idr-aggregation-framework-02.txt> Cisco		<draft-ietf-idr-aggregation-framework-03.txt> Cisco
	John W. Stewart, III		John W. Stewart, III
	Juniper		Juniper
	March 1998		August 1998
	A Framework for Inter-Domain Route Aggregation		A Framework for Inter-Domain Route Aggregation
	<draft-ietf-idr-aggregation-framework-02.txt>		<draft-ietf-idr-aggregation-framework-03.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months. Internet-Drafts may be updated, replaced or obsoleted by		months. Internet-Drafts may be updated, replaced or obsoleted by
	skipping to change at page 2, line 39		skipping to change at page 2, line 39
	However, the ability of various levels of the global routing system to		However, the ability of various levels of the global routing system to
	implement efficient aggregation schemes varies widely. As a result, the		implement efficient aggregation schemes varies widely. As a result, the
	size and growth rate of the Internet routing table, as well as the asso-		size and growth rate of the Internet routing table, as well as the asso-
	ciated route computation required, remain major issues today. To sup-		ciated route computation required, remain major issues today. To sup-
	port Internet growth, it is important to maximize the efficiency of		port Internet growth, it is important to maximize the efficiency of
	aggregation at all levels in the routing system.		aggregation at all levels in the routing system.
	Because of the current size of the routing system and its dynamic		Because of the current size of the routing system and its dynamic
	nature, the first step towards this goal is to establish a clearly-		nature, the first step towards this goal is to establish a clearly-
	defined framework in which scaleable inter-domain route aggregation can		defined framework in which scaleable inter-domain route aggregation can
	be realized. The framework described in this document emphasizes the		be realized. The framework described in this document is based on the
			predominant and current experience in the Internet. It emphasizes the
	philosophy of aggregation by the source, both within routing domains as		philosophy of aggregation by the source, both within routing domains as
	well as towards upstream providers. The framework also strongly encour-		well as towards upstream providers. The framework also strongly encour-
	ages the use of the "no-export" BGP community to balance the provider-		ages the use of the "no-export" BGP community to balance the provider-
	subscriber need for more granular routing information with the Inter-		subscriber need for more granular routing information with the Inter-
	net's need for scalable inter-domain routing. The advantages of this		net's need for scalable inter-domain routing. The advantages of this
	framework include the following:		framework include the following:
	- Route aggregation is done in a distributed fashion. The Internet		- Route aggregation is done in a distributed fashion, with emphasis
	is too large and too distributed for aggregation to be performed		on aggregation by the party or parties injecting the aggregatable
	successfully by anyone other than the party injecting the aggregat-		routing information into the global mesh.
	able routing information into the global mesh.
	- The flexibility of a routing domain to be able to inject more gran-		- The flexibility of a routing domain to be able to inject more gran-
	ular routing information to an adjacent domain to control the		ular routing information to an adjacent domain to control the
	resulting traffic patterns, without having an impact on the global		resulting traffic patterns, without having an impact on the global
	routing system.		routing system.
	In addition to describing the philosophy, we illustrate it by presenting		In addition to describing the philosophy, we illustrate it by presenting
	sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam-		sample configurations. IPv4 prefixes, BGP4 and ASs are used in exam-
	ples, though the principles are applicable to inter-domain route aggre-		ples, though the principles are applicable to inter-domain route aggre-
	gation in general.		gation in general.
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	- Aggregation from the originating AS		- Aggregation from the originating AS
	That is, in its outbound route announcements, each AS aggregates		That is, in its outbound route announcements, each AS aggregates
	the BGP routes originated by itself, by dedicated AS and by pri-		the BGP routes originated by itself, by dedicated AS and by pri-
	vate-ASs. [10] ("Routes originated by an AS" refers to routes		vate-ASs. [10] ("Routes originated by an AS" refers to routes
	which have that AS first in the AS path attribute. For example,		which have that AS first in the AS path attribute. For example,
	routes statically configured and injected into BGP fall into this		routes statically configured and injected into BGP fall into this
	category.)		category.)
	In general no "proxy aggregation" (i.e., aggregation of a route by		This framework does not depend on "proxy aggregation" which refers
	an AS other than the originating AS) shall be performed. This pre-		to route aggregation done by an AS other than the originating AS.
	serves the capability of a multi-homed site to control the granu-		This preserves the capability of a multi-homed site to control the
	larity of routing information injected into the global routing sys-		granularity of routing information injected into the global routing
	tem. Proxy aggregation may be appropriate on a small scale where		system. Since proxy aggregation involves coordination among multiple
	the necessary coordination is tractable. However, on a large		organizations, the complexity of doing proxy aggregation increases
	scale, experience has shown that proxy aggregation is problematic		with the number of parties involved in the coordination. The
	because the coordination is intractable.		complexity, in turn, impacts the practicality of proxy aggregation.
	An AS shall always originate via a stable mechanism (e.g., static		An AS shall always originate via a stable mechanism (e.g., static
	route configuration) the BGP routes for the large aggregates from		route configuration) the BGP routes for the large aggregates from
	which it allocates addresses to customers. This ensures that it is		which it allocates addresses to customers. This ensures that it is
	safe for its customers to use BGP "no-export".		safe for its customers to use BGP "no-export".
	- Using BGP community "no-export" toward upstream providers		- Using BGP community "no-export" toward upstream providers
	That is, in its route announcements toward its upstream provider,		That is, in its route announcements toward its upstream provider,
	an AS tags the BGP community "no-export" to routes it originates		an AS tags the BGP community "no-export" to routes it originates
	that do not need to be propagated beyond its upstream provider		that do not need to be propagated beyond its upstream provider
	skipping to change at page 6, line 37		skipping to change at page 6, line 36
	to be advertised out by its upstream providers. For example,		to be advertised out by its upstream providers. For example,
	- The route is a more-specific of the upstream provider's block.		- The route is a more-specific of the upstream provider's block.
	However, the customer is either singly homed; or its connection to		However, the customer is either singly homed; or its connection to
	this particular upstream provider is used for backup only.		this particular upstream provider is used for backup only.
	- The more-specifics of a larger block are announced by the customer		- The more-specifics of a larger block are announced by the customer
	in order to balance traffic over the multiple links to the upstream		in order to balance traffic over the multiple links to the upstream
	provider.		provider.
	One approach to suppress such routes is to aggregate them even though		Our approach to suppress such routes is to give control to the ASs that
	they are originated by other ASs (termed "proxy aggregation"). However,		originate the more-specifics (as seen by its upstream providers) and let
	due to the legitimate need for injecting more-specifics for multi-hom-		them tag the BGP community "no-export" to the appropriate routes.
	ing, proxy aggregation needs to be done with special coordination and
	care. The coordination work involved is non-trivial in a large environ-
	ment, and as a result, little aggregation savings have been achieved
	with proxy aggregation to date.
	Instead of "proxy aggregation," our approach for dealing with these
	cases is to give control to the ASs that originate the more-specifics
	(as seen by its upstream providers) and let them tag the BGP community
	"no-export" to the appropriate routes.
	The BGP community "no-export" is a well known BGP community [6, 7]. A		The BGP community "no-export" is a well known BGP community [6, 7]. A
	route with this attribute is not propagated beyond an AS boundary. So,		route with this attribute is not propagated beyond an AS boundary. So,
	if a route is tagged with this community in its announcement to an		if a route is tagged with this community in its announcement to an
	upstream provider and is accepted by the upstream provider, the route		upstream provider and is accepted by the upstream provider, the route
	will not be announced beyond the upstream provider's AS. This achieves		will not be announced beyond the upstream provider's AS. This achieves
	the goal of suppressing the more-specifics in the upstream provider's		the goal of suppressing the more-specifics in the upstream provider's
	outbound announcement.		outbound announcement.
	In this framework, the BGP community "no-export" shall be tagged to		In this framework, the BGP community "no-export" shall be tagged to
	routes that are to be advertized to, but not propagated by, its upstream		routes that are to be advertized to, but not propagated by, its upstream
	provider. They may include routes allocated out of its upstream		provider. They may include routes allocated out of its upstream
	provider's block or the more specific routes announced to its upstream		provider's block or the more specific routes announced to its upstream
	provider for the purpose of load balancing. This aggregation strategy		provider for the purpose of load balancing. This aggregation strategy
	can be implemented via prefix-based filtering as shown in the example of		can be implemented via prefix-based filtering as shown in the example of
	Section 5.		Section 5.
	For its own protection, a downstream AS shall announce only its own		For its own protection, a downstream AS shall announce only its own
	routes and its customer routes to its upstream providers. Thus, the		routes and its customer routes to its upstream providers. Thus, the
	outbound routing announcement and aggregation policy can be expressed as		outbound routing announcement and aggregation policy can be expressed as
	follows:		follows:
	skipping to change at page 10, line 40		skipping to change at page 10, line 13
	RFC 1997, August 1996.		RFC 1997, August 1996.
	[7] Chen, E., and Bates, T., "An Application of the BGP Community		[7] Chen, E., and Bates, T., "An Application of the BGP Community
	Attribute in Multi-home Routing", RFC 1998, August 1996.		Attribute in Multi-home Routing", RFC 1998, August 1996.
	[8] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why		[8] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why
	would I want it and what is it anyway?", RFC 2071, January 1997.		would I want it and what is it anyway?", RFC 2071, January 1997.
	[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.		[9] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
	[10] Stewart, J., and Chen, E., "Using BGP Without Consuming a Unique		[10] Stewart, J., Bates, T., Chandra, R., and Chen, E., "Using a
	ASN", Internet-Draft, January 1997 (expires July 1997), <draft-stewart-		Dedicated AS for Sites Homed to a Single Provider", RFC2270, January,
	bgp-multiprotocol-00.txt>.		1998.
	[11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour		[11] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4 Address Behaviour
	Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-		Today", Internet-Draft, October 1996 (expires April 1997), <draft-iab-
	ip-ad-today-01.txt>.		ip-ad-today-01.txt>.
	[12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900,		[12] Carpenter, B., Rekhter, Y., "Renumbering Needs Work", RFC 1900,
	February 1996.		February 1996.
	[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Con-		[13] Cisco systems, Cisco IOS Software Version 10.3 Router Products Con-
	figuration Guide (Addendum), May 1995.		figuration Guide (Addendum), May 1995.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/