Internet-Draft VXLAN and SRv6 Gateway Deployment October 2026
Zhang & Lin Expires 4 May 2027 [Page]
Workgroup:
Internet Engineering Task Force
Published:
Intended Status:
Informational
Expires:
Authors:
X. Zhang
China Mobile
C. Lin
New H3C Technologies

VXLAN and SRv6 Gateway Deployment Options and Considerations

Abstract

VXLAN is widely deployed in data center networks, often with Ethernet VPN (EVPN) as its control plane. Segment Routing over IPv6 (SRv6) is used to provide services and path control over IPv6 networks, including networks connecting data centers and wide area networks.

This document describes deployment options for connecting VXLAN-based data center networks to SRv6 networks. These options include VXLAN and SRv6 service interworking at a gateway, and the transport of VXLAN traffic over an SRv6 network. The document discusses their characteristics, deployment trade-offs, and operational considerations.

Status of This Memo

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 4 May 2027.

▲

Table of Contents

1. Introduction

VXLAN [RFC7348] is widely used in data center networks to provide network virtualization over an IP underlay. A VXLAN Network Identifier (VNI) identifies a VXLAN segment, and VXLAN Tunnel Endpoints (VTEPs) encapsulate and decapsulate tenant traffic.

Ethernet VPN (EVPN) [RFC7432] is commonly used as the control plane for VXLAN networks. EVPN provides mechanisms for advertising MAC and IP reachability information and supporting multihoming. Its use with network virtualization overlays is described in [RFC8365].

Segment Routing over IPv6 (SRv6) [RFC8986] uses IPv6 addresses to encode Segment Identifiers (SIDs) and their associated behaviors. SRv6 can be used to provide VPN services and path control over IPv6 networks. BGP-based overlay services using SRv6 are described in [RFC9252].

As operators deploy SRv6 in networks connecting data centers and wide area networks, they may need to connect existing VXLAN-based data center networks to SRv6-based transport or VPN services. Deploying functions at the data center boundary can enable this connectivity while allowing the data center and the external network to retain their respective architectures.

This document discusses two deployment options:

These options may coexist in a network. For example, an operator may use service interworking for most tenants while using VXLAN over SRv6 for selected applications.

This document does not define new protocol mechanisms. The availability of the described functions depends on the applicable specifications and device implementations.

2. Terminology

VTEP:
VXLAN Tunnel Endpoint.
VNI:
VXLAN Network Identifier.
VRF:
Virtual Routing and Forwarding instance.
SID:
Segment Identifier.
SRH:
Segment Routing Header.
BUM:
Broadcast, Unknown unicast, and Multicast.
Boundary gateway:
A node at the boundary between network domains that provides service interworking or connects traffic to an SRv6 transport network.
Service interworking:
The association of services in different network domains, including data-plane encapsulation processing and any required control-plane route processing.

3. Deployment Options

3.1. VXLAN and SRv6 Interworking

In this option, VXLAN is used within the data center, while SRv6 is used in the external network. A boundary gateway associates the services on the two sides and forwards traffic between them.

      Data Center                                  Remote Network
  +------------------+                         +------------------+
  | VTEP             |                         | PE or Gateway    |
  +--------+---------+                         +---------+--------+
           |                                             |
           | VXLAN                                       | SRv6
           |                                             |
  +--------+---------------------------------------------+--------+
  |                    Boundary Gateway                           |
  |            Service association and forwarding                 |
  +---------------------------------------------------------------+
Figure 1: VXLAN and SRv6 Interworking

For traffic from the VXLAN domain to the SRv6 domain, the gateway typically:

  1. Receives and terminates the VXLAN encapsulation.
  2. Associates the VNI with a local Layer 2 service instance or IP VRF.
  3. Selects the corresponding service in the SRv6 domain.
  4. Forwards the traffic using the encapsulation and forwarding behavior required by that service.

Traffic in the reverse direction is processed accordingly.

Depending on the control planes used on each side, the gateway may also need to import, export, or re-advertise reachability information. The required processing depends on the service type and implementation.

3.1.1. EVPN VXLAN and L3VPN SRv6 Interworking

