draft-ietf-lisp-eid-block-10.txt		draft-ietf-lisp-eid-block-11.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft Telecom ParisTech		Internet-Draft Telecom ParisTech
	Intended status: Informational D. Lewis		Intended status: Informational D. Lewis
	Expires: July 12, 2015 Cisco Systems, Inc.		Expires: October 29, 2015 Cisco Systems, Inc.
	D. Meyer		D. Meyer
	Brocade		Brocade
	V. Fuller		V. Fuller
	January 8, 2015		April 27, 2015
	LISP EID Block		LISP EID Block
	draft-ietf-lisp-eid-block-10.txt		draft-ietf-lisp-eid-block-11.txt
	Abstract		Abstract
	This is a direction to IANA to allocate a /32 IPv6 prefix for use		This is a direction to IANA to allocate a /32 IPv6 prefix for use
	with the Locator/ID Separation Protocol (LISP). The prefix will be		with the Locator/ID Separation Protocol (LISP). The prefix will be
	used for local intra-domain routing and global endpoint		used for local intra-domain routing and global endpoint
	identification, by sites deploying LISP as EID (Endpoint IDentifier)		identification, by sites deploying LISP as EID (Endpoint IDentifier)
	addressing space.		addressing space.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 July 12, 2015.		This Internet-Draft will expire on October 29, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 14		skipping to change at page 2, line 14
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 3		3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 3
	4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6		5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5
	6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6		6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6
	7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7		7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. LISP Terminology . . . . . . . . . . . . . . . . . . 11		Appendix A. LISP Terminology . . . . . . . . . . . . . . . . . . 11
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 13		Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	mapping system. In the meanwhile (waiting the Map-Reply),		mapping system. In the meanwhile (waiting the Map-Reply),
	packets may be dropped in order to avoid excessive buffering.		packets may be dropped in order to avoid excessive buffering.
	Avoid penalize non-LISP traffic: In certain circumstances it might		Avoid penalize non-LISP traffic: In certain circumstances it might
	be desirable to configure a router using LISP features to		be desirable to configure a router using LISP features to
	natively forward all packets that have not a destination		natively forward all packets that have not a destination
	address in the block, hence, no lookup whatsoever is performed		address in the block, hence, no lookup whatsoever is performed
	and packets destined to non-LISP sites are not penalized in any		and packets destined to non-LISP sites are not penalized in any
	manner.		manner.
	Avoid excessive stretch: In some deployment scenarios, in order to
	avoid packet drops, packets triggering a LISP Cache miss are
	forwarded toward a PETR, during the time necessary to perform a
	mapping lookup over the LISP mapping system. Once a mapping is
	obtained packet are not forwarded anymore toward the PETR, they
	are LISP encapsulated and forwarded according to the LISP
	specifications. The existence of a LISP specific EID block
	would allow to avoid scenarios with excessive overhead, where
	the destination is a LISP EID and where (while the mapping is
	looked up) packets are forwarded over paths like
	Source->ITR->PETR->PITR->ETR->Destination, which may show an
	excessive stretch factor and degraded performance.
	Traffic Engineering: In some deployment scenarios it might be		Traffic Engineering: In some deployment scenarios it might be
	desirable to apply different traffic engineering policies for		desirable to apply different traffic engineering policies for
	LISP and non-LISP traffic. A LISP specific EID block would		LISP and non-LISP traffic. A LISP specific EID block would
	allow improved traffic engineering capabilities with respect to		allow improved traffic engineering capabilities with respect to
	LISP vs. non-LISP traffic. In particular, LISP traffic might		LISP vs. non-LISP traffic. In particular, LISP traffic might
	be identified without having to use DPI techniques in order to		be identified without having to use DPI techniques in order to
	parse the encapsulated packet, performing instead a simple		parse the encapsulated packet, performing instead a simple
	inspection of the outer header is sufficient.		inspection of the outer header is sufficient.
	Transition Mechanism: The existence of an LISP specific EID block		Transition Mechanism: The existence of an LISP specific EID block
	skipping to change at page 5, line 20		skipping to change at page 5, line 8
	IPv6 prefix.		IPv6 prefix.
	4. Expected use		4. Expected use
	Sites planning to deploy LISP may request a prefix in the IPv6 EID		Sites planning to deploy LISP may request a prefix in the IPv6 EID
	block. Such prefix will be used for routing and endpoint		block. Such prefix will be used for routing and endpoint
	identification inside the site requesting it. Mappings related to		identification inside the site requesting it. Mappings related to
	such prefix, or part of it, will be made available through the		such prefix, or part of it, will be made available through the
	mapping system in use and registered to one or more Map Server(s).		mapping system in use and registered to one or more Map Server(s).
	To provide reachability from the non-LISP Internet, EID prefixes may
	be restrictively announced in the BGP routing infrastructure by one
	or more PITR(s) as more specifics (longer mask length). The intended
	scope of these more specific prefix advertisements may be deliberated
	limited by the PITR to reflect local routing policies.
	The EID block must be used for LISP experimentation and must not be		The EID block must be used for LISP experimentation and must not be
	advertised in the form of more specific route advertisements in the		advertised in the form of more specific route advertisements in the
	non-LISP inter-domain routing environment. Interworking between the		non-LISP inter-domain routing environment. Interworking between the
	EID block sub-prefixes and the non-LISP Internet is done according to		EID block sub-prefixes and the non-LISP Internet is done according to
	[RFC6832] and [RFC7215].		[RFC6832] and [RFC7215].
	As the LISP adoption progress, the EID block will potentially help in		As the LISP adoption progress, the EID block will potentially help in
	reducing the impact on the BGP routing infrastructure with respect to		reducing the impact on the BGP routing infrastructure with respect to
	the case of the same number of adopters using global unicast space		the case of the same number of adopters using global unicast space
	allocated by RIRs ([MobiArch2007]). From a short-term perspective,		allocated by RIRs ([MobiArch2007]). From a short-term perspective,
	skipping to change at page 7, line 50		skipping to change at page 7, line 33
	element, must not include any special handling code or hardware for		element, must not include any special handling code or hardware for
	addresses in the IPv6 EID block. In particular, it is recommended		addresses in the IPv6 EID block. In particular, it is recommended
	that the default router configuration does not handle such addresses		that the default router configuration does not handle such addresses
	in any special way. Doing differently could prevent communication		in any special way. Doing differently could prevent communication
	between the Legacy Internet and LISP sites or even break local intra-		between the Legacy Internet and LISP sites or even break local intra-
	domain connectivity.		domain connectivity.
	8. Security Considerations		8. Security Considerations
	This document does not introduce new security threats in the LISP		This document does not introduce new security threats in the LISP
	architecture nor in the Legacy Internet architecture.		architecture nor in the legacy Internet architecture.
	9. IANA Considerations		9. IANA Considerations
	This document instructs the IANA to assign a /32 IPv6 prefix for use		This document instructs the IANA to assign a /32 IPv6 prefix for use
	as the global LISP EID space using a hierarchical allocation as		as the global LISP EID space using a hierarchical allocation as
	outlined in [RFC5226] and summarized in Table 1.		outlined in [RFC5226] and summarized in Table 1.
	+----------------------+--------------------+		+----------------------+--------------------+
	| Attribute | Value |		| Attribute | Value |
	+----------------------+--------------------+		+----------------------+--------------------+
	skipping to change at page 9, line 11		skipping to change at page 9, line 8
	Allocation and management of the Global EID Space is detailed in a		Allocation and management of the Global EID Space is detailed in a
	different document. Nevertheless, all prefix allocations out of this		different document. Nevertheless, all prefix allocations out of this
	space must be temporary and no allocation must go beyond December		space must be temporary and no allocation must go beyond December
	2018 unless the IETF Review decides for a permanent Global EID Space		2018 unless the IETF Review decides for a permanent Global EID Space
	assignment.		assignment.
	10. Acknowledgments		10. Acknowledgments
	Special thanks to Roque Gagliano for his suggestions and pointers.		Special thanks to Roque Gagliano for his suggestions and pointers.
	Thanks to Damien, Saucez, David Conrad, Scott Bradner, John Curran,		Thanks to Ron Bonica, Damien Saucez, David Conrad, Scott Bradner,
	Paul Wilson, Geoff Huston, Wes George, Arturo Servin, Sander		John Curran, Paul Wilson, Geoff Huston, Wes George, Arturo Servin,
	Steffann, Brian Carpenter, Roger Jorgensen, Terry Manderson, Brian		Sander Steffann, Brian Carpenter, Roger Jorgensen, Terry Manderson,
	Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris Morrow,		Brian Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris
	and Peter Schoenmaker, for their insightful comments. Thanks as well		Morrow, and Peter Schoenmaker, for their insightful comments. Thanks
	to all participants to the fruitful discussions on the IETF mailing		as well to all participants to the fruitful discussions on the IETF
	list.		mailing list.
	The work of Luigi Iannone has been partially supported by the ANR-13-		The work of Luigi Iannone has been partially supported by the ANR-13-
	INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-		INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
	Labs SOFNETS Project.		Labs SOFNETS Project.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-lisp-eid-block-mgmnt]		[I-D.ietf-lisp-eid-block-mgmnt]
	skipping to change at page 13, line 40		skipping to change at page 13, line 27
	logical next-hop on the overlay network. The primary function of		logical next-hop on the overlay network. The primary function of
	LISP+ALT routers is to provide a lightweight forwarding		LISP+ALT routers is to provide a lightweight forwarding
	infrastructure for LISP control-plane messages (Map-Request and		infrastructure for LISP control-plane messages (Map-Request and
	Map-Reply), and to transport data packets when the packet has the		Map-Reply), and to transport data packets when the packet has the
	same destination address in both the inner (encapsulating)		same destination address in both the inner (encapsulating)
	destination and outer destination addresses ((i.e., a Data Probe		destination and outer destination addresses ((i.e., a Data Probe
	packet). See [RFC6836] for more details.		packet). See [RFC6836] for more details.
	Appendix B. Document Change Log		Appendix B. Document Change Log
			Version 11 Posted April 2015.
			o In Section 4, deleted contradictory text on EID prefix
			advertisement in non-LISP inter-domain routing environments.
			o In Section 3 deleted the "Avoid excessive strech" bullet, because
			confusing.
			o Deleted last bullet of the list in Section 3 because retundant
			w.r.t. global content of the document.
	Version 10 Posted January 2015.		Version 10 Posted January 2015.
	o Keep alive verision		o Keep alive version
	Version 09 Posted July 2014.		Version 09 Posted July 2014.
	o Few Editorial modifications as requested by D. Saucez, as		o Few Editorial modifications as requested by D. Saucez, as
	shepherd, during the write up of the document.		shepherd, during the write up of the document.
	o Allocation date postponed to beginning 2015, as suggested by D.		o Allocation date postponed to beginning 2015, as suggested by D.
	Saucez.		Saucez.
	Version 08 Posted January 2014.		Version 08 Posted January 2014.
End of changes. 12 change blocks.
	35 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/