draft-ietf-lisp-map-versioning-06.txt   draft-ietf-lisp-map-versioning-07.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: May 3, 2012 O. Bonaventure Expires: July 22, 2012 INRIA Sophia Antipolis
O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
October 31, 2011 January 19, 2012
LISP Map-Versioning LISP Map-Versioning
draft-ietf-lisp-map-versioning-06.txt draft-ietf-lisp-map-versioning-07.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 44 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 May 3, 2012. This Internet-Draft will expire on July 22, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 26 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . 10 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 10
7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 11
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. Map-Versioning and unidirectional traffic . . . . . . . . 12
8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12 8.2. Map-Versioning and interworking . . . . . . . . . . . . . 12
8.3. Map-Versioning and interworking . . . . . . . . . . . . . 13 8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12
8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13
8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14 8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13
8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14 8.3. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 14
8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15 8.4. Map-Version for lightweight LISP implementation . . . . . 14
8.5. Map-Version for lightweight LISP implementation . . . . . 15 9. Incremental deployment and implementation status . . . . . . . 15
9. Incremental deployment and implementation status . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10.1. Map-Versioning against traffic disruption . . . . . . . . 15
10.1. Map-Versioning against traffic disruption . . . . . . . . 16 10.2. Map-Versioning against reachability information DoS . . . 16
10.2. Map-Versioning against reachability information DoS . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. Open Issues and Considerations . . . . . . . . . . . . . . . . 17
12. Open Issues and Considerations . . . . . . . . . . . . . . . . 18 12.1. Lack of Synchronization among ETRs . . . . . . . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Estimation of time before Map-Version wrap-around . . 19 Appendix A. Estimation of time before Map-Version wrap-around . . 19
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 20 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 (Endsystem ID to Routing
([I-D.ietf-lisp]) context to perform packet encapsulation. The LOCator) mappings used in the LISP (Locator/Id Separation Protocol
mechanism is totally transparent to xTRs not supporting such [I-D.ietf-lisp]) context to perform packet encapsulation. The
functionality. It is not meant to replace any existing LISP mechanism is totally transparent to xTRs (Ingress and Egress Tunnel
mechanism, but rather to extend them providing new functionalities. Routers) not supporting such functionality. It is not meant to
If for any unforseen reason a normative conflict between the present replace any existing LISP mechanism, but rather to extend them
document and the LISP main specifications is found, the latter providing new functionalities. If for any unforseen reason a
([I-D.ietf-lisp]) has precedence on the present document. normative conflict between the present document and the LISP main
specifications is found, the latter ([I-D.ietf-lisp]) has precedence
on the present document.
The basic mechanism is to associate a Map-Version number to each LISP The basic mechanism is to associate a Map-Version number to each LISP
EID-to-RLOC mapping and transport such a version number in the LISP- EID-to-RLOC mapping and transport such a version number in the LISP-
specific header. When a mapping changes, a new version number is specific header. When a mapping changes, a new version number is
assigned to the updated mapping. A change in an EID-to-RLOC mapping assigned to the updated mapping. A change in an EID-to-RLOC mapping
can be a change in the RLOCs set, by adding or removing one or more can be a change in the RLOCs set, by adding or removing one or more
RLOCs, but it can also be a change in the priority or weight of one RLOCs, but it can also be a change in the priority or weight of one
or more RLOCs. or more RLOCs.
When Map-Versioning is used, LISP-encapsulated data packets contain When Map-Versioning is used, LISP-encapsulated data packets contain
the version number of the two mappings used to select the RLOCs in the version number of the two mappings used to select the RLOCs in
the outer header (i.e., both source and destination). These version the outer header (i.e., both source and destination). These version
numbers are encoded in the 24 low-order bits of the first longword of numbers are encoded in the 24 low-order bits of the first longword of
the LISP header and indicated by a specific bit in the flags (first 8 the LISP header and indicated by a specific bit in the flags (first 8
high-order bits of the first longword of the LISP header). Note that high-order bits of the first longword of the LISP header). Note that
not all packets need to carry version numbers. not all packets need to carry version numbers.
When an ITR encapsulates a data packet, with a LISP header containing When an ITR (Ingress Tunnel Router) encapsulates a data packet, with
the Map-Version numbers, it puts in the LISP-specific header two a LISP header containing the Map-Version numbers, it puts in the
version numbers: LISP-specific header two version numbers:
1. The version number assigned to the mapping (contained in the EID- 1. The version number assigned to the mapping (contained in the EID-
to-RLOC Database) used to select the source RLOC. to-RLOC Database) used to select the source RLOC.
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 (Egress Tunnel Router) receiving the packet to know if the ITR has
that any ETR at the destination EID site has provided to the ITR in a the latest version number that any ETR at the destination EID site
Map-Reply. If it is not the case the ETR can send to the ITR a Map- has provided to the ITR in a Map-Reply. If it is not the case the
Request containing the updated mapping or soliciting a Map-Request ETR can send to the ITR a Map-Request containing the updated mapping
from the ITR (both cases are already defined in [I-D.ietf-lisp]). In or soliciting a Map-Request from the ITR (both cases are already
this way the ITR can update its EID-to-RLOC Cache. On the other defined in [I-D.ietf-lisp]). In this way the ITR can update its EID-
hand, it enables an ETR receiving such a packet to know if it has in to-RLOC Cache. On the other hand, it enables an ETR receiving such a
its EID-to-RLOC Cache the latest mapping for the source EID (in case packet to know if it has in its EID-to-RLOC Cache the latest mapping
of bidirectional traffic). If it is not the case a Map-Request can for the source EID (in case of bidirectional traffic). If it is not
be sent. the case a Map-Request can be sent.
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]. Section 12 provides additional are discussed in [I-D.ietf-lisp]. Section 12 provides additional
issues and concerns raised by this document. issues and concerns raised by this document. In particular,
Section 12.1 provides details about the ETRs' synchronization issue
in the context of Map-Versioning.
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 11, line 42 skipping to change at page 12, line 5
This packet format works perfectly with xTRs that do not support Map- This packet format works perfectly with xTRs that do not support Map-
Versioning, since they can simply ignore those bits. Versioning, since they can simply ignore those bits.
8. Benefits and case studies for Map-Versioning 8. Benefits and case studies for Map-Versioning
In the following sections we provide more discussion on various In the following sections we provide more discussion on various
aspects and use of the Map-Versioning. Security observations are aspects and use of the Map-Versioning. Security observations are
instead grouped in Section 10. instead grouped in Section 10.
8.1. Synchronization of different xTRs 8.1. Map-Versioning and unidirectional traffic
Map-Versioning does not require additional synchronization mechanism
compared to the normal functioning of LISP without Map-Versioning.
Clearly all the ETRs have to reply with the same Map-Version number,
otherwise there can be an inconsistency that creates additional
control traffic, instabilities, traffic disruptions. It is the same
without Map-Versioning, with ETRs that have to reply with the same
mapping, otherwise the same problems can arise.
As an example, let's consider the topology of Figure 1 where ITR A.1
of domain A is sending unidirectional traffic to the domain B, while
A.2 of domain A exchange bidirectional traffic with domain B. In
particular, ITR A.2 send traffic to ETR B and ETR A.2 receives
traffic from ITR B.
+-----------------+ +-----------------+
| Domain A | | Domain B |
| +---------+ | |
| | ITR A.1 |--- | |
| +---------+ \ +---------+ |
| | ------->| ETR B | |
| | ------->| | |
| +---------+ / | | |
| | ITR A.2 |--- -----| ITR B | |
| | | / +---------+ |
| | ETR A.2 |<----- | |
| +---------+ | |
| | | |
+-----------------+ +-----------------+
Figure 1
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
start to send Map-Requests.
The same problem can, however, arise without Map-Versioning. For
instance, if the two ITRs of domain A send different Loc Status Bits.
In this case either the traffic is disrupted, if the ETR B trusts the
Locator Status Bits, or if ETR B does not trusts the Locator Status
Bits it will start sending Map-Requests to confirm the each change in
the reachability.
So far, LISP does not provide any specific synchronization mechanism,
but assumes that synchronization is provided by configuring the
different xTRs consistently. The same applies for Map-Versioning.
If in the future any synchronization mechanism is provided, Map-
Versioning will take advantage of it automatically since it is
included in the Record format, as described in Section 7.
8.2. Map-Versioning and unidirectional traffic
When using Map-Versioning the LISP specific header carries two Map- When using Map-Versioning the LISP specific header carries two Map-
Version numbers, for both source and destination mappings. This can Version numbers, for both source and destination mappings. This can
raise the question on what will happen in the case of unidirectional raise the question on what will happen in the case of unidirectional
flows, like for instance in the case presented in Figure 2, since flows, like for instance in the case presented in Figure 1, since
LISP specification do not mandate for ETR to have a mapping for the LISP specification do not mandate for ETR to have a mapping for the
source EID. source EID.
+-----------------+ +-----------------+ +-----------------+ +-----------------+
| Domain A | | Domain B | | Domain A | | Domain B |
| +---------+ +---------+ | | +---------+ +---------+ |
| | ITR A |----------->| ETR B | | | | ITR A |----------->| ETR B | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | |
+-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 2 Figure 1
For what concerns the ITR, it is able to put both source and For what concerns the ITR, it is able to put both source and
destination version number in the LISP header since the Source Map- destination version number in the LISP header since the Source Map-
Version number is in ITR's database, while the Destination Map- Version number is in ITR's database, while the Destination Map-
Version number is in ITR's cache. Version number is in ITR's cache.
For what concerns the ETR, it simply checks only the Destination Map- For what concerns the ETR, it simply checks only the Destination Map-
Version number in the same way as described in Section 5, ignoring Version number in the same way as described in Section 5, ignoring
the Source Map-Version number. the Source Map-Version number.
8.3. Map-Versioning and interworking 8.2. Map-Versioning and interworking
Map-Versioning is compatible with the LISP interworking between LISP Map-Versioning is compatible with the LISP interworking between LISP
and non-LISP sites as defined in [I-D.ietf-lisp-interworking]. LISP and non-LISP sites as defined in [I-D.ietf-lisp-interworking]. LISP
interworking defines three techniques to make LISP sites and non-LISP interworking defines three techniques to make LISP sites and non-LISP
sites, namely Proxy-ITR, LISP-NAT, and Proxy-ETR. Hereafter it is sites, namely Proxy-ITR, LISP-NAT, and Proxy-ETR. Hereafter it is
described how Map-Versioning relates to these three mechanisms. described how Map-Versioning relates to these three mechanisms.
8.3.1. Map-Versioning and Proxy-ITRs 8.2.1. Map-Versioning and Proxy-ITRs
The purpose of the Proxy-ITR (PITR) is to encapsulate traffic The purpose of the Proxy-ITR (PITR) is to encapsulate traffic
originating in a non-LISP site in order to deliver the packet to one originating in a non-LISP site in order to deliver the packet to one
of the ETRs of the LISP site (cf. Figure 3). This case is very of the ETRs of the LISP site (cf. Figure 2). This case is very
similar to the unidirectional traffic case described in Section 8.2, similar to the unidirectional traffic case described in Section 8.1,
hence similar rules apply. hence similar rules apply.
+----------+ +-------------+ +----------+ +-------------+
| LISP | | non-LISP | | LISP | | non-LISP |
| Domain A | | Domain B | | Domain A | | Domain B |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | ETR A |<-------| Proxy ITR |<-------| | | | ETR A |<-------| Proxy ITR |<-------| |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | | | | | | |
+----------+ +-------------+ +----------+ +-------------+
Figure 3 Figure 2
The main difference is that a Proxy-ITR does not have any mapping, The main difference is that a Proxy-ITR does not have any mapping,
since it just encapsulate packets arriving from non-LISP site, thus since it just encapsulate packets arriving from non-LISP site, thus
cannot provide a Source Map-Version. In this case, the proxy-ITR cannot provide a Source Map-Version. In this case, the proxy-ITR
will just put the Null Map-Version value as Source Map-Version will just put the Null Map-Version value as Source Map-Version
number, while the receiving ETR will ignore the field. number, while the receiving ETR will ignore the field.
With this setup the LISP Domain A is able to check whether or not the With this setup the LISP Domain A is able to check whether or not the
PITR is using the latest mapping. If this is not the case the PITR is using the latest mapping. If this is not the case the
mapping for LISP Domain A on the PITR can be updated using one of the mapping for LISP Domain A on the PITR can be updated using one of the
mechanisms defined in [I-D.ietf-lisp] and mechanisms defined in [I-D.ietf-lisp] and
[I-D.ietf-lisp-interworking]. [I-D.ietf-lisp-interworking].
8.3.2. Map-Versioning and LISP-NAT 8.2.2. Map-Versioning and LISP-NAT
The LISP-NAT mechanism is based on address translation from non- The LISP-NAT mechanism is based on address translation from non-
routable EIDs to routable EIDs and does not involve any form of routable EIDs to routable EIDs and does not involve any form of
encapsulation. As such Map-Versioning does not apply in this case. encapsulation. As such Map-Versioning does not apply in this case.
8.3.3. Map-Versioning and Proxy-ETRs 8.2.3. Map-Versioning and Proxy-ETRs
The purpose of the Proxy-ETR (PETR) is to decapsulate traffic The purpose of the Proxy-ETR (PETR) is to decapsulate traffic
originating in a LISP site in order to deliver the packet to the non- originating in a LISP site in order to deliver the packet to the non-
LISP site (cf. Figure 4). One of the main reasons of deploy PETRs is LISP site (cf. Figure 3). One of the main reasons of deploy PETRs is
to bypass uRPF (Unicast Reverse Path Forwarding) checks on the to bypass uRPF (Unicast Reverse Path Forwarding) checks on the
provider edge. provider edge.
+----------+ +-------------+ +----------+ +-------------+
| LISP | | non-LISP | | LISP | | non-LISP |
| Domain A | | Domain B | | Domain A | | Domain B |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | ITR A |------->| Proxy ETR |------->| | | | ITR A |------->| Proxy ETR |------->| |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | | | | | | |
+----------+ +-------------+ +----------+ +-------------+
Figure 4 Figure 3
A Proxy-ETR does not have any mapping, since it just decapsulates A Proxy-ETR does not have any mapping, since it just decapsulates
packets arriving from LISP site. In this case, the ITR will just put packets arriving from LISP site. In this case, the ITR will just put
the Null Map-Version value as Destination Map-Version number, while the Null Map-Version value as Destination Map-Version number, while
the receiving Proxy-ETR will ignore the field. the receiving Proxy-ETR will ignore the field.
With this setup the Proxy-ETR is able to check whether or not the With this setup the Proxy-ETR is able to check whether or not the
mapping has changed. If this is the case the mapping for LISP Domain mapping has changed. If this is the case the mapping for LISP Domain
A on the PETR can be updated using one of the mechanisms defined in A on the PETR can be updated using one of the mechanisms defined in
[I-D.ietf-lisp] and [I-D.ietf-lisp-interworking]. [I-D.ietf-lisp] and [I-D.ietf-lisp-interworking].
8.4. RLOC shutdown/withdraw 8.3. RLOC shutdown/withdraw
Map-Versioning can be even used to perform a graceful shutdown or Map-Versioning can be even used to perform a graceful shutdown or
withdraw of a specific RLOC. This is achieved by simply issuing a withdraw of a specific RLOC. This is achieved by simply issuing a
new mapping, with an updated Map-Version number, where the specific new mapping, with an updated Map-Version number, where the specific
RLOC to be shut down is withdrawn or announced as unreachable (R bit RLOC to be shut down is withdrawn or announced as unreachable (R bit
in the Map Record, see [I-D.ietf-lisp]), but without actually turning in the Map Record, see [I-D.ietf-lisp]), but without actually turning
it off. it off.
Once no more traffic is received by the RLOC, it can be shut down Once no more traffic is received by the RLOC, it can be shut down
gracefully, because at least all sites actively using the mapping gracefully, because at least all sites actively using the mapping
have updated it. have updated it.
It should be pointed out that for frequent up/down changes such a It should be pointed out that for frequent up/down changes such a
mechanism should not be used since this can generate excessive load mechanism should not be used since this can generate excessive load
on the Mapping System. on the Mapping System.
8.5. Map-Version for lightweight LISP implementation 8.4. Map-Version for lightweight LISP implementation
The use of Map-Versioning can help in developing a lightweight The use of Map-Versioning can help in developing a lightweight
implementation of LISP. This comes with the price of not supporting implementation of LISP. This comes with the price of not supporting
Loc-Status-Bit, which are useful in some contexts. Loc-Status-Bit, which are useful in some contexts.
In the current LISP specifications the set of RLOCs must always be In the current LISP specifications the set of RLOCs must always be
maintained ordered and consistent with the content of the Loc Status maintained ordered and consistent with the content of the Loc Status
Bits (see section 6.5 of [I-D.ietf-lisp]). With Map-Versioning such Bits (see section 6.5 of [I-D.ietf-lisp]). With Map-Versioning such
type of mechanisms can be avoided. When a new RLOC is added to a type of mechanisms can be avoided. When a new RLOC is added to a
mapping, it is not necessary to "append" new locators to the existing mapping, it is not necessary to "append" new locators to the existing
skipping to change at page 18, 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. Even without Map-Versioning, LISP o Support to ETR synchronization.The implications that a temporary
([I-D.ietf-lisp]) requires ETRs to announce the same mapping for lack of synchronization may have on the traffic is yet to be fully
the same EID-Prefix to a requester. The implications that a explored. Details on how to keep synchronization are presented in
temporary lack of synchronization may have on the traffic is yet Section 6.6 of [I-D.ietf-lisp]. Section 12.1 hereafter discusses
to be fully explored. There are two ways Map-Versioning is the issue in further details with respect to the Map-Versioning
helpful with respect to the synchronization problem. On the one mechanism.
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 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].
12.1. Lack of Synchronization among ETRs
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.
Map-Versioning does not require additional synchronization mechanism
compared to the normal functioning of LISP without Map-Versioning.
Clearly all the ETRs have to reply with the same Map-Version number,
otherwise there can be an inconsistency that creates additional
control traffic, instabilities, traffic disruptions. It is the same
without Map-Versioning, with ETRs that have to reply with the same
mapping, otherwise the same problems can arise.
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.
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
A.2 of domain A exchange bidirectional traffic with domain B. In
particular, ITR A.2 send traffic to ETR B and ETR A.2 receives
traffic from ITR B.
+-----------------+ +-----------------+
| Domain A | | Domain B |
| +---------+ | |
| | ITR A.1 |--- | |
| +---------+ \ +---------+ |
| | ------->| ETR B | |
| | ------->| | |
| +---------+ / | | |
| | ITR A.2 |--- -----| ITR B | |
| | | / +---------+ |
| | ETR A.2 |<----- | |
| +---------+ | |
| | | |
+-----------------+ +-----------------+
Figure 4
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
start to send Map-Requests.
The same problem can, however, arise without Map-Versioning. For
instance, if the two ITRs of domain A send different Loc Status Bits.
In this case either the traffic is disrupted, if the ETR B trusts the
Locator Status Bits, or if ETR B does not trusts the Locator Status
Bits it will start sending Map-Requests to confirm the each change in
the reachability.
So far, LISP does not provide any specific synchronization mechanism,
but assumes that synchronization is provided by configuring the
different xTRs consistently (see Section 6.6 in [I-D.ietf-lisp]).
The same applies for Map-Versioning. If in the future any
synchronization mechanism is provided, Map-Versioning will take
advantage of it automatically since it is included in the Record
format, as described in Section 7.
13. Acknowledgements 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).
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-15 (work in progress), July 2011. draft-ietf-lisp-19 (work in progress), January 2012.
[I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02 (work in progress),
June 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.
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
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-10
(work in progress), September 2011. (work in progress), December 2011.
[I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02 (work in progress),
June 2011.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server Interface", Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-12 (work in progress), October 2011. 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 proposed 12 bits size for the Map-Version number. Using a
skipping to change at page 20, line 32 skipping to change at page 20, line 42
| 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 07 Posted January 2012.
* Moved Subsection 8.1 in Section 12 as requested by R. Bonica.
* Added explicit reference to the discussion about ETR
synchronization at the end of the Introduction, as requested by
R. Bonica.
* Added cross-reference to Section 6.6 in [I-D.ietf-lisp] as
requested by R. Bonica.
* Moved [I-D.ietf-lisp-interworking] as normative reference as
requested by R. Droms.
* Added long version of all acronyms in the Introduction as
requested by S. Bryant.
o Version 06 Posted October 2011. o Version 06 Posted October 2011.
* Added disclaimer in the Introduction about general issues * Added disclaimer in the Introduction about general issues
concerning LISP as requested by A. Farrel. concerning LISP as requested by A. Farrel.
* Fixed sentence about legacy systems in the abstract as * Fixed sentence about legacy systems in the abstract as
requested by A. Farrel. requested by A. Farrel.
* Added Section 12 as requested by A. Farrel. * Added Section 12 as requested by A. Farrel.
skipping to change at page 21, line 33 skipping to change at page 22, line 14
* Fixed several typos pointed out by Stephen Farrell. * Fixed several typos pointed out by Stephen Farrell.
o Version 03 Posted September 2011. o Version 03 Posted September 2011.
* Added reference in Section 7 toward the main lisp documents * Added reference in Section 7 toward the main lisp documents
specifying the section, as requested by Jari Arkko. specifying the section, as requested by Jari Arkko.
* Fixed all typos and editorial issues pointed out by Jari Arkko. * Fixed all typos and editorial issues pointed out by Jari Arkko.
* Added clarification in Section 8.4 as requested by Jari Arkko. * Added clarification in Section 8.3 as requested by Jari Arkko.
* Extentend all acronyms in the abstract as requested by Jari * Extentend all acronyms in the abstract as requested by Jari
Arkko. Arkko.
* Clarified silent drop polocy in Section 5.2 as requested by * Clarified silent drop polocy in Section 5.2 as requested by
both Richard Barnes and Jari Arkko. both Richard Barnes and Jari Arkko.
* Fixed typos pointed out by Richard Barnes. * Fixed typos pointed out by Richard Barnes.
o Version 02 Posted July 2011. o Version 02 Posted July 2011.
* Added text in Section 5 about ETR synchronization, as suggested * Added text in Section 5 about ETR synchronization, as suggested
by Alia Atlas. by Alia Atlas.
* Modified text in Section 8.5 concerning lightweight LISP * Modified text in Section 8.4 concerning lightweight LISP
implementation, as suggested by Alia Atlas. implementation, as suggested by Alia Atlas.
* Deleted text concerning old versions of [I-D.ietf-lisp-ms] and * Deleted text concerning old versions of [I-D.ietf-lisp-ms] and
[I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas. [I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas.
* Fixed section 4.1 to be less restrictive, as suggested by * Fixed section 4.1 to be less restrictive, as suggested by
Jesper Skriver. Jesper Skriver.
o Version 01 Posted March 2011. o Version 01 Posted March 2011.
skipping to change at page 22, line 44 skipping to change at page 23, line 27
Luigi Iannone Luigi Iannone
Telekom Innovation Laboratories 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 INRIA Sophia Antipolis
Place St. Barbe 2 2004 route des Lucioles - BP 93
Louvain-la-Neuve Sophia Antipolis
Belgium France
Email: damien.saucez@inria.fr
Email: damien.saucez@uclouvain.be
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Place St. Barbe 2 Place St. Barbe 2
Louvain-la-Neuve Louvain-la-Neuve
Belgium Belgium
Email: olivier.bonaventure@uclouvain.be Email: olivier.bonaventure@uclouvain.be
 End of changes. 36 change blocks. 
138 lines changed or deleted 169 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/