Decoupled Interconnection of LISP and EVPN VXLAN Domains

Introduction This document describes decoupled Layer 2 and Layer 3 services between a Locator/ID Separation Protocol (LISP) domain and an Ethernet VPN (EVPN) domain within the same administrative domain. Both domains use VXLAN , with LISP mapping and BGP EVPN control planes, respectively. Separate border devices terminate their own overlays; reachability, replication state, underlay routing, and forwarding contexts remain independent. The Layer 2 service extends an Ethernet bridge domain through a handoff between a LISP Layer 2 border and an EVPN Gateway (). The Layer 3 service connects a PxTR and EVPN-GW through tenant IP transit, using a suitable IGP or eBGP and ordinary redistribution of selected IP prefixes at each border (). Service selection depends on the required Ethernet or routed IP connectivity rather than the subnet layout. states the service requirements; describes the additional behavior for routed connectivity within a common IP prefix. LISP MAC-address EIDs are described in . The LISP Layer 2 procedures used here are described in , which remains work in progress. This document applies the decoupled Ethernet-handoff model of to a LISP Layer 2 service and an EVPN service; RFC 9014 does not itself specify LISP-EVPN interworking. This informational document describes an architecture using existing protocols. It does not define a new wire protocol or direct translation between LISP endpoint messages and EVPN routes.

Definition of Terms LISP terminology follows and , including Instance ID (IID), Map-Server (MS), and Map-Resolver (MR).

Bridge Domain (BD):: A Layer 2 forwarding context for Ethernet switching and eligible BUM replication, independent of IP addressing.
BUM:: Broadcast, unknown-unicast, and multicast Ethernet traffic.
Decoupled Routed Interconnect:: Separate PxTR and EVPN-GW devices exchanging IP-prefix reachability and forwarding tenant IP packets across tenant IP transit.
eBGP:: External BGP, a BGP session between peers in different autonomous systems .
Ethernet-Handoff Layer 2 Interconnect:: A LISP Layer 2 border and an EVPN-GW on separate devices, connected by an Ethernet service handoff.
Ethernet Handoff:: The Ethernet connection between the LISP Layer 2 border and EVPN-GW, identified by interfaces and optional VLAN tags.
EVPN Domain:: A domain using BGP EVPN as its control plane and VXLAN as its overlay data plane.
EVPN Gateway (EVPN-GW):: The EVPN-facing border, acting as an EVPN PE/NVE and VXLAN VTEP. It provides an Ethernet attachment for Layer 2 or IP-prefix exchange for Layer 3.
EVPN Route Type 2 (RT-2):: The MAC/IP Advertisement route , distributing MAC reachability and optional associated IP information.
EVPN Route Type 3 (RT-3):: The Inclusive Multicast Ethernet Tag (IMET) route , used for EVPN BUM delivery .
EVPN Route Type 5 (RT-5):: The IP Prefix route .
IGP:: An Interior Gateway Protocol for distributing IP reachability within a routing domain.
Interconnect:: The separate LISP-facing and EVPN-facing borders and their Ethernet handoff or tenant IP transit.
LISP Domain:: A domain using LISP as its control plane and VXLAN as its overlay data plane.
LISP Layer 2 Border:: A LISP xTR terminating its VXLAN overlay and providing a Layer 2 service on the Ethernet handoff. This role is distinct from the routed PxTR.
MAC EID:: A MAC address used as a LISP endpoint identifier, scoped by an IID, with IP RLOCs identifying the endpoint's overlay location.
PxTR:: A router performing Proxy-ITR and Proxy-ETR functions ; the LISP-facing border of the routed interconnect.
Route Reflector (RR):: A BGP route reflector used to distribute EVPN routes within the EVPN domain.
Tenant IP Transit:: A routed connection between the PxTR and EVPN-GW in the tenant forwarding context, carrying IP packets and route exchange.
VNI:: A VXLAN Network Identifier associated with a Layer 2 bridge domain or Layer 3 routing context.
VRF:: A Virtual Routing and Forwarding instance representing a Layer 3 forwarding context.
VTEP:: A VXLAN Tunnel End Point .

