draft-ietf-lisp-map-versioning-05.txt   draft-ietf-lisp-map-versioning-06.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft TU Berlin - Deutsche Telekom Internet-Draft Telekom Innovation Laboratories
Intended status: Experimental Laboratories AG Intended status: Experimental D. Saucez
Expires: April 15, 2012 D. Saucez Expires: May 3, 2012 O. Bonaventure
O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
October 13, 2011 October 31, 2011
LISP Map-Versioning LISP Map-Versioning
draft-ietf-lisp-map-versioning-05.txt draft-ietf-lisp-map-versioning-06.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
inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel
Routers (ETRs) about modifications of the mappings used to Routers (ETRs) about modifications of the mappings used to
encapsulate packets. The mechanism is transparent to legacy encapsulate packets. The mechanism is transparent to implementations
implementations, since in the LISP-specific header and in the Map not supporting this feature, since in the LISP-specific header and in
Records, bits used for Map-Versioning can be safely ignored by ITRs the Map Records, bits used for Map-Versioning can be safely ignored
and ETRs that do not support the mechanism. by ITRs and ETRs that do not support the mechanism.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 15, 2012. This Internet-Draft will expire on May 3, 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 26 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . . 4 4. EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . . 4
4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . . 5 4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . . 5
5. Dealing with Map-Version numbers . . . . . . . . . . . . . . . 6 5. Dealing with Map-Version numbers . . . . . . . . . . . . . . . 6
5.1. Handling Destination Map-Version number . . . . . . . . . 7 5.1. Handling Destination Map-Version number . . . . . . . . . 7
5.2. Handling Source Map-Version number . . . . . . . . . . . . 9 5.2. Handling Source Map-Version number . . . . . . . . . . . . 9
6. LISP header and Map-Version numbers . . . . . . . . . . . . . 9 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 10
7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10
8. Benefits and case studies for Map-Versioning . . . . . . . . . 11 8. Benefits and case studies for Map-Versioning . . . . . . . . . 11
8.1. Synchronization of different xTRs . . . . . . . . . . . . 11 8.1. Synchronization of different xTRs . . . . . . . . . . . . 11
8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12 8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12
8.3. Map-Versioning and interworking . . . . . . . . . . . . . 13 8.3. Map-Versioning and interworking . . . . . . . . . . . . . 13
8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13
8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14 8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14
8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14 8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14
8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15 8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15
8.5. Map-Version for lightweight LISP implementation . . . . . 15 8.5. Map-Version for lightweight LISP implementation . . . . . 15
9. Incremental deployment and implementation status . . . . . . . 16 9. Incremental deployment and implementation status . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Map-Versioning against traffic disruption . . . . . . . . 16 10.1. Map-Versioning against traffic disruption . . . . . . . . 16
10.2. Map-Versioning against reachability information DoS . . . 17 10.2. Map-Versioning against reachability information DoS . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. Open Issues and Considerations . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Estimation of time before Map-Version wrap-around . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19 Appendix A. Estimation of time before Map-Version wrap-around . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
This document describes the Map-Versioning mechanism used to provide This document describes the Map-Versioning mechanism used to provide
information on changes in the EID-to-RLOC mappings used in the LISP information on changes in the EID-to-RLOC mappings used in the LISP
([I-D.ietf-lisp]) context to perform packet encapsulation. The ([I-D.ietf-lisp]) context to perform packet encapsulation. The
mechanism is totally transparent to xTRs not supporting such mechanism is totally transparent to xTRs not supporting such
functionality. It is not meant to replace any existing LISP functionality. It is not meant to replace any existing LISP
mechanism, but rather to extend them providing new functionalities. mechanism, but rather to extend them providing new functionalities.
If for any unforseen reason a normative conflict between the present If for any unforseen reason a normative conflict between the present
skipping to change at page 3, line 49 skipping to change at page 3, line 49
2. The version number assigned to the mapping (contained in the EID- 2. The version number assigned to the mapping (contained in the EID-
to-RLOC Cache) used to select the destination RLOC. to-RLOC Cache) used to select the destination RLOC.
This operation is two-fold. On the one hand, it enables the ETR This operation is two-fold. On the one hand, it enables the ETR
receiving the packet to know if the ITR has the latest version number receiving the packet to know if the ITR has the latest version number
that any ETR at the destination EID site has provided to the ITR in a that any ETR at the destination EID site has provided to the ITR in a
Map-Reply. If it is not the case the ETR can send to the ITR a Map- Map-Reply. If it is not the case the ETR can send to the ITR a Map-
Request containing the updated mapping or soliciting a Map-Request Request containing the updated mapping or soliciting a Map-Request
from the ITR (both cases are already defined in [I-D.ietf-lisp]). In from the ITR (both cases are already defined in [I-D.ietf-lisp]). In
this way the ITR can update its cache. On the other hand, it enables this way the ITR can update its EID-to-RLOC Cache. On the other
an ETR receiving such a packet to know if it has in its EID-to-RLOC hand, it enables an ETR receiving such a packet to know if it has in
Cache the latest mapping for the source EID (in case of bidirectional its EID-to-RLOC Cache the latest mapping for the source EID (in case
traffic). If it is not the case a Map-Request can be sent. of bidirectional traffic). If it is not the case a Map-Request can
be sent.
Issues and concerns about the deployment of LISP for Internet traffic
are discussed in [I-D.ietf-lisp]. Section 12 provides additional
issues and concerns raised by this document.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions of Terms 3. Definitions of Terms
The present document uses terms already defined in main LISP The present document uses terms already defined in main LISP
skipping to change at page 5, line 46 skipping to change at page 6, line 4
the version of the EID-to-RLOC mapping. Such a value is used for the version of the EID-to-RLOC mapping. Such a value is used for
special purposes and is named the Null Map-Version number. special purposes and is named the Null Map-Version number.
The Null Map-Version MAY appear in the LISP specific header as either The Null Map-Version MAY appear in the LISP specific header as either
Source Map-Version number (cf. Section 5.2) or Destination Map- Source Map-Version number (cf. Section 5.2) or Destination Map-
Version number (cf. Section 5.1). When the Source Map-Version number Version number (cf. Section 5.1). When the Source Map-Version number
is set to the Null Map-version value it means that no map version is set to the Null Map-version value it means that no map version
information is conveyed for the source site. This means that if a information is conveyed for the source site. This means that if a
mapping exists for the source EID in the EID-to-RLOC Cache, then the mapping exists for the source EID in the EID-to-RLOC Cache, then the
ETR MUST NOT compare the received Null Map-Version with the content ETR MUST NOT compare the received Null Map-Version with the content
of the EID-to-RLOC cache. When the Destination Map-version number is of the EID-to-RLOC Cache. When the Destination Map-version number is
set to the Null Map-version value it means that no map version set to the Null Map-version value it means that no map version
information is conveyed for the destination site. This means that information is conveyed for the destination site. This means that
the ETR MUST NOT compare the value with the Map-Version number of the the ETR MUST NOT compare the value with the Map-Version number of the
mapping for the destination EID present in the EID-to-RLOC Database. mapping for the destination EID present in the EID-to-RLOC Database.
The other use of the Null Map-Version number is in the Map Records, The other use of the Null Map-Version number is in the Map Records,
which are part of the Map-Request, Map-Reply and Map-Register which are part of the Map-Request, Map-Reply and Map-Register
messages (defined in [I-D.ietf-lisp]). Map Records that have a Null messages (defined in [I-D.ietf-lisp]). Map Records that have a Null
Map-Version number indicate that there is no Map-Version number Map-Version number indicate that there is no Map-Version number
associated with the mapping. This means that LISP encapsulated associated with the mapping. This means that LISP encapsulated
skipping to change at page 6, line 38 skipping to change at page 6, line 45
changes) the LISP site updates the mapping also assigning a new Map- changes) the LISP site updates the mapping also assigning a new Map-
Version number. Version number.
To each mapping, a version number is associated and changes each time To each mapping, a version number is associated and changes each time
the mapping is changed. Note that map-versioning does not introduce the mapping is changed. Note that map-versioning does not introduce
new problems concerning the coordination of different ETRs of a new problems concerning the coordination of different ETRs of a
domain. Indeed, ETRs belonging to the same LISP site must return for domain. Indeed, ETRs belonging to the same LISP site must return for
a specific EID-prefix the same mapping, including the same Map- a specific EID-prefix the same mapping, including the same Map-
Version number. In principle this is orthogonal to whether or not Version number. In principle this is orthogonal to whether or not
map-versioning is used. The synchronization problem and its map-versioning is used. The synchronization problem and its
implication on the traffic is out of the scope of this document. implication on the traffic is out of the scope of this document (see
Section 12).
In order to announce in a data-driven fashion that the mapping has In order to announce in a data-driven fashion that the mapping has
been updated, Map-Version numbers used to create the outer IP header been updated, Map-Version numbers used to create the outer IP header
of the LISP-encapsulated packet are embedded in the LISP-specific of the LISP-encapsulated packet are embedded in the LISP-specific
header. This means that the header needs to contain two Map-Version header. This means that the header needs to contain two Map-Version
numbers: numbers:
o The Source Map-Version number of the EID-to-RLOC mapping in the o The Source Map-Version number of the EID-to-RLOC mapping in the
EID-to-RLOC Database used to select the source RLOC. EID-to-RLOC Database used to select the source RLOC.
o The Destination Map-Version number of the EID-to-RLOC mapping in o The Destination Map-Version number of the EID-to-RLOC mapping in
the EID-to-RLOC Cache used to select the destination RLOC. the EID-to-RLOC Cache used to select the destination RLOC.
By embedding both Source Map-Version number and Destination Map- By embedding both Source Map-Version number and Destination Map-
Version number an ETR receiving a LISP packet with Map-Version Version number an ETR receiving a LISP packet with Map-Version
numbers, can perform the following checks: numbers, can perform the following checks:
1. The ITR that has sent the packet has an up-to-date mapping in its 1. The ITR that has sent the packet has an up-to-date mapping in its
cache for the destination EID and is performing encapsulation EID-to-RLOC Cache for the destination EID and is performing
correctly. encapsulation correctly.
2. In case of bidirectional traffic, the mapping in the local ETR 2. In case of bidirectional traffic, the mapping in the local ETR
EID-to-RLOC cache for the source EID is up-to-date. EID-to-RLOC Cache for the source EID is up-to-date.
If one or both of the above conditions do not hold, the ETR can send If one or both of the above conditions do not hold, the ETR can send
a Map-Request either to make the ITR aware that a new mapping is a Map-Request either to make the ITR aware that a new mapping is
available (see Section 5.1) or to update the mapping in the local available (see Section 5.1) or to update the mapping in the local
cache (see Section 5.2). EID-to-RLOC Cache (see Section 5.2).
5.1. Handling Destination Map-Version number 5.1. Handling Destination Map-Version number
When an ETR receives a packet, the Destination Map-Version number When an ETR receives a packet, the Destination Map-Version number
relates to the mapping for the destination EID for which the ETR is a relates to the mapping for the destination EID for which the ETR is a
RLOC. This mapping is part of the ETR EID-to-RLOC Database. Since RLOC. This mapping is part of the ETR EID-to-RLOC Database. Since
the ETR is authoritative for the mapping, it has the correct and up- the ETR is authoritative for the mapping, it has the correct and up-
to-date Destination Map-Version number. A check on this version to-date Destination Map-Version number. A check on this version
number can be done, where the following cases can arise: number can be done, where the following cases can arise:
skipping to change at page 8, line 28 skipping to change at page 8, line 38
keeping sending Map-Requests at very low rate it is possible to keeping sending Map-Requests at very low rate it is possible to
recover from this situation. 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 caches of ITRs must have the older mapping, all the entries in the EID-to-RLOC Caches of ITRs
expired. Hence, all ITRs sending traffic should have refreshed the must have expired. Hence, all ITRs sending traffic should have
mapping according to [I-D.ietf-lisp]. If packets with old Map- refreshed the mapping according to [I-D.ietf-lisp]. If packets with
Version number are still received, then either someone has not old Map-Version number are still received, then either someone has
respected the TTL, or it is a form of spoof/attack. In both cases not respected the TTL, or it is a form of spoof/attack. In both
this is not valid behavior with respect to the specifications and the cases this is not valid behavior with respect to the specifications
packet SHOULD be silently dropped. and the packet SHOULD be silently dropped.
LISP-encapsulated packets with the V-bit set, when the original LISP-encapsulated packets with the V-bit set, when the original
mapping in the EID-to-RLOC Database has version number set to the mapping in the EID-to-RLOC Database has version number set to the
Null Map-Version value, MAY be silently dropped. As explained in Null Map-Version value, MAY be silently dropped. As explained in
Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
means that ITRs, using the mapping for encapsulation, MUST NOT use means that ITRs, using the mapping for encapsulation, MUST NOT use
Map-Version number in the LISP-specific header. Map-Version number in the LISP-specific header.
For LISP-encapsulated packets with the V-bit set, when the original For LISP-encapsulated packets with the V-bit set, when the original
mapping in the EID-to-RLOC Database has version number set to a value mapping in the EID-to-RLOC Database has version number set to a value
skipping to change at page 9, line 15 skipping to change at page 9, line 21
5.2. Handling Source Map-Version number 5.2. Handling Source Map-Version number
When an ETR receives a packet, the Source Map-Version number relates When an ETR receives a packet, the Source Map-Version number relates
to the mapping for the source EID for which the ITR that sent the to the mapping for the source EID for which the ITR that sent the
packet is authoritative. If the ETR has an entry in its EID-to-RLOC packet is authoritative. If the ETR has an entry in its EID-to-RLOC
Cache for the source EID, then a check can be performed and the Cache for the source EID, then a check can be performed and the
following cases can arise: following cases can arise:
1. The packet arrives with the same Source Map-Version number stored 1. The packet arrives with the same Source Map-Version number stored
in the EID-to-RLOC Cache. This is the correct regular case. The in the EID-to-RLOC Cache. This is the correct regular case. The
ITR has in its cache an up-to-date copy of the mapping. No ITR has in its EID-to-RLOC Cache an up-to-date copy of the
further actions are needed. mapping. No further actions are needed.
2. The packet arrives with a Source Map-Version number greater 2. The packet arrives with a Source Map-Version number greater
(i.e., newer) than the one stored in the local EID-to-RLOC Cache. (i.e., newer) than the one stored in the local EID-to-RLOC Cache.
This means that ETR has in its cache a mapping that is stale and This means that ETR has in its EID-to-RLOC Cache a mapping that
needs to be updated. A Map-Request SHOULD be sent to get the new is stale and needs to be updated. A Map-Request SHOULD be sent
mapping for the source EID. This is a normal Map-Request message to get the new mapping for the source EID. This is a normal Map-
sent through the mapping system and MUST respect the Request message sent through the mapping system and MUST respect
specifications in [I-D.ietf-lisp], including rate limitation the specifications in [I-D.ietf-lisp], including rate limitation
policies. policies.
3. The packet arrives with a Source Map-Version number smaller 3. The packet arrives with a Source Map-Version number smaller
(i.e., older) than the one stored in the local EID-to-RLOC Cache. (i.e., older) than the one stored in the local EID-to-RLOC Cache.
Such a case is not valid with respect to the specifications. Such a case is not valid with respect to the specifications.
Indeed, if the mapping is already present in the EID-to-RLOC Indeed, if the mapping is already present in the EID-to-RLOC
Cache, this means that an explicit Map-Request has been sent and Cache, this means that an explicit Map-Request has been sent and
a Map-Reply has been received from an authoritative source. a Map-Reply has been received from an authoritative source.
Assuming that the mapping system is not corrupted anyhow, the Assuming that the mapping system is not corrupted anyhow, the
Map-Version in the EID-to-RLOC Cache is the correct one, while Map-Version in the EID-to-RLOC Cache is the correct one, while
skipping to change at page 15, line 43 skipping to change at page 16, line 4
ones as explained in Section 6.5 of [I-D.ietf-lisp]. A new mapping ones as explained in Section 6.5 of [I-D.ietf-lisp]. A new mapping
with a new Map-Version number will be issued, and since the old with a new Map-Version number will be issued, and since the old
locators are still valid the transition will be with no disruptions. locators are still valid the transition will be with no disruptions.
The same applies for the case a RLOC is withdrawn. There is no need The same applies for the case a RLOC is withdrawn. There is no need
to maintain holes in the list of locators, as is the case when using to maintain holes in the list of locators, as is the case when using
Locator Status Bits, for sites that are not using the RLOC that has Locator Status Bits, for sites that are not using the RLOC that has
been withdrawn the transition will be with no disruptions. been withdrawn the transition will be with no disruptions.
All of these operations, as already stated, do not need to maintain All of these operations, as already stated, do not need to maintain
any consistency among Locator Status Bits, and the way RLOC are any consistency among Locator Status Bits, and the way RLOC are
stored in the cache. stored in the EID-to-RLOC Cache.
Further, Map-Version can be used to substitute the "clock sweep" Further, Map-Version can be used to substitute the "clock sweep"
operation described in Section 6.5.1 of [I-D.ietf-lisp]. Indeed, operation described in Section 6.5.1 of [I-D.ietf-lisp]. Indeed,
every LISP site communicating to a specific LISP site that has every LISP site communicating to a specific LISP site that has
updated the mapping will be informed of the available new mapping in updated the mapping will be informed of the available new mapping in
a data-driven manner. a data-driven manner.
Note that what is proposed in the present section is just an example Note that what is proposed in the present section is just an example
and MUST NOT be considered as specifications for a lightweight LISP and MUST NOT be considered as specifications for a lightweight LISP
implementation. In case the IETF decides to undertake such a work, implementation. In case the IETF decides to undertake such a work,
skipping to change at page 17, line 44 skipping to change at page 18, line 9
It is clear, that Map-Versioning does not protect against DoS and It is clear, that Map-Versioning does not protect against DoS and
DDoS attacks, where an xTR looses processing power doing checks on DDoS attacks, where an xTR looses processing power doing checks on
the LISP header of packets sent by attackers. This is independent the LISP header of packets sent by attackers. This is independent
from Map-Versioning and is the same for Loc Status Bits. from Map-Versioning and is the same for Loc Status Bits.
11. IANA Considerations 11. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
12. Acknowledgements 12. Open Issues and Considerations
There are a number of implications of the use of Map-Versioning that
are not yet completely explored. Among these are:
o Performance of the convergence time when an EID-to-RLOC mapping
changes, i.e., how much time is needed to update mappings in the
EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs
for the EID whose mapping has been changed.
o Support to ETR synchronization. Even without Map-Versioning, LISP
([I-D.ietf-lisp]) requires ETRs to announce the same mapping for
the same EID-Prefix to a requester. The implications that a
temporary lack of synchronization may have on the traffic is yet
to be fully explored. There are two ways Map-Versioning is
helpful with respect to the synchronization problem. On the one
hand, assigning version numbers to mappings helps in debugging,
since quick checks on the consistency of the mappings on different
ETRs can be done by looking at the Map-Version number. On the
other hand, Map-Versioning can be used to control the traffic
toward ETRs that announce the latest mapping.
The authors expect that experimentation will help assess the
performance and the limitations of the Map-Versioning mechanism.
Issues and concerns about the deployment of LISP for Internet traffic
are discussed in [I-D.ietf-lisp].
13. Acknowledgements
The authors would like to thank Alia Atlas, Jesper Skriver, Pierre The authors would like to thank Alia Atlas, Jesper Skriver, Pierre
Francois, Noel Chiappa, Dino Farinacci for their comments and review. Francois, Noel Chiappa, Dino Farinacci for their comments and review.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
13. References 14. References
13.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-15 (work in progress), July 2011. draft-ietf-lisp-15 (work in progress), July 2011.
[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.
13.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",
draft-iannone-openlisp-implementation-01 (work in draft-iannone-openlisp-implementation-01 (work in
progress), July 2008. progress), July 2008.
[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-09 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
(work in progress), September 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-11 (work in progress), August 2011. draft-ietf-lisp-ms-12 (work in progress), October 2011.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-00 (work in progress), Analysis", draft-ietf-lisp-threats-00 (work in progress),
July 2011. July 2011.
Appendix A. Estimation of time before Map-Version wrap-around Appendix A. Estimation of time before Map-Version wrap-around
The present section proposes an estimation of the wrap-around time The present section proposes an estimation of the wrap-around time
for the proposed 12 bits size for the Map-Version number. Using a for the proposed 12 bits size for the Map-Version number. Using a
skipping to change at page 19, line 41 skipping to change at page 20, line 32
| 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 06 Posted October 2011.
* Added disclaimer in the Introduction about general issues
concerning LISP as requested by A. Farrel.
* Fixed sentence about legacy systems in the abstract as
requested by A. Farrel.
* Added Section 12 as requested by A. Farrel.
o Version 05 Posted October 2011. o Version 05 Posted October 2011.
* Added sentence in Section 3 on the use of Big Endian, as for * Added sentence in Section 3 on the use of Big Endian, as for
comment of P. Resnick. comment of P. Resnick.
* Extended the end of Section 4 in order to clarify that Map- * Extended the end of Section 4 in order to clarify that Map-
Version numbers are assigned to mappings by configuration and Version numbers are assigned to mappings by configuration and
not automatically generated by ETRs, as for comments of R. not automatically generated by ETRs, as for comments of R.
Sparks Sparks
skipping to change at page 21, line 36 skipping to change at page 22, line 36
* Editorial polishing of all sections. * Editorial polishing of all sections.
* Added clarifications in section "Dealing with Map-Version * Added clarifications in section "Dealing with Map-Version
numbers" for the case of the special Map-Version number 0. numbers" for the case of the special Map-Version number 0.
* Rename of draft-iannone-mapping-versioning-02.txt. * Rename of draft-iannone-mapping-versioning-02.txt.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
TU Berlin - Deutsche Telekom Laboratories AG Telekom Innovation Laboratories
Ernst-Reuter Platz 7 Ernst-Reuter Platz 7
Berlin Berlin
Germany Germany
Email: luigi@net.t-labs.tu-berlin.de Email: luigi@net.t-labs.tu-berlin.de
Damien Saucez Damien Saucez
Universite catholique de Louvain Universite catholique de Louvain
Place St. Barbe 2 Place St. Barbe 2
Louvain-la-Neuve Louvain-la-Neuve
 End of changes. 24 change blocks. 
52 lines changed or deleted 95 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/