draft-ietf-grow-va-02.txt		draft-ietf-grow-va-03.txt
	Network Working Group P. Francis		Network Working Group P. Francis
	Internet-Draft MPI-SWS		Internet-Draft MPI-SWS
	Intended status: Informational X. Xu		Intended status: Informational X. Xu
	Expires: September 9, 2010 Huawei		Expires: March 4, 2011 Huawei
	H. Ballani		H. Ballani
	Cornell U.		Cornell U.
	D. Jen		D. Jen
	UCLA		UCLA
	R. Raszuk		R. Raszuk
	Cisco		Cisco
	L. Zhang		L. Zhang
	UCLA		UCLA
	March 8, 2010		August 31, 2010
	FIB Suppression with Virtual Aggregation		FIB Suppression with Virtual Aggregation
	draft-ietf-grow-va-02.txt		draft-ietf-grow-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. FIB suppression
	is an approach to relieving stress on the FIB by NOT loading selected		is an approach to relieving stress on the FIB by NOT loading selected
	RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to		RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	magnitude with negligible increase in path length and load. FIB		magnitude with negligible increase in path length and load. FIB
	suppression deployed autonomously by an ISP (cooperation between ISPs		suppression deployed autonomously by an ISP (cooperation between ISPs
	is not required), and can co-exist with legacy routers in the ISP.		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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on March 4, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 5		1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4
	1.2. Requirements notation . . . . . . . . . . . . . . . . . . 6		1.2. Requirements notation . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.4. Temporary Sections . . . . . . . . . . . . . . . . . . . . 7		2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 6
	1.4.1. Document revisions . . . . . . . . . . . . . . . . . . 7		2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 8
	2. Overview of Virtual Aggregation (VA) . . . . . . . . . . . . . 9		2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 9
	2.1. Mix of legacy and VA routers . . . . . . . . . . . . . . . 11		3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 10
	2.2. Summary of Tunnels and Paths . . . . . . . . . . . . . . . 11		3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 11
	3. Specification of VA . . . . . . . . . . . . . . . . . . . . . 13		3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 11
	3.1. VA Operation . . . . . . . . . . . . . . . . . . . . . . . 13		3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 11
	3.1.1. Legacy Routers . . . . . . . . . . . . . . . . . . . . 13		3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 15
	3.1.2. Advertising and Handling Virtual Prefixes (VP) . . . . 14		3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 15
	3.1.3. Border VA Routers . . . . . . . . . . . . . . . . . . 17		3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 16
	3.1.4. Advertising and Handling Sub-Prefixes . . . . . . . . 18		3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 17
	3.1.5. Suppressing FIB Sub-prefix Routes . . . . . . . . . . 18		4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 18
	3.2. New Configuration . . . . . . . . . . . . . . . . . . . . 20		4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 18
	4. Usage of Tunnels . . . . . . . . . . . . . . . . . . . . . . . 21		4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 19
	4.1. MPLS tunnels . . . . . . . . . . . . . . . . . . . . . . . 21		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	4.2. Usage of Inner Label . . . . . . . . . . . . . . . . . . . 21		6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 22		6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 20
	6.1. Properly Configured VA . . . . . . . . . . . . . . . . . . 22		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	6.2. Mis-configured VA . . . . . . . . . . . . . . . . . . . . 23		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		8.2. Informative References . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	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
	skipping to change at page 7, line 20		skipping to change at page 6, line 20
	VA router: A router that operates Virtual Aggregation according to		VA router: A router that operates Virtual Aggregation according to
	this document.		this document.
	Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to		Virtual Prefix (VP): A Virtual Prefix (VP) is a prefix used to
	aggregate its contained regular prefixes (sub-prefixes). The set		aggregate its contained regular prefixes (sub-prefixes). The set
	of sub-prefixes in a VP are not physically aggregatable, and so		of sub-prefixes in a VP are not physically aggregatable, and so
	they are aggregated at APRs through the use of tunnels.		they are aggregated at APRs through the use of tunnels.
	VP-List: A list of defined VPs. All routers must agree on the		VP-List: A list of defined VPs. All routers must agree on the
	contents of this list (which is statically configured into every		contents of this list (which is statically configured into every
	VA router).		VA router).
	1.4. Temporary Sections
	This section contains temporary information, and will be removed in
	the final version.
	1.4.1. Document revisions
	This document was previously published as both
	draft-francis-idr-intra-va-01.txt and draft-francis-intra-va-01.txt.
	1.4.1.1. Revisions from the 01 version of draft-ietf-grow-va
	The specification of how to use tunnels has been incorporated
	directly into this draft. Formerly the specifications were provided
	in separate drafts ([I-D.ietf-grow-va-mpls], and
	[I-D.ietf-grow-va-mpls-innerlabel]). The tunneling types specified
	in [I-D.ietf-grow-va-gre] are not included in this draft.
	The simpler "core-edge" style of deployment has been removed from
	this draft and specified in a stand-alone draft
	[I-D.ietf-grow-simple-va] to simplify its understanding for those
	interested in only that style of deployment.
	Added text about usage of uRPF (strict and loose).
	Added text about flapping APR failure scenario.
	1.4.1.2. Revisions from the 00 version of draft-ietf-grow-va
	Removed the notion that FIB suppression can be done by suppressing
	entries from the Routing Table (as defined in Section 3.2 of
	[RFC4271]), an idea that was introduced in the second version of the
	draft. Suppressing from the Routing Table breaks PIM-SM, which
	relies on the contents of the unicast Routing Table to produce its
	forwarding table.
	1.4.1.3. Revisions from the 00 version (of
	draft-francis-intra-va-00.txt)
	Added additional authors (Jen, Raszuk, Zhang), to reflect primary
	contributors moving forwards. In addition, a number of minor
	clarifications were made.
	1.4.1.4. Revisions from the 01 version (of
	draft-francis-idr-intra-va-01.txt)
	1. Changed file name from draft-francis-idr-intra-va to
	draft-francis-intra-va.
	2. Restructured the document to make the edge suppression mode a
	specific sub-case of VA rather than a separate mode of operation.
	This includes modifying the title of the draft.
	3. Removed MPLS tunneling details so that specific tunneling
	approaches can be described in separate documents.
	1.4.1.5. Revisions from 00 version
	o Changed intended document type from STD to BCP, as per advice from
	Dublin IDR meeting.
	o Cleaned up the MPLS language, and specified that the full-address
	routes to remote ASBRs must be imported into OSPF (Section 3.1.3).
	As per Daniel Ginsburg's email
	http://www.ietf.org/mail-archive/web/idr/current/msg02933.html.
	o Clarified that legacy routers must run MPLS. As per Daniel
	Ginsburg's email
	http://www.ietf.org/mail-archive/web/idr/current/msg02935.html.
	o Fixed LOCAL_PREF bug. As per Daniel Ginsburg's email
	http://www.ietf.org/mail-archive/web/idr/current/msg02940.html.
	o Removed the need for the extended communities attribute on VP
	routes, and added the requirement that all VA routers be
	statically configured with the complete list of VPs. As per
	Daniel Ginsburg's emails
	http://www.ietf.org/mail-archive/web/idr/current/msg02940.html and
	http://www.ietf.org/mail-archive/web/idr/current/msg02958.html.
	In addition, the procedure for adding, deleting, splitting, and
	merging VPs was added. As part of this, the possibility of having
	overlapping VPs was added.
	o Added the special case of a core-edge topology with default routes
	to the edge as suggested by Robert Raszuk in email
	http://www.ietf.org/mail-archive/web/idr/current/msg02948.html.
	Note that this altered the structure and even title of the
	document.
	o Clarified that FIB suppression can be achieved by not loading
	entries into the Routing Table, as suggested by Rajiv Asati in
	email
	http://www.ietf.org/mail-archive/web/idr/current/msg03019.html.
	2. Overview of Virtual Aggregation (VA)		2. Overview of Virtual Aggregation (VA)
	For descriptive simplicity, this section starts by describing VA		For descriptive simplicity, this section starts by describing VA
	assuming that there are no legacy routers in the domain. Section 2.1		assuming that there are no legacy routers in the domain. Section 2.1
	overviews the additional functions required by VA routers to		overviews the additional functions required by VA routers to
	accommodate legacy routers.		accommodate legacy routers.
	A key concept behind VA is to operate BGP as normal, and in		A key concept behind VA is to operate BGP as normal, and in
	particular to populate the RIB with the full DFRT, but to suppress		particular to populate the RIB with the full DFRT, but to suppress
	many or most prefixes from being loaded into the FIB. By populating		many or most prefixes from being loaded into the FIB. By populating
	skipping to change at page 16, line 31		skipping to change at page 14, line 4
	an ISP somewhere advertised a very large prefix (a /4, say), then		an ISP somewhere advertised a very large prefix (a /4, say), then
	this would cause APRs to throw out all VPs that are smaller than		this would cause APRs to throw out all VPs that are smaller than
	this. For this reason, VPs MUST be set through static configuration		this. For this reason, VPs MUST be set through static configuration
	only.		only.
	3.1.2.4. Non-APR Routers		3.1.2.4. Non-APR Routers
	A non-APR router MUST install at least the following routes:		A non-APR router MUST install at least the following routes:
	1. Routes to VPs (identifiable using the VP-List).		1. Routes to VPs (identifiable using the VP-List).
	2. Routes to all sub-prefixes that are not covered by any VP in the		2. Routes to all sub-prefixes that are not covered by any VP in the
	VP-list.		VP-List.
	If the non-APR has a tunnel to the BGP NEXT_HOP of any such route, it		If the non-APR has a tunnel to the BGP NEXT_HOP of any such route, it
	MUST use the tunnel to forward packets to the BGP NEXT_HOP.		MUST use the tunnel to forward packets to the BGP NEXT_HOP.
	When an APR fails, routers must select another APR to send packets to		When an APR fails, routers must select another APR to send packets to
	(if there is one). This happens, however, through normal internal		(if there is one). This happens, however, through normal internal
	BGP convergence mechanisms.		BGP convergence mechanisms.
	3.1.2.5. Adding and deleting VPs		3.1.2.5. Adding and deleting VPs
	skipping to change at page 19, line 4		skipping to change at page 16, line 28
	attractive according to the normal BGP best path selection		attractive according to the normal BGP best path selection
	algorithm.		algorithm.
	2. If the router is an APR, a route for every sub-prefix within the		2. If the router is an APR, a route for every sub-prefix within the
	VP MUST be FIB-installed (subject to the above limitation that		VP MUST be FIB-installed (subject to the above limitation that
	there be a tunnel).		there be a tunnel).
	3. If a non-APR router has a sub-prefix route that does not fall		3. If a non-APR router has a sub-prefix route that does not fall
	within any VP (as determined by the VP-List), then the route MUST		within any VP (as determined by the VP-List), then the route MUST
	be installed. This may occur because the ISP hasn't defined a VP		be installed. This may occur because the ISP hasn't defined a VP
	covering that prefix, for instance during an incremental		covering that prefix, for instance during an incremental
	deployment buildup.		deployment buildup.
	4. If an ASBR is using strict uRPF to do ingress filtering, then it		4. If an ASBR is using strict uRPF to do ingress filtering, then it
	MUST install routes for which the remote ASBR is the BGP NEXT_HOP		MUST install routes for which the remote ASBR is the BGP NEXT_HOP
	[RFC2827]. Note that only a APR may do loose uRPF filtering, and		[RFC2827]. Note that only a APR may do loose uRPF filtering, and
	then only for routes to sub-prefixes within its VPs.		then only for routes to sub-prefixes within its VPs.
	5. All other sub-prefix routes MAY be suppressed. Such "optional"		5. All other sub-prefix routes MAY be suppressed. Such "optional"
	sub-prefixes that are nevertheless installed are referred to as		sub-prefixes that are nevertheless installed are referred to as
	Popular Prefixes. Note, however, that whether or not to install		Popular Prefixes. Note, however, that whether or not to install
	a given sub-prefix SHOULD NOT be based on whether or not there is		a given sub-prefix SHOULD NOT be based on whether or not there is
	an active route to a VP in the VP-list. This avoids the		an active route to a VP in the VP-List. This avoids the
	situation whereby, during BGP initialization, the router receives		situation whereby, during BGP initialization, the router receives
	some sub-prefix routes before receiving the corresponding VP		some sub-prefix routes before receiving the corresponding VP
	route, with the result that it installs routes in its FIB that it		route, with the result that it installs routes in its FIB that it
	will only remove a short time later, possibly even overflowing		will only remove a short time later, possibly even overflowing
	its FIB.		its FIB.
	3.1.5.1. Selecting Popular Prefixes		3.1.5.1. Selecting Popular Prefixes
	Individual routers MAY independently choose which sub-prefixes are		Individual routers MAY independently choose which sub-prefixes are
	Popular Prefixes. There is no need for different routers to install		Popular Prefixes. There is no need for different routers to install
End of changes. 12 change blocks.
	133 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/