LibreMesh releases: only layer2+3 or both layer2+3 and layer2?

[ilario]

From @p4u's comment on #345:

IMO layer2+layer3 libremesh firmware should be burned in hell. Just layer3 or just layer2 is simpler, works better and pobably fits 99% of use cases.
Is there someone around the globe that is actually using the magic properties of mixing layer2+layer3 mesh routing?

In case a better default is decided, this should be reflected by lime-basic dependencies.

[pedro-nonfree]

we are very happy just using layer 3. And in case we would like to experiment a layer 2 subnet deployment we expect to have a border node that translates between layer 3 (bmx) to layer 2 (batman-adv) just as we do with BGP (our common language routing protocol in guifi; and internet) to bmx6.

This permanent situation of two protocols running in all nodes of a network remembers me to that situation of qMp that started using 3 routing protocols parallel (bmx6, olsr, babel); it ended up with bmx6 and I think it ran better.

Solving the problem for 99% of use cases is the way to go.

As far as I know, there are communities that prefer layer 2 or layer 3. I hope is easier delivering two flavors of libremesh (one in layer 2 and one in layer 3). What would be the recommended flavor between the two? In our case, bmx6 requires an external web application (guifi.net web) to register IPs; so this is not very welcome for a community network bootstrap. The priority would be the most easy protocol to start and from there scale (I'm biased on guifi.net's case; I don't know what is easier, bmx or batman-adv for a first deployment). It is also important to know the most stable protocol and how easy is to maintain it.

[dangowrt]

So this is one nice network setup you are describing there, similar to what we have here (and using libremesh develop branch on top of OpenWrt snapshots for that). And it may make sense in a particular community. I've already seen so much efforts to basically make libremesh the replacement for qMp -- sacrificing modularity and flexibility for all other existing communities on the way which may decide for different structures. Please don't do that mistake again. Because those differences do not necessarily relate only to technical necessities, but often times also reflect the social cultural environment and history in which they came into existence.
So: Around my place, there is a loosely organized network without organizational body which is a back-bone on roofs. We like to run bmx7 for that, use layer-3 routing. We have two larger community-run ISPs (think: like EXO. Here called westnetz.org and reudnetz.org), but also a bunch places with consumer-grade VDSL2 or DOCSIS connectivity which also provide WAN connectivity to the whole mesh. We do not have any "cloud" infrastructure, VPN or central routing what-so-ever and do not want to have any of that, because it would require creating a legal entity and lots of liability and responsibility problems. Hence we use a ULA for bmx7 and gateways right now provide NAT'ed subnets for IPv4 (and hopefully re-distribute dynamic IPv6 sub-prefix in the future).

We have users which are also mostly communities rather than individuals, think of larger house projects (30+ people, 8+ APs) and all that. This is different from monolithic Freifunk design (which we abolished because it didn't work for us at all) and also different (but more similar) to guifi.net.
Generally, when using bmx7, there is no need for any central registry (IP registration portal you mentioned) because it's based on public key hashes within the defined ULA.
Within the specific sites "on the ground" batman-adv is used. And true, not all of those nodes run bmx7, many (think: 4MB flash) devices are not capable of having bmx7 as well as WPA3/SAE due to space limitation and we then use batman-adv on top of 802.11s with WPA3/SAE only (currently those are also not running DHCP servers and there is a quite annoying limitation that due to current brokenness of lease-sharing there can be only one border-gateway between a layer-2 connected site and the layer-3 backbone mesh). And we need a way to fix that, ideally using libremesh.
libremesh can do quite a lot of things and though it is not well maintained at all, I still see it's modularity and flexibility to "assimilate" into existing network setups as one of it's greatest strengths. We can quite easily build libremesh firmware compatible with ancient OLSRv1 freifunk networks as well as for batman-adv gluon-type networks -- and for those even provide "hybrid" nodes with bmx7 which replace the annoying clould-based gateway commonly found there. And for small nodes have LiMe with batman-adv only or even really use gluon....

So if you say you are routing on layer-3 only, then why do you need DHCP lease-sharing?
Running two protocols on the same node is indeed only needed for border gateway nodes, connecting a single-SSID-roaming site (think: community house project) to the backbone (think: directional gear sitting on roof-tops) -- but in some places (think: large trailer parks) we want to have more than one of those border gateways providing connectivity to the same layer-2. There are currently many problems with this, the need to have them choose the same WAN gateway is one of them (because otherwise it will be different v6 prefixes as well as public v4 behind NAT and roaming will once again not work). But anyway, we do require somehow distributed DHCPd, in which way ever...

[p4u]

Well, I was not aiming to open this discussion neither changing anything relevant on the firmware. Just I wanted to share that my life is much happier since I only use bmx7 in my networks :) El 8 de febrer de 2019 17:40:44 CET, Ilario Gelmetti <[email protected]> ha escrit:

…

From @p4u's [comment](#345 (comment)) on #345: > IMO layer2+layer3 libremesh firmware should be burned in hell. Just layer3 or just layer2 is simpler, works better and pobably fits 99% of use cases. > Is there someone around the globe that is actually using the magic properties of mixing layer2+layer3 mesh routing? In case a better default is decided, this should be reflected by [lime-basic dependencies](https://github.com/libremesh/lime-packages/blob/master/packages/lime-basic/Makefile#L27). -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #468

-- Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la brevetat.

[ilario]

The discussion on #666 indicates that there's little interest to have a layer3-only version of LibreMesh.
In my opinion it would be interesting to have two types of LibreMesh: layer2+3 and layer2-only versions.

The layer2+3 will surely be released (I mean, it is what we already have).

An additional layer2-only release would be a great thing to have (for small communities not needing fragmentation and for the non-border nodes of fragmented networks) but depends on how much motivation/time receives.

[ilario]

In order to have a layer2-only version, we absolutely need to address #56 first.

[amuuza]

Hey, I'm only writing to add a bit of pressure for a layer-2-only LibreMesh version : )
That might help to save low-resource devices like old XM nanostations.