draft-ietf-lisp-alt-06.txt		draft-ietf-lisp-alt-07.txt
	Network Working Group V. Fuller		Network Working Group V. Fuller
	Internet-Draft D. Farinacci		Internet-Draft D. Farinacci
	Intended status: Experimental D. Meyer		Intended status: Experimental D. Meyer
	Expires: September 5, 2011 D. Lewis		Expires: January 1, 2012 D. Lewis
	Cisco		Cisco
	March 4, 2011		June 30, 2011
	LISP Alternative Topology (LISP+ALT)		LISP Alternative Topology (LISP+ALT)
	draft-ietf-lisp-alt-06.txt		draft-ietf-lisp-alt-07.txt
	Abstract		Abstract
	This document describes a simple mapping database to be used by the		This document describes a simple distributed index system to be used
	Locator/ID Separation Protocol (LISP) to find Endpoint Identifier		by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
	(EID) to Routing Locator (RLOC) mappings. Termed the Alternative		(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
	Logical Topology (ALT), the database is built as an overlay network		which holds the mapping information for a particular Endpoint
	on the public Internet using the Border Gateway Protocol (BGP) and		Identifier (EID). The MR can then query that ETR to obtain the
	the Generic Routing Encapsulation (GRE). Using these proven		actual mapping information, which consists of a list of Routing
	protocols, the ALT can be built and deployed relatively quickly		Locators (RLOCs) for the EID. Termed the Alternative Logical
	without major changes to the existing routing infrastructure.		Topology (ALT), the index is built as an overlay network on the
			public Internet using the Border Gateway Protocol (BGP) and the
			Generic Routing Encapsulation (GRE). Using these proven protocols,
			the ALT can be built and deployed relatively quickly without any
			changes to the existing routing infrastructure.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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 September 5, 2011.		This Internet-Draft will expire on January 1, 2012.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
	3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8		3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8		3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9
	3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9		3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10
	3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9		3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10
	3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9		3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
	3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9		3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
	3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10		3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
	4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11		4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12		4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
	4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 12		4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13
	4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 14		4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
	5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 15		5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
	5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 15		5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
	5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 15		5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 16
	6. BGP configuration and protocol considerations . . . . . . . . 17		6. BGP configuration and protocol considerations . . . . . . . . 18
	6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 17		6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18
	6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 17		6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18
	7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 18		7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19
	7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 18		7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19
	7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 18		7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19
	7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 19		7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20
	7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 19		7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20
	8. Connecting sites to the ALT network . . . . . . . . . . . . . 21		8. Connecting sites to the ALT network . . . . . . . . . . . . . 22
	8.1. ETRs originating information into the ALT . . . . . . . . 21		8.1. ETRs originating information into the ALT . . . . . . . . 22
	8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 21		8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 24		10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 24		10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 25
	10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 25		10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26
	10.3. Use of new IETF standard BGP Security mechanisms . . . . . 25		10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	12.2. Informative References . . . . . . . . . . . . . . . . . . 27		12.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	This document describes the LISP+ALT mapping database, to be used by		This document describes the LISP+ALT system, used by a [LISP] ITR or
	LISP to find EID-to-RLOC mappings. The ALT network is built using		MR to find the ETR that holds the RLOC mapping information for a
	the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol		particular EID. The ALT network is built using the Border Gateway
	extension [RFC4760], and the Generic Routing Encapsulation (GRE,		Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
	[RFC2784]) to construct an overlay network of devices (ALT Routers)		[RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
	which operate on EID-prefixes and use EIDs as forwarding		construct an overlay network of devices (ALT Routers) which operate
	destinations.		on EID-prefixes and use EIDs as forwarding destinations.
	ALT Routers advertise hierarchically-delegated segments of the EID		ALT Routers advertise hierarchically-delegated segments of the EID
	namespace (i.e., prefixes) toward the rest of the ALT; they also		namespace (i.e., prefixes) toward the rest of the ALT; they also
	forward traffic destined for an EID covered by one of those prefixes		forward traffic destined for an EID covered by one of those prefixes
	toward the network element that is authoritative for that EID and is		toward the network element that is authoritative for that EID and is
	the origin of the BGP advertisement for that EID-prefix. An Ingress		the origin of the BGP advertisement for that EID-prefix. An Ingress
	Tunnel Router (ITR) uses this overlay to send a LISP Map-Request (see		Tunnel Router (ITR) uses this overlay to send a LISP Map-Request
	[LISP]) to the Egress Tunnel Router (ETR) that holds the EID-to-RLOC		(defined in [LISP]) to the Egress Tunnel Router (ETR) that holds the
	mapping for a matching EID-prefix. In most cases, an ITR does not		EID-to-RLOC mapping for a matching EID-prefix. In most cases, an ITR
	connect directly to the overlay network but instead sends Map-		does not connect directly to the overlay network but instead sends
	Requests via a Map-Resolver (MR; see [LISP-MS]) which does.		Map-Requests via a Map-Resolver (described in [LISP-MS]) which does.
	Likewise, in most cases, an ETR does not connect directly to the		Likewise, in most cases, an ETR does not connect directly to the
	overlay network but instead registers its EID-prefixes with a Map-		overlay network but instead registers its EID-prefixes with a Map-
	Server that advertises those EID-prefixes on to the ALT and forwards		Server that advertises those EID-prefixes on to the ALT and forwards
	Map-Requests for them to the ETR.		Map-Requests for them to the ETR.
	It is important to note that the ALT does not distribute actual EID-		It is important to note that the ALT does not distribute actual EID-
	to-RLOC mappings. What it does provide is a forwarding path from an		to-RLOC mappings. What it does provide is a forwarding path from an
	ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which		ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
	holds that mapping. The ITR/MR uses this path to send an ALT		holds that mapping. The ITR/MR uses this path to send an ALT
	Datagram (see Section 3) to an ETR which then responds with a Map-		Datagram (see Section 3) to an ETR which then responds with a Map-
	skipping to change at page 3, line 50		skipping to change at page 4, line 50
	and GRE); little, if any, LISP-specific modifications should be		and GRE); little, if any, LISP-specific modifications should be
	needed for such devices to be deployed on the ALT. Note, though,		needed for such devices to be deployed on the ALT. Note, though,
	that organizational and operational considerations suggest that ALT		that organizational and operational considerations suggest that ALT
	Routers be both logically and physically separate from the "native"		Routers be both logically and physically separate from the "native"
	Internet packet transport system; deploying this overlay on those		Internet packet transport system; deploying this overlay on those
	routers which are already participating in the global routing system		routers which are already participating in the global routing system
	and actively forwarding Internet traffic is not recommended.		and actively forwarding Internet traffic is not recommended.
	The remainder of this document is organized as follows: Section 2		The remainder of this document is organized as follows: Section 2
	provides the definitions of terms used in this document. Section 3		provides the definitions of terms used in this document. Section 3
	outlines the basic LISP 1.5 model. Section 4 provides a basic		outlines the LISP ALT model, where EID prefixes are routed across an
	overview of the LISP Alternate Topology architecture, and Section 5		overlay network. Section 4 provides a basic overview of the LISP
	describes how the ALT uses BGP to propagate Endpoint Identifier		Alternate Topology architecture, and Section 5 describes how the ALT
	reachability over the overlay network and Section 6 describes other		uses BGP to propagate Endpoint Identifier reachability over the
	considerations for using BGP on the ALT. Section 7 describes the		overlay network and Section 6 describes other considerations for
	construction of the ALT aggregation hierarchy, and Section 8		using BGP on the ALT. Section 7 describes the construction of the
	discusses how LISP+ALT elements are connected to form the overlay		ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT
	network.		elements are connected to form the overlay network.
	2. Definition of Terms		2. Definition of Terms
	LISP+ALT operates on two name spaces and introduces a new network		This section provides high-level definitions of LISP concepts and
	element, the LISP+ALT Router (see below). This section provides		components involved with and affected by LISP+ALT.
	high-level definitions of the LISP+ALT name spaces, network elements,
	and message types.
	Alternative Logical Topology (ALT): The virtual overlay network		Alternative Logical Topology (ALT): The virtual overlay network
	made up of tunnels between LISP+ALT Routers. The Border Gateway		made up of tunnels between LISP+ALT Routers. The Border Gateway
	Protocol (BGP) runs between ALT Routers and is used to carry		Protocol (BGP) runs between ALT Routers and is used to carry
	reachability information for EID-prefixes. The ALT provides a way		reachability information for EID-prefixes. The ALT provides a way
	to forward Map-Requests (and, if supported, Data Probes) toward		to forward Map-Requests (and, if supported, Data Probes) toward
	the ETR that "owns" an EID-prefix. As a tunneled overlay, its		the ETR that "owns" an EID-prefix. As a tunneled overlay, its
	performance is expected to be quite limited so use of it to		performance is expected to be quite limited so use of it to
	forward high-bandwidth flows of Data Probes is strongly		forward high-bandwidth flows of Data Probes is strongly
	discouraged (see Section 3.3 for additional discussion).		discouraged (see Section 3.3 for additional discussion).
	skipping to change at page 8, line 15		skipping to change at page 9, line 15
	3. The LISP+ALT model		3. The LISP+ALT model
	The LISP+ALT model uses the same basic query/response protocol that		The LISP+ALT model uses the same basic query/response protocol that
	is documented in [LISP]. In particular, LISP+ALT provides two types		is documented in [LISP]. In particular, LISP+ALT provides two types
	of packet that an ITR can originate to obtain EID-to-RLOC mappings:		of packet that an ITR can originate to obtain EID-to-RLOC mappings:
	Map-Request: A Map-Request message is sent into the ALT to request		Map-Request: A Map-Request message is sent into the ALT to request
	an EID-to-RLOC mapping. The ETR which owns the mapping will		an EID-to-RLOC mapping. The ETR which owns the mapping will
	respond to the ITR with a Map-Reply message. Since the ALT only		respond to the ITR with a Map-Reply message. Since the ALT only
	forwards on EID destinations, the destination address of the Map-		forwards on EID destinations, the destination address of the Map-
	Request sent on the ALT must be an EID. See [LISP] for the format		Request sent on the ALT must be an EID.
	of Map-Request and Map-Reply packets.
	Data Probe: Alternatively, an ITR may encapsulate and send the first		Data Probe: Alternatively, an ITR may encapsulate and send the first
	data packet destined for an EID with no known RLOCs into the ALT		data packet destined for an EID with no known RLOCs into the ALT
	as a Data Probe. This might be done minimize packet loss and to		as a Data Probe. This might be done minimize packet loss and to
	probe for the mapping. As above, the authoritative ETR for the		probe for the mapping. As above, the authoritative ETR for the
	EID-prefix will respond to the ITR with a Map-Reply message when		EID-prefix will respond to the ITR with a Map-Reply message when
	it receives the data packet over the ALT. As a side-effect, the		it receives the data packet over the ALT. As a side-effect, the
	encapsulated data packet is delivered to the end-system at the ETR		encapsulated data packet is delivered to the end-system at the ETR
	site. Note that the Data Probe's inner IP destination address,		site. Note that the Data Probe's inner IP destination address,
	which is an EID, is copied to the outer IP destination address so		which is an EID, is copied to the outer IP destination address so
	that the resulting packet can be routed over the ALT. See		that the resulting packet can be routed over the ALT. See
	Section 3.3 for caveats on the usability of Data Probes.		Section 3.3 for caveats on the usability of Data Probes.
	The term "ALT Datagram" is short-hand for a Map-Request or Data Probe		The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
	to be sent into or forwarded on the ALT. Note that while the outer		to be sent into or forwarded on the ALT. Note that such packets use
	header Source Address of an ALT Datagram is currently expected to be		an RLOC as the outer header source IP address and an EID as the outer
	an RLOC, there may be situations (e.g. for experimentation with		header destination IP address.
	caching in intermediate ALT nodes) where an EID would be used to
	force a Map-Reply to be routed back through the ALT.		Detailed descriptions of the LISP packet types referenced by this
			document may be found in [LISP].
	3.1. Routeability of EIDs		3.1. Routeability of EIDs
	A LISP EID has the same syntax as IP address and can be used,		A LISP EID has the same syntax as IP address and can be used,
	unaltered, as the source or destination of an IP datagram. In		unaltered, as the source or destination of an IP datagram. In
	general, though, EIDs are not routable on the public Internet; LISP+		general, though, EIDs are not routable on the public Internet; LISP+
	ALT provides a separate, virtual network, known as the LISP		ALT provides a separate, virtual network, known as the LISP
	Alternative Logical Topology (ALT) on which a datagram using an EID		Alternative Logical Topology (ALT) on which a datagram using an EID
	as an IP destination address may be transmitted. This network is		as an IP destination address may be transmitted. This network is
	built as an overlay on the public Internet using tunnels to		built as an overlay on the public Internet using tunnels to
	skipping to change at page 19, line 8		skipping to change at page 20, line 8
	owns it, it is possible to perform site-to-site traffic engineering		owns it, it is possible to perform site-to-site traffic engineering
	by setting the preference and/or weight fields, and by including		by setting the preference and/or weight fields, and by including
	more-specific EID-to-RLOC information in Map-Reply messages.		more-specific EID-to-RLOC information in Map-Reply messages.
	This is a powerful mechanism that can conceivably replace the		This is a powerful mechanism that can conceivably replace the
	traditional practice of routing prefix deaggregation for traffic		traditional practice of routing prefix deaggregation for traffic
	engineering purposes. Rather than propagating more-specific		engineering purposes. Rather than propagating more-specific
	information into the global routing system for local- or regional-		information into the global routing system for local- or regional-
	optimization of traffic flows, such more-specific information can be		optimization of traffic flows, such more-specific information can be
	exchanged, through LISP (not LISP+ALT), on an as-needed basis between		exchanged, through LISP (not LISP+ALT), on an as-needed basis between
	only those ITRs/ETRs (and, thus, site pairs) that need it. Should a		only those ITRs/ETRs (and, thus, site pairs) that need it. Such an
	receiving ITR decide that it does not wish to store such more-		exchange of "more-specifics" between sites facilitates traffic
	specific information, it has the option of discarding it as long as a		engineering, by allowing richer and more fine-grained policies to be
	shorter, covering EID-prefix exists. Such an exchange of "more-		applied without advertising additional prefixes into either the ALT
	specifics" between sites facilitates traffic engineering, by allowing		or the global routing system.
	richer and more fine-grained policies to be applied without
	advertising additional prefixes into either the ALT or the global
	routing system.
	Note that these new traffic engineering capabilities are an attribute		Note that these new traffic engineering capabilities are an attribute
	of LISP and are not specific to LISP+ALT; discussion is included here		of LISP and are not specific to LISP+ALT; discussion is included here
	because the BGP-based global routing system has traditionally used		because the BGP-based global routing system has traditionally used
	propagation of more-specific routes as a crude form of traffic		propagation of more-specific routes as a crude form of traffic
	engineering.		engineering.
	7.3. Edge aggregation and dampening		7.3. Edge aggregation and dampening
	Normal BGP best common practices apply to the ALT network. In		Normal BGP best common practices apply to the ALT network. In
	skipping to change at page 20, line 44		skipping to change at page 21, line 41
	placement of aggregation boundaries.		placement of aggregation boundaries.
	4. EID prefix portability between competing operators of the ALT		4. EID prefix portability between competing operators of the ALT
	infrastructure. A significant benefit for an end-site to adopt		infrastructure. A significant benefit for an end-site to adopt
	LISP is the availability of EID space that is not tied to a		LISP is the availability of EID space that is not tied to a
	specific connectivity provider; it is important to ensure that an		specific connectivity provider; it is important to ensure that an
	end site doesn't trade lock-in to a connectivity provider for		end site doesn't trade lock-in to a connectivity provider for
	lock-in to a provider of its EID assignment, ALT connectivity, or		lock-in to a provider of its EID assignment, ALT connectivity, or
	Map Server facilities.		Map Server facilities.
	This is, by no means, and exhaustive list.		This is, by no means, an exhaustive list.
	While resolving these issues is beyond the scope of this document,		While resolving these issues is beyond the scope of this document,
	the authors recommend that existing distributed resource structures,		the authors recommend that existing distributed resource structures,
	such as the IANA/Regional Internet Registries and the ICANN/Domain		such as the IANA/Regional Internet Registries and the ICANN/Domain
	Registrar, be carefully considered when designing and deploying the		Registrar, be carefully considered when designing and deploying the
	ALT infrastructure.		ALT infrastructure.
	8. Connecting sites to the ALT network		8. Connecting sites to the ALT network
	8.1. ETRs originating information into the ALT		8.1. ETRs originating information into the ALT
	skipping to change at page 27, line 11		skipping to change at page 28, line 11
	to provide invaluable insight as the LISP effort has evolved. Others		to provide invaluable insight as the LISP effort has evolved. Others
	who have provided valuable contributions include John Zwiebel, Hannu		who have provided valuable contributions include John Zwiebel, Hannu
	Flinck, Amit Jain, John Scudder, and Scott Brim.		Flinck, Amit Jain, John Scudder, and Scott Brim.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-10.txt (work in progress), March 2011.		draft-ietf-lisp-14.txt (work in progress), June 2011.
	[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",		[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
	draft-ietf-lisp-ms-07.txt (work in progress), March 2011.		draft-ietf-lisp-ms-09.txt (work in progress), May 2011.
	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	March 2000.		March 2000.
	[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.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
End of changes. 16 change blocks.
	91 lines changed or deleted		90 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/