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/