In this option, the data center uses EVPN VXLAN, while the external network provides an SRv6-based Layer 3 VPN service.

  EVPN VXLAN Data Center    Boundary Gateway       SRv6 L3VPN
  +-------------------+     +---------------+     +-------------+
  | VTEP              |-----| IP VRF        |-----| L3VPN PE    |
  +-------------------+     +---------------+     +-------------+
                      VXLAN                 SRv6
Figure 2: EVPN VXLAN and L3VPN SRv6 Interworking

This option is primarily intended for Layer 3 connectivity. The gateway associates the tenant VRF on the VXLAN side with the corresponding VPN service on the SRv6 side.

IP reachability learned from the data center may need to be introduced into the L3VPN control plane. In the reverse direction, L3VPN routes may need to be introduced into the EVPN VXLAN domain. Because the two sides use different VPN route types and attributes, operators cannot assume that routes can be exchanged transparently without processing.

The deployment needs to account for the following:

  • The EVPN routes and associated IP reachability information that an implementation can use for interworking.
  • Route import, export, or re-advertisement capabilities.
  • Route Targets, next-hop handling, and other attributes required on each side.
  • Route filtering, loop prevention, and tenant isolation.

An L3VPN provides IP connectivity. It does not by itself preserve EVPN Layer 2 service semantics, such as a shared Ethernet broadcast domain or Layer 2 MAC learning across the boundary.

This option is suitable when data center tenants need IP connectivity to an SRv6 L3VPN network and do not require Layer 2 extension across the boundary.

3.1.2. EVPN VXLAN and EVPN SRv6 Interworking

In this option, both network domains use EVPN, while their data planes use VXLAN and SRv6, respectively.

  EVPN VXLAN Data Center    Boundary Gateway       EVPN SRv6
  +-------------------+     +---------------+     +-------------+
  | VTEP              |-----| EVPN Boundary |-----| EVPN PE     |
  +-------------------+     +---------------+     +-------------+
                      VXLAN                 SRv6
Figure 3: EVPN VXLAN and EVPN SRv6 Interworking

The gateway associates the EVPN service instances on the two sides and processes the data-plane encapsulations. Depending on the service and implementation, the interworking may provide:

  • Layer 3 connectivity using tenant IP reachability information.
  • Layer 2 connectivity using MAC and IP reachability information.

Although both sides use EVPN, routes may still require processing at the boundary. For example, next hops, encapsulation-related information, service identifiers, or routing-policy attributes may need to be changed or re-advertised.

Layer 2 interworking also requires consideration of BUM traffic, multihoming, MAC mobility, and loop prevention. Operators need to verify which Layer 2 service functions are supported across the boundary by the relevant implementations.

This option is suitable when both domains use EVPN and the operator requires Layer 3 connectivity or, where supported, Layer 2 connectivity between them.

3.1.3. Advantages and Limitations

Advantages of VXLAN and SRv6 interworking include:

  • Each domain can use its own encapsulation and service architecture.
  • The boundary can provide a point for tenant isolation, route filtering, and fault containment.
  • Routes can be filtered or aggregated at the boundary, subject to the desired reachability and failure behavior.
  • Layer 3 interworking can avoid extending Layer 2 domains across the network.

Limitations and operational costs include:

  • The gateway needs to support the required service associations, forwarding functions, and control-plane processing.
  • Service identifiers and routes may require mapping or re-advertisement.
  • The gateway can become a capacity bottleneck or a concentrated point of failure unless redundancy is provided.
  • Support for specific route types, Layer 2 functions, and multihoming behavior may vary between implementations.

3.2. VXLAN over SRv6

In this option, VXLAN encapsulation is retained between VTEPs, and an SRv6 network carries the traffic between them. A boundary node may steer VTEP-to-VTEP traffic into an SRv6 path without converting the VXLAN service into an SRv6 VPN service.

  Data Center A        SRv6 Transport Network       Data Center B
  +------------+       +------------------------+    +------------+
  | VTEP A     |=======| SRv6 path or policy    |====| VTEP B     |
  +------------+       +------------------------+    +------------+

             VXLAN traffic is retained between VTEPs
