Internet-Draft L2VPN over SRv6 August 2026
Garg Expires 4 March 2027 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-garg-l2vpn-over-srv6-01
Published:
Intended Status:
Informational
Expires:
Author:
Abhishek. Garg
Ciena

Method to enable signaling of L2VPN services using SRv6 extensions

Abstract

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.

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 March 2027.

▲

Table of Contents

1. 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 [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.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. 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.

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

5. 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 Section 5.3). Readers SHOULD interpret End.L2VPN SID accordingly wherever it appears in this document.

5.1. 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:

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.

5.2. 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 Section 5.3.

5.3. 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:

 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)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~        PW Interface Parameters Sub-TLV (optional)            ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              PW Status Sub-TLV (optional)                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits):
The IS-IS TLV type codepoint assigned by IANA (TBD; see Section 8).
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 [RFC4446]. 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 [RFC8986].
  • 0x02: ELAN (multipoint). The End.L2VPN SID uses End.DT2U behavior as defined in [RFC8986].

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 Section 5.3.1.
PW Interface Parameters Sub-TLV (optional):
An optional sub-TLV carrying legacy pseudowire interface parameters, encoded using the format defined in [RFC4446].
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.

5.3.1. 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:

 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     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLV Type (8 bits):
The sub-TLV type codepoint (TBD; see Section 8).
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 [RFC8986]. 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 Section 5.3.
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.

6. 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.

                   +--------+
                   |  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:

6.1. 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:

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.

6.2. 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.

7. 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 [RFC5304]).

Operators SHOULD also consider the impact of stale advertisements, replayed information, and excessive service advertisements on nodes with constrained resources.

8. IANA Considerations

This document requests the following allocations from IANA.

8.1. IS-IS TLV Codepoints Registry

This document requests one new codepoint from the "IS-IS TLV Codepoints" registry:

Table 1
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.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[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>.

9.2. Informative References

[RFC4446]
Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, , <https://www.rfc-editor.org/info/rfc4446>.
[RFC5304]
Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <https://www.rfc-editor.org/info/rfc5304>.

Author's Address

Abhishek Garg
Ciena