Re: [RFC PATCH net-next 0/3] seg6: SRv6 L2 VPN with End.DT2U and srl2 device

[Nicolas Dichtel <nicolas.dichtel@6wind.com>]

Le 22/03/2026 à 01:05, Andrea Mayer a écrit :
> Hi all,
Hi,

first, thank you for posting this RFC.

> 
> this RFC series adds support for the SRv6 End.DT2U behavior and
> introduces the srl2 Ethernet pseudowire device, together with
> corresponding selftests.
> 
> Motivation
> ==========
> 
> The main goal is to enable L2 service delivery through an internal
> SRv6 L2 endpoint, in a way similar to how VXLAN provides L2 services
> through a VXLAN netdevice.
> 
> Today, Linux supports SRv6 L2 decapsulation only through an
> End.DX2-style model, where the exposed Ethernet frame is forwarded
> to a configured egress interface. The current implementation does
> not provide a native netdevice representing the SRv6 L2 service
> endpoint. This is a significant limitation compared to VXLAN, where
> the tunnel endpoint is represented by a netdevice that can be
> attached to a bridge and integrated naturally into the local L2
> data plane.
> 
> On the encapsulation side, the existing H.L2.Encaps mode is
> implemented as a route-based lwtunnel, which only intercepts packets
> entering the IP routing path. Non-IP protocols such as ARP are
> never routed and therefore cannot be encapsulated, making it
> unsuitable for full L2 service delivery.
> 
> Design
> ======
> 
> This series addresses that limitation by introducing srl2, a native
> SRv6 L2 endpoint interface. The intent is to make SRv6 L2 delivery
> usable in the same deployment model already familiar from VXLAN: an
> internal interface that represents the L2 service endpoint and can
> participate naturally in local L2 forwarding.
The current design, with vxlan, uses two interfaces: one bridge and one vxlan.
I presume this design was chosen because the vxlan protocol is implemented in
the vxlan driver.
I wonder if using the same design for SRv6 is the best choice. Why not use only
a bridge interface? Instead of pointing to a port, the FDB entries could point
to a nexthop id. This enables to associate a srv6 encap directly to a MAC
address. Something like:

$ ip nexthop list id 1234
id 1234 encap seg6 mode encap segs ...
$ bridge fdb show dev br0
02:03:04:05:06:07 dev br0 nhid 1234 ...

What is the gain of having two interfaces?
In term of scalability, it is interesting to have only one interface.

Regards,
Nicolas

> 
> On top of that, the series adds support for End.DT2U so that Ethernet
> payloads carried over SRv6 can be decapsulated and delivered into an
> L2 domain through either a bridge port or an srl2 interface.
> 
> Relation to RFC 8986
> ====================
> 
> RFC 8986 describes End.DT2U in terms of an abstract L2 table
> associated with the SID. That abstraction specifies the externally
> observable forwarding behavior of the node, but it does not mandate a
> specific internal implementation. What matters is functional
> equivalence.
> 
> This series enforces that property by restricting valid End.DT2U
> decapsulation targets to endpoints that provide the required L2
> forwarding semantics by construction.
> 
> When the target device is a bridge port, the Linux bridge provides
> the expected behavior directly: source MAC learning, destination MAC
> lookup, and unknown-unicast flooding within the corresponding L2
> domain.
> 
> When the target device is an srl2 interface, the same model is
> realized in a degenerate but valid form, corresponding to a minimal
> two-port L2 domain in which one endpoint is srl2. In that case,
> forwarding is trivial: frames are delivered to srl2 only when
> addressed to its MAC address, or when they are broadcast or multicast.
> No general FDB is required in this case because there are no
> additional L2 destinations to learn.
> 
> Any other type of decapsulation target is rejected at configuration
> time, since it would not guarantee the forwarding behavior required by
> End.DT2U.
> 
> The srl2 device is the minimal baseline implementation providing
> point-to-point L2 encapsulation with a single segment list.
> Additional features can be added incrementally based on community
> feedback and use cases.
> 
> Usage
> =====
> 
>   ip link add srl2-0 type srl2 segs fc00::a,fc00::b
>   ip link set srl2-0 master br0
> 
>   ip -6 route add fc00::100/128 encap seg6local action End.DT2U \
>       l2dev srl2-0 dev dum0
> 
>   # encapsulating traffic from veth-hs into srl2-0
>   ip link set veth-hs master br0
> 
> Selftest topology
> =================
> 
>             cafe::1                                cafe::2
>            10.0.0.1                               10.0.0.2
>           +--------+                             +--------+
>           |  hs-1  |                             |  hs-2  |
>           +---+----+                             +----+---+
>               |                                       |
>         +-----+------+                         +------+-----+
>         |   veth-hs  |                         |  veth-hs   |
>         |      |     |   fcf0:0:1:2::/64       |     |      |
>         |    br0     +-------------------------+   br0      |
>         |      |     |                         |     |      |
>         |   srl2-0   |                         |  srl2-0    |
>         |    rt-1    |                         |   rt-2     |
>         +------------+                         +------------+
> 
> The test verifies IPv4/IPv6 host-to-host and host-to-gateway
> connectivity over the SRv6 L2 VPN, including ARP resolution
> through the tunnel.
> 
> A companion iproute2 series provides userspace support:
> 
>   [RFC PATCH iproute2-next 0/4] seg6: add SRv6 End.DT2U and srl2 support
> 
> 
> This is an RFC posting to collect feedback on both the overall design
> and the userspace API before moving forward with a formal submission.
> 
> Comments are very welcome, especially on:
> - the introduction of srl2 as an internal SRv6 L2 endpoint
> - the choice of constraining End.DT2U targets to bridge ports
>   and srl2 devices
> - the netlink/uAPI exposure
> - the selftest coverage and topology
> 
> Thanks,
> Andrea and Stefano
> 
> 
> Andrea Mayer (3):
>   seg6: add support for the SRv6 End.DT2U behavior
>   seg6: add SRv6 L2 tunnel device (srl2)
>   selftests: seg6: add SRv6 srl2 + End.DT2U L2 VPN test
> 
>  include/linux/srl2.h                          |   7 +
>  include/uapi/linux/seg6_local.h               |   3 +
>  include/uapi/linux/srl2.h                     |  20 +
>  net/ipv6/Kconfig                              |  16 +
>  net/ipv6/Makefile                             |   1 +
>  net/ipv6/seg6.c                               |   1 +
>  net/ipv6/seg6_local.c                         | 160 ++++-
>  net/ipv6/srl2.c                               | 269 ++++++++
>  tools/testing/selftests/net/Makefile          |   1 +
>  tools/testing/selftests/net/config            |   1 +
>  .../selftests/net/srv6_srl2_l2vpn_test.sh     | 621 ++++++++++++++++++
>  11 files changed, 1094 insertions(+), 6 deletions(-)
>  create mode 100644 include/linux/srl2.h
>  create mode 100644 include/uapi/linux/srl2.h
>  create mode 100644 net/ipv6/srl2.c
>  create mode 100755 tools/testing/selftests/net/srv6_srl2_l2vpn_test.sh
>