| Internet-Draft | LISP-EVPN Interconnect | October 2026 |
| Pitta Venkatachalapathy & Portoles-Comeras | Expires 24 April 2027 | [Page] |
This document describes decoupled Layer 2 and Layer 3 interconnection services between a LISP-based VXLAN domain and a BGP EVPN-based VXLAN domain. The LISP-facing border and EVPN Gateway are implemented on separate devices. The Layer 2 service extends a bridge domain through an Ethernet handoff, with independent MAC reachability and broadcast, unknown-unicast, and multicast forwarding in each overlay. The Layer 3 service uses tenant IP transit and prefix exchange through an Interior Gateway Protocol (IGP) or eBGP, with ordinary route redistribution at each border between the transit and its own overlay control plane. IP subnet layouts are deployment considerations; they do not define the service. Subnet-prefix exchange and additional requirements for optional routed connectivity within a common IP prefix are discussed.¶
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 24 April 2027.¶
Copyright (c) 2026 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 decoupled Layer 2 and Layer 3 services between a Locator/ID Separation Protocol (LISP) domain [RFC9300] [RFC9301] and an Ethernet VPN (EVPN) domain [RFC7432] [RFC8365] within the same administrative domain. Both domains use VXLAN [RFC7348], 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 (Section 4). 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 (Section 5).¶
Service selection depends on the required Ethernet or routed IP connectivity rather than the subnet layout. Section 3 states the service requirements; Section 5.5 describes the additional behavior for routed connectivity within a common IP prefix.¶
LISP MAC-address EIDs are described in [RFC8060]. The LISP Layer 2 procedures used here are described in [I-D.ietf-lisp-eid-mobility], which remains work in progress. This document applies the decoupled Ethernet-handoff model of [RFC9014] 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.¶
LISP terminology follows [RFC9300] and [RFC9301], including Instance ID (IID), Map-Server (MS), and Map-Resolver (MR).¶
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. Section 4 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. Section 5 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 Section 5.5. Advertising the common aggregate from both domains is not sufficient.¶
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.¶
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 [RFC9014]; the use of a LISP Layer 2 border is an architectural application described here.¶
H1: MAC-1 H2: MAC-2
| |
LISP xTR EVPN VTEP
| |
VXLAN VXLAN
| |
+------+-------+ +-------+------+
| LISP L2 | Ethernet/VLAN | EVPN-GW |
| border +------------------+ |
+------+-------+ handoff +-------+------+
| |
LISP MS/MR EVPN BGP/RR
LISP L2 IID/BD EVPN MAC-VRF/BD
<---------- Shared Ethernet service ------------->
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.¶
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 [RFC7432] and [RFC8365].¶
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 [I-D.ietf-lisp-eid-mobility]. Known-unicast forwarding follows Section 4.3.¶
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 Section 4.4.¶
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.¶
The borders forward on MAC reachability in this model. RT-5 subnet-prefix redistribution does not select the destination endpoint for these bridged frames.¶
Each domain maintains independent replication state: the LISP procedures in Sections 6.2.5 and 6.2.6 of [I-D.ietf-lisp-eid-mobility], and the EVPN BUM procedures, including IMET participation, in [RFC8365]. 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.¶
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 Section 4.2. 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 [I-D.ietf-lisp-eid-mobility] 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.¶
The baseline uses one single-active Ethernet path per interconnected bridge domain, consistent with the decoupled model in [RFC9014]. 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 [I-D.ietf-lisp-eid-mobility] 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 Section 4.2.¶
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 Section 5.5.¶
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.¶
Figure 2 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 [RFC2328] [RFC5340] and IS-IS [RFC1195] [RFC5308]. 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 [RFC4271] [RFC4760]; with an IGP, they form the applicable adjacencies within the tenant routing context.¶
LISP Domain EVPN Domain
+---------+ +---------+
| xTR | | VTEP |
+----+----+ +----+----+
| |
VXLAN VXLAN
| |
+----+----+ Tenant IP transit +----+----+
| PxTR +-------------------------------+ EVPN-GW |
+---------+ IP routing: IGP or eBGP +---------+
| |
LISP MS/MR EVPN BGP/RR
Ordinary redistribution at each border function
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 Section 5.2 and Section 5.3. 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 Section 6.¶
In Figure 2, 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.¶
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 Section 5.1.1, 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 [RFC9136] 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 Section 5.1 and local policy for prefix selection and EVPN origination. Route-origin and forwarding-path requirements are described in Section 6.¶
The EVPN-GW selects subnet reachability from EVPN RT-5 advertisements [RFC9136] or an administratively defined summary and redistributes it into the transit routing protocol. In the deployment example in Section 5.1.1, 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 Section 4.¶
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 Section 5.1 and the route-origin and forwarding-path requirements in Section 6.¶
Figure 3 shows the path between H1 and H2 in the subnet-prefix deployment example in Section 5.1.1. Forwarding uses the tenant associations described in Section 5.1.¶
H1 -- IP -- LISP xTR
|
VXLAN
|
PxTR
|
Tenant IP transit
|
EVPN-GW
|
VXLAN
|
H2 -- IP -- EVPN VTEP
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.¶
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 [I-D.ietf-lisp-eid-mobility] describes intra-subnet IP forwarding on the LISP side. Applying this model at the LISP-EVPN boundary requires the following additional service behavior.¶
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 [RFC9161]. The router-MAC proxy used here instead directs traffic into IP forwarding. A related intra-subnet routing approach is described in [I-D.sajassi-bess-evpn-l3-optimized-irb] 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 [RFC9136]; 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.¶
Operators configure the service associations and tenant contexts on both borders as described in Section 4.1 and Section 5.1. Configuration preserves tenant isolation and avoids unintended parallel bridged and routed paths. Common-prefix routing adds the requirements in Section 5.5.¶
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 Section 4.2 and Section 4.6.¶
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.¶
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 [RFC9300] [RFC9301], BGP [RFC4271] [RFC4760], BGP EVPN [RFC7432] [RFC8365], EVPN interconnect [RFC9014], and VXLAN [RFC7348] are described in their respective specifications and are not repeated here.¶
This document has no IANA actions.¶