draft-ietf-grow-simple-va-08.txt		draft-ietf-grow-simple-va-09.txt
	GROW Working Group R. Raszuk		GROW Working Group R. Raszuk
	Internet-Draft NTT MCL		Internet-Draft NTT MCL
	Intended status: Informational J. Heitz		Intended status: Informational J. Heitz
	Expires: November 30, 2012 Ericsson		Expires: December 7, 2012 Ericsson
	A. Lo		A. Lo
	Arista		Arista
	L. Zhang		L. Zhang
	UCLA		UCLA
	X. Xu		X. Xu
	Huawei		Huawei
	May 29, 2012		June 5, 2012
	Simple Virtual Aggregation (S-VA)		Simple Virtual Aggregation (S-VA)
	draft-ietf-grow-simple-va-08.txt		draft-ietf-grow-simple-va-09.txt
	Abstract		Abstract
	The continued growth in the Default Free Routing Table (DFRT)		The continued growth in the Default Free Routing Table (DFRT)
	stresses the global routing system in a number of ways. One of the		stresses the global routing system in a number of ways. One of the
	most costly stresses is FIB size: ISPs often must upgrade router		most costly stresses is Forwarding Information Base (FIB) size: ISPs
	hardware simply because the FIB has run out of space, and router		often must upgrade router hardware simply because the FIB has run out
	vendors must design routers that have adequate FIB.		of space, and router vendors must design routers that have adequate
			FIB.
	FIB suppression is an approach to relieving stress on the FIB by NOT		FIB suppression is an approach to relieving stress on the FIB by NOT
	loading selected RIB entries into the FIB. Simple Virtual		loading selected RIB entries into the FIB. Simple Virtual
	Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that		Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
	allows any and all edge routers to shrink their RIB and FIB		allows any and all edge routers to shrink their RIB and FIB
	requirements substantially and therefore increase their useful		requirements substantially and therefore increase their useful
	lifetime.		lifetime.
	S-VA does not increase FIB requirements for core routers. S-VA is		S-VA does not increase FIB requirements for core routers. S-VA is
	extremely easy to configure considerably more so than the various		extremely easy to configure considerably more so than the various
	skipping to change at page 2, line 8		skipping to change at page 2, line 10
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 30, 2012.		This Internet-Draft will expire on December 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 16		skipping to change at page 3, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5		1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5		1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6		2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6
	3. Deployment considerations . . . . . . . . . . . . . . . . . . 8		3. Deployment considerations . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	ISPs today manage constant DFRT growth in a number of ways. One way,		ISPs today manage constant Default Free Routing Table (DFRT) growth
	of course, is for ISPs to upgrade their router hardware before DFRT		in a number of ways. One way, of course, is for ISPs to upgrade
	growth outstrips the size of the FIB. This is too expensive for many		their router hardware before DFRT growth outstrips the size of the
	ISPs. They would prefer to extend the lifetime of routers whose FIBs		FIB. This is too expensive for many ISPs. They would prefer to
	can no longer hold the full DFRT.		extend the lifetime of routers whose FIBs can no longer hold the full
			DFRT.
	A common approach taken by lower-tier ISPs is to default route to		A common approach taken by lower-tier ISPs is to default route to
	their providers. Routes to customers and peer ISPs are maintained,		their providers. Routes to customers and peer ISPs are maintained,
	but everything else defaults to the provider. This approach has		but everything else defaults to the provider. This approach has
	several disadvantages. First, packets to Internet destinations may		several disadvantages. First, packets to Internet destinations may
	take longer-than-necessary AS paths.		take longer-than-necessary AS paths.
	This problem can be mitigated through careful configuration of		This problem can be mitigated through careful configuration of
	partial defaults, but this can require substantial configuration		partial defaults, but this can require substantial configuration
	overhead. A second problem with defaulting to providers is that the		overhead. A second problem with defaulting to providers is that the
	skipping to change at page 4, line 45		skipping to change at page 4, line 46
	full DFRT.		full DFRT.
	This draft describes a very simple technique, called Simple Virtual		This draft describes a very simple technique, called Simple Virtual
	Aggregation (S-VA), that allows any and all edge routers to have		Aggregation (S-VA), that allows any and all edge routers to have
	substantially reduced FIB requirements even while still advertising		substantially reduced FIB requirements even while still advertising
	and receiving the full DFRT over BGP. The basic idea is as follows.		and receiving the full DFRT over BGP. The basic idea is as follows.
	Core routers in the ISP maintain the full DFRT in the FIB and RIB.		Core routers in the ISP maintain the full DFRT in the FIB and RIB.
	Edge routers maintain the full DFRT in the BGP protocol RIB, but		Edge routers maintain the full DFRT in the BGP protocol RIB, but
	suppress certain routes from being installed in RIB and FIB tables.		suppress certain routes from being installed in RIB and FIB tables.
	Edge routers may install a default route to core routers, to ABRs		Edge routers may install a default route to core routers, to ABRs
	which are installed on the POP to core boundary or to the ASBR		which are installed on the Point of Presence (POP) to core boundary
	routers.		or to the ASBR routers.
	S-VA requires no changes to BGP and no changes to any choice of		S-VA requires no changes to BGP and no changes to any choice of
	forwarding mechanisms in routers. Configuration is extremely simple:		forwarding mechanisms in routers. Configuration is extremely simple:
	S-VA must be enabled on the edge router which needs to save its RIB		S-VA must be enabled on the edge router which needs to save its RIB
	and FIB space. In the same time operator must inject into his intra-		and FIB space. In the same time operator must inject into his intra-
	domain routing a new prefix further called virtual aggregate (VA-		domain routing a new prefix further called virtual aggregate (VA-
	prefix) which will be used as the aggregate forwarding reference by		prefix) which will be used as the aggregate forwarding reference by
	the edge routers performing S-VA. Everything else is automatic.		the edge routers performing S-VA. Everything else is automatic.
	ISPs can deploy FIB suppression autonomously and with no coordination		ISPs can deploy FIB suppression autonomously and with no coordination
	with neighbor ASes.		with neighbor ASes.
	skipping to change at page 6, line 44		skipping to change at page 6, line 44
	2. Operation of S-VA		2. Operation of S-VA
	There are three types of routers in S-VA, FIB-Installing routers		There are three types of routers in S-VA, FIB-Installing routers
	(FIR), FIB-Suppressing routers (FSR), and optionally legacy routers.		(FIR), FIB-Suppressing routers (FSR), and optionally legacy routers.
	While any router can be an FIR or an FSR (there are no topology		While any router can be an FIR or an FSR (there are no topology
	constraints), the most simple form of deployment is for AS border or		constraints), the most simple form of deployment is for AS border or
	POP border routers to be configured as FIRs, and for customer facing		POP border routers to be configured as FIRs, and for customer facing
	edge routers respectively in the AS or in the POP to be configured as		edge routers respectively in the AS or in the POP to be configured as
	FSRs.		FSRs.
	FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The		There are two basic network deployment scenarios for S-VA - with and
	ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to		without presence of a default route. In both cases simple VA
	match the other BGP routes which are also advertised by said FIR.		operates in an identical way however when default route is found and
	The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The		is eligible to become a less specific prefix by router's
	FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the		configuration the S-VA may use it. That should not prevent detection
	default route.		of any other potential prefix with different next hop as the next hop
			of default route.
			In the event of FIRs originating a default BGP route to NLRI 0/0
			[RFC4271]. The ORIGIN is set to INCOMPLETE (value 2) and the BGP
			NEXT_HOP is set to match the other BGP routes which are also
			advertised by said FIR. The ATOMIC_AGGREGATE and AGGREGATOR
			attributes are not included. The FIR MUST attach a NO_EXPORT
			Community Attribute [RFC1997] to the default route.
	FIRs should not FIB-suppress any routes. They may, however, still		FIRs should not FIB-suppress any routes. They may, however, still
	use some form of local FIB compression algorithm if deemed necessary.		use some form of local FIB compression algorithm if deemed necessary.
	FSRs must detect the VA prefix 0/0 and install it both in loc-RIB,		FSRs must detect the VA prefix or prefixes (including 0/0) and
	RIB and FIB. Following that FSR may suppress any more specific		install it both in loc-RIB, RIB and FIB. Following that FSR may
	routes which carry the same next hop as the VA prefix. To guarantee		suppress any more specific routes which carry the same next hop as
	semantical correctness FSR by default should also be able to detect		the VA prefix. To guarantee semantical correctness FSR by default
	installation of not matching next hop route and reinstall all the		should also be able to detect installation of not matching next hop
	more specifics which were previously eligible for suppression to		route and reinstall all the more specifics which were previously
	maintain semantical forwarding correctness.		eligible for suppression to maintain semantical forwarding
			correctness.
	Generally, any more specific route which carries the same next hop as		Generally, any more specific route which carries the same next hop as
	the VA-prefix 0/0 is eligible for suppression. However, provided		the VA-prefix is eligible for suppression. However, provided that
	that there was at least one less specific prefix (e.g., 1.0.0.0/8)		there was at least one less specific prefix with different next hop
	and the next-hop of such prefix was different from that of the VA		between VA-prefix and the prefixes which got suppressed then all
	0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are		previously suppressed prefixes must be reinstalled.
	otherwise subject to suppression would not be eligible for
	suppression anymore.
	Similarly when IBGP multipath is enabled and when multiple VA		Similarly when IBGP multipath is enabled and when multiple VA
	prefixes are detected which are multipath candidates under given		prefixes are detected which are multipath candidates under given
	network condition only those more specific prefixes are subject to		network condition only those more specific prefixes are subject to
	suppression which have the identical set of next hops as multipath		suppression which have the identical set of next hops as multipath
	set of VA prefixes.		set of VA prefixes.
	We illustrate the expected behavior on the figure below. This figure		We illustrate the expected behavior on the figure below. This figure
	shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is		shows an autonomous system with a FIR FIR1 and an FSR FSR1. FSR1 is
	an ASBR and is connected to two remote ASBRs, EP1 and EP2.		an ASBR and is connected to two remote ASBRs, EP1 and EP2.
	skipping to change at page 9, line 38		skipping to change at page 9, line 49
	The authors are not aware of any new security considerations due to		The authors are not aware of any new security considerations due to
	S-VA.		S-VA.
	6. Acknowledgements		6. Acknowledgements
	The concept for Virtual Aggregation comes from Paul Francis. In this		The concept for Virtual Aggregation comes from Paul Francis. In this
	document authors only simplified some aspects of its behavior to		document authors only simplified some aspects of its behavior to
	allow simpler adoption by some operators.		allow simpler adoption by some operators.
	Authors would like to thank Clarence Filsfils and Nick Hilliard for		Authors would like to thank Clarence Filsfils, Nick Hilliard, S.
	their valuable input.
			Moonesamy and Tom Petch for their review and valuable input.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP		[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
	Communities Attribute", RFC 1997, August 1996.		Communities Attribute", RFC 1997, August 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 12 change blocks.
	37 lines changed or deleted		47 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/