Interconnect Service Requirements The LISP and EVPN domains have independent reachability systems even when both use VXLAN. An interconnect needs to identify the service being joined, expose reachability through the appropriate border, and preserve tenant isolation and applicable policy. Matching VNI values or IP prefixes do not establish a service. An Ethernet service needs an explicit bridge-domain and handoff mapping, MAC reachability, and controlled BUM delivery. It preserves endpoint Ethernet frames across the domain boundary. IP address resolution, when used, operates within that Ethernet service. describes its architecture and forwarding procedures. A routed IP service needs an explicit forwarding-context mapping and selected IP-prefix reachability in each direction. Routing uses destination IP lookup and does not extend the Ethernet broadcast domain. describes its architecture and forwarding procedures. IP subnet layouts affect deployment requirements. For example, a shared Ethernet service can support H1 and H2 in 203.0.113.0/24. A routed service can connect separately allocated prefixes such as 192.0.2.0/24 and 198.51.100.0/24 using subnet-prefix exchange. Routed connectivity within a common prefix instead needs precise destination ownership and an address-resolution mechanism that directs traffic to the endpoint-facing router, as described in . Advertising the common aggregate from both domains is not sufficient.

Layer 2 Interconnection The Layer 2 service extends an Ethernet bridge domain across the two overlay domains. Service selection and MAC forwarding are independent of IP addressing. The service can carry one or more IP subnets and non-IP Ethernet traffic, subject to service policy. It does not itself route between IP subnets; communication between those subnets requires a tenant router or an Integrated Routing and Bridging (IRB) function in addition to the Ethernet service. Using the same IP prefix or the same VNI in two domains does not establish the service.

Ethernet-Handoff Reference Architecture A LISP Layer 2 border and an EVPN-GW on separate devices terminate their respective VXLAN overlays and connect through an Ethernet/VLAN handoff. Each border treats the handoff as an attachment to its own bridge domain. This architecture follows the decoupled approach in Section 3 of ; the use of a LISP Layer 2 border is an architectural application described here.

Decoupled Ethernet-Handoff Layer 2 Interconnect ]]> Administrative configuration maps the LISP Layer 2 IID, its VXLAN VNI and bridge domain, the handoff interface/VLAN, and the EVPN bridge domain, MAC-VRF, route targets, and Layer 2 VNI. The two VNIs can differ. The Ethernet frame and service identity are retained while each border supplies its own egress encapsulation. Bridging preserves the inner IP TTL or Hop Limit and the endpoint source and destination MAC addresses. No direct LISP-to-BGP exchange is required across this handoff. LISP mappings remain inside the LISP domain; EVPN routes remain inside the EVPN domain. In particular, RT-2 is not translated into a Map-Register, and RT-3 is not translated into a LISP replication list. Source-MAC learning on the Ethernet attachment supplies reachability for the baseline described below.

MAC Learning and Reachability When a frame from H1 crosses the handoff into the EVPN-GW, the gateway learns H1's original source MAC on that attachment and originates an RT-2 route into the EVPN domain according to and . When a frame from H2 crosses the handoff into the LISP border, the border learns H2's original source MAC on that attachment. It registers the MAC EID, scoped by the service IID, with its own RLOC set in the LISP mapping system. The Layer 2 registration and lookup procedures are those of Section 6 of . Known-unicast forwarding follows . The border tracks the learning source per service. Handoff-learned MACs are eligible for export as handoff-attached reachability; overlay-learned MACs remain overlay destinations. Reflected frames or additional interdomain paths must not create false ownership or cause overlay-learned MACs to be exported back into the same overlay as newly attached endpoints. MAC aging, removal, movement, or handoff failure requires withdrawal or replacement of the corresponding RT-2 route or LISP registration using native procedures. Registration refresh and cache convergence must reflect valid ownership, handoff reachability, and mapping lifetimes. Cross-domain movement uses relearning and each domain's mobility procedures; this document defines no translation of EVPN mobility sequence numbers into LISP state or hitless-mobility guarantee. Silent-endpoint discovery is discussed in .

