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
Hi all,
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.
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
--
2.20.1
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 >
Il 26/03/2026 17:32, Nicolas Dichtel ha scritto: > 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. among our medium-term design goals we have: 1) achieving the feature parity with vxlan 2) being at least isomorphic with vxlan in terms of exposed CLI mechanisms in this way we can port the existing vxlan based solution for cloud infrastructures and container networking to srv6 on top of this, we can design srv6 specific machinery for higher efficiency therefore, the bridge+sr6 solution has to be supported to achieve feature parity/isomorphism with vxlan on top of this, we also include a solution that does not need the bridge and terminates an L2 tunnel directly into a single sr6 interface characterized by a mac address (this is for the decap side) for the encap side, we are considering per-mac solutions (see our answer to Justin) in a way which is aligned with vxlan design for the reasons mentioned above ciao Stefano > > 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 >> > -- ******************************************************************* Prof. Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 *******************************************************************
Le 27/03/2026 à 02:09, Stefano Salsano a écrit : [snip] >> What is the gain of having two interfaces? >> In term of scalability, it is interesting to have only one interface. > > among our medium-term design goals we have: > > 1) achieving the feature parity with vxlan > 2) being at least isomorphic with vxlan in terms of exposed CLI mechanisms > > in this way we can port the existing vxlan based solution for cloud > infrastructures and container networking to srv6 > > on top of this, we can design srv6 specific machinery for higher efficiency > > therefore, the bridge+sr6 solution has to be supported to achieve feature > parity/isomorphism with vxlan > > on top of this, we also include a solution that does not need the bridge and > terminates an L2 tunnel directly into a single sr6 interface characterized by a > mac address (this is for the decap side) Make sense, thanks for the details. > > for the encap side, we are considering per-mac solutions (see our answer to > Justin) in a way which is aligned with vxlan design for the reasons mentioned above Ok. Regards, Nicolas
On Sun, Mar 22, 2026 at 12:06 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote: > > Hi all, > > this RFC series adds support for the SRv6 End.DT2U behavior and > introduces the srl2 Ethernet pseudowire device, together with > corresponding selftests. Hi Andrea, Thanks for the work you (and Stefano) put into this series! As discussed offline, there is interest in such a solution. A general comment: I'm not sure about the name "srl2", as we're talking about SRv6 specifically here. I would personally love to have "l2srv6", although I suspect we may end up with "l2seg6" to remain consistent. Cheers, Justin
Il 24/03/2026 17:00, Justin Iurman ha scritto: > On Sun, Mar 22, 2026 at 12:06 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote: >> >> Hi all, >> >> this RFC series adds support for the SRv6 End.DT2U behavior and >> introduces the srl2 Ethernet pseudowire device, together with >> corresponding selftests. > > Hi Andrea, > > Thanks for the work you (and Stefano) put into this series! As > discussed offline, there is interest in such a solution. Hi Justin, thx for your interest! > A general comment: I'm not sure about the name "srl2", as we're > talking about SRv6 specifically here. fair point > I would personally love to have > "l2srv6", although I suspect we may end up with "l2seg6" to remain > consistent. I'd like to keep it as short as possible, our initial idea was seg6l2, very close to your last suggestion, then we opted for srl2 losing the "6" concept now it comes to my mind that l2 is somehow redudant in an interface type name, as an interface is an l2 concept per se, so my preferred option becomes: sr6 (short and memorable...) as an alternative seg6 can work but I strongly prefer sr6 ciao Stefano > > Cheers, > Justin -- ******************************************************************* Prof. Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 *******************************************************************
Le 25/03/2026 à 08:10, Stefano Salsano a écrit : > Il 24/03/2026 17:00, Justin Iurman ha scritto: >> On Sun, Mar 22, 2026 at 12:06 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote: >>> >>> Hi all, >>> >>> this RFC series adds support for the SRv6 End.DT2U behavior and >>> introduces the srl2 Ethernet pseudowire device, together with >>> corresponding selftests. >> >> Hi Andrea, >> >> Thanks for the work you (and Stefano) put into this series! As >> discussed offline, there is interest in such a solution. > > Hi Justin, > > thx for your interest! > >> A general comment: I'm not sure about the name "srl2", as we're >> talking about SRv6 specifically here. > > fair point > >> I would personally love to have >> "l2srv6", although I suspect we may end up with "l2seg6" to remain >> consistent. > > I'd like to keep it as short as possible, our initial idea was seg6l2, very > close to your last suggestion, then we opted for srl2 losing the "6" concept > > now it comes to my mind that l2 is somehow redudant in an interface type name, > as an interface is an l2 concept per se, so my preferred option becomes: > > sr6 Note that the interface name is defined to kind + a number when the IFLA_IFNAME attribute is not specified: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c?h=v7.0-rc5#n3823 Here, the default name will be 'sr60' :) 'vti6' is already in this case, so it's probably ok. I vote for 'sr6' too ;-) My two cents, Nicolas
Il 26/03/2026 17:30, Nicolas Dichtel ha scritto: > > > Le 25/03/2026 à 08:10, Stefano Salsano a écrit : >> Il 24/03/2026 17:00, Justin Iurman ha scritto: >>> On Sun, Mar 22, 2026 at 12:06 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote: >>>> >>>> Hi all, >>>> >>>> this RFC series adds support for the SRv6 End.DT2U behavior and >>>> introduces the srl2 Ethernet pseudowire device, together with >>>> corresponding selftests. >>> >>> Hi Andrea, >>> >>> Thanks for the work you (and Stefano) put into this series! As >>> discussed offline, there is interest in such a solution. >> >> Hi Justin, >> >> thx for your interest! >> >>> A general comment: I'm not sure about the name "srl2", as we're >>> talking about SRv6 specifically here. >> >> fair point >> >>> I would personally love to have >>> "l2srv6", although I suspect we may end up with "l2seg6" to remain >>> consistent. >> >> I'd like to keep it as short as possible, our initial idea was seg6l2, very >> close to your last suggestion, then we opted for srl2 losing the "6" concept >> >> now it comes to my mind that l2 is somehow redudant in an interface type name, >> as an interface is an l2 concept per se, so my preferred option becomes: >> >> sr6 > Note that the interface name is defined to kind + a number when the IFLA_IFNAME > attribute is not specified: > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/rtnetlink.c?h=v7.0-rc5*n3823__;Iw!!O5Bi4QcV!Bw3h__JfgzAoQlG3DyfQsdX5VEQi5Zx9dXbROUeKuwomkISAWgGMwNxjv059RhKI5xV9MpHHknEXDTb9diS16akPWyJi_dCP7aE$ > > Here, the default name will be 'sr60' :) +1 > 'vti6' is already in this case, so it's probably ok. I vote for 'sr6' too ;-) > > My two cents, > Nicolas -- ******************************************************************* Prof. Stefano Salsano Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 *******************************************************************
On Wed, Mar 25, 2026 at 7:10 AM Stefano Salsano <stefano.salsano@uniroma2.it> wrote: > > Il 24/03/2026 17:00, Justin Iurman ha scritto: > > On Sun, Mar 22, 2026 at 12:06 AM Andrea Mayer <andrea.mayer@uniroma2.it> wrote: > >> > >> Hi all, > >> > >> this RFC series adds support for the SRv6 End.DT2U behavior and > >> introduces the srl2 Ethernet pseudowire device, together with > >> corresponding selftests. > > > > Hi Andrea, > > > > Thanks for the work you (and Stefano) put into this series! As > > discussed offline, there is interest in such a solution. > > Hi Justin, > > thx for your interest! > > > A general comment: I'm not sure about the name "srl2", as we're > > talking about SRv6 specifically here. > > fair point > > > I would personally love to have > > "l2srv6", although I suspect we may end up with "l2seg6" to remain > > consistent. > > I'd like to keep it as short as possible, our initial idea was seg6l2, > very close to your last suggestion, then we opted for srl2 losing the > "6" concept > > now it comes to my mind that l2 is somehow redudant in an interface type > name, as an interface is an l2 concept per se, so my preferred option > becomes: > > sr6 > > (short and memorable...) > > as an alternative seg6 can work but I strongly prefer sr6 Hi Stefano, Makes sense, both would work for me FWIW. Let's see if others have opinions. Thanks, Justin
© 2016 - 2026 Red Hat, Inc.