draft-ietf-lisp-deployment-01.txt		draft-ietf-lisp-deployment-02.txt
	Network Working Group L. Jakab		Network Working Group L. Jakab
	Internet-Draft A. Cabellos-Aparicio		Internet-Draft A. Cabellos-Aparicio
	Intended status: Informational F. Coras		Intended status: Informational F. Coras
	Expires: January 12, 2012 J. Domingo-Pascual		Expires: May 4, 2012 J. Domingo-Pascual
	Technical University of Catalonia		Technical University of Catalonia
	D. Lewis		D. Lewis
	Cisco Systems		Cisco Systems
	July 11, 2011		November 1, 2011
	LISP Network Element Deployment Considerations		LISP Network Element Deployment Considerations
	draft-ietf-lisp-deployment-01.txt		draft-ietf-lisp-deployment-02.txt
	Abstract		Abstract
	This document discusses the different scenarios for the deployment of		This document discusses the different scenarios for the deployment of
	the new network elements introduced by the Locator/Identifier		the new network elements introduced by the Locator/Identifier
	Separation Protocol (LISP).		Separation Protocol (LISP).
	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
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 12, 2012.		This Internet-Draft will expire on May 4, 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 2, line 28		skipping to change at page 2, line 28
	2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11		2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
	3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11		3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11
	3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11		3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12		3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12
	4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13		4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13
	4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16		5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16		5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
	5.3. Proxy-ITR Route Distribution . . . . . . . . . . . . . . . 17		5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
	5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19		5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	With LISP, two LISP sites can route packets among them and control		With LISP, two LISP sites can route packets among them and control
	their ingress TE policies. Typically, LISP is seen as applicable to		their ingress TE policies. Typically, LISP is seen as applicable to
	stub networks, however the LISP protocol can also be applied to		stub networks, however the LISP protocol can also be applied to
	transit networks recursively.		transit networks recursively.
	Consider the scenario depicted in Figure 4. Packets originating from		Consider the scenario depicted in Figure 4. Packets originating from
	the LISP site Stub1, client of ISP_A, with destination Stub4, client		the LISP site Stub1, client of ISP_A, with destination Stub4, client
	of ISP_B, are LISP encapsulated at their entry point into the ISP_A's		of ISP_B, are LISP encapsulated at their entry point into the ISP_A's
	network. The external IP header now has as the source RLOC an IP		network. The external IP header now has as the source RLOC an IP
	from ISP_A's address space (R_A1, R_A2, or R_A3) and destination RLOC		from ISP_A's address space and destination RLOC from ISP_B's address
	from ISP_B's address space (R_B1 or R_B2). One or more ASes separate		space. One or more ASes separate ISP_A from ISP_B. With a single
	ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4		level of LISP encapsulation, Stub4 has control over its ingress
	has control over its ingress traffic. However, ISP_B only has the		traffic. However, ISP_B only has the current tools (such as BGP
	current tools (such as BGP prefix deaggregation) to control on which		prefix deaggregation) to control on which of his own upstream or
	of his own upstream or peering links should packets enter. This is		peering links should packets enter. This is either not feasible (if
	either not feasible (if fine-grained per-customer control is		fine-grained per-customer control is required, the very specific
	required, the very specific prefixes may not be propagated) or		prefixes may not be propagated) or increases DFZ table size.
	increases DFZ table size.
	_.--.		_.--.
	Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3		Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3
	\ | R_A1|----,' `. ---|R_B1 | /		\ | R_A1|----,' `. ---|R_B1 | /
	--| R_A2|---( Transit ) | |--		--| R_A2|---( Transit ) | |--
	Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4		Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4
	+-------+ `--. _.-' +-------+		+-------+ `--. _.-' +-------+
	... ISP_A `--'' ISP_B ...		... ISP_A `--'' ISP_B ...
	Figure 4: Inter-Service provider TE scenario		Figure 4: Inter-Service provider TE scenario
	A solution for this is to apply LISP recursively. ISP_A and ISP_B		A solution for this is to apply LISP recursively. ISP_A and ISP_B
	may reach a bilateral agreement to deploy their own private mapping		may reach a bilateral agreement to deploy their own private mapping
	system. ISP_A then encapsulates packets destined for the prefixes of		system. ISP_A then encapsulates packets destined for the prefixes of
	ISP_B, which are listed in the shared mapping system. Note that in		ISP_B, which are listed in the shared mapping system. Note that in
	this case the packet is double-encapsulated. ISP_B's ETR removes the		this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3
	outer, second layer of LISP encapsulation from the incoming packet,		as source and R_B1 or R_B2 as destination in the example above).
	and routes it towards the original RLOC, the ETR of Stub4, which does		ISP_B's ETR removes the outer, second layer of LISP encapsulation
	the final decapsulation.		from the incoming packet, and routes it towards the original RLOC,
			the ETR of Stub4, which does the final decapsulation.
	If ISP_A and ISP_B agree to share a private distributed mapping		If ISP_A and ISP_B agree to share a private distributed mapping
	database, both can control their ingress TE without the need of		database, both can control their ingress TE without the need of
	disaggregating prefixes. In this scenario the private database		disaggregating prefixes. In this scenario the private database
	contains RLOC-to-RLOC bindings. The convergence time on the TE		contains RLOC-to-RLOC bindings. The convergence time on the TE
	policies updates is expected to be fast, since ISPs only have to		policies updates is expected to be fast, since ISPs only have to
	update/query a mapping to/from the database.		update/query a mapping to/from the database.
	This deployment scenario includes two important recommendations.		This deployment scenario includes two important recommendations.
	First, it is intended to be deployed only between two ISPs (ISP_A and		First, it is intended to be deployed only between two ISPs (ISP_A and
	skipping to change at page 10, line 11		skipping to change at page 10, line 5
	o The ISP ITR must encapsulate packets and therefore must know the		o The ISP ITR must encapsulate packets and therefore must know the
	RLOC-to-RLOC binding. These bindings are stored in a mapping		RLOC-to-RLOC binding. These bindings are stored in a mapping
	database and may be cached in the ITR's mapping cache. Cache		database and may be cached in the ITR's mapping cache. Cache
	misses lead to an extra lookup latency, unless NERD		misses lead to an extra lookup latency, unless NERD
	[I-D.lear-lisp-nerd] is used for the lookups.		[I-D.lear-lisp-nerd] is used for the lookups.
	o The operational overhead of maintaining the shared mapping		o The operational overhead of maintaining the shared mapping
	database.		database.
			o If an IPv6 address block is reserved for EID use, as specified in
			[I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
			level) can avoid LISP processing altogether for non-LISP
			destinations. The ISP tunnel routers however will not be able to
			take advantage of this optimization, all RLOC-to-RLOC mappings
			need a lookup in the private database (or map-cache, once results
			are cached).
	2.5. Tunnel Routers Behind NAT		2.5. Tunnel Routers Behind NAT
	NAT in this section refers to IPv4 network address and port		NAT in this section refers to IPv4 network address and port
	translation.		translation.
	2.5.1. ITR		2.5.1. ITR
	Packets encapsulated by an ITR are just UDP packets from a NAT		Packets encapsulated by an ITR are just UDP packets from a NAT
	device's point of view, and they are handled like any UDP packet,		device's point of view, and they are handled like any UDP packet,
	there are no additional requirements for LISP data packets.		there are no additional requirements for LISP data packets.
	skipping to change at page 17, line 12		skipping to change at page 17, line 12
	ratio becomes high enough, this approach can prove increasingly		ratio becomes high enough, this approach can prove increasingly
	attractive.		attractive.
	Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix		Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
	deaggregation for traffic engineering purposes, resulting in slower		deaggregation for traffic engineering purposes, resulting in slower
	routing table increase in the case of new allocations and potential		routing table increase in the case of new allocations and potential
	decrease for existing ones. Moreover, MSPs serving different clients		decrease for existing ones. Moreover, MSPs serving different clients
	with adjacent aggregable prefixes may lead to additional decrease,		with adjacent aggregable prefixes may lead to additional decrease,
	but quantifying this decrease is subject to future research study.		but quantifying this decrease is subject to future research study.
	5.3. Proxy-ITR Route Distribution		5.3. Proxy-ITR Route Distribution (PITR-RD)
	Instead of a LISP site, or the MSP, announcing their EIDs with BGP to		Instead of a LISP site, or the MSP, announcing their EIDs with BGP to
	the DFZ, this function can be outsourced to a third party, a P-ITR		the DFZ, this function can be outsourced to a third party, a P-ITR
	Service Provider (PSP). This will result in a decrease of the		Service Provider (PSP). This will result in a decrease of the
	operational complexity both at the site and at the MSP.		operational complexity both at the site and at the MSP.
	The PSP manages a set of distributed P-ITR(s) that will advertise the		The PSP manages a set of distributed P-ITR(s) that will advertise the
	corresponding EID prefixes through BGP to the DFZ. These P-ITR(s)		corresponding EID prefixes through BGP to the DFZ. These P-ITR(s)
	will then encapsulate the traffic they receive for those EIDs towards		will then encapsulate the traffic they receive for those EIDs towards
	the RLOCs of the LISP site, ensuring their reachability from non-LISP		the RLOCs of the LISP site, ensuring their reachability from non-LISP
	skipping to change at page 20, line 22		skipping to change at page 20, line 22
	7. IANA Considerations		7. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	8. Acknowledgements		8. Acknowledgements
	Many thanks to Margaret Wasserman for her contribution to the IETF76		Many thanks to Margaret Wasserman for her contribution to the IETF76
	presentation that kickstarted this work. The authors would also like		presentation that kickstarted this work. The authors would also like
	to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,		to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
	Dino Farinacci, Terry Manderson, Noel Chiappa, and everyone else who		Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and
	provided input.		everyone else who provided input.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-lisp]		[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-15 (work in progress), July 2011.		draft-ietf-lisp-15 (work in progress), July 2011.
	[I-D.ietf-lisp-alt]		[I-D.ietf-lisp-alt]
	Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP		Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
	Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07		Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
	(work in progress), June 2011.		(work in progress), September 2011.
	[I-D.ietf-lisp-interworking]		[I-D.ietf-lisp-interworking]
	Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking LISP with IPv4 and IPv6",		"Interworking LISP with IPv4 and IPv6",
	draft-ietf-lisp-interworking-02 (work in progress),		draft-ietf-lisp-interworking-02 (work in progress),
	June 2011.		June 2011.
	[I-D.ietf-lisp-ms]		[I-D.ietf-lisp-ms]
	Fuller, V. and D. Farinacci, "LISP Map Server",		Fuller, V. and D. Farinacci, "LISP Map Server Interface",
	draft-ietf-lisp-ms-10 (work in progress), July 2011.		draft-ietf-lisp-ms-12 (work in progress), October 2011.
	[I-D.ietf-lisp-sec]		[I-D.ietf-lisp-sec]
	Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,		Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
	and O. Bonaventure, "LISP-Security (LISP-SEC)",		and O. Bonaventure, "LISP-Security (LISP-SEC)",
	draft-ietf-lisp-sec-00 (work in progress), July 2011.		draft-ietf-lisp-sec-00 (work in progress), July 2011.
	[I-D.saucez-lisp-security]		[I-D.saucez-lisp-security]
	Saucez, D., Iannone, L., and O. Bonaventure, "LISP		Saucez, D., Iannone, L., and O. Bonaventure, "LISP
	Security Threats", draft-saucez-lisp-security-03 (work in		Security Threats", draft-saucez-lisp-security-03 (work in
	progress), March 2011.		progress), March 2011.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-lisp-eid-block]		[I-D.ietf-lisp-eid-block]
	Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP		Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
	EID Block", draft-ietf-lisp-eid-block-00 (work in		EID Block", draft-ietf-lisp-eid-block-01 (work in
	progress), July 2011.		progress), October 2011.
	[I-D.lear-lisp-nerd]		[I-D.lear-lisp-nerd]
	Lear, E., "NERD: A Not-so-novel EID to RLOC Database",		Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
	draft-lear-lisp-nerd-08 (work in progress), March 2010.		draft-lear-lisp-nerd-08 (work in progress), March 2010.
	[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS		[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
	performance and the effectiveness of caching", 2002.		performance and the effectiveness of caching", 2002.
	Authors' Addresses		Authors' Addresses
End of changes. 13 change blocks.
	27 lines changed or deleted		35 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/