Known Unicast Forwarding After reachability for H2 has been learned, a frame from H1 follows this path. The reverse path uses the corresponding EVPN MAC route for H1 and the LISP mapping for H1.

H1 sends an Ethernet frame addressed to H2's MAC.
The ingress LISP xTR resolves H2's MAC EID to the LISP border's RLOC and encapsulates the frame using the LISP service's Layer 2 VNI.
The LISP border decapsulates the frame and bridges it onto the service's Ethernet handoff without rewriting the endpoint MAC addresses.
The EVPN-GW uses its installed MAC forwarding state to select H2's EVPN VTEP and re-encapsulates the frame using the EVPN service's Layer 2 VNI.
The egress VTEP applies the configured policy and bridges the frame to H2.

The borders forward on MAC reachability in this model. RT-5 subnet-prefix redistribution does not select the destination endpoint for these bridged frames.

Broadcast, Unknown Unicast, and Multicast Each domain maintains independent replication state: the LISP procedures in Sections 6.2.5 and 6.2.6 of , and the EVPN BUM procedures, including IMET participation, in . Replication lists and underlay multicast groups need not span the boundary. In either direction, a broadcast reaches the active border as one eligible copy, crosses the Ethernet handoff, and is replicated by the receiving border as attachment-originated traffic. Borders do not reflect frames onto their ingress attachment; native overlay split-horizon rules continue to apply. An unresolved MAC at a LISP ingress first triggers a mapping lookup; a cache miss alone does not authorize flooding. If the mapping result permits unknown-unicast flooding, the service can supply a copy to the handoff. The receiving border performs its own lookup to forward as known unicast or apply its unknown-unicast policy. Address resolution or permitted unknown unicast can trigger MAC learning for silent endpoints. Dropping unknown unicast in either domain can prevent their delivery. The service needs compatible discovery behavior in both directions, with alternative discovery, provisioning, or validated bindings when unknown unicast is suppressed. This document defines no LISP/EVPN multicast control-plane translation. Multicast follows the service's receiver policy, with the handoff included for groups that can have receivers in the other domain. Controlled flooding or IGMP/MLD snooping can provide delivery. Snooping requires valid membership and multicast-router-port state across the handoff, established by the necessary reports and queries crossing the service or equivalent configuration. Reserved bridge-control frames follow the selected Ethernet service rules and are not indiscriminately flooded.

ARP and IPv6 Neighbor Discovery The service bridges permitted ARP and IPv6 Neighbor Discovery (ND) frames, including broadcast, multicast, and unicast forms. For on-link hosts H1 (203.0.113.10/24) and H2 (203.0.113.20/24), H1's ARP request and H2's reply cross the handoff, triggering MAC learning as described in . For an off-link destination, the endpoint resolves its gateway instead. ARP/ND suppression is optional and requires validated, current IP-to-MAC bindings for remote endpoints, with a compatible fallback when absent. MAC learning alone does not establish those bindings, and the mapping-based LISP ARP optimization in Section 6.4 of does not by itself distribute them into EVPN. Required ND and IPv6 Duplicate Address Detection messages must work across the extended service; suppression must not hide duplicates or prevent required discovery. Default-gateway behavior needs to be consistent across the Ethernet service. If both domains provide the same gateway IP, the gateway MAC, anycast behavior, and advertisement or filtering policy need coordination. Endpoint-MAC export must not unintentionally change ownership of that gateway.

Redundancy and Loop Prevention The baseline uses one single-active Ethernet path per interconnected bridge domain, consistent with the decoupled model in . The path comprises a LISP Layer 2 border, the Ethernet handoff, and an EVPN-GW, and carries both unicast and BUM traffic. Standby paths do not forward the service across the boundary. Concurrent all-active interdomain paths are outside this baseline. Each domain uses its own multihoming procedures: EVPN Ethernet segment and designated-forwarder procedures, and Section 6.3 of for LISP. The topology and path-selection mechanism are deployment-specific and must provide a usable, loop-free active path. LISP's BUM designated-forwarder selection alone does not restrict known-unicast forwarding. Unicast locator eligibility and EVPN forwarding state must therefore select borders with a usable active handoff. On failure, stop service forwarding on the old path before activating a usable replacement. Remove or update affected MAC advertisements, LISP registrations, and replication state using the existing domain procedures. MAC learning and mapping/cache convergence follow .

Layer 3 Interconnection The Layer 3 service exchanges selected IP-prefix reachability between the LISP and EVPN domains and forwards packets using IP lookup. Administrative configuration maps the LISP IID and VXLAN forwarding context to the EVPN routing context, VRF, VNI, and route-target policy. The two domains retain independent control planes and underlays. The subnet-prefix procedures below apply when the advertised prefixes identify the destination domain unambiguously. The deployment example uses separately allocated subnet spaces. Routed connectivity for endpoints distributed within a common prefix requires more precise reachability and compatible address-resolution behavior, as discussed in . The service routes tenant IP packets across the transit between the separate border devices. It does not extend Ethernet adjacency or BUM traffic across the interconnect.

Decoupled Routed Reference Architecture shows separate PxTR and EVPN-GW devices connected by tenant IP transit. A routed interface or VLAN subinterface connects the PxTR routing context to the corresponding EVPN-GW IP-VRF while maintaining tenant isolation. Each border terminates its own VXLAN overlay; the transit does not extend either endpoint bridge domain. The borders exchange selected IPv4 and/or IPv6 unicast prefixes using any IGP supported by both implementations that provides the required reachability, redistribution, and tenant isolation, or using eBGP. Examples of IGPs are OSPF and IS-IS . The protocol and routing instances support the IP versions used by the service. With eBGP, the borders use different local autonomous-system numbers and the required unicast address families ; with an IGP, they form the applicable adjacencies within the tenant routing context.

Decoupled Routed Interconnect Configuration associates the transit with the LISP IID and VXLAN forwarding context on the PxTR, and with the IP-VRF, VNI, and route-target policy on the EVPN-GW. The unicast prefixes exchanged do not convey these associations or LISP RLOC sets. The overlays may use the same or different VNI values. The transit protocol derives usable routes and next hops through its own procedures; transit next hops are distinct from LISP RLOCs and EVPN overlay next hops. LISP mappings and EVPN service routes remain in their respective control planes. Ordinary redistribution at each border connects transit routing to its native overlay reachability, as described in and . LISP prefix discovery and the local realization of redistribution are implementation-specific; no additional LISP discovery mechanism or direct LISP-to-EVPN message translation is required. Each domain maintains its own underlay without requiring import of the other domain's underlay reachability. These unicast procedures do not provide IP multicast interworking. Deployments can use multiple border devices and transit paths for redundancy or scale, subject to the forwarding-path and route-eligibility requirements in .

Subnet-Prefix Deployment Example In , the LISP domain manages 192.0.2.0/24 and the EVPN domain manages 198.51.100.0/24. H1 belongs to the LISP-managed address space and attaches to a LISP xTR; H2 belongs to the EVPN-managed address space and attaches to an EVPN VTEP.

LISP-to-EVPN Subnet-Prefix Redistribution The PxTR redistributes eligible LISP subnet prefixes into the selected transit routing protocol. Input can be summarized or administratively defined subnet reachability; in the deployment example in , it includes 192.0.2.0/24. These procedures exchange subnet prefixes rather than individual endpoint host routes. The EVPN-GW installs the selected route toward the PxTR, then originates the corresponding RT-5 using its own EVPN-facing next hop and forwarding context. EVPN VTEPs send traffic for the prefix to the EVPN-GW, which routes it toward the PxTR. Redistribution uses the configured tenant associations in and local policy for prefix selection and EVPN origination. Route-origin and forwarding-path requirements are described in .

