[Babel-users] Some thoughts about Babel (feature requests)

[Max B]

We forked babeld and have included an ipc process which allows us to add and remove interfaces while babeld is running: 
github.com/sudomesh/babeld

The history state on master is a bit of a nightmare,  but the maxb/upstream-fixes branch has all of the sudomesh changes applied as one commit to babeld master.

Agreed that it's inconvenient to have running configuration differ from config on file,  but we only use it for the exit server and the l2tp interfaces come up and down so frequently that it's been a reasonable solution so far. 

On December 16, 2015 4:33:49 PM PST, Juliusz Chroboczek <jch at pps.univ-paris-diderot.fr> wrote:
>> I met today with Kostko and we discussed Babel a bit. We have few
>> feature requests which would really improve how we are using Babel in
>> wlan slovenija network.
>
>All of your requests are reasonable.  (But please distinguish between
>Babel, which is a protocol, and babeld, which is just one of the
>available
>implementations of Babel.  And not necessarily the bestest -- Toke's
>implementation, while not quite ready yet, shows a lot of promise.)
>
>> So, on VPN servers we create tunnels to each node. This means, that
>to
>> make it work with Babel, we have then to put all tunnels into one
>> bridge and configure Babel to use that bridge.
>
>Agreed, this is bad.
>
>> - alternatively, there could be some IPC interface where we could
>call
>> into Babel (Kostko prefers, but I do not like it because then
>> configuration on disk differs from the one running)
>
>This was implemented in the (sadly defunct) Quagga implementation of
>Babel.  Doing that in babeld is planned for 1.8.0 (the version after
>current head is released as 1.7.0).
>
>(Hmm, perhaps it's time to freeze 1.7.0 as it is now and delay the
>remaining changes to after 1.8.0.  Matthieu, opinion?)
>
>Note however that you can already call babeld with interfaces that
>don't
>exist yet:
>
>  babeld tun0 tun1 tun2 tun3 ... tun42
>
>and babeld will notice when one of the listed interfaces comes into
>existence.  (You can speed the process up by sending SIGUSR2 to babeld
>when a new interface appears.)
>
>> Additionally, we worry that Babel does not handle many interfaces
>> well, that is, in a performant manner. Especially observing that
>Babel
>> used to use linear searching in lists for other things. So we have an
>> interface for every node, which means that this can grow into
>> thousands. Will Babel handle that well?
>
>As you guessed, babeld does a linear search across all interfaces for
>every received packet, and in a few other places.  As usual, we'll be
>glad
>to fix that when you provide us with profiling data that show that this
>is
>a hot spot.  (My policy is to keep the data structures as simple as
>possible until I get profiling data.)
>
>-- Juliusz
>
>_______________________________________________
>Babel-users mailing list
>Babel-users at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20151216/6c8e0fae/attachment-0001.html>