draft-ietf-lisp-eid-mobility-07.txt   draft-ietf-lisp-eid-mobility-08.txt 
Network Working Group M. Portoles Network Working Group M. Portoles
Internet-Draft V. Ashtaputre Internet-Draft V. Ashtaputre
Intended status: Experimental V. Moreno Intended status: Experimental V. Moreno
Expires: July 21, 2021 F. Maino Expires: 26 January 2022 F. Maino
Cisco Systems Cisco Systems
D. Farinacci D. Farinacci
lispers.net lispers.net
January 17, 2021 25 July 2021
LISP L2/L3 EID Mobility Using a Unified Control Plane LISP L2/L3 EID Mobility Using a Unified Control Plane
draft-ietf-lisp-eid-mobility-07 draft-ietf-lisp-eid-mobility-08
Abstract Abstract
The LISP control plane offers the flexibility to support multiple The LISP control plane offers the flexibility to support multiple
overlay flavors simultaneously. This document specifies how LISP can overlay flavors simultaneously. This document specifies how LISP can
be used to provide control-plane support to deploy a unified L2 and be used to provide control-plane support to deploy a unified L2 and
L3 overlay solution for End-point Identifier (EID) mobility, as well L3 overlay solution for End-point Identifier (EID) mobility, as well
as analyzing possible deployment options and models. as analyzing possible deployment options and models.
Requirements Language Requirements Language
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 21, 2021. This Internet-Draft will expire on 26 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4
4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 6 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5
4.1. Reference Architecture and packet flows . . . . . . . . . 6 4.1. Reference Architecture and packet flows . . . . . . . . . 5
4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6
4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 7 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6
4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7 4.1.2.1. L3 Mobility Flow using Data Driven SMRs . . . . . 7
4.1.2.2. L3 Mobility Flow using Publish/Subscribe 4.1.2.2. L3 Mobility Flow using Publish/Subscribe
Mechanisms . . . . . . . . . . . . . . . . . . . 8 Mechanisms . . . . . . . . . . . . . . . . . . . . 8
4.2. Implementation Considerations . . . . . . . . . . . . . . 9 4.2. Implementation Considerations . . . . . . . . . . . . . . 9
4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 9
4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 9
4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 10
4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 11 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 10
4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 11
4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 11
5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 11
5.1. Reference Architecture and packet flows . . . . . . . . . 11 5.1. Reference Architecture and packet flows . . . . . . . . . 11
5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 12
5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 13
5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13 5.1.2.1. L2 Mobility Flow using Data Driven SMRs . . . . . 13
5.1.2.2. L2 Mobility Flow using Publish/Subscribe 5.1.2.2. L2 Mobility Flow using Publish/Subscribe
mechanisms . . . . . . . . . . . . . . . . . . . 14 mechanisms . . . . . . . . . . . . . . . . . . . . 14
5.2. Implementation Considerations . . . . . . . . . . . . . . 14 5.2. Implementation Considerations . . . . . . . . . . . . . . 14
5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 14 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 15
5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 15
5.2.3. Interface to the LISP Mapping System . . . . . . . . 16 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.4. SMR support to track L2 hosts that moved away . . . . 16
5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 17
5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 17
5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 18
5.3. Support to ARP resolution through Mapping System . . . . 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.1. Map-Server support to ARP resolution: Packet Flow . . 18
5.3.2. ARP registrations: MAC as a locator record . . . . . 19 5.3.2. ARP registrations: MAC as a locator record . . . . . 19
5.3.3. Implementation Considerations . . . . . . . . . . . . 21 5.3.3. Implementation Considerations . . . . . . . . . . . . 21
skipping to change at page 5, line 32 skipping to change at page 4, line 49
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--' / '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
: End : : End : : End : : End : : End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4: :Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4 IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4
MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3 MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3
Figure 1: Reference System Architecture with unified L2 and L3 Figure 1: Reference System Architecture with unified L2 and L3
overlays overlays
The recommended selection between the use of L2 and L3 overlays is to The recommended selection between the use of L2 and L3 overlays is to
map them to bridged (intra-subnet or non-IP) and routed (inter- map them to bridged (intra-subnet or non-IP) and routed (inter-
subnet) traffic. The rest of the document follows this subnet) traffic. The rest of the document follows this
recommendation to describe the packet flows. recommendation to describe the packet flows.
However, note that in a different selection approach, intra-subnet However, note that in a different selection approach, intra-subnet
traffic MAY also be sent over the L3 overlay. Section 6.1 specifies traffic MAY also be sent over the L3 overlay. Section 6.1 specifies
the changes needed to send all IP traffic using the L3 overlay and the changes needed to send all IP traffic using the L3 overlay and
restricting the use of the L2 overlay to non-IP traffic. restricting the use of the L2 overlay to non-IP traffic.
When required, the control plane makes use of two basic types of EID- When required, the control plane makes use of two basic types of EID-
to-RLOC mappings associated to end-hosts and in order to support the to-RLOC mappings associated to end-hosts and in order to support the
unified architecture: unified architecture:
o EID = <IID, MAC> to RLOC=<IP>. This is used to support the L2 * EID = <IID, MAC> to RLOC=<IP>. This is used to support the L2
overlay. overlay.
o EID = <IID, IP> to RLOC=<IP>. This is the traditional mapping as * EID = <IID, IP> to RLOC=<IP>. This is the traditional mapping as
defined in the original LISP specification and supports the L3 defined in the original LISP specification and supports the L3
overlay. overlay.
4. L3 Overlays and Mobility Support 4. L3 Overlays and Mobility Support
4.1. Reference Architecture and packet flows 4.1. Reference Architecture and packet flows
In order to support the packet flow descriptions in this section we In order to support the packet flow descriptions in this section we
use Figure 1 as reference. This section uses Sites A and D to use Figure 1 as reference. This section uses Sites A and D to
describe the flows. describe the flows.
skipping to change at page 6, line 33 skipping to change at page 5, line 50
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--' / '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
: End : : End : : End : : End : : End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4: :Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Figure 2: Reference Mobility Architecture Figure 2: Reference Mobility Architecture
4.1.1. Routed Traffic Flow: L3 Overlay use 4.1.1. Routed Traffic Flow: L3 Overlay use
Inter-subnet traffic is encapsulated using the L3 overlay. The Inter-subnet traffic is encapsulated using the L3 overlay. The
process to encapsulate this traffic is the same as described in the process to encapsulate this traffic is the same as described in the
original specification [RFC6830]. We describe the packet flow here original specification [RFC6830]. We describe the packet flow here
for completeness for completeness
The following is a sequence example of the unicast packet flow and The following is a sequence example of the unicast packet flow and
the control plane operations when in the topology shown in Figure 1 the control plane operations when in the topology shown in Figure 1
End-Device 1, in LISP site A, wants to communicate with End-Device 4 End-Device 1, in LISP site A, wants to communicate with End-Device 4
in LISP site D. Note that both end systems reside in different in LISP site D. Note that both end systems reside in different
subnets. We'll assume that End-Device 1 knows the EID IP address of subnets. We'll assume that End-Device 1 knows the EID IP address of
End-Device 4 (e.g. it is learned using a DNS service). End-Device 4 (e.g. it is learned using a DNS service).
o End-Device 1 sends an IP packet frame with destination 2.0.0.4 and * End-Device 1 sends an IP packet frame with destination 2.0.0.4 and
source 1.0.0.1. As the destination address lies on a different source 1.0.0.1. As the destination address lies on a different
subnet End-Device 1 sends the packet following its routing table subnet End-Device 1 sends the packet following its routing table
to ITR A (e.g., it is its default gateway). to ITR A (e.g., it is its default gateway).
o ITR A does a L3 lookup in its local map-cache for the destination * ITR A does a L3 lookup in its local map-cache for the destination
IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss, the ITR sends a
Map-request to the mapping database system looking up for Map-request to the mapping database system looking up for
EID=<IID1,2.0.0.4>. EID=<IID1,2.0.0.4>.
o The mapping systems forwards the Map-Request to ETR D, that has * The mapping systems forwards the Map-Request to ETR D, that has
registered the EID-to-RLOC mapping of EID=<IID1,2.0.0.4>. registered the EID-to-RLOC mapping of EID=<IID1,2.0.0.4>.
o ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC * ETR D sends a Map-Reply to ITR A that includes the EID-to-RLOC
mapping: EID=<IID1,2.0.0.4> -> RLOC=IP_D, where IP_D is the mapping: EID=<IID1,2.0.0.4> -> RLOC=IP_D, where IP_D is the
locator of ETR D. locator of ETR D.
o ITR A populates the local map-cache with the EID to RLOC mapping, * ITR A populates the local map-cache with the EID to RLOC mapping,
and encapsulates all subsequent packets with a destination IP and encapsulates all subsequent packets with a destination IP
2.0.0.4 using destination RLOC=IP_D. 2.0.0.4 using destination RLOC=IP_D.
4.1.2. L3 Mobility Flow 4.1.2. L3 Mobility Flow
The support to L3 mobility covers the requirements to allow an end- The support to L3 mobility covers the requirements to allow an end-
host to move from a given site to another and maintain correspondence 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 with the rest of end-hosts that are connected to the same L3 routing
domain. This support MUST ensure convergence of L3 forwarding (IPv4/ domain. This support MUST ensure convergence of L3 forwarding (IPv4/
IPv6 based) from the old location to the new one when the host IPv6 based) from the old location to the new one when the host
skipping to change at page 7, line 42 skipping to change at page 7, line 17
[I-D.ietf-lisp-pubsub]. The following two sections are sequence [I-D.ietf-lisp-pubsub]. The following two sections are sequence
descriptions of the packet flow when End-Device 1 in the reference descriptions of the packet flow when End-Device 1 in the reference
figure roams to site D. figure roams to site D.
4.1.2.1. L3 Mobility Flow using Data Driven SMRs 4.1.2.1. L3 Mobility Flow using Data Driven SMRs
The following is a sequence description of the packet flow when End- The following is a sequence description of the packet flow when End-
Device 1 in the reference figure roams to site D. This sequence uses 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. 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 * When End-Device 1 is attached or detected in site D, ETR D sets up
the database mapping corresponding to EID=<IID1, 1.0.0.1>. ETR D the database mapping corresponding to EID=<IID1, 1.0.0.1>. ETR D
sends a Map-Register to the mapping system registering RLOC=IP_D sends a Map-Register to the mapping system registering RLOC=IP_D
as locator for EID=<IID1, 1.0.0.1>. Now the mapping system is as locator for EID=<IID1, 1.0.0.1>. Now the mapping system is
updated with the new EID-to-RLOC mapping (location) for End-Device updated with the new EID-to-RLOC mapping (location) for End-Device
1. 1.
o The Mapping System, after receiving the new registration for * The Mapping System, after receiving the new registration for
EID=<IID1, 1.0.0.1> sends a Map-Notify to the departure ETR(s) EID=<IID1, 1.0.0.1> sends a Map-Notify to the departure ETR(s)
(ETR A) to inform it of the move. Then, ETR A removes its local (ETR A) to inform it of the move. Then, ETR A removes its local
database mapping information and stops registering EID=<IID1, database mapping information and stops registering EID=<IID1,
1.0.0.1>. 1.0.0.1>.
o Any ITR or PiTR participating in the L3 overlay (corresponding to * Any ITR or PiTR participating in the L3 overlay (corresponding to
IID1) that were sending traffic to 1.0.0.1 before the migration IID1) that were sending traffic to 1.0.0.1 before the migration
keep sending traffic to ETR A. keep sending traffic to ETR A.
o Once ETR A is notified by the Mapping system, when it receives * 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 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=<IID1, Solicit-Map-Request (SMR) back to the ITR (or PiTR) for EID=<IID1,
1.0.0.1>. 1.0.0.1>.
o Upon receiving the SMR the ITR invalidates its local map- cache * Upon receiving the SMR the ITR invalidates its local map- cache
entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request for that entry for EID=<IID1, 1.0.0.1> and sends a new Map-Request for that
EID. The Map-Reply includes the new EID-to-RLOC mapping for End- EID. The Map-Reply includes the new EID-to-RLOC mapping for End-
Device 1 with RLOC=IP_D. Device 1 with RLOC=IP_D.
o Similarly, once the local database mapping is removed from ITR A, * Similarly, once the local database mapping is removed from ITR A,
non-encapsulated packets arriving at ITR A from a local End-Device non-encapsulated packets arriving at ITR A from a local End-Device
and destined to End-Device 1 result in a cache miss, which and destined to End-Device 1 result in a cache miss, which
triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate triggers sending a Map-Request for EID=<IID1, 1.0.0.1> to populate
the map-cache of ITR A. the map-cache of ITR A.
4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms 4.1.2.2. L3 Mobility Flow using Publish/Subscribe Mechanisms
When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used,
the flow of signaling to achieve EID mobility is modified. In this the flow of signaling to achieve EID mobility is modified. In this
case, when an local end-device connected via an ITR establishes case, when an local end-device connected via an ITR establishes
skipping to change at page 8, line 43 skipping to change at page 8, line 21
ETR), the ITR will issue a Map-Request for the mobile end-device. ETR), the ITR will issue a Map-Request for the mobile end-device.
Following the Mapping Request Subscribe Procedures defined in Following the Mapping Request Subscribe Procedures defined in
[I-D.ietf-lisp-pubsub], the Map-request will be issued with the N-bit [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 set on the EID-Record so that the ITR is notified of any RLOC-set
changes for the mobile EID-prefix. changes for the mobile EID-prefix.
The following is a sequence description of the packet flow when End- The following is a sequence description of the packet flow when End-
Device 1 in the reference figure roams to site D. This sequence Device 1 in the reference figure roams to site D. This sequence
leverages Publish/Subscribe mechanisms to update the ITR map-caches. leverages Publish/Subscribe mechanisms to update the ITR map-caches.
o When an end-Device connected via an ITR establishes communication * 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 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 Map-Request for the mobile end-device. Following the Mapping
Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], Request Subscribe Procedures defined in [I-D.ietf-lisp-pubsub],
the Map-request will be issued with the N-bit set on the EID- 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 Record so that the ITR is notified of any RLOC-set changes for the
mobile EID-prefix. mobile EID-prefix.
o When the mobile end-device (End-Device 1) is attached or detected * 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) 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 sets up the database mapping corresponding to the EID of the
mobile end-device (e.g. EID=<IID1, 1.0.0.1>). The ETR at the new mobile end-device (e.g. EID=<IID1, 1.0.0.1>). The ETR at the new
site (e.g. ETR D) sends a Map-Register to the mapping system 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 registering its RLOCs (e.g. RLOC=IP_D) as locator for the EID of
the mobile end-device (e.g. EID=<IID1, 1.0.0.1>). Now the the mobile end-device (e.g. EID=<IID1, 1.0.0.1>). Now the
mapping system is updated with the new EID-to-RLOC mapping mapping system is updated with the new EID-to-RLOC mapping
(location) for the mobile end-device (e.g. End-Device 1). (location) for the mobile end-device (e.g. End-Device 1).
o The Mapping System, after receiving the new registration for the * The Mapping System, after receiving the new registration for the
EID of the mobile end-device (EID=<IID1, 1.0.0.1>) sends a Map- EID of the mobile end-device (EID=<IID1, 1.0.0.1>) sends a Map-
Notify to the departure site (ETR A) to inform it of the move. 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 Then, the ETR at the departure site (ETR A) removes its local
database mapping information and stops registering the EID for the database mapping information and stops registering the EID for the
mobile end-device (EID=<IID1, 1.0.0.1>). mobile end-device (EID=<IID1, 1.0.0.1>).
o Any ITR or PiTR participating in the L3 overlay (corresponding to * 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) IID1) that were sending traffic to the mobile end-device (1.0.0.1)
would have Subscribed to receive notifications of any changes in 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 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 Mapping System publishes the updated RLOC-set to the Subscribed
ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub].
o Upon receiving the Map-Notify message, the ITR updates the RLOC- * 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- set in its local map-cache entry for the EID of the mobile end-
device (EID=<IID1, 1.0.0.1>). Once the map-cache is updated, device (EID=<IID1, 1.0.0.1>). Once the map-cache is updated,
traffic is tunneled by the ITR to the new location. traffic is tunneled by the ITR to the new location.
4.2. Implementation Considerations 4.2. Implementation Considerations
4.2.1. L3 Segmentation 4.2.1. L3 Segmentation
LISP support of segmentation and multi-tenancy is structured around LISP support of segmentation and multi-tenancy is structured around
the propagation and use of Instance-IDs, and handled as part of the the propagation and use of Instance-IDs, and handled as part of the
skipping to change at page 10, line 5 skipping to change at page 9, line 28
Instance-IDs can be used to support L3 overlay segmentation, such as Instance-IDs can be used to support L3 overlay segmentation, such as
in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]). in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]).
4.2.2. L3 Database-Mappings 4.2.2. L3 Database-Mappings
When an end-host is attached or detected in an ETR that provides When an end-host is attached or detected in an ETR that provides
L3-overlay services and mobility, a database Mapping is registered to L3-overlay services and mobility, a database Mapping is registered to
the mapping system with the following structure: the mapping system with the following structure:
o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR * The EID 2-tuple (IID, IP) with its binding to a corresponding ETR
locator set (IP RLOC) locator set (IP RLOC)
The registration of these EIDs MUST follow the LCAF format as defined The registration of these EIDs MUST follow the LCAF format as defined
in [RFC8060] and the specific EID record to be used is illustrated in in [RFC8060] and the specific EID record to be used is illustrated in
the following figure: the following figure:
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved | E | Locator Count | EID mask-len | ACT |A| Reserved |
skipping to change at page 11, line 24 skipping to change at page 11, line 15
In order to support mobility, an ETR SHALL maintain a list of EID In order to support mobility, an ETR SHALL maintain a list of EID
records for which it has to generate a SMR message whenever it records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination. receives traffic with that EID as destination.
The particular strategy to maintain an Away Table is implementation The particular strategy to maintain an Away Table is implementation
specific and it will be typically based on the strategy to detect the specific and it will be typically based on the strategy to detect the
presence of hosts and the use of Map-Notify messages received from presence of hosts and the use of Map-Notify messages received from
the Map-Server. In essence the table SHOULD provide support to the the Map-Server. In essence the table SHOULD provide support to the
following: following:
o Keep track of end-hosts that were once connected to an ETR and * Keep track of end-hosts that were once connected to an ETR and
have moved away. have moved away.
o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR * Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR
message SHOULD be generated. message SHOULD be generated.
4.2.5. L3 multicast support 4.2.5. L3 multicast support
L3 Multicast traffic on the overlay MAY be supported by either L3 Multicast traffic on the overlay MAY be supported by either
replicated unicast, or underlay (RLOC) multicast. Specific solutions replicated unicast, or underlay (RLOC) multicast. Specific solutions
to support L3 multicast over LISP controlled overlays are specified to support L3 multicast over LISP controlled overlays are specified
in in [RFC6831], and [RFC8378]. in in [RFC6831], and [RFC8378].
4.2.6. Time-to-Live Handling in Data-Plane 4.2.6. Time-to-Live Handling in Data-Plane
skipping to change at page 12, line 21 skipping to change at page 12, line 21
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 . ( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--' / '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
: End : : End : : End : : End : : End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4: :Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------' '--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Figure 3: Reference Mobility Architecture Figure 3: Reference Mobility Architecture
5.1.1. Bridged Traffic Flow: L2 Overlay use 5.1.1. Bridged Traffic Flow: L2 Overlay use
Bridged traffic is encapsulated using the L2 overlay. This section Bridged traffic is encapsulated using the L2 overlay. This section
provides an example of the unicast packet flow and the control plane provides an example of the unicast packet flow and the control plane
operations when in the topology shown in Figure 1, the End-Device 2 operations when in the topology shown in Figure 1, the End-Device 2
in site B communicates with the End-Device 3 in site C. In this case in site B communicates with the End-Device 3 in site C. In this case
we assume that End Device 2, knows the MAC address of End-Device 3 we assume that End Device 2, knows the MAC address of End-Device 3
(e.g., learned through ARP). (e.g., learned through ARP).
o End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination * End-Device 2 sends an Ethernet/IEEE 802 MAC frame with destination
0:0:3:0:0:3 and source 0:0:3:0:0:2. 0:0:3:0:0:3 and source 0:0:3:0:0:2.
o ITR B does a L2 lookup in its local map-cache for the destination * ITR B does a L2 lookup in its local map-cache for the destination
MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a miss, the
ITR sends a Map-Request to the mapping database system looking up ITR sends a Map-Request to the mapping database system looking up
for EID=<IID2,0:0:3:0:0:3>. for EID=<IID2,0:0:3:0:0:3>.
o The mapping systems forwards the Map-Request to ETR C, that has * The mapping systems forwards the Map-Request to ETR C, that has
registered the EID-to-RLOC mapping for EID=<IID2,0:0:3:0:0:3>. registered the EID-to-RLOC mapping for EID=<IID2,0:0:3:0:0:3>.
Alternatively, depending on the mapping system configuration, a Alternatively, depending on the mapping system configuration, a
Map-Server which is part of the mapping database system MAY send a Map-Server which is part of the mapping database system MAY send a
Map-Reply directly to ITR B. Map-Reply directly to ITR B.
o ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC * ETR C sends a Map-Reply to ITR B that includes the EID-to-RLOC
mapping: EID=<IID2, 0:0:3:0:0:3> -> RLOC=IP_C, where IP_C is the mapping: EID=<IID2, 0:0:3:0:0:3> -> RLOC=IP_C, where IP_C is the
locator of ETR C. locator of ETR C.
o ITR B populates the local map-cache with the EID to RLOC mapping, * ITR B populates the local map-cache with the EID to RLOC mapping,
and encapsulates all subsequent packets with a destination MAC and encapsulates all subsequent packets with a destination MAC
0:0:3:0:0:3 using destination RLOC=IP_C. 0:0:3:0:0:3 using destination RLOC=IP_C.
5.1.2. L2 Mobility Flow 5.1.2. L2 Mobility Flow
The support to L2 mobility covers the requirements to allow an end- The support to L2 mobility covers the requirements to allow an end-
host to move from a given site to another and maintain correspondence 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 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 (e.g. extended VLAN). This support MUST ensure convergence of L2
forwarding (MAC based) from the old location to the new one, when the forwarding (MAC based) from the old location to the new one, when the
skipping to change at page 13, line 26 skipping to change at page 13, line 30
[I-D.ietf-lisp-pubsub]. The following two sections are sequence [I-D.ietf-lisp-pubsub]. The following two sections are sequence
descriptions of the packet flow when End-Device 2 in the reference descriptions of the packet flow when End-Device 2 in the reference
figure roams to site C, which is extending its own subnet network. figure roams to site C, which is extending its own subnet network.
5.1.2.1. L2 Mobility Flow using Data Driven SMRs 5.1.2.1. L2 Mobility Flow using Data Driven SMRs
The following is a sequence description of the packet flow when End- The following is a sequence description of the packet flow when End-
Device 2 in the reference figure roams to site C. This sequence uses 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. 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 * When End-Device 2 is attached or detected in site C, ETR C sets up
the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>. the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
ETR C sends a Map-Register to the mapping system registering ETR C sends a Map-Register to the mapping system registering
RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>. RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>.
o The Mapping System, after receiving the new registration for * The Mapping System, after receiving the new registration for
EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the new EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with the new
locator set (IP_B). ETR B removes then its local database mapping locator set (IP_B). ETR B removes then its local database mapping
and stops registering <IID2, 0:0:3:0:0:2>. and stops registering <IID2, 0:0:3:0:0:2>.
o Any PiTR or ITR participating in the same L2-overlay * Any PiTR or ITR participating in the same L2-overlay
(corresponding to IID2) that was encapsulating traffic to (corresponding to IID2) that was encapsulating traffic to
0:0:3:0:0:2 before the migration continues encapsulating this 0:0:3:0:0:2 before the migration continues encapsulating this
traffic to ETR B. traffic to ETR B.
o Once ETR B is notified by the Mapping system, when it receives * Once ETR B is notified by the Mapping system, when it receives
traffic from an ITR which is destined to 0:0:3:0:0:2, it will traffic from an ITR which is destined to 0:0:3:0:0:2, it will
generate a Solicit-Map-Request (SMR) message that is sent to the generate a Solicit-Map-Request (SMR) message that is sent to the
ITR for (IID2,0:0:3:0:0:2). ITR for (IID2,0:0:3:0:0:2).
o Upon receiving the SMR the ITR sends a new Map-Request for the * Upon receiving the SMR the ITR sends a new Map-Request for the
EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a Map-Reply EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a Map-Reply
that includes the new EID-to-RLOC mapping for <IID2,0:0:3:0:0:2> that includes the new EID-to-RLOC mapping for <IID2,0:0:3:0:0:2>
with RLOC=IP_B. This entry is cached in the L2 table of the ITR, 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 replacing the previous one, and traffic is then forwarded to the
new location. new location.
5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms 5.1.2.2. L2 Mobility Flow using Publish/Subscribe mechanisms
When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used, When Publish/Subscribe ([I-D.ietf-lisp-pubsub]) mechanisms are used,
the flow of signaling to achieve EID mobility is modified. In this the flow of signaling to achieve EID mobility is modified. In this
skipping to change at page 14, line 21 skipping to change at page 14, line 24
Request for the mobile End-device. Following the Mapping Request Request for the mobile End-device. Following the Mapping Request
Subscribe Procedures defined in [I-D.ietf-lisp-pubsub], the Map- 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 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- the ITR is notified of any RLOC-set changes for the mobile EID-
prefix. prefix.
The following is a sequence description of the packet flow when End- The following is a sequence description of the packet flow when End-
Device 2 in the reference figure roams to site C. This sequence Device 2 in the reference figure roams to site C. This sequence
leverages Publish/Subscribe mechanisms to update the ITR map-caches. 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 * When End-Device 2 is attached or detected in site C, ETR C sets up
the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>. the database mapping corresponding to EID=<IID2, 0:0:3:0:0:2>.
ETR C sends a Map-Register to the mapping system registering ETR C sends a Map-Register to the mapping system registering
RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>. RLOC=IP_B as locator for EID=<IID2, 0:0:3:0:0:2>.
o The Mapping System, after receiving the new registration for * The Mapping System, after receiving the new registration for
EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to the departure site EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to the departure site
(ETR B) with the new locator set (IP_B). ETR B removes then its (ETR B) with the new locator set (IP_B). ETR B removes then its
local database mapping and stops registering <IID2, 0:0:3:0:0:2>. local database mapping and stops registering <IID2, 0:0:3:0:0:2>.
o Any ITR or PiTR participating in the same L2-overlay * Any ITR or PiTR participating in the same L2-overlay
(corresponding to IID2) that was encapsulating traffic to (corresponding to IID2) that was encapsulating traffic to
0:0:3:0:0:2 before the migration would have Subscribed to receive 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 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 Mapping System publishes the updated RLOC-set to the Subscribed
ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping ITRs by sending a Map-Notify to the ITRs or PiTRs per the Mapping
Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub]. Notification Publish Procedures defined in [I-D.ietf-lisp-pubsub].
o Upon receiving the Map-Notify message, the ITR updates the RLOC- * Upon receiving the Map-Notify message, the ITR updates the RLOC-
set in its local map-cache entry for EID=<IID2, 0:0:3:0:0:2>. set in its local map-cache entry for EID=<IID2, 0:0:3:0:0:2>.
Once the map-cache is updated, traffic is tunneled by the ITR to Once the map-cache is updated, traffic is tunneled by the ITR to
the new location. the new location.
5.2. Implementation Considerations 5.2. Implementation Considerations
5.2.1. L2 Segmentation 5.2.1. L2 Segmentation
As with L3 overlays, LISP support of L2 segmentation is structured As with L3 overlays, LISP support of L2 segmentation is structured
around the propagation and use of Instance-IDs, and handled as part around the propagation and use of Instance-IDs, and handled as part
of the EID in control plane operations. The encoding is described in of the EID in control plane operations. The encoding is described in
[RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a [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 Mapping System and MAY be used to identify the overlay type (e.g., L2
or L3 overlay). or L3 overlay).
An Instance-ID can be used for L2 overlay segmentation. An important An Instance-ID can be used for L2 overlay segmentation. An important
skipping to change at page 15, line 30 skipping to change at page 15, line 36
single IID. These are all examples of local operations that could be single IID. These are all examples of local operations that could be
effected on VLANs in order to map them to IIDs, they are provided as effected on VLANs in order to map them to IIDs, they are provided as
examples and are not exhaustive. examples and are not exhaustive.
5.2.2. L2 Database-Mappings 5.2.2. L2 Database-Mappings
When an end-host is attached or detected in an ETR that provides When an end-host is attached or detected in an ETR that provides
L2-overlay services, a database Mapping is registered to the mapping L2-overlay services, a database Mapping is registered to the mapping
system with the following structure: system with the following structure:
o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP * The EID 2-tuple (IID, MAC) with its binding to a locator set (IP
RLOC) RLOC)
The registration of these EIDs MUST follow the LCAF format as defined The registration of these EIDs MUST follow the LCAF format as defined
in [RFC8060] and as illustrated in the following figure: in [RFC8060] and as illustrated in the following figure:
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved | E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 5 skipping to change at page 17, line 5
5.2.4. SMR support to track L2 hosts that moved away 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 In order to support mobility, an ETR SHALL maintain a list of EID
records for which it has to generate a SMR message whenever it records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination. receives traffic with that EID as destination.
The particular strategy to maintain a SMR table is implementation The particular strategy to maintain a SMR table is implementation
specific. In essence the table SHOULD provide support for the specific. In essence the table SHOULD provide support for the
following: following:
o Keep track of end-hosts that were once connected to an ETR and * Keep track of end-hosts that were once connected to an ETR and
have moved away. have moved away.
o Support for L2 EID records, the 2-tuple (IID, MAC), for which a * Support for L2 EID records, the 2-tuple (IID, MAC), for which a
SMR message SHOULD be generated. SMR message SHOULD be generated.
5.2.5. L2 Broadcast and Multicast traffic 5.2.5. L2 Broadcast and Multicast traffic
Broadcast and Multicast traffic on the L2-overlay is supported by Broadcast and Multicast traffic on the L2-overlay is supported by
either replicated unicast, or underlay (RLOC) multicast. either replicated unicast, or underlay (RLOC) multicast.
xTRs that offer L2 overlay services and are part of the same xTRs that offer L2 overlay services and are part of the same
Instance-ID join a common Multicast Group. When required, this group Instance-ID join a common Multicast Group. When required, this group
allows ITRs to send traffic that needs to be replicated (flooded) to allows ITRs to send traffic that needs to be replicated (flooded) to
skipping to change at page 18, line 34 skipping to change at page 18, line 34
end systems are typically provisioned with IP addresses as well as end systems are typically provisioned with IP addresses as well as
MAC addresses. MAC addresses.
In this case, to limit the flooding of ARP traffic and reduce the use In this case, to limit the flooding of ARP traffic and reduce the use
of multicast in the RLOC network, the LISP mapping system MAY be used of multicast in the RLOC network, the LISP mapping system MAY be used
to support ARP resolution at the ITR. to support ARP resolution at the ITR.
In order to provide this support, ETRs handle and register an In order to provide this support, ETRs handle and register an
additional EID-to-RLOC mapping as follows, additional EID-to-RLOC mapping as follows,
o EID-record contents = <IID, IP>, RLOC-record contents <MAC>. * EID-record contents = <IID, IP>, RLOC-record contents <MAC>.
There is a dedicated IID used for the registration of the ARP/ND There is a dedicated IID used for the registration of the ARP/ND
related mappings. Thus, a system with L2 and L3 overlays as well as related mappings. Thus, a system with L2 and L3 overlays as well as
ARP/ND mappings would have three IIDs at play. In the spirit of ARP/ND mappings would have three IIDs at play. In the spirit of
providing clarity, we will refer to those IIDs as L2-IID, L3-IID and providing clarity, we will refer to those IIDs as L2-IID, L3-IID and
ARP-IID respectively. By using these definitions, we do not intend ARP-IID respectively. By using these definitions, we do not intend
to coin new terminology, nor is there anything special about those to coin new terminology, nor is there anything special about those
IIDs that would make them differ from the generic definition of an IIDs that would make them differ from the generic definition of an
IID. The types of mappings expected in such a system are summarized IID. The types of mappings expected in such a system are summarized
below: below:
o EID = <IID1, IP> to RLOC = <IP-RLOC> (L3-overlay) * EID = <IID1, IP> to RLOC = <IP-RLOC> (L3-overlay)
o EID = <IID2, MAC> to RLOC = <IP-RLOC> (L2-overlay) * EID = <IID2, MAC> to RLOC = <IP-RLOC> (L2-overlay)
o EID = <IID3, IP> to RLOC = <MAC-RLOC> (ARP/ND mapping) * EID = <IID3, IP> to RLOC = <MAC-RLOC> (ARP/ND mapping)
The following packet flow sequence describes the use of the LISP The following packet flow sequence describes the use of the LISP
Mapping System to support ARP resolution for hosts residing in a Mapping System to support ARP resolution for hosts residing in a
subnet that is extended to multiple sites. Using Figure 1, End- subnet that is extended to multiple sites. Using Figure 1, End-
Device 2 tries to find the MAC address of End-Device 3. Note that Device 2 tries to find the MAC address of End-Device 3. Note that
both have IP addresses within the same subnet: both have IP addresses within the same subnet:
o End-Device 2 sends a broadcast ARP message to discover the MAC * End-Device 2 sends a broadcast ARP message to discover the MAC
address of End-Device 3. The ARP request targets IP 3.0.0.3. address of End-Device 3. The ARP request targets IP 3.0.0.3.
o ITR B receives the ARP message, but rather than flooding it on the * ITR B receives the ARP message, but rather than flooding it on the
overlay network sends a Map-Request to the mapping database system overlay network sends a Map-Request to the mapping database system
for EID = <IID2,3.0.0.3>. for EID = <IID2,3.0.0.3>.
o When receiving the Map-Request, the Map-Server sends a Proxy-Map- * When receiving the Map-Request, the Map-Server sends a Proxy-Map-
Reply back to ITR B with the mapping EID = <IID2,3.0.0.3> -> MAC Reply back to ITR B with the mapping EID = <IID2,3.0.0.3> -> MAC
0:0:3:0:0:3. 0:0:3:0:0:3.
o Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device * Using this Map-Reply, ITR B sends an ARP-Reply back to End-Device
2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3. 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3.
o End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can * End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and can
now send a L2 traffic to End-Device 3. When this traffic reaches now send a L2 traffic to End-Device 3. When this traffic reaches
ITR B is sent over the L2-overlay as described above in ITR B is sent over the L2-overlay as described above in
Section 5.1.1. Section 5.1.1.
This example shows how LISP, by replacing dynamic data plane learning This example shows how LISP, by replacing dynamic data plane learning
(such as Flood-and-Learn) can reduce the use of multicast in the (such as Flood-and-Learn) can reduce the use of multicast in the
underlay network. underlay network.
Note that ARP resolution using the Mapping System is a stateful Note that ARP resolution using the Mapping System is a stateful
operation on the ITR. The source IP,MAC tuple coming from the ARP operation on the ITR. The source IP,MAC tuple coming from the ARP
skipping to change at page 19, line 48 skipping to change at page 19, line 48
Note that the ITR SHOULD cache the ARP entry. In that case future Note that the ITR SHOULD cache the ARP entry. In that case future
ARP-requests can be handled without sending additional Map-Requests. ARP-requests can be handled without sending additional Map-Requests.
5.3.2. ARP registrations: MAC as a locator record 5.3.2. ARP registrations: MAC as a locator record
When an end-host is attached or detected in an ETR that provides When an end-host is attached or detected in an ETR that provides
L2-overlay services and also supports ARP resolution using the LISP L2-overlay services and also supports ARP resolution using the LISP
control-plane, an additional mapping entry is registered to the control-plane, an additional mapping entry is registered to the
mapping system: mapping system:
o The EID 2-tuple (IID, IP) and its binding to a corresponding host * The EID 2-tuple (IID, IP) and its binding to a corresponding host
MAC address. MAC address.
In this case both the xTRs and the Mapping System MUST support an In this case both the xTRs and the Mapping System MUST support an
EID-to-RLOC mapping where the MAC address is set as a locator record. EID-to-RLOC mapping where the MAC address is set as a locator record.
In order to guarantee compatibility with current implementations of In order to guarantee compatibility with current implementations of
xTRs, the MAC locator record SHALL be encoded following the AFI-List xTRs, the MAC locator record SHALL be encoded following the AFI-List
LCAF Type defined in [RFC8060]. This option would also allow adding LCAF Type defined in [RFC8060]. This option would also allow adding
additional attributes to the locator record, while maintaining additional attributes to the locator record, while maintaining
compatibility with legacy devices. compatibility with legacy devices.
skipping to change at page 21, line 30 skipping to change at page 21, line 28
Note that an IP EID record that carries a MAC address in the locator Note that an IP EID record that carries a MAC address in the locator
record, SHALL be registered with the Proxy Map-Reply bit set. record, SHALL be registered with the Proxy Map-Reply bit set.
5.3.3. Implementation Considerations 5.3.3. Implementation Considerations
While ARP support through the LISP Mapping System fits the LISP While ARP support through the LISP Mapping System fits the LISP
Control-Plane there are a series of considerations to take into Control-Plane there are a series of considerations to take into
account when providing this feature: account when providing this feature:
o As indicated, when and end-host is attached the ETR maintains and * As indicated, when and end-host is attached the ETR maintains and
registers a mapping with the binding EID = <IID, IP> -> RLOC = registers a mapping with the binding EID = <IID, IP> -> RLOC =
<MAC>. <MAC>.
o ARP support through the LISP Mapping System is OPTIONAL and the * ARP support through the LISP Mapping System is OPTIONAL and the
xTRs should allow the possibility to enable or disable the xTRs should allow the possibility to enable or disable the
feature. feature.
o When the ARP entry has not been registered, a Map Server SHOULD * When the ARP entry has not been registered, a Map Server SHOULD
send a Negative Map-Reply with action "No Action" as a response to send a Negative Map-Reply with action "No Action" as a response to
an ARP based Map Request. an ARP based Map Request.
o In case the ITR receives a Negative Map-Reply for an ARP request * In case the ITR receives a Negative Map-Reply for an ARP request
it should fallback to flooding the ARP packet as any other L2 it should fallback to flooding the ARP packet as any other L2
Broadcast packet (as described in Section 5.2.5). Broadcast packet (as described in Section 5.2.5).
o When receiving a positive Map-Reply for an ARP based Map-Request, * When receiving a positive Map-Reply for an ARP based Map-Request,
the ETR MUST recreate the actual ARP Reply, impersonating the real the ETR MUST recreate the actual ARP Reply, impersonating the real
host. As a consequence, ARP support is a stateful operation where host. As a consequence, ARP support is a stateful operation where
the ITR needs to store enough information about the host that the ITR needs to store enough information about the host that
generates an ARP request in order to recreate the ARP Reply. generates an ARP request in order to recreate the ARP Reply.
o ARP replies learned from the Mapping System SHOULD be cached and * ARP replies learned from the Mapping System SHOULD be cached and
the information used to reply to subsequent ARP requests to the the information used to reply to subsequent ARP requests to the
same hosts. same hosts.
6. Optional Deployment Models 6. Optional Deployment Models
The support of an integrated L2 and L3 overlay solution takes The support of an integrated L2 and L3 overlay solution takes
multiple architectural design options, that depend on the specific multiple architectural design options, that depend on the specific
requirements of the deployment environment. While some of the requirements of the deployment environment. While some of the
previous describe specific packet flows and solutions based on the previous describe specific packet flows and solutions based on the
recommended solution, this section documents OPTIONAL design recommended solution, this section documents OPTIONAL design
skipping to change at page 22, line 32 skipping to change at page 22, line 32
and L3 overlays is not the only one possible. In fact, providing L2 and L3 overlays is not the only one possible. In fact, providing L2
extension to some cloud platforms is not always possible and subnets extension to some cloud platforms is not always possible and subnets
need to be extended using the L3 overlay. need to be extended using the L3 overlay.
In order to send all IP traffic (intra- and inter-subnet) through the In order to send all IP traffic (intra- and inter-subnet) through the
L3 overlay the solution MUST change the ARP resolution process L3 overlay the solution MUST change the ARP resolution process
described in Section 5.3.1 to the following one (we follow again described in Section 5.3.1 to the following one (we follow again
Figure 1 to drive the example. End-Device 2 queries about End-Device Figure 1 to drive the example. End-Device 2 queries about End-Device
3): 3):
o End-Device 1 sends a broadcast ARP message to discover the MAC * End-Device 1 sends a broadcast ARP message to discover the MAC
address of 3.0.0.3. address of 3.0.0.3.
o ITR B receives the ARP message and sends a Map-Request to the * ITR B receives the ARP message and sends a Map-Request to the
Mapping System for EID = <IID1,3.0.0.3>. Mapping System for EID = <IID1,3.0.0.3>.
o In this case, the Map-Request is routed by the Mapping system * In this case, the Map-Request is routed by the Mapping system
infrastructure to ETR C, that will send a Map-Reply back to ITR B infrastructure to ETR C, that will send a Map-Reply back to ITR B
containing the mapping EID = <IID1,3.0.0.3> -> RLOC=IP_C. containing the mapping EID = <IID1,3.0.0.3> -> RLOC=IP_C.
o ITR B populates its local cache with the received entry on the L3 * ITR B populates its local cache with the received entry on the L3
forwarding table. Then, using the cache information it sends a forwarding table. Then, using the cache information it sends a
Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End- Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End-
Device 1. Device 1.
o End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends * End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and sends
traffic with destination address 3.0.0.3 and destination MAC, traffic with destination address 3.0.0.3 and destination MAC,
MAC_xTR_B. MAC_xTR_B.
o As the destination MAC address is the one from xTR B, when xTR B * As the destination MAC address is the one from xTR B, when xTR B
receives this traffic it is forwarded using the L3-overlay. receives this traffic it is forwarded using the L3-overlay.
o Note that when implementing this solution, when a host that is * Note that when implementing this solution, when a host that is
local to an ETR moves away, the ETR SHOULD locally send a local to an ETR moves away, the ETR SHOULD locally send a
Gratuitous ARP with its own MAC address and the IP of the moved Gratuitous ARP with its own MAC address and the IP of the moved
host, to refresh the ARP tables of local hosts and guarantee the host, to refresh the ARP tables of local hosts and guarantee the
use of the L3 overlay when connecting to the remote host. use of the L3 overlay when connecting to the remote host.
It is also important to note that using this strategy to extend It is also important to note that using this strategy to extend
subnets through the L3 overlay but still keeping the L2 overlay for subnets through the L3 overlay but still keeping the L2 overlay for
the rest of traffic MAY lead to flow asymmetries. This MAY be the the rest of traffic MAY lead to flow asymmetries. This MAY be the
case in deployments that filter Gratuitous ARPs, or when moved hosts case in deployments that filter Gratuitous ARPs, or when moved hosts
continue using actual L2 information collected before a migration. continue using actual L2 information collected before a migration.
6.2. Data-plane Encapsulation Options 6.2. Data-plane Encapsulation Options
The LISP control-plane offers independence from the data-plane The LISP control-plane offers independence from the data-plane
encapsulation. Any encapsulation format that can carry a 24-bit encapsulation. Any encapsulation format that can carry a 24-bit
instance-ID can be used to provide the unified overlay. instance-ID can be used to provide the unified overlay.
Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] Common encapsulation formats that can be used are [VXLAN-GPE], [LISP]
and [VXLAN]: and [VXLAN]:
o VXLAN-GPE encap: This encapsulation format is defined in * VXLAN-GPE encap: This encapsulation format is defined in
[I-D.ietf-lisp-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 packets and the VNI field directly maps to the Instance-ID used in
the control plane. Note that when using this encapsulation for a the control plane. Note that when using this encapsulation for a
unified solution the P-bit is set and the Next-Protocol field is unified solution the P-bit is set and the Next-Protocol field is
used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in
L3-overlays, and value 0x3 in L2-overlays). L3-overlays, and value 0x3 in L2-overlays).
o LISP encap: This is the encapsulation format defined in the * LISP encap: This is the encapsulation format defined in the
original LISP specification [RFC6830]. The encapsulation allows original LISP specification [RFC6830]. The encapsulation allows
encapsulating both L2 and L3 packets. The Instance-ID used in the encapsulating both L2 and L3 packets. The Instance-ID used in the
EIDs directly maps to the Instance-ID that the LISP header EIDs directly maps to the Instance-ID that the LISP header
carries. At the ETR, after decapsulation, the IID MAY be used to carries. At the ETR, after decapsulation, the IID MAY be used to
decide between L2 processing or L3 processing. decide between L2 processing or L3 processing.
o VXLAN encap: This is a L2 encapsulation format defined in * VXLAN encap: This is a L2 encapsulation format defined in
[RFC7348]. While being a L2 encapsulation it can be used both for [RFC7348]. While being a L2 encapsulation it can be used both for
L2 and L3 overlays. The Instance-ID used in LISP signaling maps L2 and L3 overlays. The Instance-ID used in LISP signaling maps
to the VNI field of the VXLAN header. Providing L3 overlays using to the VNI field of the VXLAN header. Providing L3 overlays using
VXLAN generally requires using the ETR MAC address as destination VXLAN generally requires using the ETR MAC address as destination
MAC address of the inner Ethernet header. The process to learn or MAC address of the inner Ethernet header. The process to learn or
derive this ETR MAC address is not included as part of this derive this ETR MAC address is not included as part of this
document. document.
7. IANA Considerations 7. IANA Considerations
skipping to change at page 25, line 19 skipping to change at page 25, line 19
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lisp-gpe] [I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- Smith, "LISP Generic Protocol Extension", Work in
gpe-19 (work in progress), July 2020. Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July
2020, <https://www.ietf.org/internet-drafts/draft-ietf-
lisp-gpe-19.txt>.
[I-D.ietf-lisp-pubsub] [I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., AlbertoRodriguezNatal, Ermagan, V., Cabellos-Aparicio, A.,
Barkai, S., and M. Boucadair, "Publish/Subscribe Barkai, S., and M. Boucadair, "Publish/Subscribe
Functionality for LISP", draft-ietf-lisp-pubsub-07 (work Functionality for LISP", Work in Progress, Internet-Draft,
in progress), January 2021. draft-ietf-lisp-pubsub-09, 28 June 2021,
<https://www.ietf.org/archive/id/draft-ietf-lisp-pubsub-
09.txt>.
[I-D.ietf-lisp-vpn] [I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", draft-ietf-lisp-vpn-06 (work in Networks (VPNs)", Work in Progress, Internet-Draft, draft-
progress), August 2020. ietf-lisp-vpn-06, 3 August 2020, <http://www.ietf.org/
internet-drafts/draft-ietf-lisp-vpn-06.txt>.
[I-D.kouvelas-lisp-map-server-reliable-transport] [I-D.kouvelas-lisp-map-server-reliable-transport]
Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C., Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C.,
Kouvelas, I., and J. Arango, "LISP Map Server Reliable Kouvelas, I., and J. Arango, "LISP Map Server Reliable
Transport", draft-kouvelas-lisp-map-server-reliable- Transport", Work in Progress, Internet-Draft, draft-
transport-05 (work in progress), August 2019. kouvelas-lisp-map-server-reliable-transport-06, 26 April
2021, <https://www.ietf.org/archive/id/draft-kouvelas-
lisp-map-server-reliable-transport-06.txt>.
Authors' Addresses Authors' Addresses
Marc Portoles Comeras Marc Portoles Comeras
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: mportole@cisco.com Email: mportole@cisco.com
Vrushali Ashtaputre Vrushali Ashtaputre
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: vrushali@cisco.com Email: vrushali@cisco.com
Victor Moreno Victor Moreno
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: vimoreno@cisco.com Email: vimoreno@cisco.com
Fabio Maino Fabio Maino
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States of America
Email: fmaino@cisco.com Email: fmaino@cisco.com
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
USA United States of America
Email: farinacci@gmail.com Email: farinacci@gmail.com
 End of changes. 91 change blocks. 
107 lines changed or deleted 112 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/