draft-ietf-lisp-deployment-11.txt		draft-ietf-lisp-deployment-12.txt
	Network Working Group L. Jakab		Network Working Group L. Jakab
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Experimental A. Cabellos-Aparicio		Intended status: Experimental A. Cabellos-Aparicio
	Expires: June 12, 2014 F. Coras		Expires: July 21, 2014 F. Coras
	J. Domingo-Pascual		J. Domingo-Pascual
	Technical University of		Technical University of
	Catalonia		Catalonia
	D. Lewis		D. Lewis
	Cisco Systems		Cisco Systems
	December 9, 2013		January 17, 2014
	LISP Network Element Deployment Considerations		LISP Network Element Deployment Considerations
	draft-ietf-lisp-deployment-11.txt		draft-ietf-lisp-deployment-12.txt
	Abstract		Abstract
	This document is a snapshot of different Locator/Identifier		This document is a snapshot of different Locator/Identifier
	Separation Protocol (LISP) deployment scenarios. It discusses the		Separation Protocol (LISP) deployment scenarios. It discusses the
	placement of new network elements introduced by the protocol,		placement of new network elements introduced by the protocol,
	representing the thinking of the LISP working group as of Summer		representing the thinking of the LISP working group as of Summer
	2013. LISP deployment scenarios may have evolved since. This memo		2013. LISP deployment scenarios may have evolved since. This memo
	represents one stable point in that evolution of understanding.		represents one stable point in that evolution of understanding.
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	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 June 12, 2014.		This Internet-Draft will expire on July 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 3, line 28		skipping to change at page 3, line 28
	places it at the border routers of stub autonomous systems, which may		places it at the border routers of stub autonomous systems, which may
	carry a partial or complete default-free zone (DFZ) routing table.		carry a partial or complete default-free zone (DFZ) routing table.
	The initial design of LISP took this location as a baseline for		The initial design of LISP took this location as a baseline for
	protocol development. However, the applications of LISP go beyond		protocol development. However, the applications of LISP go beyond
	just decreasing the size of the DFZ routing table, and include		just decreasing the size of the DFZ routing table, and include
	improved multihoming and ingress traffic engineering (TE) support for		improved multihoming and ingress traffic engineering (TE) support for
	edge networks, and even individual hosts. Throughout the document we		edge networks, and even individual hosts. Throughout the document we
	will use the term LISP site to refer to these networks/hosts behind a		will use the term LISP site to refer to these networks/hosts behind a
	LISP Tunnel Router. We formally define the following two terms:		LISP Tunnel Router. We formally define the following two terms:
	Network element: Active or passive device that is connected to other		Network element: Facility or equipment used in the provision of a
	active or passive devices for transporting packet switched data.		communications service over the Internet [TELCO96].
	LISP site: A single host or a set of network elements in an edge		LISP site: A single host or a set of network elements in an edge
	network under the administrative control of a single organization,		network under the administrative control of a single organization,
	delimited from other networks by LISP Tunnel Router(s).		delimited from other networks by LISP Tunnel Router(s).
	Since LISP is a protocol which can be used for different purposes, it		Since LISP is a protocol which can be used for different purposes, it
	is important to identify possible deployment scenarios and the		is important to identify possible deployment scenarios and the
	additional requirements they may impose on the protocol specification		additional requirements they may impose on the protocol specification
	and other protocols. Additionally, this document is intended as a		and other protocols. Additionally, this document is intended as a
	guide for the operational community for LISP deployments in their		guide for the operational community for LISP deployments in their
	skipping to change at page 10, line 17		skipping to change at page 10, line 17
	o In LISP, ITRs set the reachability bits when encapsulating data		o In LISP, ITRs set the reachability bits when encapsulating data
	packets. Hence, ITRs need a mechanism to be aware of the liveness		packets. Hence, ITRs need a mechanism to be aware of the liveness
	of all ETRs serving their site.		of all ETRs serving their site.
	o MTU within the site network must be large enough to accommodate		o MTU within the site network must be large enough to accommodate
	encapsulated packets.		encapsulated packets.
	o In this scenario, each ITR is serving fewer hosts than in the case		o In this scenario, each ITR is serving fewer hosts than in the case
	when it is deployed at the border of the network. It has been		when it is deployed at the border of the network. It has been
	shown that cache hit ratio grows logarithmically with the amount		shown that cache hit ratio grows logarithmically with the amount
	of users [cache]. Taking this into account, when ITRs are		of users [CACHE]. Taking this into account, when ITRs are
	deployed closer to the host the effectiveness of the mapping cache		deployed closer to the host the effectiveness of the mapping cache
	may be lower (i.e., the miss ratio is higher). Another		may be lower (i.e., the miss ratio is higher). Another
	consequence of this is that the site may transmit a higher amount		consequence of this is that the site may transmit a higher amount
	of Map-Requests, increasing the load on the distributed mapping		of Map-Requests, increasing the load on the distributed mapping
	database.		database.
	o By placing the ITRs inside the site, they will still need global		o By placing the ITRs inside the site, they will still need global
	RLOCs, and this may add complexity to intra-site routing		RLOCs, and this may add complexity to intra-site routing
	configuration, and further intra-site issues when there is a		configuration, and further intra-site issues when there is a
	change of providers.		change of providers.
	skipping to change at page 14, line 18		skipping to change at page 14, line 18
	according to the specific mapping system that is employed (e.g., ALT		according to the specific mapping system that is employed (e.g., ALT
	[RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping		[RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping
	database, and the storing of EID-to-RLOC mapping data is subject to		database, and the storing of EID-to-RLOC mapping data is subject to
	the policies of the "root" operators, who should check ownership		the policies of the "root" operators, who should check ownership
	rights for the EID prefixes stored in the database by participants.		rights for the EID prefixes stored in the database by participants.
	These policies are out of the scope of this document.		These policies are out of the scope of this document.
	The LISP DDT protocol is used by LISP Mapping Service providers to		The LISP DDT protocol is used by LISP Mapping Service providers to
	provide reachability between those providers' Map-Resolvers and Map-		provide reachability between those providers' Map-Resolvers and Map-
	Servers. The DDT Root is currently operated by a collection of		Servers. The DDT Root is currently operated by a collection of
	organizations on an open basis. See [DDT-Root] for more details.		organizations on an open basis. See [DDT-ROOT] for more details.
	Similarly to the DNS root, it has several different server instances		Similarly to the DNS root, it has several different server instances
	using names of the letters of the Greek alphabet (alpha, delta,		using names of the letters of the Greek alphabet (alpha, delta,
	etc.), operated by independent organizations. When this document was		etc.), operated by independent organizations. When this document was
	published, there were 5 such instances, one of them being anycasted.		published, there were 5 such instances, one of them being anycasted.
	The Root provides the list of server instances on their web site and		The Root provides the list of server instances on their web site and
	configuration files for several map server implementations. The DDT		configuration files for several map server implementations. The DDT
	Root, and LISP Mapping Providers both rely on and abide by existing		Root, and LISP Mapping Providers both rely on and abide by existing
	allocation policies by Regional Internet Registries to determine		allocation policies by Regional Internet Registries to determine
	prefix ownership for use as EIDs.		prefix ownership for use as EIDs.
	skipping to change at page 22, line 48		skipping to change at page 22, line 48
	Note that throughout Section 5 we focused on the effects of LISP		Note that throughout Section 5 we focused on the effects of LISP
	deployment on the DFZ route table size. Other metrics may be		deployment on the DFZ route table size. Other metrics may be
	impacted as well, but to the best of our knowlegde have not been		impacted as well, but to the best of our knowlegde have not been
	measured as of yet.		measured as of yet.
	6. Security Considerations		6. Security Considerations
	All security implications of LISP deployments are to be discussed in		All security implications of LISP deployments are to be discussed in
	separate documents. [I-D.ietf-lisp-threats] gives an overview of		separate documents. [I-D.ietf-lisp-threats] gives an overview of
	LISP threat models, while securing mapping lookups is discussed in		LISP threat models, including ETR operators attracting traffic by
	[I-D.ietf-lisp-sec].		overclaiming an EID-prefix (Section 4.4.3). Securing mapping lookups
			is discussed in [I-D.ietf-lisp-sec].
	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,
	skipping to change at page 23, line 36		skipping to change at page 23, line 36
	[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking between Locator/ID Separation Protocol		"Interworking between Locator/ID Separation Protocol
	(LISP) and Non-LISP Sites", RFC 6832, January 2013.		(LISP) and Non-LISP Sites", RFC 6832, January 2013.
	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation		[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Protocol (LISP) Map-Server Interface", RFC 6833,		Protocol (LISP) Map-Server Interface", RFC 6833,
	January 2013.		January 2013.
	9.2. Informative References		9.2. Informative References
	[DDT-Root]		[CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
			performance and the effectiveness of caching", 2002.
			[DDT-ROOT]
	"DDT Root", <http://ddt-root.org/>.		"DDT Root", <http://ddt-root.org/>.
	[I-D.ietf-lisp-ddt]		[I-D.ietf-lisp-ddt]
	Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP		Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
	Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in		Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
	progress), March 2013.		progress), March 2013.
	[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)",
	skipping to change at page 24, line 29		skipping to change at page 24, line 32
	January 2013.		January 2013.
	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,		[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol Alternative Logical		"Locator/ID Separation Protocol Alternative Logical
	Topology (LISP+ALT)", RFC 6836, January 2013.		Topology (LISP+ALT)", RFC 6836, January 2013.
	[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.		[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
	Selkirk, "Port Control Protocol (PCP)", RFC 6887,		Selkirk, "Port Control Protocol (PCP)", RFC 6887,
	April 2013.		April 2013.
	[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS		[TELCO96] "Telecommunications Act of 1996", 1996.
	performance and the effectiveness of caching", 2002.
	Appendix A. Step-by-Step Example BGP to LISP Migration Procedure		Appendix A. Step-by-Step Example BGP to LISP Migration Procedure
	To help the operational community deploy LISP, this informative		To help the operational community deploy LISP, this informative
	section offers a step-by-step guide for migrating a BGP based		section offers a step-by-step guide for migrating a BGP based
	Internet presence to a LISP site. It includes a pre-install/		Internet presence to a LISP site. It includes a pre-install/
	pre-turn-up checklist, and customer and provider activation		pre-turn-up checklist, and customer and provider activation
	procedures.		procedures.
	A.1. Customer Pre-Install and Pre-Turn-up Checklist		A.1. Customer Pre-Install and Pre-Turn-up Checklist
End of changes. 11 change blocks.
	14 lines changed or deleted		17 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/