On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote:
I'd like to give some thought's for the upcoming batman-adv release, especially
on compat version 15. This somewhat summarizes my discussion with T_X on the wireless
community weekend (WCW -- 2013-05-10 - 2013-05-12). As some of you may know already,
we're running a small freifunk network in western Germany (Köln-Bonn-area) - about
~100 nodes in total; ~40 are online at the moment.
It's not my intention to bash on batman-adv in general or to start flame-wars (like:
batman-adv vs. olsr or something else) - I'd like to provide some statement on the
impact of the upcoming protocol changes.
Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time
now) and it's good to discuss it. :)
1. The upcoming protocol change appears to be painful - we have no suitable migration
Compat version 14 and 15 will be incompatible. Nodes will loose mesh connectivity (to
older nodes). Since we cannot upgrade all nodes at once, we'll have to run different
networks in parallel.
In fact, we're running two networks at the moment (compat 13 and 14). We aren't
able to upgrade the existing compat 13 nodes in the next months - by that, we'll
probably have some compat 13 ones for at least 1/2 year. There is no way of telling newer
nodes to use compat version 13. Since some "supernodes" (dedicated servers) are
part of the batman-adv cloud, we need twice the servers as well.
Upgrading to compat version 15 will require a huge amount of work: New infrastructure
(servers) must be deployed and nodes meshing with each other must be upgraded in parallel.
We are very well aware that a compat change is a huge burden especially on community
networks, which have
more troubles to reach all nodes. But the compat change was designed to stop
"bumping" the whole network
all the time but upgrading/adding features individually. More on that below.
Btw, it's interesting that you use compat version 13 - only one release had that
included, and we are
on compat 14 for quite some time ...
2. Backwards-compatilibilty doesn't seem to be a design target.
Actually, that is one of the main design targets. We are aware that with our current
packet type design,
we cannot change even parts of the protocol without breaking compatibility. This has
bothered us for quite
some time and we have worked on solutions to prevent compat bumps as good as possible. We
different means [2,3] to be able to add new features, change features, let sub-features
protocols (by using TVLVs) without breaking the rest and ensure compatibility on their own
, route even
yet unknown packets on their own , ... Actually the TVLV thing is pretty similar to
(e.g. IEEE 802.11) which use that to ensure backwards compatiblity for years. The goal is
to keep the
compat bump stable for at least a decade now, if not longer. No guarantees of course, but
bump is made to CREATE backwards compatiblity. :)
Note that the compat bump is not released yet but still only in our development branch.
Looking at other routing protocols (BGP-4 - for example) - they
provide decent ways for protocol extension while still providing backwards compatibility
for the version specified 7 years ago. Looking at batman-adv a lot of protocol changes
have been introduced in the past years - but no backwards compatibility is there. Eg.
- There will be no flag for using compat 14 version in newer version of batman-adv - if
15 is out.
- Nodes using 14 and 15 cannot mesh.
It is right that compat 14 and 15 won't be compatible. Backward compatibility will
start with compat 15,
and keeping them compatible will not be worth the effort.
Since batman-adv depends on the kernel (old batman-adv versions
won't build with recent kernels) using 14 will not be an option in a few months: If
some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer
I think it would be possible to maintain older releases of batman-adv and add
compatibility code for
newer kernels. We are doing the same now to provide compatibility for older kernels .
be happy if someone (you?) would take over that job, I guess it would mostly mean to test
and add a little bit of compat code like we do for the old kernels. You are welcome to
such "stable" versions. :)
-> Freifunk KBU will not use compat version 15 in the foreseeable future
This is your decision, as you want.
-> We're aware, that we cannot use version 14 in some months
-> At the point, when 14 becomes unusable (introduced into OpenWRT Kernels / release
we need -- or Debian), we will almost certainly discontinue batman-adv and go one with
sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel than
two different version of batman-adv)
I don't see that by releasing batman-adv with the new compat version, suddenly your
- in Debian you usually keep the same kernel for YEARS, and in OpenWRT you can just keep
package at the desired version number. The only problem you might run into is that newer
not work, as stated above.
-> We'd by very happy if someone forks batman-adv to provide
modules for recent kernels still using version 14
As stated above, someone needs to maintain these compat codes. No "fork" is
needed, we can "officially"
host and support that in our git repositories and servers (e.g. having one or multiple
"long term releases").
However, please be aware that waiting for "someone" might not help, contribute
yourself or (actively) finding
someone who wants to help with that might be better. :)
-> Maybe, some future version of batman-adv addresses
backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again -
noticing, that batman-adv remained stable (or migratable) over the last years and start
using it again. Maybe, batman-adv will fit our needs, then.
You are free to use whatever you want. I think I've made a clear point that this
compat bump is designed
to address the compat issues we had. What you roll out then is up to you (personally
I'd be interested
what you'll use instead) - but I guess you'll miss a lot of very nice features of
P.S.: Note that I'm talking about "we" and "us", but this is
pretty much my personal opinion and no
official statement of the batman-group whatsoever. :)