| Internet-Draft | L2VPN over SRv6 | September 2026 |
| Garg & Joshi | Expires 5 March 2027 | [Page] |
This document describes a mechanism to provide L2VPN services using Segment Routing over IPv6 (SRv6), eliminating the need for a separate signaling protocol for VPN label distribution. In current deployments, L2VPN services rely on dedicated protocols such as the Label Distribution Protocol (LDP) or Border Gateway Protocol (BGP) for service label signaling, which adds control-plane complexity. The proposed mechanism introduces an SRv6-based extension that enables L2VPN service identification within the SRv6 framework, reducing control-plane overhead and providing a simplified and efficient solution for L2VPN service delivery.¶
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 5 March 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.¶
Layer 2 Virtual Private Network (L2VPN) services are widely deployed across service provider (SP) and data center (DC) networks to provide connectivity between geographically distributed sites.¶
These services typically rely on two separate mechanisms for transport and service signaling. The transport layer is provided by protocols such as MPLS or IP, while the service label (or pseudowire identifier) is distributed using dedicated control-plane protocols such as LDP or BGP.¶
With the evolution of networking technologies, Segment Routing over IPv6 (SRv6) has emerged as a flexible and scalable approach for traffic engineering and service delivery, as described in [RFC8402] and [RFC8986].¶
In parallel, network environments continue to include a mix of modern and legacy devices with varying capabilities and scalability constraints. In many deployments, lightweight L2VPN services are needed for use cases such as management traffic or small-scale data center interconnect (DCI), where existing BGP-based solutions may be overly complex.¶
This document focuses on improving L2VPN services by introducing an SRv6 extension that carries L2VPN service identification natively, without requiring a separate service signaling protocol.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
L2VPN services are widely deployed across SP and DC networks. Existing solutions typically require separate mechanisms for transport and service identification, resulting in additional label overhead and dependency on multiple control-plane protocols. These protocols must remain synchronized for correct operation, which increases operational complexity and may lead to service issues in case of inconsistency.¶
Current approaches, such as Ethernet VPN (EVPN) over SRv6, reduce data-plane complexity but rely heavily on BGP, which can introduce scalability challenges, particularly on resource-constrained devices.¶
In many deployments, lightweight L2VPN services are required for use cases such as management traffic or small-scale DCI, where existing solutions may be overly complex.¶
Therefore, there is a need for a simplified and scalable L2VPN mechanism with reduced control-plane overhead and improved operational efficiency.¶
This document proposes a simplified L2VPN mechanism based on SRv6, eliminating the need for separate signaling protocols for transport and service identification.¶
In the proposed approach, SRv6 is used for both transport and pseudowire (PW) signaling, thereby reducing the dependency on multiple control-plane protocols. This unification simplifies service provisioning and reduces operational overhead.¶
In a typical SRv6 deployment, an Endpoint SID (End SID) derived from an SRv6 locator is used to provide end-to-end transport connectivity. This document extends the same concept to L2VPN services by introducing SRv6 endpoint functions that represent the L2VPN service. These functions include End.DX2 for E-LINE forwarding and End.DT2U or End.DT2M for ELAN forwarding, depending on whether the traffic requires unicast or broadcast/multicast lookup. They enable both service identification and forwarding behavior within the SRv6 framework.¶
By leveraging SRv6 for both transport and service layers, the proposed mechanism reduces control-plane complexity and avoids the need for maintaining separate label spaces or signaling protocols.¶
Throughout this document, the term "End.L2VPN SID" is used as a generic reference to the SRv6 L2VPN endpoint SID. It refers to End.DX2, End.DT2U, or End.DT2M depending on the service type and forwarding behavior indicated by the L2VPN SRv6 Service TLV and its sub-TLVs (see Section 5.3). Readers SHOULD interpret End.L2VPN SID accordingly wherever it appears in this document.¶
The SRv6 endpoint behavior assigned to the L2VPN SID depends on the L2VPN service type, as follows:¶
End.DX2 (Endpoint with decapsulation and Layer-2 cross-connect), as defined in Section 4.8 of [RFC8986]: Used for E-LINE (point-to-point) services. The receiving PE decapsulates the SRv6 header and forwards the L2 payload directly to the attachment circuit associated with the specific pseudowire. This behavior is applicable when there is a single, known next-hop L2 destination.¶
End.DT2U (Endpoint with decapsulation and unicast MAC L2 table lookup), as defined in Section 4.10 of [RFC8986]: Used for ELAN (multipoint) services. The receiving PE decapsulates the SRv6 header and performs a unicast MAC address lookup in the L2 forwarding table associated with the VPN instance. This behavior is applicable when the destination MAC needs to be resolved from a shared L2 forwarding table.¶
End.DT2M (Endpoint with decapsulation and multicast MAC table lookup), as defined in [RFC8986]: Used for ELAN broadcast, unknown-unicast, and multicast (BUM) traffic. The receiving PE decapsulates the SRv6 header and performs multicast Layer-2 lookup or replication in the ELAN forwarding context.¶
The Service-Type field in the L2VPN SRv6 Service TLV identifies the base L2VPN service model, while the SRv6 service sub-TLVs identify the exact forwarding behaviors in use. Together, these fields allow the receiving PE to correctly interpret and install the forwarding state.¶
A PW-ID that is unique within an L2VPN instance is used to generate an End.L2VPN SID. In the model used by this document, the service-specific portion of the SID (the function value) is derived by combining the PW-ID with a behavior-type discriminator. This same construction is used for both E-LINE and ELAN services, so that each advertised SRv6 endpoint behavior has a distinct SID.¶
In one example encoding, the higher-order function bits carry the PW-ID and the lower-order 4 bits carry a behavior-type value. An implementation could use behavior-type value 0x1 for End.DX2, 0x2 for End.DT2U, and 0x3 for End.DT2M. Under this model, the function value can be computed as: Function = (PW-ID << 4) | behavior-type.¶
For example, if the Function field is 16 bits long, the lower 4 bits are used for the behavior-type discriminator and the upper 12 bits are used for the PW-ID. In that case, the usable PW-ID range is 1 through 4095.¶
For PW-ID 11 (0xB), the resulting function values are 0xB1 for End.DX2, 0xB2 for End.DT2U, and 0xB3 for End.DT2M. Therefore, an E-LINE service that uses End.DX2 advertises a SID whose function value is 0xB1, while an ELAN service can advertise 0xB2 for End.DT2U and 0xB3 for End.DT2M. If the local locator is 2001:db8:bbbb:C::/64, the corresponding SIDs are 2001:db8:bbbb:C:B1::, 2001:db8:bbbb:C:B2::, and 2001:db8:bbbb:C:B3::. The exact encoding of the behavior-type discriminator is implementation-defined, but the resulting function values MUST be distinct for each advertised behavior associated with the same service. The resulting SID is then advertised via the mechanism described in Section 5.3.¶
To signal L2VPN services, this document introduces a new IGP TLV that carries L2VPN pseudowire information. In the example described here, the signaling is carried in IS-IS. Equivalent advertisement in other IGPs is outside the scope of this document.¶
An IS-IS LSP carries the L2VPN information in a new TLV, defined as the L2VPN SRv6 Service TLV. The TLV format is as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Neighbor IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encap-Type | Service-Type | Layer-2 MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SRv6 Service Data Sub-TLV (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SRv6 BUM Service Data Sub-TLV (optional, ELAN only) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PW Interface Parameters Sub-TLV (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PW Status Sub-TLV (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Bit 7 (C): Control Word. When set to 1, indicates that the control word is enabled for this pseudowire. Both PEs MUST agree on the value of this bit before the pseudowire can be placed in service.¶
Bits 6-0 (Reserved): MUST be set to zero on transmission and MUST be ignored on receipt.¶
Indicates the pseudowire encapsulation type. Values are consistent with the IANA "Pseudowire Types" registry [RFC4446]. Common values include:¶
Indicates the L2VPN service type:¶
Other values are reserved and MUST NOT be used.¶
A receiving PE MUST verify that PW-ID, Neighbor IP Address, Service-Type, Encap-Type, Layer-2 MTU, and Control Word flag are consistent with the locally configured service before installing forwarding state for the remote End.L2VPN SID. If the SRv6 BUM Service Data Sub-TLV is present, the receiving PE MUST process it only for Service-Type 0x02 (ELAN).¶
The SRv6 Service Data Sub-TLV carries the End.L2VPN SID value and its associated SID structure. The format is as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID Value (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc-Block-Len | Loc-Node-Len | Func-Len | Arg-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The SRv6 endpoint behavior code for the advertised SID, taken from the IANA "SRv6 Endpoint Behaviors" registry as defined in [RFC8986]. The value MUST be consistent with the Service-Type in the enclosing L2VPN SRv6 Service TLV:¶
The SRv6 BUM Service Data Sub-TLV carries the End.DT2M SID value and associated SID structure for ELAN broadcast, unknown-unicast, and multicast traffic. This sub-TLV MUST be advertised only when Service-Type is 0x02 (ELAN). The format is as follows:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BUM SRv6 SID Value (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc-Block-Len | Loc-Node-Len | Func-Len | Arg-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Consider a topology with three PE devices (PE1, PE2, PE3) connected through one P device. IS-IS and SRv6 are configured on all nodes, and PW configuration is present on the PE devices.¶
+--------+
| PE1 |
+--------+
|
|
+--------+
| P |
+--------+
/ \
/ \
/ \
+--------+ +--------+
| PE2 | | PE3 |
+--------+ +--------+
¶
IS-IS IPv6 and SRv6 are configured on all nodes:¶
Node addressing:¶
The example below focuses on PW 11 (E-LINE) between PE1 and PE3.¶
PE1 configuration:¶
#L2VPN-srv6 pw-id 11 neighbor 3::3 service-type eline¶
PE3 configuration:¶
#L2VPN-srv6 pw-id 11 neighbor 1::1 service-type eline¶
SID derivation:¶
After pseudowire configuration, each PE advertises an IS-IS LSP containing an L2VPN SRv6 Service TLV for the configured PW.¶
When PE1 receives the IS-IS update from PE3, it examines the L2VPN SRv6 Service TLV and verifies the following parameters against its local configuration:¶
If all parameters are consistent, PE1 installs PE3's End.DX2 SID 2001:db8:bbbb:C:B1:: in its SRv6 forwarding table, mapped to the PW 11 attachment circuit.¶
The same process occurs on PE3 when it receives the matching advertisement from PE1: PE3 installs 2001:db8:bbbb:A:B1:: in its SRv6 forwarding table.¶
When PE1 detects traffic on the attachment circuit for PW 11, it looks up PW 11 in its SRv6 forwarding table, retrieves PE3's End.DX2 SID 2001:db8:bbbb:C:B1::, and creates an IPv6 packet with that destination address. The L2VPN payload is encapsulated as the IPv6 payload.¶
When the P device receives the IPv6 packet, it performs a longest-prefix match on the destination SID. Because the SRv6 locator for PE3, 2001:db8:bbbb:C::/64, is present in the forwarding table, the packet is forwarded toward PE3.¶
When PE3 receives the packet, it matches the destination address 2001:db8:bbbb:C:B1:: against its End.DX2 SID for PW 11, decapsulates the IPv6 header, and forwards the L2 payload toward the PW 11 attachment circuit.¶
This document introduces a new signaling element that can influence pseudowire forwarding state. Incorrect, spoofed, or unauthorized L2VPN SRv6 Service TLV advertisements could redirect traffic, blackhole traffic, or cause unintended pseudowire bindings to be installed.¶
A receiving PE MUST validate that the advertised PW-ID, Neighbor IP Address, Service-Type, Encap-Type, Layer-2 MTU, and Control Word flag match locally provisioned state before installing any forwarding state derived from the received advertisement.¶
Implementations and deployments SHOULD use the authentication and integrity mechanisms available for the underlying IGP carrying this information (e.g., IS-IS authentication as described in [RFC5304]).¶
Operators SHOULD also consider the impact of stale advertisements, replayed information, and excessive service advertisements on nodes with constrained resources.¶
This document requests the following allocations from IANA.¶
This document requests one new codepoint from the "IS-IS TLV Codepoints" registry:¶
| Value | Name | IIH | LSP | SNP | Purge | Reference |
|---|---|---|---|---|---|---|
| TBD | L2VPN SRv6 Service TLV | No | Yes | No | No | This document |
The TLV carries L2VPN pseudowire service information for an SRv6-based L2VPN signaling mechanism, including PW-ID, Neighbor IP Address, End.L2VPN SID, Encap-Type, Service-Type, Layer-2 MTU, Control Word flag, and optional sub-TLVs.¶
This document does not request any sub-TLV codepoint assignment. Such allocations MAY be defined by future documents if needed.¶