draft-ietf-lisp-map-versioning-07.txt   draft-ietf-lisp-map-versioning-08.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: July 22, 2012 INRIA Sophia Antipolis Expires: August 17, 2012 INRIA Sophia Antipolis
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
January 19, 2012 February 14, 2012
LISP Map-Versioning LISP Map-Versioning
draft-ietf-lisp-map-versioning-07.txt draft-ietf-lisp-map-versioning-08.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 July 22, 2012. This Internet-Draft will expire on August 17, 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 17, line 19 skipping to change at page 17, line 19
12. Open Issues and Considerations 12. Open Issues and Considerations
There are a number of implications of the use of Map-Versioning that There are a number of implications of the use of Map-Versioning that
are not yet completely explored. Among these are: are not yet completely explored. Among these are:
o Performance of the convergence time when an EID-to-RLOC mapping 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 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 EID-to-RLOC Cache of the ITRs currently sending traffic to ETRs
for the EID whose mapping has been changed. for the EID whose mapping has been changed.
o Support to ETR synchronization.The implications that a temporary o Support to ETR synchronization. The implications that a temporary
lack of synchronization may have on the traffic is yet to be fully lack of synchronization may have on the traffic is yet to be fully
explored. Details on how to keep synchronization are presented in explored. Details on how to keep synchronization are presented in
Section 6.6 of [I-D.ietf-lisp]. Section 12.1 hereafter discusses Section 6.6 of [I-D.ietf-lisp]. Section 12.1 hereafter discusses
the issue in further details with respect to the Map-Versioning the issue in further details with respect to the Map-Versioning
mechanism. mechanism.
The authors expect that experimentation will help assess the The authors expect that experimentation will help assess the
performance and the limitations of the Map-Versioning mechanism. performance and the limitations of the Map-Versioning mechanism.
Issues and concerns about the deployment of LISP for Internet traffic Issues and concerns about the deployment of LISP for Internet traffic
are discussed in [I-D.ietf-lisp]. are discussed in [I-D.ietf-lisp].
skipping to change at page 18, line 7 skipping to change at page 18, line 7
There are two ways Map-Versioning is helpful with respect to the There are two ways Map-Versioning is helpful with respect to the
synchronization problem. On the one hand, assigning version numbers synchronization problem. On the one hand, assigning version numbers
to mappings helps in debugging, since quick checks on the consistency 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- 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 Version number. On the other hand, Map-Versioning can be used to
control the traffic toward ETRs that announce the latest mapping. control the traffic toward ETRs that announce the latest mapping.
As an example, let's consider the topology of Figure 4 where ITR A.1 As an example, let's consider the topology of Figure 4 where ITR A.1
of domain A is sending unidirectional traffic to the domain B, while of domain A is sending unidirectional traffic to the domain B, while
A.2 of domain A exchange bidirectional traffic with domain B. In A.2 of domain A exchanges bidirectional traffic with domain B. In
particular, ITR A.2 send traffic to ETR B and ETR A.2 receives particular, ITR A.2 sends traffic to ETR B and ETR A.2 receives
traffic from ITR B. traffic from ITR B.
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Domain A | | Domain B | | Domain A | | Domain B |
| +---------+ | | | +---------+ | |
| | ITR A.1 |--- | | | | ITR A.1 |--- | |
| +---------+ \ +---------+ | | +---------+ \ +---------+ |
| | ------->| ETR B | | | | ------->| ETR B | |
| | ------->| | | | | ------->| | |
| +---------+ / | | | | +---------+ / | | |
skipping to change at page 18, line 33 skipping to change at page 18, line 33
| | | | | | | |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 4 Figure 4
Obviously in the case of Map-Versioning both ITR A.1 and ITR A.2 of Obviously in the case of Map-Versioning both ITR A.1 and ITR A.2 of
domain A must use the same value otherwise the ETR of domain B will domain A must use the same value otherwise the ETR of domain B will
start to send Map-Requests. start to send Map-Requests.
The same problem can, however, arise without Map-Versioning. For The same problem can, however, arise without Map-Versioning. For
instance, if the two ITRs of domain A send different Loc Status Bits. instance, if the two ITRs of domain A send different Locator Status
In this case either the traffic is disrupted, if the ETR B trusts the Bits. In this case either the traffic is disrupted, if the ETR B
Locator Status Bits, or if ETR B does not trusts the Locator Status trusts the Locator Status Bits, or if ETR B does not trust the
Bits it will start sending Map-Requests to confirm the each change in Locator Status Bits it will start sending Map-Requests to confirm the
the reachability. each change in the reachability.
So far, LISP does not provide any specific synchronization mechanism, So far, LISP does not provide any specific synchronization mechanism,
but assumes that synchronization is provided by configuring the but assumes that synchronization is provided by configuring the
different xTRs consistently (see Section 6.6 in [I-D.ietf-lisp]). different xTRs consistently (see Section 6.6 in [I-D.ietf-lisp]).
The same applies for Map-Versioning. If in the future any The same applies for Map-Versioning. If in the future any
synchronization mechanism is provided, Map-Versioning will take synchronization mechanism is provided, Map-Versioning will take
advantage of it automatically since it is included in the Record advantage of it automatically since it is included in the Record
format, as described in Section 7. format, as described in Section 7.
13. Acknowledgements 13. Acknowledgements
skipping to change at page 19, line 15 skipping to change at page 19, line 15
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).
14. References 14. References
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-19 (work in progress), January 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-02 (work in progress), draft-ietf-lisp-interworking-03 (work in progress),
June 2011. 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",
draft-iannone-openlisp-implementation-01 (work in draft-iannone-openlisp-implementation-01 (work in
skipping to change at page 20, line 4 skipping to change at page 20, line 4
draft-ietf-lisp-ms-15 (work in progress), January 2012. draft-ietf-lisp-ms-15 (work in progress), January 2012.
[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 12 bits size of the Map-Version number.
granularity of seconds and assuming as worst-case that a new version
is issued each second, it takes slightly more than 1 hour before the Using a granularity of seconds and assuming as worst-case that a new
version wraps around. Note that the granularity of seconds is in version is issued each second, it takes slightly more than 1 hour
line with the rate limitation policy for Map-Request messages, as before the version wraps around. Note that the granularity of
proposed in the LISP main specifications ([I-D.ietf-lisp]). seconds is in line with the rate limitation policy for Map-Request
messages, as proposed in the LISP main specifications
([I-D.ietf-lisp]).
Alternatively a granularity of minutes can also be used, as for the Alternatively a granularity of minutes can also be used, as for the
TTL of the Map-Reply ([I-D.ietf-lisp]). In this case the worst TTL of the Map-Reply ([I-D.ietf-lisp]). In this case the worst
scenario is when a new version is issued every minute, leading to a scenario is when a new version is issued every minute, leading to a
much longer time before wrap-around. In particular, when using 12 much longer time before wrap-around. In particular, when using 12
bits, the wrap-around time is almost 3 days. bits, the wrap-around time is almost 3 days.
For general information, hereafter there is a table with a rough For general information, hereafter there is a table with a rough
estimation of the time before wrap-around in the worst-case scenario, estimation of the time before wrap-around in the worst-case scenario,
considering different sizes (bits length) of the Map-Version number considering different sizes (bits length) of the Map-Version number
and different time granularity. and different time granularity.
Since even in the case of high mapping change rate (1 per second) the
wrap around time using 12 bits is far larger then any reasonable
Round-Trip-Time (RTT), there is no risk of race conditions.
+---------------+--------------------------------------------+ +---------------+--------------------------------------------+
|Version Number | Time before wrap around | |Version Number | Time before wrap around |
| Size (bits) +---------------------+----------------------+ | Size (bits) +---------------------+----------------------+
| |Granularity: Minutes | Granularity: Seconds | | |Granularity: Minutes | Granularity: Seconds |
| | (mapping changes | (mapping changes | | | (mapping changes | (mapping changes |
| | every 1 minute) | every 1 second) | | | every 1 minute) | every 1 second) |
+-------------------------------------+----------------------+ +-------------------------------------+----------------------+
| 32 | 8171 Years | 136 Years | | 32 | 8171 Years | 136 Years |
| 30 | 2042 Years | 34 Years | | 30 | 2042 Years | 34 Years |
| 24 | 31 Years | 194 Days | | 24 | 31 Years | 194 Days |
| 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 08 Posted Ferbruary 2012.
* 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
R. Bonica. R. Bonica.
* Added cross-reference to Section 6.6 in [I-D.ietf-lisp] as * Added cross-reference to Section 6.6 in [I-D.ietf-lisp] as
 End of changes. 12 change blocks. 
21 lines changed or deleted 31 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/