EVPN-to-LISP Subnet-Prefix Redistribution The EVPN-GW selects subnet reachability from EVPN RT-5 advertisements or an administratively defined summary and redistributes it into the transit routing protocol. In the deployment example in , this prefix is 198.51.100.0/24. RT-5 routes are the only EVPN route inputs for this subnet-prefix exchange; RT-2 and RT-3 routes serve the independent Layer 2 model in . The PxTR installs the selected route toward the EVPN-GW through the tenant transit and makes the prefix reachable from LISP through its own LISP-facing RLOCs. The EVPN-GW transit address is an IP forwarding next hop on the PxTR; it is not substituted for the PxTR's RLOC in LISP reachability. Redistribution applies local prefix-acceptance, filtering, and LISP-attribute policy using the tenant associations in and the route-origin and forwarding-path requirements in .

Decoupled Routed Data-Plane Forwarding shows the path between H1 and H2 in the subnet-prefix deployment example in . Forwarding uses the tenant associations described in .

Decoupled Routed Subnet-Prefix Forwarding Example

H1 sends an IP packet addressed to H2 to its LISP xTR.
The ingress xTR uses its LISP forwarding state for H2's prefix and encapsulates the packet in VXLAN toward the PxTR.
The PxTR decapsulates the packet, selects the tenant routing context from the incoming service association, and performs a destination-IP lookup. The route for 198.51.100.0/24 selects the EVPN-GW across the tenant IP transit.
The EVPN-GW receives the packet in the corresponding IP-VRF and performs a destination-IP lookup. Its EVPN forwarding state selects H2's egress VTEP and VNI; the gateway encapsulates the packet in VXLAN and forwards it to that VTEP.
The egress VTEP decapsulates the packet and delivers it to H2 using its local IP forwarding state.

In the reverse direction, the EVPN VTEP uses RT-5 reachability for 192.0.2.0/24 to send the packet to the EVPN-GW, which decapsulates and routes it to the PxTR. The PxTR uses its LISP forwarding state to encapsulate toward H1's xTR for delivery to H1. The tenant IP transit carries native IP packets without a VXLAN VNI. On an Ethernet transit, frames use the border routers' transit MAC addresses. Tenant source and destination IP addresses are preserved, and ordinary TTL or Hop Limit handling applies. ARP or ND resolves the adjacent border router; host address resolution and Ethernet BUM do not extend between the overlays.

Optional Routed Connectivity within a Common IP Prefix This optional deployment case applies when endpoints within a common IP prefix require routed IP connectivity. Operators select the Layer 3 service and provide the additional behavior below; subnet-prefix exchange alone does not establish this service. Section 7.1 of describes intra-subnet IP forwarding on the LISP side. Applying this model at the LISP-EVPN boundary requires the following additional service behavior.

Reachability identifies the owning domain of each destination using IPv4 /32 or IPv6 /128 prefixes, or equally precise state. Advertising the common aggregate from both domains is not sufficient.
For a LISP-owned endpoint, the PxTR exports eligible host-prefix reachability through the selected transit routing protocol. The EVPN-GW originates the corresponding EVPN RT-5 host-prefix reachability using its own EVPN-facing next hop. For an EVPN-owned endpoint, the EVPN-GW exports the eligible host prefix through that routing protocol, and the PxTR makes the corresponding host EID reachable through its own LISP-facing RLOCs. The selected input state is authenticated or otherwise validated; MAC-only RT-2 state does not establish IP ownership.
The endpoint-facing router provides proxy ARP or an appropriate IPv6 ND proxy behavior so that same-prefix traffic reaches the router's MAC. The IPv6 deployment also needs a supported address-uniqueness and Duplicate Address Detection strategy; an ARP proxy is not an IPv6 procedure.
Host-route and mapping removal follows endpoint withdrawal or movement. Import policy and ownership tracking prevent a host learned through the interconnect from being exported back as locally owned reachability.