Figure 4: VXLAN over SRv6

In one possible deployment, traffic between VTEPs is encapsulated when it enters the SRv6 transport network. At the SRv6 tunnel egress, the outer SRv6 encapsulation is removed, and the VXLAN packet is forwarded toward the destination VTEP. The destination VTEP then terminates the VXLAN encapsulation.

An illustrative packet format is shown below:

  +---------------------------------------------------------------+
  | Outer IPv6 header                                             |
  +---------------------------------------------------------------+
  | SRH, when present                                             |
  +---------------------------------------------------------------+
  | VTEP-to-VTEP IP header                                        |
  +---------------------------------------------------------------+
  | UDP | VXLAN | Tenant packet                                   |
  +---------------------------------------------------------------+
Figure 5: Illustrative VXLAN over SRv6 Packet Format

The actual packet format depends on the SRv6 encapsulation mode and implementation. The VTEP address family and the supported encapsulation combinations also depend on the devices used.

Using an SRv6 network to transport VXLAN does not, by itself, provide an SRv6 VPN service or establish an EVPN control plane between sites. VTEP reachability and any cross-site EVPN control-plane connectivity require separate design.

3.2.1. Advantages and Limitations

Advantages of VXLAN over SRv6 include:

  • VXLAN service encapsulation is retained between VTEPs.
  • The boundary node does not necessarily need to translate VXLAN services into SRv6 VPN services.
  • SRv6 path-control capabilities may be used for transport, depending on the deployment.
  • The impact on the existing VXLAN service model may be limited.

Limitations and operational costs include:

  • Additional encapsulation increases packet overhead and may affect MTU and forwarding performance.
  • VTEP reachability, traffic steering, and SRv6 tunnel termination require explicit design.
  • VXLAN and EVPN service state may extend across sites, increasing the scope of failures and operational dependencies.
  • Cross-site Layer 2 services can increase BUM traffic and the complexity of MAC mobility, ARP and Neighbor Discovery, and multihoming operations.

4. Considerations

4.1. Selecting a Deployment Option

Operators can select an option based on the required service, the role of the SRv6 network, implementation support, and operational boundaries.

Service requirement:
Interworking is suitable when services are terminated or associated at the boundary, especially for Layer 3 connectivity. VXLAN over SRv6 is suitable when VXLAN encapsulation is to be retained between VTEPs.
Role of the SRv6 network:
With interworking, the SRv6 network provides a VPN or other service to which the data center connects. With VXLAN over SRv6, the SRv6 network primarily transports VTEP-to-VTEP traffic.
Control plane:
Interworking may require route import, export, or re-advertisement at the gateway. With VXLAN over SRv6, cross-site VTEP reachability and, if used, EVPN control-plane connectivity need to be provided separately.
Fault containment:
An interworking gateway can provide a boundary for limiting route and Layer 2 fault propagation. With VXLAN over SRv6, service state and failures may have a wider cross-site scope.
Device capabilities:
Interworking requires the relevant service interworking and forwarding functions. VXLAN over SRv6 requires compatible VXLAN, IP, SRv6 encapsulation, steering, and forwarding functions.
Encapsulation overhead:
With interworking, each domain uses its respective encapsulation. With VXLAN over SRv6, nested encapsulation requires particular attention to MTU and performance.

A deployment selection process can proceed as follows:

  1. Determine whether the application requires Layer 2 connectivity across the boundary or only IP connectivity.
  2. Determine whether the SRv6 network provides a VPN service or primarily acts as a transport network.
  3. Verify device support for the required control-plane and data-plane functions.
  4. Define operational and fault-management boundaries.
  5. Validate forwarding, failure recovery, scale, and performance before production deployment.

4.2. Gateway Placement and High Availability

Interworking gateways can be deployed centrally at data center exits or distributed across multiple boundary nodes.

A centralized deployment may simplify policy and service management, but it can concentrate traffic and failure impact. A distributed deployment may provide additional capacity and more local forwarding, but it can increase configuration and consistency requirements.

