draft-ietf-grow-simple-va-02.txt		draft-ietf-grow-simple-va-03.txt
	Network Working Group P. Francis		GROW Working Group R. Raszuk
	Internet-Draft MPI-SWS		Internet-Draft A. Lo
	Intended status: Informational X. Xu		Intended status: Informational Cisco
	Expires: September 3, 2011 Huawei		Expires: January 5, 2012 L. Zhang
	H. Ballani
	Cornell U.
	R. Raszuk
	Cisco
	L. Zhang
	UCLA		UCLA
	March 2, 2011		X. Xu
			Huawei
			July 4, 2011
	Simple Virtual Aggregation (S-VA)		Simple Virtual Aggregation (S-VA)
	draft-ietf-grow-simple-va-02.txt		draft-ietf-grow-simple-va-03.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 FIB size: ISPs often must upgrade router
	hardware simply because the FIB has run out of space, and router		hardware simply because the FIB has run out of space, and router
	vendors must design routers that have adequate FIB. FIB suppression		vendors must design routers that have adequate FIB.
	is an approach to relieving stress on the FIB by NOT loading selected
	RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a		FIB suppression is an approach to relieving stress on the FIB by NOT
	simple form of Virtual Aggregation (VA) that allows any and all edge		loading selected RIB entries into the FIB. Simple Virtual
	routers to shrink their FIB requirements substantially and therefore		Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that
	increase their useful lifetime. S-VA does not change FIB		allows any and all edge routers to shrink their RIB and FIB
	requirements for core routers. S-VA is extremely easy to		requirements substantially and therefore increase their useful
	configure---considerably more so than the various tricks done today		lifetime.
	to extend the life of edge routers. S-VA can be deployed
	autonomously by an ISP (cooperation between ISPs is not required),		S-VA does not increase FIB requirements for core routers. S-VA is
	and can co-exist with legacy routers in the ISP. There are no		extremely easy to configure considerably more so than the various
	changes from the 01 version to this version.		tricks done today to extend the life of edge routers. S-VA can be
			deployed autonomously by an ISP (cooperation between ISPs is not
			required), and can co-exist with legacy routers in the ISP.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 5, 2012.
	This Internet-Draft will expire on September 3, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	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 . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . 6		2. Operation of S-VA . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Deployment considerations . . . . . . . . . . . . . . . . . . . 7
	2.2. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	ISPs today manage constant DFRT growth in a number of ways. One way,		ISPs today manage constant DFRT growth in a number of ways. One way,
	of course, is for ISPs to upgrade their router hardware before DFRT		of course, is for ISPs to upgrade their router hardware before DFRT
	growth outstrips the size of the FIB. This is too expensive for many		growth outstrips the size of the FIB. This is too expensive for many
	ISPs. They would prefer to extend the lifetime of routers whose FIBs		ISPs. They would prefer to extend the lifetime of routers whose FIBs
	can no longer hold the full DFRT.		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. This problem can be mitigated		take longer-than-necessary AS paths.
	through careful configuration of partial defaults, but this can
	require substantial configuration overhead. A second problem with		This problem can be mitigated through careful configuration of
	defaulting to providers is that the ISP is no longer able to provide		partial defaults, but this can require substantial configuration
	the full DFRT to its customers. Finally, provider defaults prevents		overhead. A second problem with defaulting to providers is that the
	the ISP from being able to detect martian packets. As a result, the		ISP is no longer able to provide the full DFRT to its customers.
	ISP transmits packets that could otherwise have been dropped over its		Finally, provider defaults prevents the ISP from being able to detect
	expensive provider links. Simple Virtual Aggregation (S-VA) solves		martian packets. As a result, the ISP transmits packets that could
	these problems because the full DFRT is used by core routers.		otherwise have been dropped over its expensive provider links.
	An alternative is for the ISP to maintain full routes in its core		An alternative is for the ISP to maintain full routes in its core
	routers, but to filter routes from edge routers that do not require a		routers, but to filter routes from edge routers that do not require a
	full DFRT. These edge routers can then default route to the core		full DFRT. These edge routers can then default route to the core or
	routers. This is often possible with edge routers that interface to		exit routers. This is often possible with edge routers that
	customer networks. The problem with this approach is that it cannot		interface to customer networks. The problem with this approach is
	be used for all edge routers. For instance, it cannot be used for		that it cannot be used for all edge routers. For instance, it cannot
	routers that connect to transits. It should also not be used for		be used for routers that connect to transits. It should also not be
	routers that connect to customers which wish to receive the full		used for routers that connect to customers which wish to receive the
	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 RIB, but suppress certain		Edge routers maintain the full DFRT in the BGP protocol RIB, but
	routes from the FIB. Edge routers install a default route to core		suppress certain routes from being installed in RIB and FIB tables.
	routers. Label Switched Paths (LSP) are used to transmit packets		Edge routers install a default route to core routers, to ABRs which
	from a core router, through the edge router, to the Next Hop remote		are installed on the POP to core boundary or to the ASBR routers.
	Autonomous System Border Router (ASBR). ASBRs strip the tunnel
	header (MPLS or IP) before forwarding tunneled packets to the remote
	ASBR (in much the same way MPLS Penultimate Hop Popping (PHP) strips
	the LSP header before forwarding packets to the tunnel target).
	S-VA requires no changes to BGP and no changes to MPLS forwarding		S-VA requires no changes to BGP and no changes to any choice of
	mechanisms in routers. Configuration is extremely simple: S-VA must		forwarding mechanisms in routers. Configuration is extremely simple:
	be enabled, and routers must told whether they are FIB-suppressing		S-VA must be enabled on the edge router which needs to save it's RIB
	routers or not. Everything else is automatic. ISPs can deploy FIB		and FIB space. In the same time operator must inject into his intra-
	suppression autonomously and with no coordination with neighbor ASes.		domain routing a new prefix further called virtual aggregate (VA-
			prefix) which will be used as the aggregate forwarding reference by
			the edge routers performing S-VA. Everything else is automatic.
			ISPs can deploy FIB suppression autonomously and with no coordination
			with neighbor ASes.
	1.1. Scope of this Document		1.1. Scope of this Document
	The scope of this document is limited to Intra-domain S-VA operation.		The scope of this document is limited to Intra-domain S-VA operation.
	In other words, the case where a single ISP autonomously operates		In other words, the case where a single ISP autonomously operates
	S-VA internally without any coordination with neighboring ISPs.		S-VA internally without any coordination with neighboring ISPs.
	Note that this document assumes that the S-VA "domain" (i.e. the unit		Note that this document assumes that the S-VA "domain" (i.e. the unit
	of autonomy) is the AS (that is, different ASes run S-VA		of autonomy) is the AS (that is, different ASes run S-VA
	independently and without coordination). For the remainder of this		independently and without coordination). For the remainder of this
	document, the terms ISP, AS, and domain are used interchangeably.		document, the terms ISP, AS, and domain are used interchangeably.
	This document applies equally to IPv4 and IPv6.		This document applies equally to IPv4 and IPv6 both unicast and
			multicast address families.
	S-VA may operate with a mix of upgraded routers and legacy routers.		S-VA may operate with a mix of upgraded routers and legacy routers.
	There are no topological restrictions placed on the mix of routers.		There are no topological restrictions placed on the mix of routers.
	In order to avoid loops between upgraded and legacy routers, however,		S-VA functionality is local to the router on which it is enabled and
	legacy routers must be able to terminate tunnels.		routing correctness is guaranteed.
	Note that S-VA is a greatly simplified variant of "full VA"		Note that S-VA is a greatly simplified variant of "full VA"
	[I-D.ietf-grow-va]. With full VA, all routers (core or otherwise)		[I-D.ietf-grow-va]. With full VA, all routers (core or otherwise)
	can have reduced FIBs. However, full VA requires substantial new		can have reduced FIBs. However, full VA requires substantial new
	configuration and operational complexity compared to S-VA. Note that		configuration and operational complexity compared to S-VA. Full VA
			also requires the use of MPLS LSPs between all routers. Note that
	S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved		S-VA was formerly specified in [I-D.ietf-grow-va]. It has been moved
	to this separate draft to simplify its understanding.		to this separate draft to simplify its understanding.
	1.2. Requirements notation		1.2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.3. Terminology		1.3. Terminology
	FIB-Installing Router (FIR): An S-VA router that does not suppress		RIB/FIB-Installing Router (FIR): An router that does not suppress
	any routes, and advertises itself as a default route for 0/0.		any routes, and advertises itself as a default route for 0/0.
	Typically a core router or route reflector would be configured as		Typically a core router, POP to core boundary router or an ASBR
	an FIR.		would be configured as an FIR.
	FIB-Suppressing Router (FSR): An S-VA router that installs a route		RIB/FIB-Suppressing Router (FSR): An S-VA router that installs a
	to 0/0, and may suppress other routes. Typically an edge router		route to 0/0, and may suppress other routes. Typically an edge
	would be configured as an FSR.		router would be configured as an FSR.
	Install and Suppress: The terms "install" and "suppress" are used to		Install and Suppress: The terms "install" and "suppress" are used to
	describe whether a RIB entry has been loaded or not loaded into		describe whether a protocol local RIB entry has been loaded or not
	the FIB. In other words, the phrase "install a route" means		loaded into the global RIB and FIB. In other words, the phrase
	"install a route into the FIB", and the phrase "suppress a route"		"install a route" means "install a route into the global RIB and
	means "do not install a route into the FIB".		FIB", and the phrase "suppress a route" means "do not install a
			route from BGP into the global RIB and FIB".
	Legacy Router: A router that does not run S-VA, and has no knowledge		Legacy Router: A router that does not run S-VA, and has no knowledge
	of S-VA.		of S-VA.
	Routing Information Base (RIB): The term RIB is used rather sloppily		Global Routing Information Base (RIB): The term global RIB is used
	in this document to refer either to the loc-RIB (as used in		to indicate the router's main routing information base. That RIB
	[RFC4271]), or to the combined Adj-RIBs-In, the Loc-RIB, and the		is normally used to populate FIB tables of the router. It needs
	Adj-RIBs-Out.		to be highlighted that unless FIB compression is used global RIB
			and FIB tables are in sync.
			Local/Protocol Routing Information Base (loc-RIB): The term local
			RIB is used to indicate the protocol's table where product of SPF
			or BGP best path selection is kept before being installed in
			global RIB. In some protocol's implementations for example BGP
			loc-RIB can be further divided into Adj-RIBs-In, the Loc-RIB, and
			the Adj-RIBs-Out.
	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 simplist form of deployment is for border routers		constraints), the most simple form of deployment is for AS border or
	to be configured as edge routers, and for non-border routers (for		POP border routers to be configured as FIRs, and for customer facing
	instance the routers used as route reflectors) to be configured as		edge routers respectively in the AS or in the POP to be configured as
	core routers. S-VA, however, does not mandate this deployment per		FSRs.
	se.
	FIRs must originate a BGP route to NLRI 0/0 [RFC4271]. The ORIGIN is		FIRs must originate a default BGP route to NLRI 0/0 [RFC4271]. The
	set to INCOMPLETE (value 2), the AS number of the FIR's AS is used in		ORIGIN is set to INCOMPLETE (value 2) and the BGP NEXT_HOP is set to
	the AS_PATH, and the BGP NEXT_HOP is set to the router's own address.		match the other BGP routes which are also advertised by said FIR.
	The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The		The ATOMIC_AGGREGATE and AGGREGATOR attributes are not included. The
	FIR MUST attach a NO_EXPORT Communities Attribute [RFC1997] to the		FIR MUST attach a NO_EXPORT Community Attribute [RFC1997] to the
	route.		default route.
	FIRs must not FIB-suppress any routes.		FIRs should not FIB-suppress any routes. They may, however, still
			use some form of local FIB compression algorithm if deemed necessary.
	FSRs must FIB-install a route to 0/0. When transmitting a packet to		FSRs must detect the VA prefix 0/0 and install it both in loc-RIB,
	a FIR (i.e. based on a 0/0 FIB lookup), the packet must be tunneled.		RIB and FIB. Following that FSR may suppres any more specific routes
	This is to prevent loops that would otherwise occur when a packet		which carry the same next hop as the VA prefix. To guarantee
	transits multiple FSRs on the way to the core, some of which have		semantical correctness FSR by default should also be able to detect
	FIB-installed the route for the destination, and others of which have		installation of not matching next hop route and reinstall all the
	not. FSRs may FIB-install any other routes. They should install any		more specifics which were previously eligible for suppression to
	routes for which their eBGP neighbor is the NEXT_HOP. There are a		maintain semantical forwarding correctness.
	couple reasons for this, which can be illustrated in the figure
	below. This figure shows an autonomous system with a FIR FIR1 and an		Generally, any more specific route which carries the same next hop as
	FSR FSR1. FSR1 is an ASBR and is connected to two remote ASBRs, EP1		the VA-prefix 0/0 is eligible for suppression. However, provided
	and EP2.		that there was at least one less specific prefix (e.g., 1.0.0.0/8)
			and the next-hop of such prefix was different from that of the VA
			0/0, those more specific prefixes (e.g., 1.1.1.0/24) which are
			otherwise subject to suppression would not be eligible for
			suppression anymore.
			Similarly when IBGP multipath is enabled and when multiple VA
			prefixes are detected which are multipath candidates under given
			network condition only those more specific prefixes are subject to
			suppresion which have the identical set of next hops as multipath set
			of VA prefixes.
			Let's illustrate the expected behaviour on the figure below. This
			figure 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.
	+------------------------------------------+		+------------------------------------------+
	| Autonomous System | +----+		| Autonomous System | +----+
	| | |EP1 |		| | |EP1 |
	| /---+---| |		| /---+---| |
	| To ----\ +----+ +----+ / | +----+		| To ----\ +----+ +----+ / | +----+
	| Other \|FIR1|----------|FSR1|/ |		| Other \|FIR1|----------|FSR1|/ |
	|Routers /| | | |\ |		|Routers /| | | |\ |
	| ----/ +----+ +----+ \ | +----+		| ----/ +----+ +----+ \ | +----+
	| \---+---|EP2 |		| \---+---|EP2 |
	| | | |		| | | |
	| | +----+		| | +----+
	+------------------------------------------+		+------------------------------------------+
	Suppose that FSR1 does not FIB-install routes for which EP1 and EP2		Suppose that FSR1 has been enabled to perform S-VA. Originally it
	are next hops. In this case, when EP2 sends a packet to FSR1 for		receives all routes from FIR1 (doing next hop self) as well as
	which the next hop is EP1, FSR1 will first tunnel the packet to FIR1,		directly connected EBGP peers EP1 and EP2. FIR1 now will advertise a
	which will tunnel it right back to FSR1. This trombone routing is		VA prefix 0/0 with next hop set to himself. That will trigger
	avoided if local ASBRs FIB-install routes where their neighbor remote		detection of such prefix on FSR1 and suppression all routes which
	ASBRs are the BGP NEXT_HOP.		have the same next hop as VA prefix and which otherwise would be
			installed in RIB and FIB. However it needs to be observed that FSR1
	In addition, FSR1 cannot filter source addresses using strict unicast		will not suppres any EBGP routes received from his peers EP1 and EP2
	Reverse Path Forwarding (uRPF) unless it FIB-installs the routes		due to next hop being different from the one assinged to VA-prefix.
	learned from the remote ASBR. Note, however, that FSRs cannot do
	loose uRPF. Rather, this must be done by FIRs.
	The above observations lead to the following rules: FSRs that are
	ASBRs should FIB-install all routes for which the neighbor is the BGP
	NEXT_HOP. FSRs that are ASBRs must FIB-install any routes that are
	used for uRPF.
	2.1. Tunnels
	S-VA works with both MPLS and IP-in-IP tunnels. There are
	potentially up to two tunnels required for a packet to traverse an AS
	with S-VA. The first tunnel is that from an FSR to a FIR (for the
	0/0 default). This is called the default tunnel. The second tunnel
	targets the remote ASBR which is the BGP NEXT_HOP, although the
	tunnel header is stripped by the local ASBR before transmitting to
	the remote ASBR. This is the exit tunnel. The start of the exit
	tunnel is an ingress local ASBR in the case where the ingress local
	ASBR has FIB-installed the associated route. Otherwise, the start of
	the exit tunnel is a FIR.
	The target address of the default tunnel is always the FIR. If MPLS
	is used, the FIRs must initiate LSPs to themselves using either the
	Label Distribution Protocol (LDP) [RFC5036]. RSVP-TE [RFC3209] may
	also be used.
	If IP-in-IP tunnels are used, then the BGP Encapsulation Extended		3. Deployment considerations
	Community (BGPencap-Attribute) ([RFC5512]) is used to convey the
	ability to accept tunnels at the target address (the BGP NEXT_HOP).
	For the exit tunnels, again either MPLS or IP-in-IP can be used. In		The simplest deployment model of S-VA is it's use within the POP. In
	the case of IP-in-IP, the inner label defined in [RFC4023] and		such model the POP to core boundary routers (usually RRs in the data
	signaled in BGP with [RFC3107] is used by the local ASBR to identify		path) would act as FIRs and would inject VA-prefix 0/0 to all of it's
	the remote ASBR which is the BGP NEXT_HOP for the packet.		clients within the POP. In such model of operation an observation
	Specifically, when a local ASBR, which can be either an FSR or a FIR,		can be made that such ABRs do have full routing knowledge and client
	advertises an eBGP-received route into iBGP, it sets the BGP NEXT_HOP		to ABR distance is negligable as compared with client to intra-domain
	as itself. It assigns a label to the route. This label is used as		exit distance.
	the inner label in packets tunneled to the local ASBR, and is used to
	identify the remote ASBR from which the route was received. When
	receiving a packet with this label, the local ASBR strips off the
	label, and forwards the native packet to the remote ASBR indicated by
	the label.
	In the case of MPLS, the inner label may or may not be used. If it		Therefor under the above intra POP S-VA deployment model clients can
	is used, then an LSP is established to the IP address of the local		be configured that even in the event of lack of ABR to ABR
	ASBR as described above for FIRs. The BGP NEXT_HOP is set to be		advertisement symmetry there is still no need to monitor if more
	itself (the same address that serves as the FEC in the LSP). The		specific unsuppressed route would cover suppressed one. Thus in this
	inner label is established as described in the previous paragraph for		particular deployment model there is no need to detect and reinstall
	IP-in-IP tunnels, but with the encapsulation defined in [RFC3032].		the previously suppressed ones.
	If the inner label is not used, then the local ASBR must initiate a		Another deploymet consideration should be given to networks which may
	Downstream Unsolicited LSP for each remote ASBR. The FEC for the LSP		utilize route reflection. In the event of enabling IBGP multipath a
	is the remote ASBR address that is used in the BGP NEXT_HOP field.		special care must be taken that both outbound prefixes as well as VA-
	When a packet is received on one of these LSPs, the local ASBR strips		prefixes would pass via said route reflectors to their clients.
	the MPLS header, and forwards the packet to the remote ASBR indicated
	by the label.
	2.2. Legacy Routers		In order to addess the above aspects the following solutions could be
			considered:
	S-VA may be operated with a mix of legacy and S-VA-upgraded routers.		- Use of intra-POP S-VA
	The legacy routers, however, must be able to forward tunneled		- Full mesh Small or medium side networks where S-VA can be deployed
	packets. In the case of MPLS tunnels, this means that they must		are normally fully meshed and do not use route reflection. It
	fully participate in MPLS signaling. If a legacy router is an ASBR,		also needs to pointed out that some large networks are also fully
	then it must also initiate tunnels to itself and be able to detunnel		meshed today.
	packets (without the inner label).		- Use of add-paths Use of add-paths new BGP encoding will allow to
			distribute more then one overall best path from RR to each client.
			- Alternate advertisement of VA-prefix S-VA prefix does not need to
			be advertised in BGP. The BGP suppression will happen as long as
			we configure the S-VA with next hop(s) and implementation verifies
			that such VA-prefix is installed in the RIB and FIB.
	3. IANA Considerations		4. IANA Considerations
	There are no IANA considerations.		There are no IANA considerations.
	4. Security Considerations		5. Security Considerations
	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.
	5. Acknowledgements		6. Acknowledgements
	The concept for S-VA comes from Robert Raszuk.		The concept for Virtual Aggregation comes from Paul Francis. In this
			document authors only simplified some aspects of it's behaviour to
			allow simpler adoption by some operators.
	6. Normative References		Authors would like to thank Clarence Filsfils for his valuable input.
	[I-D.ietf-grow-va]		7. References
	Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
	L. Zhang, "FIB Suppression with Virtual Aggregation",		7.1. Normative References
	draft-ietf-grow-va-00 (work in progress), May 2009.
	[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.
	[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
	Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
	Encoding", RFC 3032, January 2001.
	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, May 2001.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.
	[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
	MPLS in IP or Generic Routing Encapsulation (GRE)",
	RFC 4023, March 2005.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		7.2. Informative References
	Specification", RFC 5036, October 2007.
	[RFC5512] Mohapatra, P. and E. Rosen, "BGP Encapsulation SAFI and		[I-D.ietf-grow-va]
	BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.		Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
			L. Zhang, "FIB Suppression with Virtual Aggregation",
			draft-ietf-grow-va-05 (work in progress), June 2011.
	Authors' Addresses		Authors' Addresses
	Paul Francis
	Max Planck Institute for Software Systems
	Gottlieb-Daimler-Strasse
	Kaiserslautern 67633
	Germany
	Phone: +49 631 930 39600
	Email: francis@mpi-sws.org
	Xiaohu Xu
	Huawei Technologies
	No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
	Beijing, Beijing 100085
	P.R.China
	Phone: +86 10 82836073
	Email: xuxh@huawei.com
	Hitesh Ballani
	Cornell University
	4130 Upson Hall
	Ithaca, NY 14853
	US
	Phone: +1 607 279 6780
	Email: hitesh@cs.cornell.edu
	Robert Raszuk		Robert Raszuk
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone:		Phone:
	Email: raszuk@cisco.com		Email: raszuk@cisco.com
			Alton Lo
			Cisco Systems, Inc.
			170 West Tasman Drive
			San Jose, CA 95134
			USA
			Phone:
			Email: altonlo@cisco.com
	Lixia Zhang		Lixia Zhang
	UCLA		UCLA
	3713 Boelter Hall		3713 Boelter Hall
	Los Angeles, CA 90095		Los Angeles, CA 90095
	US		US
	Phone:		Phone:
	Email: lixia@cs.ucla.edu		Email: lixia@cs.ucla.edu
			Xiaohu Xu
			Huawei Technologies
			No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
			Beijing, Beijing 100085
			P.R.China
			Phone: +86 10 82836073
			Email: xuxh@huawei.com
End of changes. 41 change blocks.
	229 lines changed or deleted		193 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/