On the EVPN side, the required router-MAC proxy operates at the endpoint-facing VTEP's IRB interface. Ordinary EVPN ARP/ND suppression normally returns the destination endpoint's MAC . The router-MAC proxy used here instead directs traffic into IP forwarding. A related intra-subnet routing approach is described in using EVPN MAC/IP RT-2 state. For example, H1 at 203.0.113.10/24 is in LISP and H2 at 203.0.113.20/24 is in EVPN. H2's local VTEP installs H1's RT-5 /32 in the tenant IP-VRF toward the EVPN-GW. When H2 ARPs for H1, the supported proxy returns the local IRB MAC. H2 sends to H1's IP address with that MAC as the Ethernet destination, and the VTEP routes through the EVPN-GW and PxTR to LISP. Using validated imported host reachability to authorize this proxy response requires explicit implementation support; installing an RT-5 route alone is insufficient. Both border devices forward these packets using IP lookup and ordinary routed TTL or Hop Limit handling across the tenant IP transit and their respective overlays. RT-5 can represent host prefixes under ; RT-2 translation is not inherently required for this approach. Detailed endpoint discovery and cross-domain mobility translation are not defined here and need an agreed implementation before deploying this optional model. Ethernet BUM remains local to each domain. This service does not provide non-IP Ethernet adjacency or automatically carry subnet broadcast, link-local multicast, or tenant IP multicast across the boundary. Applications requiring those properties use the Layer 2 model or a separately specified multicast/proxy service.

Operational Considerations Operators configure the service associations and tenant contexts on both borders as described in and . Configuration preserves tenant isolation and avoids unintended parallel bridged and routed paths. Common-prefix routing adds the requirements in . Redistribution policy preserves route origin across LISP, the transit routing protocol, and EVPN. Imported reachability must not be exported back to its originating domain as locally owned. Native IGP or BGP loop prevention does not replace policy at the interconnect. Exported reachability requires valid source state and a usable forwarding path. When either is lost, the borders withdraw or update dependent RT-5 and LISP reachability using existing protocol mechanisms, while retaining valid alternate paths. Loss of one endpoint alone does not require withdrawal of a still-valid summary. Bridged MAC lifecycle and failover follow and . Each overlay underlay accommodates VXLAN encapsulation overhead. The tenant IP transit carries the permitted tenant IP packet size, and the Ethernet handoff carries the permitted customer frame size, including VLAN tags where used. These MTU requirements apply across the complete service path.

Security Considerations This document does not define a new protocol or a new encapsulation. It describes an interconnect architecture that uses existing LISP, tenant IP routing, BGP EVPN, and VXLAN mechanisms. Routed interconnection exposes selected IP reachability; bridged interconnection also exposes MAC reachability and a shared broadcast domain. Incorrect service mappings, import or export policy, or attachment selection can leak tenant traffic, create forwarding loops, or connect unintended endpoints. Operators apply explicit authorization and isolation per service. The routed transit and its selected routing protocol are part of the tenant boundary. Operators restrict routing participation to authorized border devices, apply protocol-appropriate controls on prefix origination and redistribution, and protect routing adjacencies, sessions, and updates using the security mechanisms supported by the deployment. Incorrect neighbor or transit-context configuration can bypass tenant isolation or introduce unauthorized reachability. A handoff-learned MAC is a reachability observation, not an authenticated endpoint identity. Forged source MACs or ARP/ND messages can cause false registration, traffic redirection, or incorrect endpoint bindings. Border acceptance policy limits permitted attachments and endpoint bindings. LISP registration authentication identifies an authorized registering device; it does not by itself authenticate every endpoint that device learns. Extending a bridge domain also extends exposure to broadcast storms, multicast replication, and duplicate-address conflicts. Deployments use boundary rate limits, loop prevention, and validated suppression state, and protect control-plane capacity against excessive MAC learning and mapping requests. Security considerations for the selected transit routing protocol and for LISP , BGP , BGP EVPN , EVPN interconnect , and VXLAN are described in their respective specifications and are not repeated here.

IANA Considerations This document has no IANA actions.