draft-ietf-lisp-map-versioning-08.txt		draft-ietf-lisp-map-versioning-09.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft Telekom Innovation Laboratories		Internet-Draft Telekom Innovation Laboratories
	Intended status: Experimental D. Saucez		Intended status: Experimental D. Saucez
	Expires: August 17, 2012 INRIA Sophia Antipolis		Expires: September 2, 2012 INRIA Sophia Antipolis
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	February 14, 2012		March 1, 2012
	LISP Map-Versioning		LISP Map-Versioning
	draft-ietf-lisp-map-versioning-08.txt		draft-ietf-lisp-map-versioning-09.txt
	Abstract		Abstract
	This document describes the LISP (Locator/ID Separation Protocol)		This document describes the LISP (Locator/ID Separation Protocol)
	Map-Versioning mechanism, which provides in-packet information about		Map-Versioning mechanism, which provides in-packet information about
	Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to		Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to
	encapsulate LISP data packets. The proposed approach is based on		encapsulate LISP data packets. The proposed approach is based on
	associating a version number to EID-to-RLOC mappings and transport		associating a version number to EID-to-RLOC mappings and transport
	such a version number in the LISP specific header of LISP-		such a version number in the LISP specific header of LISP-
	encapsulated packets. LISP Map-Versioning is particularly useful to		encapsulated packets. LISP Map-Versioning is particularly useful to
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	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 August 17, 2012.		This Internet-Draft will expire on September 2, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 8, line 10		skipping to change at page 8, line 10
	Since the ETR is authoritative on the mapping, meaning that the		Since the ETR is authoritative on the mapping, meaning that the
	Map-Version number of its mapping is the correct one, this		Map-Version number of its mapping is the correct one, this
	implies that someone is not behaving correctly with respect to		implies that someone is not behaving correctly with respect to
	the specifications. In this case the packet carries a version		the specifications. In this case the packet carries a version
	number that is not valid, otherwise the ETR would have the same,		number that is not valid, otherwise the ETR would have the same,
	and SHOULD be silently dropped.		and SHOULD be silently dropped.
	3. The packets arrive with a Destination Map-Version number smaller		3. The packets arrive with a Destination Map-Version number smaller
	(i.e., older) than the one stored in the EID-to-RLOC Database.		(i.e., older) than the one stored in the EID-to-RLOC Database.
	This means that the ITR sending the packet has an old mapping in		This means that the ITR sending the packet has an old mapping in
	its EID-to-RLOC Cache containing stale information. The ITR		its EID-to-RLOC Cache containing stale information. The ETR MAY
	sending the packet has to be informed that a newer mapping is		choose to normally process the encapsulated datagram according to
	available. This is done with a Map-Request message sent back to		[I-D.ietf-lisp], however, the ITR sending the packet has to be
	the ITR. The Map-Request will either trigger a Map-Request back		informed that a newer mapping is available. This is done with a
	using the Solicit-Map-Request (SMR) bit or it will piggyback the		Map-Request message sent back to the ITR. The Map-Request will
	newer mapping. These are not new mechanisms; how to SMR or		either trigger a Map-Request back using the Solicit-Map-Request
	piggyback mappings in Map-Request messages is already described		(SMR) bit or it will piggyback the newer mapping. These are not
	in [I-D.ietf-lisp], while their security is discussed in		new mechanisms; how to SMR or piggyback mappings in Map-Request
	[I-D.ietf-lisp-threats]. These Map-Request messages should be		messages is already described in [I-D.ietf-lisp], while their
	rate limited (rate limitation policies are also described in		security is discussed in [I-D.ietf-lisp-threats]. These Map-
	[I-D.ietf-lisp]). The feature introduced by Map-Version numbers		Request messages should be rate limited (rate limitation policies
	is the possibility of blocking traffic not using the latest		are also described in [I-D.ietf-lisp]). The feature introduced
	mapping. Indeed, after a certain number of retries, if the		by Map-Version numbers is the possibility of blocking traffic not
	Destination Map-Version number in the packets is not updated, the		using the latest mapping. Indeed, after a certain number of
	ETR MAY drop packets with a stale Map-Version number while		retries, if the Destination Map-Version number in the packets is
	strongly reducing the rate of Map-Request messages. This because		not updated, the ETR MAY drop packets with a stale Map-Version
	either the ITR is refusing to use the mapping for which the ETR		number while strongly reducing the rate of Map-Request messages.
	is authoritative or (worse) it might be some form of attack.		This because either the ITR is refusing to use the mapping for
	Another case might be that the control-plane is experiencing		which the ETR is authoritative or (worse) it might be some form
	transient failures so the Map-Requests cannot reach that ITR. By		of attack. Another case might be that the control-plane is
	keeping sending Map-Requests at very low rate it is possible to		experiencing transient failures so the Map-Requests cannot reach
	recover from this situation.		that ITR. By keeping sending Map-Requests at very low rate it is
			possible to recover from this situation.
	The rule in the third case MAY be more restrictive. If the mapping		The rule in the third case MAY be more restrictive. If the mapping
	has been the same for a period of time as long as the TTL (defined in		has been the same for a period of time as long as the TTL (defined in
	[I-D.ietf-lisp]) of the previous version of the mapping, all packets		[I-D.ietf-lisp]) of the previous version of the mapping, all packets
	arriving with an old Map-Version SHOULD be silently dropped right		arriving with an old Map-Version SHOULD be silently dropped right
	away without issuing any Map-Request. The reason that allows such		away without issuing any Map-Request. The reason that allows such
	action is the fact that if the new mapping with the updated version		action is the fact that if the new mapping with the updated version
	number has been unchanged for at least the same time as the TTL of		number has been unchanged for at least the same time as the TTL of
	the older mapping, all the entries in the EID-to-RLOC Caches of ITRs		the older mapping, all the entries in the EID-to-RLOC Caches of ITRs
	must have expired. Hence, all ITRs sending traffic should have		must have expired. Hence, all ITRs sending traffic should have
	skipping to change at page 19, line 20		skipping to change at page 19, line 20
	14.1. Normative References		14.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-22 (work in progress), February 2012.		draft-ietf-lisp-22 (work in progress), February 2012.
	[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-03 (work in progress),		draft-ietf-lisp-interworking-05 (work in progress),
	February 2012.		February 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	14.2. Informative References		14.2. Informative References
	[I-D.iannone-openlisp-implementation]		[I-D.iannone-openlisp-implementation]
	Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP		Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
	Implementation Report",		Implementation Report",
	skipping to change at page 21, line 4		skipping to change at page 21, line 4
	| 16 | 45 Days | 18 Hours |		| 16 | 45 Days | 18 Hours |
	| 15 | 22 Days | 9 Hours |		| 15 | 22 Days | 9 Hours |
	| 14 | 11 Days | 4 Hours |		| 14 | 11 Days | 4 Hours |
	| 13 | 5.6 Days | 2.2 Hours |		| 13 | 5.6 Days | 2.2 Hours |
	| 12 | 2.8 Days | 1.1 Hours |		| 12 | 2.8 Days | 1.1 Hours |
	+---------------+---------------------+----------------------+		+---------------+---------------------+----------------------+
	Figure 5: Estimation of time before wrap-around		Figure 5: Estimation of time before wrap-around
	Appendix B. Document Change Log		Appendix B. Document Change Log
			o Version 09 Posted March 2012.
			* Text in Section 5.1 made more explicit in the case of smaller
			(i.e., older) Destination Map-Version Number, as pointed out by
			Ralph E. Droms.
	o Version 08 Posted Ferbruary 2012.		o Version 08 Posted Ferbruary 2012.
	* Clarifications added to Appendix A as requested by S. Bryant.		* Clarifications added to Appendix A as requested by S. Bryant.
	o Version 07 Posted January 2012.		o Version 07 Posted January 2012.
	* Moved Subsection 8.1 in Section 12 as requested by R. Bonica.		* Moved Subsection 8.1 in Section 12 as requested by R. Bonica.
	* Added explicit reference to the discussion about ETR		* Added explicit reference to the discussion about ETR
	synchronization at the end of the Introduction, as requested by		synchronization at the end of the Introduction, as requested by
End of changes. 7 change blocks.
	27 lines changed or deleted		34 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/