Operators should evaluate:

  • Gateway, link, and control-plane failure detection and recovery.
  • Redundancy and traffic steering across multiple gateways.
  • Route consistency and loop prevention.
  • Load distribution and capacity during normal operation and failures.
  • Asymmetric forwarding and its effect on stateful services.

4.3. Tenant and Route Isolation

The relationship between VNIs, EVPN instances, IP VRFs, and services in the SRv6 domain needs to be clearly defined.

Deployment planning should include:

  • Allocation and scope of tenant and service identifiers.
  • Route Distinguisher and Route Target configuration.
  • Route import and export policies.
  • IPv4 and IPv6 reachability and advertisement scope.
  • Route-source identification and loop prevention when routes are re-advertised.
  • The effect of route aggregation on reachability, convergence, and fault diagnosis.
  • Prevention of unintended route leaking between tenants.

4.4. Layer 2 Service Scope

When Layer 2 connectivity is extended across domains or sites, operators should evaluate:

  • MAC and IP route propagation.
  • MAC mobility and host reachability.
  • ARP and Neighbor Discovery suppression.
  • BUM traffic replication and expected traffic volume.
  • Multihoming behavior and Designated Forwarder election, where applicable.
  • Layer 2 loop prevention and failure containment.

If applications require only IP connectivity, a Layer 3 interworking design may reduce the amount of Layer 2 state and the scope of Layer 2 failures.

4.5. MTU, Performance, and Scale

The end-to-end MTU should be calculated using the encapsulations actually used along the path. VXLAN over SRv6 requires particular attention to nested encapsulation and any SRH overhead.

Validation should include:

  • Hardware forwarding support for the selected encapsulation combinations.
  • Supported SID-list lengths and their performance impact.
  • Throughput and packet rate under normal and failure conditions.
  • VNI, VRF, route, MAC, ARP, Neighbor Discovery, tunnel, and SID scale.
  • Large-packet handling, Path MTU Discovery, and packet-drop behavior.
  • Available capacity after a gateway or link failure.

4.6. Security and Operational Visibility

Operators should define trust boundaries and restrict the acceptance of routing information and data-plane traffic to authorized sources.

Operational visibility should allow an operator to associate tenant services with their VNIs, VRFs, gateways, SIDs, and transport paths. Monitoring and troubleshooting should cover:

  • Control-plane state and route advertisements.
  • Data-plane counters, packet drops, and encapsulation errors.
  • End-to-end service reachability.
  • MTU and performance problems.
  • Configuration changes, rollback procedures, and responsibilities across operational teams.

Additional security considerations are discussed in Section 5.

4.7. Deployment and Migration Validation

Before production deployment, operators should validate at least:

  1. Bidirectional forwarding for the required IPv4 and IPv6 services.
  2. Route installation, withdrawal, and policy changes.
  3. Gateway, VTEP, link, and control-plane failure recovery.
  4. Loop prevention and load distribution in multi-gateway deployments.
  5. Maximum packet sizes, MTU mismatches, and encapsulation errors.
  6. Forwarding and control-plane scale under expected operating conditions.
  7. Interoperability across vendors and software versions.

5. Security Considerations

The deployment options in this document introduce boundaries between network domains and, in some cases, between different service control planes. Incorrect configuration at these boundaries can cause traffic misdelivery, unintended tenant connectivity, or route leaks.

Operators should apply appropriate controls to:

VXLAN over SRv6 can extend the reach of a VXLAN or EVPN service across sites. Operators should consider whether the resulting trust and failure boundaries are acceptable for the applications carried.

6. IANA Considerations

This document has no IANA actions.

7. Informative References

[RFC7348]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, , <https://www.rfc-editor.org/info/rfc7348>.
[RFC7432]
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <https://www.rfc-editor.org/info/rfc7432>.
[RFC8365]
Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, , <https://www.rfc-editor.org/info/rfc8365>.
[RFC8986]
Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9252]
Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI 10.17487/RFC9252, , <https://www.rfc-editor.org/info/rfc9252>.

Authors' Addresses

Xiaoqiu Zhang
China Mobile
China
Changwang Lin
New H3C Technologies
China