LISP L2/L3 EID Mobility Using a Unified Control Plane

4.1.1. Routed Traffic Flow: L3 Overlay use

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.¶

4.1.2. L3 Mobility Flow

The support to L3 mobility covers the requirements to allow an end-host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L3 routing domain. This support MUST ensure convergence of L3 forwarding (IPv4/IPv6 based) from the old location to the new one when the host completes its move.¶

The update of the ITR map-caches when EIDs move MAY be achieved using Data Driven SMRs or the Publish/Subscribe mechanisms defined in [I-D.ietf-lisp-pubsub]. The following two sections are sequence descriptions of the packet flow when End-Device 1 in the reference figure roams to site D.¶

4.2.1. L3 Segmentation

LISP support of segmentation and multi-tenancy is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in [RFC8060] and its use in [RFC8111].¶

Instance-IDs can be used to support L3 overlay segmentation, such as in extended VRFs or multi-VPN overlays ([I-D.ietf-lisp-vpn]).¶

4.2.2. L3 Database-Mappings

When an end-host is attached or detected in an ETR that provides L3-overlay services and mobility, a database Mapping is registered to the mapping system with the following structure:¶

• 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].¶

4.2.3. LISP Mapping System support

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.¶

4.2.5. L3 multicast support

L3 Multicast traffic on the overlay MAY be supported by either replicated unicast, or underlay (RLOC) multicast. Specific solutions to support L3 multicast over LISP controlled overlays are specified in in [RFC6831], and [RFC8378].¶

4.2.6. Time-to-Live Handling in Data-Plane

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.¶

5.1.2. L2 Mobility Flow

The support to L2 mobility covers the requirements to allow an end-host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L2 domain (e.g. extended VLAN). This support MUST ensure convergence of L2 forwarding (MAC based) from the old location to the new one, when the host completes its move.¶

The update of the ITR map-caches when EIDs move MAY be achieved using Data Driven SMRs or the Publish/Subscribe mechanisms defined in [I-D.ietf-lisp-pubsub]. The following two sections are sequence descriptions of the packet flow when End-Device 2 in the reference figure roams to site C, which is extending its own subnet network.¶

5.2.1. L2 Segmentation

As with L3 overlays, LISP support of L2 segmentation is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a Mapping System and MAY be used to identify the overlay type (e.g., L2 or L3 overlay).¶

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.¶

5.2.2. L2 Database-Mappings

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].¶

5.2.3. Interface to the LISP Mapping System

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.¶

5.2.7. Time-to-Live Handling in Data-Plane

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.¶

5.3.1. Identification of L2 multihomed sites

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.¶

5.3.2. Discovery of peer xTRs in multihomed sites

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.¶

5.3.3. Designated Forwarder Selection

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.¶

5.3.4. Split Horizon filtering

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.¶

5.3.5. Multihoming operation

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.¶

5.4.2. ARP registrations: MAC as a locator record

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:¶

Locator Count:

This value SHOULD be set to 1.¶

Instance-ID:

This is the IID used to provide segmentation of the L2-overlays, L3 overlays and ARP tables.¶

Priority and Weight:

IP to MAC bindings are one to one bindings. An ETR SHOULD not register more than one MAC address in the locator record together with an IP based EID. The Priority of the MAC address record is set to 255. The Weight value SHOULD be ignored and the recommendation is to set it to 0.¶

L bit:

This bit of the locator record SHOULD only be set to 1 when an ETR is registering its own IP to MAC binding.¶

p bit:

This bit of the locator record SHOULD be set to 0.¶

R bit:

This bit of the locator record SHOULD be set to 0.¶

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.¶

5.4.3. Implementation Considerations

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.¶