Re: proposal: Hybrid network stack for Trixie

[Ansgar 🙀 <ansgar@debian.org>]

Hi,

On Tue, 2024-09-24 at 15:34 +0200, Lukas Märdian wrote:
> My ideas was not so much about switching from one networking daemon to another.
> In most cases users will probably stick to the network stack of their chosen
> environment. With systemd-networkd and NetworkManager being good candidates for
> their corresponding scenarios.
> 
> But knowledge builds up over the years in our community and spreads around forums,
> stack overflow, etc.
> 
> Those are the places where we figure out "How to setup a bond on Debian?",
> "How to connect a headless embedded board to the WiFi network" or "How to change
> the embedded-switch mode on SR-IOV physical functions?". We find solutions and
> help each other out, which is great!
> 
> But with fragmented network-configuration tooling those solutions will not work
> in many cases, as they depend on a specific context of the base-image in use
> (e.g. server vs desktop vs embedded vs cloud).
> 
> With Netplan I'm hoping to avoid such frustration by providing a way to configure
> the network that works independently of the base-image context. Of course without
> forcing people to use it or impacting the lower layer to be configured directly.

But this only works for features for which all the following is true:

1. The feature is supported by systemd-networkd,
2. The feature is also supported by NetworkManager,
3. The feature is also supported by netplan.

Any feature not supported by all three will lead to fragmentation: one
would first have to make sure to switch to, for example, the
NetworkManager backend, but then might just find out that netplan
doesn't support the feature and one has to configure NetworkManager
without netplan anyway.

At that point just making NM the default without additional layers
might be better: the feature set covered by just

- The feature is supported by NetworkManager

is larger than the earlier feature set.

Ansgar