draft-ietf-lisp-6834bis-06.txt   draft-ietf-lisp-6834bis-07.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Telecom ParisTech Internet-Draft Huawei Technologies France S.A.S.U
Obsoletes: 6834 (if approved) D. Saucez Obsoletes: 6834 (if approved) D. Saucez
Intended status: Standards Track Intended status: Standards Track INRIA
Expires: August 16, 2020 O. Bonaventure Expires: April 18, 2021 O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
February 13, 2020 October 15, 2020
Locator/ID Separation Protocol (LISP) Map-Versioning Locator/ID Separation Protocol (LISP) Map-Versioning
draft-ietf-lisp-6834bis-06 draft-ietf-lisp-6834bis-07
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 the associating a version number to EID-to-RLOC mappings and the
transport of such a version number in the LISP-specific header of transport of such a version number in the LISP-specific header of
LISP-encapsulated packets. LISP Map-Versioning is particularly LISP-encapsulated packets. LISP Map-Versioning is particularly
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2020. This Internet-Draft will expire on April 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 46 skipping to change at page 2, line 46
8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12 8.2.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 12
8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13 8.2.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13
8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13 8.2.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13
8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13 8.3. RLOC Shutdown/Withdraw . . . . . . . . . . . . . . . . . 13
8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14 8.4. Map-Version Additional Use Cases . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Map-Versioning against Traffic Disruption . . . . . . . . 14 9.1. Map-Versioning against Traffic Disruption . . . . . . . . 14
9.2. Map-Versioning against Reachability Information DoS . . . 15 9.2. Map-Versioning against Reachability Information DoS . . . 15
10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 (Endpoint ID to Routing information on changes in the EID-to-RLOC (Endpoint ID to Routing
Locator) mappings used in the LISP (Locator/ID Separation Protocol Locator) mappings used in the LISP (Locator/ID Separation Protocol
[I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis]) context to [I-D.ietf-lisp-rfc6830bis][I-D.ietf-lisp-rfc6833bis]) context to
perform packet encapsulation. The mechanism is totally transparent perform packet encapsulation. The mechanism is totally transparent
to xTRs (Ingress and Egress Tunnel Routers) not supporting or not to xTRs (Ingress and Egress Tunnel Routers) not supporting or not
skipping to change at page 4, line 21 skipping to change at page 4, line 21
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definitions of Terms 3. Definitions of Terms
This document uses terms already defined in the main LISP This document uses terms already defined in the main LISP
specification (, [I-D.ietf-lisp-rfc6830bis] specification ([I-D.ietf-lisp-rfc6830bis],
[I-D.ietf-lisp-rfc6833bis]). Here, we define the terms that are [I-D.ietf-lisp-rfc6833bis]). Here, we define the terms that are
specific to the Map-Versioning mechanism. Throughout the whole specific to the Map-Versioning mechanism. Throughout the whole
document, Big Endian bit ordering is used. document, Big Endian bit ordering is used.
Map-Version number: An unsigned 12-bit integer is assigned to an Map-Version number: An unsigned 12-bit integer is assigned to an
EID-to-RLOC mapping, not including the value 0 (0x000). EID-to-RLOC mapping, not including the value 0 (0x000).
Null Map-Version: The 12-bit null value of 0 (0x000) is not used as Null Map-Version: The 12-bit null value of 0 (0x000) is not used as
a Map-Version number. It is used to signal that no Map-Version a Map-Version number. It is used to signal that no Map-Version
number is assigned to the EID-to-RLOC mapping. number is assigned to the EID-to-RLOC mapping.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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
EID-to-RLOC 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 relates to the mapping for the destination EID for which the ETR is
an RLOC. This mapping is part of the ETR EID-to-RLOC Database. an RLOC. This mapping is part of the ETR EID-to-RLOC Database.
Since the ETR is authoritative for the mapping, it has the correct Since the ETR is authoritative for the mapping, it has the correct
and up-to-date Destination Map-Version number. A check on this and up to-date Destination Map-Version number. A check on this
version number can be done, where the following cases can arise: version number can be done, where the following cases can arise:
1. The packet arrives with the same Destination Map-Version number 1. The packet arrives with the same Destination Map-Version number
stored in the EID-to-RLOC Database. This is the regular case. stored in the EID-to-RLOC Database. This is the regular case.
The ITR sending the packet has in its EID-to-RLOC Cache an up-to- The ITR sending the packet has in its EID-to-RLOC Cache an up-to-
date mapping. No further actions are needed. date mapping. No further actions are needed.
2. The packet arrives with a Destination Map-Version number greater 2. The packet arrives with a Destination Map-Version number greater
(i.e., newer) than the one stored in the EID-to-RLOC Database. (i.e., newer) than the one stored in the EID-to-RLOC Database.
Since the ETR is authoritative on the mapping, meaning that the Since the ETR is authoritative on the mapping, meaning that the
skipping to change at page 10, line 32 skipping to change at page 10, line 32
by the ITR to select the RLOC present in the "Source Routing by the ITR to select the RLOC present in the "Source Routing
Locator" field. Section 5.2 describes how to set this value on Locator" field. Section 5.2 describes how to set this value on
transmission and handle it on reception. transmission and handle it on reception.
Destination Map-Version number (12 bits): Map-Version of the mapping Destination Map-Version number (12 bits): Map-Version of the mapping
used by the ITR to select the RLOC present in the "Destination used by the ITR to select the RLOC present in the "Destination
Routing Locator" field. Section 5.1 describes how to set this Routing Locator" field. Section 5.1 describes how to set this
value on transmission and handle it on reception. value on transmission and handle it on reception.
Not all of the LISP-encapsulated packets need to carry version Not all of the LISP-encapsulated packets need to carry version
numbers. When Map-Version numbers are carried in these packets, the numbers. When Map-Version numbers are carried, the V-bit MUST be set
V-bit MUST be set to 1. All permissible combinations of the flags to 1. All permissible combinations of the flags when the V-bit is
when the V-bit is set to 1 are described in set to 1 are described in [I-D.ietf-lisp-rfc6830bis].
[I-D.ietf-lisp-rfc6830bis].
7. Map Record and Map-Version 7. Map Record and Map-Version
To accommodate the proposed mechanism, the Map Records that are To accommodate the proposed mechanism, the Map Records that are
transported in Map-Request/Map-Reply/Map-Register messages need to transported in Map-Request/Map-Reply/Map-Register messages need to
carry the Map-Version number as well. For this purpose, the 12 bits carry the Map-Version number as well. For this purpose, the 12 bits
before the EID-AFI field in the Record that describes a mapping are before the EID-AFI field in the Record that describes a mapping are
used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example. used (see [I-D.ietf-lisp-rfc6833bis] and reported here as an example.
0 1 2 3 0 1 2 3
skipping to change at page 16, line 9 skipping to change at page 16, line 9
10. Deployment Considerations 10. Deployment Considerations
Even without Map-Versioning, LISP requires ETRs to announce the same Even without Map-Versioning, LISP requires ETRs to announce the same
mapping for the same EID-Prefix to a requester. Map-Versioning does mapping for the same EID-Prefix to a requester. Map-Versioning does
not require additional synchronization mechanisms as compared to the not require additional synchronization mechanisms as compared to the
normal functioning of LISP without Map-Versioning. Clearly, all the normal functioning of LISP without Map-Versioning. Clearly, all the
ETRs have to reply with the same Map-Version number; otherwise, there ETRs have to reply with the same Map-Version number; otherwise, there
can be an inconsistency that creates additional control traffic, can be an inconsistency that creates additional control traffic,
instabilities, and traffic disruptions. It is the same without Map- instabilities, and traffic disruptions. It is the same without Map-
Versioning, with ETRs that have to reply with the same mapping; Versioning, with ETRs that have to reply with the same mapping;
otherwise, the same problems can arise. otherwise, the same problems arise.
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 Domain B, while A.2 of Domain A is sending unidirectional traffic to Domain B, while A.2
skipping to change at page 17, line 16 skipping to change at page 17, line 16
but assumes that synchronization is provided by configuring the but assumes that synchronization is provided by configuring the
different xTRs consistently. The same applies for Map-Versioning. different xTRs consistently. The same applies for Map-Versioning.
If in the future any synchronization mechanism is provided, Map- If in the future any synchronization mechanism is provided, Map-
Versioning will take advantage of it automatically, since it is Versioning will take advantage of it automatically, since it is
included in the Record format, as described in Section 7. included in the Record format, as described in Section 7.
11. IANA Considerations 11. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
12. Acknowledgments 12. References
This work benefited support from NewNet@Paris, Cisco's Chair
"Networks for the Future" at Telecom ParisTech
(http://newnet.telecom-paristech.fr). Any opinions, findings or
recommendations expressed in this material are those of the author(s)
and do not necessarily reflect the views of partners of the Chair.
13. References
13.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-35 (work in progress),
June 2019. September 2020.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-
Aparicio, "Locator/ID Separation Protocol (LISP) Control- Aparicio, "Locator/ID Separation Protocol (LISP) Control-
Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), Plane", draft-ietf-lisp-rfc6833bis-29 (work in progress),
June 2019. September 2020.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 12.2. Informative References
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013, DOI 10.17487/RFC6834, January 2013,
<https://www.rfc-editor.org/info/rfc6834>. <https://www.rfc-editor.org/info/rfc6834>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Telecom ParisTech Huawei Technologies France S.A.S.U
EMail: ggx@gigix.net EMail: luigi.iannone@huawei.com
Damien Saucez Damien Saucez
INRIA
EMail: damien.saucez@gmail.com EMail: damien.saucez@gmail.com
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
EMail: olivier.bonaventure@uclouvain.be EMail: olivier.bonaventure@uclouvain.be
 End of changes. 18 change blocks. 
34 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/