draft-ietf-lisp-alt-08.txt		draft-ietf-lisp-alt-09.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: March 11, 2012 D. Lewis		Expires: March 23, 2012 D. Lewis
	Cisco		Cisco
	September 8, 2011		September 20, 2011
	LISP Alternative Topology (LISP+ALT)		LISP Alternative Topology (LISP+ALT)
	draft-ietf-lisp-alt-08.txt		draft-ietf-lisp-alt-09.txt
	Abstract		Abstract
	This document describes a simple distributed index system to be used		This document describes a simple distributed index system to be used
	by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router		by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
	(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)		(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
	which holds the mapping information for a particular Endpoint		which holds the mapping information for a particular Endpoint
	Identifier (EID). The MR can then query that ETR to obtain the		Identifier (EID). The MR can then query that ETR to obtain the
	actual mapping information, which consists of a list of Routing		actual mapping information, which consists of a list of Routing
	Locators (RLOCs) for the EID. Termed the Alternative Logical		Locators (RLOCs) for the EID. Termed the Alternative Logical
	skipping to change at page 1, line 43		skipping to change at page 1, line 43
	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 March 11, 2012.		This Internet-Draft will expire on March 23, 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
	skipping to change at page 3, line 23		skipping to change at page 3, line 23
	3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10		3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
	3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10		3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
	3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11		3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
	4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12		4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13		4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
	4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13		4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13
	4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15		4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
	5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16		5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
	5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16		5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
	5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17		5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17
	6. BGP configuration and protocol considerations . . . . . . . . 18		5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
	6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18		6. BGP configuration and protocol considerations . . . . . . . . 19
	6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18		6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19
	7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19		6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19
	7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19		7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20
	7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19		7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20
	7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20		7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 20
	7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20		7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 21
	8. Connecting sites to the ALT network . . . . . . . . . . . . . 22		7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 21
	8.1. ETRs originating information into the ALT . . . . . . . . 22		8. Connecting sites to the ALT network . . . . . . . . . . . . . 23
	8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22		8.1. ETRs originating information into the ALT . . . . . . . . 23
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 25		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 25		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26		10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 26
	10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26		10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 27
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		10.3. Use of new IETF standard BGP Security mechanisms . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 28		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	12.2. Informative References . . . . . . . . . . . . . . . . . . 28		12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29		12.2. Informative References . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Introduction		1. Introduction
	This document describes the LISP+ALT system, used by a [LISP] ITR or		This document describes the LISP+ALT system, used by a [LISP] ITR or
	MR to find the ETR that holds the RLOC mapping information for a		MR to find the ETR that holds the RLOC mapping information for a
	particular EID. The ALT network is built using the Border Gateway		particular EID. The ALT network is built using the Border Gateway
	Protocol (BGP, [RFC4271]), the BGP multi-protocol extension		Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
	[RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to		[RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
	construct an overlay network of devices (ALT Routers) which operate		construct an overlay network of devices (ALT Routers) which operate
	on EID-prefixes and use EIDs as forwarding destinations.		on EID-prefixes and use EIDs as forwarding destinations.
	skipping to change at page 13, line 8		skipping to change at page 13, line 8
	In summary, LISP+ALT uses BGP to build paths through ALT Routers so		In summary, LISP+ALT uses BGP to build paths through ALT Routers so
	that an ALT Datagram sent into the ALT can be forwarded to the ETR		that an ALT Datagram sent into the ALT can be forwarded to the ETR
	that holds the EID-to-RLOC mapping for that EID-prefix. This		that holds the EID-to-RLOC mapping for that EID-prefix. This
	reachability is carried as IPv4 or ipv6 NLRI without modification		reachability is carried as IPv4 or ipv6 NLRI without modification
	(since an EID-prefix has the same syntax as IPv4 or ipv6 address		(since an EID-prefix has the same syntax as IPv4 or ipv6 address
	prefix). ALT Routers establish BGP sessions with one another,		prefix). ALT Routers establish BGP sessions with one another,
	forming the ALT. An ALT Router at the "edge" of the topology learns		forming the ALT. An ALT Router at the "edge" of the topology learns
	EID-prefixes originated by authoritative ETRs. Learning may be		EID-prefixes originated by authoritative ETRs. Learning may be
	though the Map Server interface, by static configuration, or via BGP		though the Map Server interface, by static configuration, or via BGP
	with the ETRs. An ALT Router may also be configured to aggregate		with the ETRs. An ALT Router may also be configured to aggregate
	EID-prefixes received from ETRs or from other LISP+ALT routers that		EID-prefixes received from ETRs or from other LISP+ALT Routers that
	are topologically "downstream" from it.		are topologically "downstream" from it.
	4.1. ITR traffic handling		4.1. ITR traffic handling
	When an ITR receives a packet originated by an end system within its		When an ITR receives a packet originated by an end system within its
	site (i.e. a host for which the ITR is the exit path out of the site)		site (i.e. a host for which the ITR is the exit path out of the site)
	and the destination EID for that packet is not known in the ITR's		and the destination EID for that packet is not known in the ITR's
	mapping cache, the ITR creates either a Map-Request for the		mapping cache, the ITR creates either a Map-Request for the
	destination EID or the original packet encapsulated as a Data Probe		destination EID or the original packet encapsulated as a Data Probe
	(see Section 3.3 for caveats on the usability of Data Probes). The		(see Section 3.3 for caveats on the usability of Data Probes). The
	skipping to change at page 16, line 22		skipping to change at page 16, line 22
	the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned		the ALT; an ETR sends a Map-Reply to one of the ITR RLOCs learned
	from the original Map-Request. See sections 6.1.2 and 6.2 of [LISP]		from the original Map-Request. See sections 6.1.2 and 6.2 of [LISP]
	for more information on the use of the Map-Request ITR RLOC field.		for more information on the use of the Map-Request ITR RLOC field.
	Keep in mind that the ITR RLOC field supports mulitple RLOCs in		Keep in mind that the ITR RLOC field supports mulitple RLOCs in
	multiple address families, so a Map-Reply sent in response to a Map-		multiple address families, so a Map-Reply sent in response to a Map-
	Request is not necessarily sent to back to the Map-Request RLOC		Request is not necessarily sent to back to the Map-Request RLOC
	source.		source.
	There may be scenarios, perhaps to encourage caching of EID-to-RLOC		There may be scenarios, perhaps to encourage caching of EID-to-RLOC
	mappings by ALT Routers, where Map-Replies could be sent over the ALT		mappings by ALT Routers, where Map-Replies could be sent over the ALT
	or where a "first-hop" ALT router might modify the originating RLOC		or where a "first-hop" ALT Router might modify the originating RLOC
	on a Map-Request received from an ITR to force the Map-Reply to be		on a Map-Request received from an ITR to force the Map-Reply to be
	returned to the "first-hop" ALT Router. These cases will not be		returned to the "first-hop" ALT Router. These cases will not be
	supported by initial LISP+ALT implementations but may be subject to		supported by initial LISP+ALT implementations but may be subject to
	future experimentation.		future experimentation.
	ALT Routers propagate path information via BGP ([RFC4271]) that is		ALT Routers propagate path information via BGP ([RFC4271]) that is
	used by ITRs to send ALT Datagrams toward the appropriate ETR for		used by ITRs to send ALT Datagrams toward the appropriate ETR for
	each EID-prefix. BGP is run on the inter-ALT Router links, and		each EID-prefix. BGP is run on the inter-ALT Router links, and
	possibly between an edge ("last hop") ALT Router and an ETR or		possibly between an edge ("last hop") ALT Router and an ETR or
	between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB		between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB
	skipping to change at page 18, line 5		skipping to change at page 17, line 23
	As documented in [LISP], when an ETR generates a Map-Reply message to		As documented in [LISP], when an ETR generates a Map-Reply message to
	return to a querying ITR, it sets the outer header IP destination		return to a querying ITR, it sets the outer header IP destination
	address to one of the requesting ITR's RLOCs so that the Map-Reply		address to one of the requesting ITR's RLOCs so that the Map-Reply
	will be sent on the underlying Internet topology, not on the ALT;		will be sent on the underlying Internet topology, not on the ALT;
	this avoids any latency penalty (or "stretch") that might be incurred		this avoids any latency penalty (or "stretch") that might be incurred
	by sending the Map-Reply via the ALT, reduces load on the ALT, and		by sending the Map-Reply via the ALT, reduces load on the ALT, and
	ensures that the Map-Reply can be routed even if the original ITR		ensures that the Map-Reply can be routed even if the original ITR
	does not have an ALT-routed EID. For details on how an ETR selects		does not have an ALT-routed EID. For details on how an ETR selects
	which ITR RLOC to use, see section 6.1.5 of [LISP].		which ITR RLOC to use, see section 6.1.5 of [LISP].
			5.3. ALT Datagram forwarding falure
			Intermediate ALT Routers, forward ALT Datagrams using normal, hop-by-
			hop routing on the ALT overlay network. Should an ALT router not be
			able to forward an ALT Datagram, whether due to an unreachable next-
			hop, TTL exceeded, or other problem, it has several choices:
			o If the ALT Router understands the LISP protocol, as is the case
			for a Map Resolver or Map Server, it may respond to a forwarding
			failure by returning a negative Map-Reply, as described in
			Section 4.2 and [LISP-MS].
			o If the ALT Router does not understand LISP, it may attempt to
			return an ICMP message to the source IP address of the packet that
			cannot be forwarded. Since the source address is an RLOC, an ALT
			Router would send this ICMP message using "native" Internet
			connectivity, not via the ALT overlay.
			o A non-LISP-capable ALT Router may also choose to silently drop the
			non-forwardable ALT Datagram.
			[LISP] and [LISP-MS] define how the source of an ALT Datagram should
			handle each of these cases. The last case, where an ALT Datagram is
			silently discarded, will generally result in several retransmissions
			by the source, followed by treating the destination as unreachable
			via LISP when no Map-Reply is received. If a problem on the ALT is
			severe enough to prevent ALT Datagrams from being delivered to a
			specific EID, this is probably the only sensible way to handle this
			case.
			Note that the use of GRE tunnels should prevent MTU problems from
			ever occurring on the ALT; an ALT Datagram that exceeds an
			intermediate MTU will be fragmented at that point and will be
			reassembled by the target of the GRE tunnel.
	6. BGP configuration and protocol considerations		6. BGP configuration and protocol considerations
	6.1. Autonomous System Numbers (ASNs) in LISP+ALT		6.1. Autonomous System Numbers (ASNs) in LISP+ALT
	The primary use of BGP today is to define the global Internet routing		The primary use of BGP today is to define the global Internet routing
	topology in terms of its participants, known as Autonomous Systems.		topology in terms of its participants, known as Autonomous Systems.
	LISP+ALT specifies the use of BGP to create a global overlay network		LISP+ALT specifies the use of BGP to create a global overlay network
	(the ALT) for finding EID-to-RLOC mappings. While related to the		(the ALT) for finding EID-to-RLOC mappings. While related to the
	global routing database, the ALT serves a very different purpose and		global routing database, the ALT serves a very different purpose and
	is organized into a very different hierarchy. Because LISP+ALT does		is organized into a very different hierarchy. Because LISP+ALT does
	skipping to change at page 27, line 12		skipping to change at page 28, line 12
	deployed, LISP+ALT can readily use these mechanisms to provide		deployed, LISP+ALT can readily use these mechanisms to provide
	authentication of EID-prefix origination and EID-to-RLOC mappings.		authentication of EID-prefix origination and EID-to-RLOC mappings.
	11. Acknowledgments		11. Acknowledgments
	The authors would like to specially thank J. Noel Chiappa who was a		The authors would like to specially thank J. Noel Chiappa who was a
	key contributer to the design of the LISP-CONS mapping database (many		key contributer to the design of the LISP-CONS mapping database (many
	ideas from which made their way into LISP+ALT) and who has continued		ideas from which made their way into LISP+ALT) and who has continued
	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, Scott Brim, and Jari Arkko.
	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-15.txt (work in progress), July 2011.		draft-ietf-lisp-15.txt (work in progress), July 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-11.txt (work in progress), August 2011.		draft-ietf-lisp-ms-12.txt (work in progress),
			September 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. 10 change blocks.
	29 lines changed or deleted		66 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/