Method to enable signaling of L2VPN services using SRv6 extensions

Introduction 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 and . 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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Problem Statement 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.

Proposed Solution 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 an SRv6 endpoint function that represents the L2VPN service. This function, referred to as End.DX2 or End.DT2U depending on the L2VPN service type (E-LINE or ELAN), enables 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.

Detailed Mechanism Throughout this document, the term "End.L2VPN SID" is used as a generic reference to the SRv6 L2VPN endpoint SID. It refers to either End.DX2 or End.DT2U depending on the service type indicated by the Service-Type field in the L2VPN SRv6 Service TLV (see ). Readers SHOULD interpret End.L2VPN SID accordingly wherever it appears in this document.

End.L2VPN SID: End.DX2 and End.DT2U 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 : 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 : 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.

The Service-Type field in the L2VPN SRv6 Service TLV signals which endpoint behavior is in use, allowing the receiving PE to correctly interpret and install the forwarding state.

SID Generation A PW-ID that is unique within an L2VPN instance is used to generate an End.L2VPN SID. One implementation model is to derive the service-specific portion of the SID (the function value) from the PW-ID. For example, if a PE has PW 11 configured, the decimal value 11 is converted to hexadecimal (0xB) and encoded as the function value within the local SRv6 locator structure to form the End.L2VPN SID. The resulting SID is then advertised via the mechanism described in .

Signaling of L2VPN 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:

Type (8 bits):

The IS-IS TLV type codepoint assigned by IANA (TBD; see ).

Length (8 bits):

The total length of the TLV value field in octets, not including the Type and Length fields.

Flags (8 bits):

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.

Reserved (8 bits):

MUST be set to zero on transmission and MUST be ignored on receipt.

PW-ID (32 bits):

A 32-bit unsigned integer that uniquely identifies the pseudowire instance within the L2VPN domain. The value MUST be non-zero. A receiving PE MUST verify that this value matches a locally configured PW before installing any forwarding state.

Neighbor IP Address (128 bits):

The IPv6 loopback address of the advertising PE. A receiving PE MUST verify that this address matches the expected peer address of the locally configured pseudowire before installing forwarding state.

Encap-Type (8 bits):

Indicates the pseudowire encapsulation type. Values are consistent with the IANA "Pseudowire Types" registry . Common values include:

0x01: Ethernet (port mode)
0x04: Ethernet VLAN

Service-Type (8 bits):

Indicates the L2VPN service type and determines the SRv6 endpoint behavior used for this pseudowire:

0x01: E-LINE (point-to-point). The End.L2VPN SID uses End.DX2 behavior as defined in .
0x02: ELAN (multipoint). The End.L2VPN SID uses End.DT2U behavior as defined in .

Other values are reserved and MUST NOT be used.

Layer-2 MTU (16 bits):

The maximum transmission unit of the attachment circuit in bytes. A receiving PE SHOULD verify that this value matches its locally configured MTU before installing forwarding state.

SRv6 Service Data Sub-TLV:

A mandatory sub-TLV carrying the End.L2VPN SID and associated SRv6 service parameters. Format is defined in .

PW Interface Parameters Sub-TLV (optional):

An optional sub-TLV carrying legacy pseudowire interface parameters, encoded using the format defined in .

PW Status Sub-TLV (optional):

An optional sub-TLV that carries pseudowire operational state, indicating whether the pseudowire is forwarding and whether attachment-circuit or PSN-facing faults have been detected.

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.

SRv6 Service Data Sub-TLV The SRv6 Service Data Sub-TLV carries the End.L2VPN SID value and its associated SID structure. The format is as follows:

Sub-TLV Type (8 bits):

The sub-TLV type codepoint (TBD; see ).

Length (8 bits):

The total length of the sub-TLV value field in octets, not including the Sub-TLV Type and Length fields.

Endpoint Behavior (16 bits):

The SRv6 endpoint behavior code for the advertised SID, taken from the IANA "SRv6 Endpoint Behaviors" registry as defined in . The value MUST be consistent with the Service-Type in the enclosing L2VPN SRv6 Service TLV:

End.DX2: for E-LINE service (Service-Type 0x01)
End.DT2U: for ELAN service (Service-Type 0x02)

SRv6 SID Value (128 bits):

The SRv6 SID representing the End.L2VPN endpoint function on the advertising PE for the associated pseudowire. The function portion of the SID is derived from the PW-ID as described in .

Loc-Block-Len (8 bits):

Length in bits of the locator block portion of the SID.

Loc-Node-Len (8 bits):

Length in bits of the locator node ID portion of the SID.

Func-Len (8 bits):

Length in bits of the function portion of the SID. This portion encodes the PW-ID value.

Arg-Len (8 bits):

Length in bits of the argument portion of the SID. Set to zero if no argument is present.

Example 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. IS-IS IPv6 and SRv6 are configured on all nodes:

PW 10 is configured between PE1 and PE2 (E-LINE, End.DX2)
PW 11 is configured between PE1 and PE3 (E-LINE, End.DX2)
PW 12 is configured between PE3 and PE2 (E-LINE, End.DX2)

Node addressing:

PE1 loopback: 1::1/128, End SID locator: 2001:db8:bbbb:A::/64
PE2 loopback: 2::2/128, End SID locator: 2001:db8:bbbb:B::/64
PE3 loopback: 3::3/128, End SID locator: 2001:db8:bbbb:C::/64

The example below focuses on PW 11 (E-LINE) between PE1 and PE3. PE1 configuration: PE3 configuration: SID derivation:

PE1 End.DX2 SID for PW 11: 2001:db8:bbbb:A::B/64 (locator 2001:db8:bbbb:A::/64, function = 0xB = decimal 11)
PE3 End.DX2 SID for PW 11: 2001:db8:bbbb:C::B/64 (locator 2001:db8:bbbb:C::/64, function = 0xB = decimal 11)

Control Plane 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:

PW-ID matches a locally configured pseudowire (PW 11)
Neighbor IP Address matches the expected peer (3::3 for PE1, 1::1 for PE3)
Service-Type, Encap-Type, Layer-2 MTU, and Control Word flag are consistent with the local service parameters

If all parameters are consistent, PE1 installs PE3's End.DX2 SID 2001:db8:bbbb:C::B/64 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::B/64 in its SRv6 forwarding table.

Data Plane 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::B, 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::B against its End.DX2 SID for PW 11, decapsulates the IPv6 header, and forwards the L2 payload toward the PW 11 attachment circuit.

Security Considerations 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 ). Operators SHOULD also consider the impact of stale advertisements, replayed information, and excessive service advertisements on nodes with constrained resources.

IANA Considerations This document requests the following allocations from IANA.

IS-IS TLV Codepoints Registry 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.