--- 1/draft-ietf-lisp-eid-mobility-02.txt 2018-11-14 00:13:13.119801753 -0800 +++ 2/draft-ietf-lisp-eid-mobility-03.txt 2018-11-14 00:13:13.179803213 -0800 @@ -1,30 +1,30 @@ Network Working Group M. Portoles Internet-Draft V. Ashtaputre Intended status: Experimental V. Moreno -Expires: November 15, 2018 F. Maino +Expires: May 17, 2019 F. Maino Cisco Systems D. Farinacci lispers.net - May 14, 2018 + November 13, 2018 LISP L2/L3 EID Mobility Using a Unified Control Plane - draft-ietf-lisp-eid-mobility-02 + draft-ietf-lisp-eid-mobility-03 Abstract The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and - L3 overlay solution, as well as analyzing possible deployment options - and models. + L3 overlay solution for End-point Identifier (EID) mobility, as well + as analyzing possible deployment options and models. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 15, 2018. + This Internet-Draft will expire on May 17, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,90 +55,96 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 - 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5 - 4.1. Reference Architecture and packet flows . . . . . . . . . 5 + 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 6 + 4.1. Reference Architecture and packet flows . . . . . . . . . 6 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 - 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 - 4.2. Implementation Considerations . . . . . . . . . . . . . . 7 - 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7 - 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8 - 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8 - 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9 - 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9 - 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9 - 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9 - 5.1. Reference Architecture and packet flows . . . . . . . . . 9 - 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10 - 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11 - 5.2. Implementation Considerations . . . . . . . . . . . . . . 11 - 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 11 - 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12 - 5.2.3. Interface to the LISP Mapping System . . . . . . . . 13 - 5.2.4. SMR support to track L2 hosts that moved away . . . . 13 - 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14 - 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14 - 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15 - 5.3. Support to ARP resolution through Mapping System . . . . 15 - 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15 - 5.3.2. ARP registrations: MAC as a locator record . . . . . 16 - 5.3.3. Implementation Considerations . . . . . . . . . . . . 18 - 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 19 - 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 19 - 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 20 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 9.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 7 + 4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7 + 4.1.2.2. L3 Mobility Flow using Publish/Subscribe + Mechanisms . . . . . . . . . . . . . . . . . . . 8 + 4.2. Implementation Considerations . . . . . . . . . . . . . . 9 + 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9 + 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9 + 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10 + 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 11 + 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11 + 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11 + 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11 + 5.1. Reference Architecture and packet flows . . . . . . . . . 11 + 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12 + 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13 + 5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13 + 5.1.2.2. L2 Mobility Flow using Publish/Subscribe + mechanisms . . . . . . . . . . . . . . . . . . . 14 + 5.2. Implementation Considerations . . . . . . . . . . . . . . 14 + 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 14 + 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15 + 5.2.3. Interface to the LISP Mapping System . . . . . . . . 16 + 5.2.4. SMR support to track L2 hosts that moved away . . . . 16 + 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17 + 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17 + 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18 + 5.3. Support to ARP resolution through Mapping System . . . . 18 + 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 18 + 5.3.2. ARP registrations: MAC as a locator record . . . . . 19 + 5.3.3. Implementation Considerations . . . . . . . . . . . . 21 + 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 + 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 + 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 9.2. Informative References . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document describes the architecture and design options required - to offer a unified L2 and L3 overlay solution with mobility using the - LISP control-plane. + to offer a unified L2 and L3 overlay solution for End-point + Identifier (EID) mobility using the LISP control-plane. The architecture takes advantage of the flexibility that LISP provides to simultaneously support different overlay types. While the LISP specification defines both the data-plane and the control- plane, this document focuses on the use of the control-plane to - provide L2 and L3 overlay services with mobility. The control plane - may be combined with a data-plane of choice e.g., [LISP], [VXLAN- - GPE], or [VXLAN]. + provide L2 and L3 overlay services with EID mobility. The control + plane may be combined with a data-plane of choice e.g., [LISP], + [VXLAN-GPE], or [VXLAN]. The recommendation on whether a flow is sent over the L2 or the L3 overlay is based on whether the traffic is bridged (intra-subnet or non-IP) or routed (inter-subnet), respectively. This allows treating both overlays as separate segments, and enables L2-only and L3-only deployments (and combinations of them) without modifying the architecture. The unified solution for L2 and L3 overlays offers the possibility to extend subnets and routing domains (as required in state-of-art Datacenter and Enterprise architectures) with mobility support and traffic optimization. An important use-case of the unified architecture is that, while most data centers are complete layer-3 routing domains, legacy applications either have not converted to IP or still use auto- discovery at layer-2 and assume all nodes in an application cluster belong to the same subnet. For these applications, the L2-overlay limits the functionality to where the legacy app lives versus having - to extend layer-2 into the network. + to extend layer-2 into the underlay network. Broadcast, Unknown and Multicast traffic on the overlay are supported by either replicated unicast, or underlay (RLOC) multicast as specified in [RFC6831] and [RFC8378]. 2. Definition of Terms LISP related terms are defined as part of the LISP specification [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server @@ -268,34 +274,44 @@ 4.1.2. L3 Mobility Flow The support to L3 mobility covers the requirements to allow an end- host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L3 routing domain. This support MUST ensure convergence of L3 forwarding (IPv4/ IPv6 based) from the old location to the new one when the host completes its move. + The update of the ITR map-caches when EIDs move MAY be achieved using + Data Driven SMRs or the Publish/Subscribe mechanisms defined in + [I-D.ietf-lisp-pubsub]. The following two sections are sequence + descriptions of the packet flow when End-Device 1 in the reference + figure roams to site D. + +4.1.2.1. L3 Mobility Flow using Data Driven SMRs + The following is a sequence description of the packet flow when End- - Device 1 in the reference figure roams to site D: + Device 1 in the reference figure roams to site D. This sequence uses + Data Driven SMRs to trigger the updates of the ITR map-caches. o When End-Device 1 is attached or detected in site D, ETR D sets up the database mapping corresponding to EID=. ETR D sends a Map-Register to the mapping system registering RLOC=IP_D as locator for EID=. Now the mapping system is updated with the new EID-to-RLOC mapping (location) for End-Device 1. o The Mapping System, after receiving the new registration for - EID= sends a Map-Notify to ETR A to inform it of - the move. Then, ETR A removes its local database mapping - information and stops registering EID=. + EID= sends a Map-Notify to the departure ETR(s) + (ETR A) to inform it of the move. Then, ETR A removes its local + database mapping information and stops registering EID=. o Any ITR or PiTR participating in the L3 overlay (corresponding to IID1) that were sending traffic to 1.0.0.1 before the migration keep sending traffic to ETR A. o Once ETR A is notified by the Mapping system, when it receives traffic from an ITR with destination 1.0.0.1, it generates a Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=. @@ -303,31 +319,85 @@ entry for EID= and sends a new Map-Request for that EID. The Map-Reply includes the new EID-to-RLOC mapping for End- Device 1 with RLOC=IP_D. o Similarly, once the local database mapping is removed from ITR A, non-encapsulated packets arriving at ITR A from a local End-Device and destined to End-Device 1 result in a cache miss, which triggers sending a Map-Request for EID= to populate the map-cache of ITR A. +4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms + + When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, + the flow of signaling to achieve EID mobility is modified. In this + case, when an local end-device connected via an ITR establishes + communication with a remote mobile end-device (connected to a remote + ETR), the ITR will issue a Map-Request for the mobile end-device. + Following the Mapping Request Subscribe Procedures defined in + [I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit + set on the EID-Record so that the ITR is notified of any RLOC-set + changes for the mobile EID-prefix. + + The following is a sequence description of the packet flow when End- + Device 1 in the reference figure roams to site D. This sequence + leverages Publish/Subscribe mechanisms to update the ITR map-caches. + + o When an end-Device connected via an ITR establishes communication + with a mobile end-device (e.g. end-device 1), the ITR will issue a + Map-Request for the mobile end-device. Following the Mapping + Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], + the Map-request will be issued with the N-bit set on the EID- + Record so that the ITR is notified of any RLOC-set changes for the + mobile EID-prefix. + + o When the mobile end-device (End-Device 1) is attached or detected + in a new site (e.g. site D), The ETR at the new site (e.g. ETR D) + sets up the database mapping corresponding to the EID of the + mobile end-device (e.g. EID=). The ETR at the new + site (e.g. ETR D) sends a Map-Register to the mapping system + registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of + the mobile end-device (e.g. EID=). Now the + mapping system is updated with the new EID-to-RLOC mapping + (location) for the mobile end-device (e.g. End-Device 1). + + o The Mapping System, after receiving the new registration for the + EID of the mobile end-device (EID=) sends a Map- + Notify to the departure site (ETR A) to inform it of the move. + Then, the ETR at the departure site (ETR A) removes its local + database mapping information and stops registering the EID for the + mobile end-device (EID=). + + o Any ITR or PiTR participating in the L3 overlay (corresponding to + IID1) that were sending traffic to the mobile end-device (1.0.0.1) + would have Subscribed to receive notifications of any changes in + the RLOC-set for the EID of the mobile end-device (1.0.0.1). The + Mapping System publishes the updated RLOC-set to the Subscribed + ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping + Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. + + o Upon receiving the Map-Notify message, the ITR updates the RLOC- + set in its local map-cache entry for the EID of the mobile end- + device (EID=). Once the map-cache is updated, + traffic is tunneled by the ITR to the new location. + 4.2. Implementation Considerations 4.2.1. L3 Segmentation LISP support of segmentation and multi-tenancy is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in [RFC8060] and its use in [RFC8111]. Instance-IDs can be used to support L3 overlay segmentation, such as - in extended VRFs or multi-VPN overlays. + in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]). 4.2.2. L3 Database-Mappings When an end-host is attached or detected in an ETR that provides L3-overlay services and mobility, a database Mapping is registered to the mapping system with the following structure: o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR locator set (IP RLOC) @@ -396,21 +466,21 @@ have moved away. o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR message SHOULD be generated. 4.2.5. L3 multicast support L3 Multicast traffic on the overlay MAY be supported by either replicated unicast, or underlay (RLOC) multicast. Specific solutions to support L3 multicast over LISP controlled overlays are specified - in in [RFC6831], [RFC8378] and [I-D.coras-lisp-re]. + in in [RFC6831], and [RFC8378]. 4.2.6. Time-to-Live Handling in Data-Plane The LISP specification ([RFC6830]) describes how to handle Time-to- Live values of the inner and outer headers during encapsulation and decapsulation of packets when using the L3 overlay. 5. L2 Overlays and Mobility Support 5.1. Reference Architecture and packet flows @@ -470,23 +540,31 @@ 5.1.2. L2 Mobility Flow The support to L2 mobility covers the requirements to allow an end- host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L2 domain (e.g. extended VLAN). This support MUST ensure convergence of L2 forwarding (MAC based) from the old location to the new one, when the host completes its move. + The update of the ITR map-caches when EIDs move MAY be achieved using + Data Driven SMRs or the Publish/Subscribe mechanisms defined in + [I-D.ietf-lisp-pubsub]. The following two sections are sequence + descriptions of the packet flow when End-Device 2 in the reference + figure roams to site C, which is extending its own subnet network. + +5.1.2.1. L2 Mobility Flow using Data Driven SMRs + The following is a sequence description of the packet flow when End- - Device 2 in the figure moves to Site C, which is extending its own - subnet network. + Device 2 in the reference figure roams to site C. This sequence uses + Data Driven SMRs to trigger the updates of the ITR map-caches. o When End-Device 2 is attached or detected in site C, ETR C sets up the database mapping corresponding to EID=. ETR C sends a Map-Register to the mapping system registering RLOC=IP_B as locator for EID=. o The Mapping System, after receiving the new registration for EID= sends a Map-Notify to ETR B with the new locator set (IP_B). ETR B removes then its local database mapping and stops registering . @@ -501,20 +579,59 @@ generate a Solicit-Map-Request (SMR) message that is sent to the ITR for (IID2,0:0:3:0:0:2). o Upon receiving the SMR the ITR sends a new Map-Request for the EID=. As a response ETR B sends a Map-Reply that includes the new EID-to-RLOC mapping for with RLOC=IP_B. This entry is cached in the L2 table of the ITR, replacing the previous one, and traffic is then forwarded to the new location. +5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms + + When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, + the flow of signaling to achieve EID mobility is modified. In this + case, when an End-Device connected via an ITR establishes + communication with a mobile EID-prefix, the ITR will issue a Map- + Request for the mobile End-device. Following the Mapping Request + Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map- + request will be issued with the N-bit set on the EID-Record so that + the ITR is notified of any RLOC-set changes for the mobile EID- + prefix. + + The following is a sequence description of the packet flow when End- + Device 2 in the reference figure roams to site C. This sequence + leverages Publish/Subscribe mechanisms to update the ITR map-caches. + + o When End-Device 2 is attached or detected in site C, ETR C sets up + the database mapping corresponding to EID=. + ETR C sends a Map-Register to the mapping system registering + RLOC=IP_B as locator for EID=. + + o The Mapping System, after receiving the new registration for + EID= sends a Map-Notify to the departure site + (ETR B) with the new locator set (IP_B). ETR B removes then its + local database mapping and stops registering . + + o Any ITR or PiTR participating in the same L2-overlay + (corresponding to IID2) that was encapsulating traffic to + 0:0:3:0:0:2 before the migration would have Subscribed to receive + notifications of any changes in the RLOC-set for 0:0:3:0:0:2. The + Mapping System publishes the updated RLOC-set to the Subscribed + ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping + Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. + + o Upon receiving the Map-Notify message, the ITR updates the RLOC- + set in its local map-cache entry for EID=. + Once the map-cache is updated, traffic is tunneled by the ITR to + the new location. + 5.2. Implementation Considerations 5.2.1. L2 Segmentation As with L3 overlays, LISP support of L2 segmentation is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a Mapping System and MAY be used to identify the overlay type (e.g., L2 or L3 overlay). @@ -572,22 +689,21 @@ | \| ... Locator +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The L2 EID record follows the structure as described in [RFC6830]. 5.2.3. Interface to the LISP Mapping System The interface between the xTRs and the Mapping System is described in [RFC6833] and this document follows the specification as described there. When available, the registrations MAY be implemented over a - reliable transport as described in - [I-D.kouvelas-lisp-map-server-reliable-transport]. + reliable transport. In order to support system convergence after mobility, when the Map- Server receives a new registration for a specific EID, it MUST send a Map-Notify to the entire RLOC set in the site that last registered this same EID. This Map-Notify is used to track moved-away state of L2 EIDs as described in Section 5.2.4. 5.2.4. SMR support to track L2 hosts that moved away In order to support mobility, an ETR SHALL maintain a list of EID @@ -898,21 +1014,21 @@ 6.2. Data-plane Encapsulation Options The LISP control-plane offers independence from the data-plane encapsulation. Any encapsulation format that can carry a 24-bit instance-ID can be used to provide the unified overlay. Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] and [VXLAN]: o VXLAN-GPE encap: This encapsulation format is defined in - [I-D.ietf-nvo3-vxlan-gpe]. It allows encapsulation both L2 and L3 + [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 packets and the VNI field directly maps to the Instance-ID used in the control plane. Note that when using this encapsulation for a unified solution the P-bit is set and the Next-Protocol field is used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in L3-overlays, and value 0x3 in L2-overlays). o LISP encap: This is the encapsulation format defined in the original LISP specification [RFC6830]. The encapsulation allows encapsulating both L2 and L3 packets. The Instance-ID used in the EIDs directly maps to the Instance-ID that the LISP header @@ -982,30 +1098,36 @@ Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, . 9.2. Informative References - [I-D.coras-lisp-re] - Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., - Maino, F., and D. Farinacci, "LISP Replication - Engineering", draft-coras-lisp-re-08 (work in progress), - November 2015. + [I-D.ietf-lisp-gpe] + Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. + Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- + gpe-06 (work in progress), September 2018. - [I-D.ietf-nvo3-vxlan-gpe] - Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol - Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work - in progress), April 2018. + [I-D.ietf-lisp-pubsub] + Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., + Cabellos-Aparicio, A., Barkai, S., Farinacci, D., + Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ + Subscribe Functionality for LISP", draft-ietf-lisp- + pubsub-02 (work in progress), November 2018. + + [I-D.ietf-lisp-vpn] + Moreno, V. and D. Farinacci, "LISP Virtual Private + Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in + progress), May 2018. [I-D.kouvelas-lisp-map-server-reliable-transport] Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. Arango, "LISP Map Server Reliable Transport", draft- kouvelas-lisp-map-server-reliable-transport-04 (work in progress), September 2017. Authors' Addresses Marc Portoles Comeras