| Internet-Draft | L2/L3 EID Mobility | November 2024 |
| Portoles, et al. | Expires 8 May 2025 | [Page] |
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 for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models.¶
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].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 8 May 2025.¶
Copyright (c) 2024 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes the architecture and design options required 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 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 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].¶
LISP related terms are defined as part of the LISP specification [RFC9300] and [RFC9301], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server (MS) and Map-Resolver (MR).¶
The following figure illustrates the reference system used to support the packet flow description throughout this document. The system presents 4 sites. Site A and Site D provide access to different subnets (non-extended), while Site B and Site C extend a common subnet. The xTR in each one of the sites registers EIDs from the sites with the LISP Mapping System and provides support to encapsulate overlay (EID) traffic through the underlay (RLOC space).¶
,-------------.
(Mapping System )
-+------------+
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
.-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
.-.' '.-.
( L3 Underlay )
( (RLOC Space) )
'.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
: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
MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3
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-subnet) traffic. The rest of the document follows this recommendation to describe the packet flows.¶
However, note that in a different selection approach, intra-subnet 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 restricting the use of the L2 overlay to non-IP traffic.¶
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 unified architecture:¶
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 describe the flows.¶
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
: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)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Inter-subnet traffic is encapsulated using the L3 overlay. The process to encapsulate this traffic is the same as described in [RFC9300] and [RFC9301]. We describe the packet flow here for completeness¶
The following is a sequence example of the unicast packet flow and 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 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 End-Device 4 (e.g. it is learned using a DNS service).¶
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 subnet End-Device 1 sends the packet following its routing table to ITR A (e.g., it is its default gateway).¶
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 Map-request to the mapping database system looking up for EID=<IID1,2.0.0.4>.¶
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>.¶
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 locator of ETR D.¶
ITR A populates the local map-cache with the EID to RLOC mapping, and encapsulates all subsequent packets with a destination IP 2.0.0.4 using destination RLOC=IP_D.¶
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.¶
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 Data Driven SMRs to trigger the updates of the ITR map-caches.¶
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 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 updated with the new EID-to-RLOC mapping (location) for End-Device 1.¶
The Mapping System, after receiving the new registration for 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 database mapping information and stops registering EID=<IID1, 1.0.0.1>.¶
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.¶
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=<IID1, 1.0.0.1>.¶
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 EID. The Map-Reply includes the new EID-to-RLOC mapping for End-Device 1 with RLOC=IP_D.¶
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=<IID1, 1.0.0.1> to populate the map-cache of ITR A.¶
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.¶
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.¶
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=<IID1, 1.0.0.1>). 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=<IID1, 1.0.0.1>). Now the mapping system is updated with the new EID-to-RLOC mapping (location) for the mobile end-device (e.g. End-Device 1).¶
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-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=<IID1, 1.0.0.1>).¶
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].¶
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=<IID1, 1.0.0.1>). Once the map-cache is updated, traffic is tunneled by the ITR to the new location.¶
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 ([I-D.ietf-lisp-vpn]).¶
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:¶
The EID 2-tuple (IID, IP) with its binding to a corresponding ETR locator set (IP RLOC)¶
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 the following figure:¶
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | Rsvd1 | Flags | Type = 2 | IID mask-len | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | 4 + n | Instance-ID... | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | ...Instance-ID | EID-AFI = 1 or 2 | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EID-Prefix (IPv4 or IPv6) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The L3 EID record follows the structure as described in [RFC9301].¶
The interface between the xTRs and the Mapping System is described in [RFC9301] 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.ietf-lisp-map-server-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 L3 EIDs as described in Section 4.2.4.¶
One of the key elements to support end-host mobility using the LISP architecture is the Solicit-Map-Request (SMR). This is a special message by means of which an ETR can request an ITR to send a new Map-Request for a particular EID record. In essence the SMR message is used as a signal to indicate a change in mapping information and it is described in [RFC9301].¶
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 receives traffic with that EID as destination.¶
The particular strategy to maintain an Away Table is implementation 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 the Map-Server. In essence the table SHOULD provide support to the following:¶
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], and [RFC8378].¶
The LISP specification ([RFC9300]) 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.¶
In order to support L2 packet flow descriptions in this section we use Figure 1 as reference. This section uses Sites B and C to describe the flows.¶
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
: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)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Bridged traffic is encapsulated using the L2 overlay. This section 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 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 (e.g., learned through ARP).¶
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.¶
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 ITR sends a Map-Request to the mapping database system looking up for EID=<IID2,0:0:3:0:0:3>.¶
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>. Alternatively, depending on the mapping system configuration, a Map-Server which is part of the mapping database system MAY send a Map-Reply directly to ITR B.¶
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 locator of ETR C.¶
ITR B populates the local map-cache with the EID to RLOC mapping, and encapsulates all subsequent packets with a destination MAC 0:0:3:0:0:3 using destination RLOC=IP_C.¶
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.¶
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 Data Driven SMRs to trigger the updates of the ITR map-caches.¶
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>. 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>.¶
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 locator set (IP_B). ETR B removes then its local database mapping and stops registering <IID2, 0:0:3:0:0:2>.¶
Any PiTR or ITR participating in the same L2-overlay (corresponding to IID2) that was encapsulating traffic to 0:0:3:0:0:2 before the migration continues encapsulating this traffic to ETR B.¶
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 generate a Solicit-Map-Request (SMR) message that is sent to the ITR for (IID2,0:0:3:0:0:2).¶
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 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, replacing the previous one, and traffic is then forwarded to the new location.¶
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.¶
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>. 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>.¶
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 (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>.¶
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].¶
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>. Once the map-cache is updated, traffic is tunneled by the ITR to the new location.¶
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).¶
An Instance-ID can be used for L2 overlay segmentation. An important aspect of L2 segmentation is the mapping of VLANs to IIDs. In this case a Bridge Domain (which is the L2 equivalent to a VRF as a forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge domain or different VLAN-IDs on different ports may map to a common Bridge Domain, which in turn maps to an IID in the L2 overlay. When ethernet traffic is double tagged, usually the outer 802.1Q tag will be mapped to a bridge domain on a per port basis, and the inner 802.1Q tag will remain part of the payload to be handled by the overlay. The IID should therefore be able to carry ethernet traffic with or without an 802.1Q header. A port may also be configured as a trunk and we may chose to take the encapsulated traffic and map it to a single IID in order to multiplex traffic from multiple VLANs on a 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 examples and are not exhaustive.¶
When an end-host is attached or detected in an ETR that provides L2-overlay services, a database Mapping is registered to the mapping system with the following structure:¶
The EID 2-tuple (IID, MAC) with its binding to a locator set (IP RLOC)¶
The registration of these EIDs MUST follow the LCAF format as defined in [RFC8060] and as illustrated in the following figure:¶
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | Rsvd1 | Flags | Type = 2 | IID mask-len | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | 4 + n | Instance-ID... | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | ...Instance-ID | EID-AFI = 6 | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Layer-2 MAC Address ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| ... Layer-2 MAC Address | Priority | Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | M Priority | M Weight | Unused Flags |L|p|R| | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Loc-AFI | Locator.... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| ... Locator +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The L2 EID record follows the structure as described in [RFC9301].¶
The interface between the xTRs and the Mapping System is described in [RFC9301] and this document follows the specification as described there. When available, the registrations MAY be implemented over a 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.¶
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 receives traffic with that EID as destination.¶
The particular strategy to maintain a SMR table is implementation specific. In essence the table SHOULD provide support for the following:¶
Broadcast and Multicast traffic on the L2-overlay is supported by either replicated unicast, or underlay (RLOC) multicast.¶
xTRs that offer L2 overlay services and are part of the same Instance-ID join a common Multicast Group. When required, this group allows ITRs to send traffic that needs to be replicated (flooded) to all ETRs participating in the L2-overlay (e.g., broadcast traffic within a subnet). When the core network (RLOC space) supports native multicast ETRs participating in the L2-overlay join a (*,G) group associated to the Instance-ID.¶
When multicast is not available in the core network, each xTR that is part of the same instance-ID SHOULD register a (S,G) entry to the mapping system using the procedures described in [RFC8378], where S is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows and ITR to know which ETRs are part of the L2 overlay and it can head-end replicate traffic to.¶
Following the same case, when multicast is not available in the core network, the procedures in [RFC8378] can be used to ensure proper distribution of link-local multicast traffic across xTRs participating in the L2 overlay. In such case, the xTRs SHOULD join a (S,G) entry with S being 0000-0000-0000/0 and where G is 0100-0000-0000/8.¶
An ITR attempts to resolve MAC destination misses through the Mapping System. When the destination host remains undiscovered the destination is considered an Unknown Unicast.¶
A Map-Server SHOULD respond to a Map-Request for an undiscovered host with a Negative Map-Reply with action "Native Forward". Alternatively the action "Drop" may be used in order to suppress Unknown Unicast forwarding.¶
An ITR that receives a Negative Map-Reply with Action "Native Forward" will handle traffic for the undiscovered host as L2 Broadcast traffic and will be unicast replicated or flooded using underlay multicast to the rest of ETRs in the Layer-2 overlay.¶
Upon discovery of a previously unknown unicast MAC EID, a data triggered SMR for the discovered EID should be sent by the discovery ETR back to the ITRs that are flooding the unknown unicast traffic. This would allow ITRs to refresh their caches and stop flooding unknown unicast traffic as necessary.¶
When using a L2 overlay and the encapsulated traffic is IP traffic, the Time-to-Live value of the inner IP header MUST remain unmodified during encapsulation and decapsulation. Network hops traversed as part of the L2 overlay SHOULD be hidden to tools like traceroute and applications that require direct L2 connectivity.¶
L2 multihoming support requires additional mechanisms to those specified in [RFC9300] and [RFC9301] to provide LISP multihoming.¶
In order to support packet flow descriptions related to L2 multihoming, this section uses Figure 4 as a reference. The figure expands site B in the previous figures to become a multihomed site with identifier site-ID "b".¶
/ \
RLOC=IP_B1 RLOC=IP_B2
+-+--+--+ +-+--+--+
.| xTR B1|.-.--.-.| xTR B2 |.-.
( +-+--+--+ +-+--+--+ )
.' Site B )
( (site-ID b) .'
'--'._.'. .'._.'--'._.'. )
'--' | '--'
'--------'
: End :
:Device 2:
'--------'
(IID1,3.0.0.2)
(IID2,0:0:3:0:0:2)
The site-ID, as defined in [RFC9301], is used as the identifier that enables logical grouping of multiple xTRs that provide multihomed access to a L2 domain.¶
All EID-to-RLOC mappings from ETRs in a L2 multihomed site MUST be registered with the site-ID, by setting bit I in the Map-Register message.¶
Providing L2 multihomed access support for L2 domains requires that participating xTRs discover each other and implement procedures like designated forwarder selection or split-horizon filtering.¶
To this end, the discovery and grouping of multihomed xTRs is supported through registration, by all participating xTRs, of a common EID that carries the site-ID of the site that they are providing multihoming access to. The Mapping System merges these registrations and notifies all participant xTRs about the aggregated list.¶
Specifically, multihomed xTRs use an EID of the Distinguished Name type [I-D.ietf-lisp-name-encoding] with name "L2-xTRs-<site-ID>" to support the multihomed site-ID registration. This EID is registered by each xTR with their corresponding locator set in the RLOC record. XTRs MUST set the merge-request bit (a bit) in the registration. XTRs MUST also set the want-map-notify bit (M bit) so that they can learn about all participating xTRs when they register.¶
In its turn the Mapping System, when receiving every multihomed site-ID registration, MUST aggregate the locator-set received from each xTR and send a Map-Notify to all participating xTRs with the resulting locator set list.¶
Note that the xTRs and Mapping System use a dedicated IID to carry and hold these regisrations. The specific name used is predefined as specified in this document and only used within the dedicated IID.¶
Using the reference figure above, the process of xTR discovery in a L2 multihomed group works as follows:¶
xTR B1, registers EID with name "L2-xTRs-b" and IP_B1 as its corresponding locator-set¶
The Map-Server creates a registration entry with the mapping EID="L2-xTRs-b" -> RLOC=IP_B1. It also sends a Map-Notify to xTR B1 with the mapping¶
xTR B2, registers EID with name "L2-xTRs-b" and IP_B2 as its corresponding locator-set.¶
The Map-Server merges the new registration with the existing one obtaining a mapping with EID="L2-xTRs-b" -> RLOC=<IP_B1, IP_B2>. It also sends a Map-Notify to xTR B1 and xTR B2 with the aggregated mapping.¶
After the Map-Server notifies xTRs with the merged list of locators, all xTRs have an up to date list of participating xTRs. Whenever a xTR joins or leaves the multihoming group, the Map-Server MUST send an updated Map-Notify to all the remaining participants.¶
When multiple xTR are providing multihomed access to a L2 site, a Designated Forwarder must be selected to forward L2 broadcast traffic to and from other sites.¶
LISP sites use the M-priority field in the RLOC record of mappings to rank which xTR is the selected forwarder for a site. When the M-priority is the same, the xTRs use RLOC addresses to break the tie.¶
Using the reference figure, the following sequence illustrates how the forwarder is selected and notified to all of the xTRs:¶
xTR B1, registers the mapping EID="L2-xTRs-b" -> RLOC=IP_B1 with the Mapping System and sets the M-priority value of the RLOC to 1¶
xTR B2, registers the mapping EID="L2-xTRs-b" -> RLOC=IP_B2 with the Mapping System and sets the M-priority value of the RLOC to 2¶
The Map-Server merges the registrations and sends a Map-Notify to both xTR B1 and xTR B2, with the merged locator-set and respecting the M-priority of each RLOC¶
On receiving the Map-Notify xTR B1 finds its own RLOC as having the best M-priority and starts acting as the broadcast Forwarder¶
On receiving the Map-Notify xTR B2 discovers that xTR B1 has a better M-priority, sets itself as backup forwarder. xTR B1 SHOULD start monitoring xTR B1 to take an active forwarder role if xTR B1 becomes unavailable.¶
In case multihomed xTRs register the multihomed site-ID EID with the same M-priority, the xTRs will use RLOC address sorting to break the tie. XTRs MUST use the numerical IP ascending order defined in [RFC9301] to sort the RLOCs and break the tie.¶
Note that multihomed xTRs can register multiple site-IDs with different M-priorities and select a different Designated Forwarder for each site. When different L2 segments want to use a different forwarder they are assigned to the corresponding site according to the preference.¶
A xTR that discovers that is part of a L2 multihoming group, SHOULD implement procedures to ensure that packets forwarded from the L2 multihomed site are not looped back into the site. The list of RLOCs learned through the L2 multihoming site-ID registration MAY be used to apply the necessary filtering to encapsulated packets received by the xTR from peer xTRs.¶
When providing multihomed access to a L2 site, any xTR can be used to forward traffic to and from remote sites. Unicast traffic is typically load split between the multiple xTRs. The Designated Forwarder MAY be the only one joining the multicast group or replication list (following Section 5.2.5).¶
If a non Designated Forwarder decides to join the multicast group, it MUST implement split horizon filtering as well as ensure that remote traffic is not forwarded to the local site, to avoid duplication.¶
Specifically, xTRs that are providing active multihoming access to a site MUST support the following:¶
All active xTRs register site L2 mappings with the Mapping System. The registration must have the I bit set and carry both the site-ID and the corresponding xTR-ID.¶
The selected Designated Forwarder joins the L2 multicast group or replication list as specified in Section 5.2.5¶
The selected Designated Forwarder is the only one that can forward broadcast traffic to and from remote sites.¶
xTRs that are not Designated Forwarder are recommended not to join the L2 broadcast group. When a non Designated Forwarder joins the broadcast group it MUST implement split horizon and broadcast suppression mechanisms to avoid traffic duplication and loops in the site.¶
A large majority of applications are IP based and, as a consequence, end systems are typically provisioned with IP addresses as well as MAC addresses.¶
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 to support ARP resolution at the ITR.¶
In order to provide this support, ETRs handle and register an additional EID-to-RLOC mapping as follows,¶
EID-record contents = <IID, IP>, RLOC-record contents <MAC>.¶
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 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 ARP-IID respectively. By using these definitions, we do not intend to coin new terminology, nor is there anything special about those IIDs that would make them differ from the generic definition of an IID. The types of mappings expected in such a system are summarized below:¶
EID = <IID1, IP> to RLOC = <IP-RLOC> (L3-overlay)¶
EID = <IID2, MAC> to RLOC = <IP-RLOC> (L2-overlay)¶
EID = <IID3, IP> to RLOC = <MAC-RLOC> (ARP/ND mapping)¶
The following packet flow sequence describes the use of the LISP Mapping System to support ARP resolution for hosts residing in a 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 both have IP addresses within the same subnet:¶
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.¶
ITR B receives the ARP message, but rather than flooding it on the overlay network sends a Map-Request to the mapping database system for EID = <IID2,3.0.0.3>.¶
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 0:0:3:0:0:3.¶
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.¶
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 ITR B is sent over the L2-overlay as described above in Section 5.1.1.¶
This example shows how LISP, by replacing dynamic data plane learning (such as Flood-and-Learn) can reduce the use of multicast in the underlay network.¶
Note that ARP resolution using the Mapping System is a stateful operation on the ITR. The source IP,MAC tuple coming from the ARP request have to be stored to generate the ARP-reply when the Map-Reply is received.¶
Note that the ITR SHOULD cache the ARP entry. In that case future ARP-requests can be handled without sending additional Map-Requests.¶
When an end-host is attached or detected in an ETR that provides L2-overlay services and also supports ARP resolution using the LISP control-plane, an additional mapping entry is registered to the mapping system:¶
The EID 2-tuple (IID, IP) and its binding to a corresponding host MAC address.¶
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.¶
In order to guarantee compatibility with current implementations of xTRs, the MAC locator record SHALL be encoded following the AFI-List LCAF Type defined in [RFC8060]. This option would also allow adding additional attributes to the locator record, while maintaining compatibility with legacy devices.¶
This mapping is registered with the Mapping System using the following EID record structure,¶
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | Rsvd1 | Flags | Type = 2 | IID mask-len | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | 4 + n | Instance-ID... | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | ...Instance-ID | EID-AFI = 1 or 2 | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EID-Prefix (IPv4 or IPv6) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | M | Unused Flags |L|p|R| AFI = 16387 | | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 2 + 6 | AFI = 6 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Layer-2 MAC Address ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| ... Layer-2 MAC Address | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.¶
An EID record with a locator record that carries a MAC address follows the same structure as described in [RFC9301]. However, some fields of the EID record and the locator record require special consideration:¶
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.¶
While ARP support through the LISP Mapping System fits the LISP Control-Plane there are a series of considerations to take into account when providing this feature:¶
As indicated, when and end-host is attached the ETR maintains and registers a mapping with the binding EID = <IID, IP> -> RLOC = <MAC>.¶
ARP support through the LISP Mapping System is OPTIONAL and the xTRs should allow the possibility to enable or disable the feature.¶
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 an ARP based Map 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 Broadcast packet (as described in Section 5.2.5).¶
When receiving a positive Map-Reply for an ARP based Map-Request, the ETR MUST recreate the actual ARP Reply, impersonating the real host. As a consequence, ARP support is a stateful operation where the ITR needs to store enough information about the host that generates an ARP request in order to recreate the ARP Reply.¶
ARP replies learned from the Mapping System SHOULD be cached and the information used to reply to subsequent ARP requests to the same hosts.¶
The support of an integrated L2 and L3 overlay solution takes multiple architectural design options, that depend on the specific requirements of the deployment environment. While some of the previous describe specific packet flows and solutions based on the recommended solution, this section documents OPTIONAL design considerations that differ from the recommended one but that MAY be required on alternative deployment environments.¶
As pointed out at the beginning the recommended selection of the 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 need to be extended using the L3 overlay.¶
In order to send all IP traffic (intra- and inter-subnet) through the L3 overlay the solution MUST change the ARP resolution process described in Section 5.4.1 to the following one (we follow again Figure 1 to drive the example. End-Device 2 queries about End-Device 3):¶
End-Device 1 sends a broadcast ARP message to discover the MAC address of 3.0.0.3.¶
ITR B receives the ARP message and sends a Map-Request to the Mapping System for EID = <IID1,3.0.0.3>.¶
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 containing the mapping EID = <IID1,3.0.0.3> -> RLOC=IP_C.¶
ITR B populates its local cache with the received entry on the L3 forwarding table. Then, using the cache information it sends a Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end End-Device 1.¶
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, MAC_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.¶
Note that when implementing this solution, when a host that is 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 host, to refresh the ARP tables of local hosts and guarantee the use of the L3 overlay when connecting to the remote host.¶
It is also important to note that using this strategy to extend 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 case in deployments that filter Gratuitous ARPs, or when moved hosts continue using actual L2 information collected before a migration.¶
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]:¶
VXLAN-GPE encap: This encapsulation format is defined in [RFC9305]. 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).¶
LISP encap: This is the encapsulation format defined in the LISP specification [RFC9300]. 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 carries. At the ETR, after decapsulation, the IID MAY be used to decide between L2 processing or L3 processing.¶
VXLAN encap: This is a L2 encapsulation format defined in [RFC7348]. While being a L2 encapsulation it can be used both for L2 and L3 overlays. The Instance-ID used in LISP signaling maps to the VNI field of the VXLAN header. Providing L3 overlays using VXLAN generally requires using the ETR MAC address as destination MAC address of the inner Ethernet header. The process to learn or derive this ETR MAC address is not included as part of this document.¶
This memo includes no request to IANA.¶
This draft builds on top of two expired drafts that introduced the concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft-hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the combined authors of those drafts, that SHOULD be considered main contributors of this draft as well: Vina Ermagan, Dino Farinacci, Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael Smith.¶