[Babel-users] Bable vs Linux Mesh mode.

[Dave Taht]

On Wed, Nov 19, 2014 at 7:11 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> Hi Ian,
>
> I've been refraining from answering in order to let somebody less biased
> reply, but nobody has taken the bait.
>
>> I've been looking to compare Babel with 802.11s, Batman-adv, smesh and
>> olsrd2 (Byzantium seems to use Babel so I am ignoring this.)
>
> I won't speak of dmesh, since it is not a routing protocol -- it's a full
> architecture that integrates a lot of things.  They currently use their
> own (link-state) routing protocol, but there's no reason I can see why
> smesh couldn't be built over Babel.
>
> Let's first compare 802.11s and Babel -- they're very different beasts,
> and fill different ecological niches.  In fact, you could run both in the
> same network, and they'd work fine together.
>
> 802.11s works at the link layer: it's invisible at the network layer, the
> network layer thinks that all the 802.11s nodes are direct neighbours.
> 802.11s was designed for small networks -- it's limited to 25 nodes per
> mesh.  There are fundamental design choices that prevent it from scaling
> much beyond that (it requires that all the nodes in the mesh have
> synchronised timestamps, for example).

There are fundamental design choices that prevent it from scaling to that,
also. And - a serious limitation - an 802.11s mesh is limited to devices all
on the same channel, which does not scale anywhere near as well
as a protocol that can find the best path over multiple channels (like
batman and babel)

> Babel works at the network layer, and it's link-layer agnostic: it will
> work over any reasonable link layer, including Ethernet, Wifi, Homeplug,
> GRE tunnels, VPNs, and even 802.11s.  (But not RFC 1149, which only
> supports a very messy form of multicast.)
>
> Because it works at the network layer, Babel is not entirely transparent
> -- DHCP, IPv6 autoconf and DNS-SD don't work for Babel nodes.  That's why
> we need AHCP or HNCP, and DNS-SD proxies.

Um, er. "Doesn't work?"

Babel works just fine on dhcp and ipv6 autoconf address assignment
on ethernet and on stations talking to APs. A box running babel can at least
observe and to some extent participate in the routing protocol (for example
I find seeing unreachable routes go by on my client useful). I also tend to use
it in this case as a "poor man´s" ruptime, where I can see the entire status
of the network from a given client.

Juliusz: I think what you are thinking about is on meshy (ad-hoc) p2p
wifi networks,
address assignment is a problem. And in general HNCP is going to be an
improvement but it aint fully baked yet.

Having a given box with variable address assignment actually
participate in routing, generally requires that you disable fetching
the default route from dhcp, dhcpv6, and ipv6 and rely on babel to
provide
default and regular routes. (static default routes are evil)

This is easy - if you are using isc dhcp you just disable fetching the
dhcp routing parameter in /etc/dhcp/dhclient.conf,  on openwrt, on
dhcp enabled nodes, you put in a defaultroute 0 for that network
stanza.

and boom, you are participating in the routing system if you have two
or more interfaces.

I do this all the time.... it is maddening that things like
NetworkManager insist on thinking I only want one interface up at a
time, however, so I end up doing stuff in /etc/network/interfaces

I want to be always connected via ethernet, 3g, and wifi and just fail
over when one goes away.

I have in the core of my lab, for example, two boxes with 8 network
ports each, both cross connected to the same 8 subnets running on
other routers (and mostly) with dynamically assigned addresses. If one
fails, the other takes over... I recently went weeks without noticing
that one router had crashed... until I crashed the other one.

>
> On the other hand, Babel is much more scalable, robust and flexible than
> 802.11s.  Babel is designed to scale to thousands of nodes in a single
> routing domain.  A Babel node can be configured to act as a full router
> (forward packets for arbitrary third parties), stub-only (only accept
> packets for itself) or anything in between (forward packets for some
> arbitrary subset of destinations).  There are fully backwards compatible
> Babel extensions that are smart about choosing paths in specific
> topologies, such as high-diversity radio networks (Babel-Z) or overlay
> networks (Babel-RTT), and more such extensions could be devised if your
> topology is particularly challenging.

Bridging in general defeats many possible optimizations that babel (or
any routing protocol) could do. In the aformentioned network I also
have homeplugs connecting part of it and the "distance" is shorter
in one case using that, but the relative capacity of two gigE hops is
greater. You can get around
this somewhat by using the rxcost parameter...

Same goes for APs which conventionally bridge wifi and ethernet.

> In short, 802.11s is great is you need a hassle-free mesh that is built
> out of a small number of Wifi routers.

I have OLPC related scars that make for a very limited usage of the word
"great" for 802.11s.

> Babel is great is you think that
> your mesh might grow larger than what 802.11s supports, or if you want to
> build an efficient heterogeneous mesh (both wired and wireless networks).
>
> As to Batman-adv -- it's a link-layer protocol, like 802.11s, but attempts
> to be more robust in larger meshes (no seqno synchronisation).  It appears
> to be extremely stable in practice, but suffers from somewhat slow
> convergence times.  Unfortunately, the Batman-adv protocol has never been
> published, so it is difficult to understand how it works.
>
> Hope this helps,
>
> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks