[RTG-DIR] About Babel management [was: RTG-DIR QA review...]

[Juliusz Chroboczek <[e-mail]>]

I've added Barbara Stark and the babel@ietf mailing list to the CC.

> Are your users only using proprietary management?  Or are they using
> another open source management mechanism?

There are currently four production-quality implementations of Babel:

  (1) the standalone reference implementation, called "babeld" (Babel Daemon);

  (2) the implementation integrated into FRR (formerly Quagga), the leading
      Open-Source routing suite; this is based on an older version of babeld;

  (3) the implementation integrated into BIRD, the other major Open-Source
      routing suite; this is an independent reimplementation;

  (4) a proprietary implementation I know very little about.

Implementations (2) and (3) aim to integrate as well as possible into
their respective routing suites, and therefore they use, respectively,
FRR's and BIRD's native management mechanisms; I will be glad to get you
in touch with FRR and BIRD specialists should you wish to learn more (as
far as I'm aware, neither uses NETCONF).  The rest of this mail only
applies to implementation (1), babeld.

Babeld has a rich management language (including BGP-style route
filtering), which can be used in two ways:

  - statically, in a set of configuration files that are read by babeld at
    startup;
  - dynamically, over a TCP or Unix Domain socket.

The management language is a textual format that is carefully designed to
be both human- and machine-readable, and extensible without breaking
backwards compatibility.  The implementation does not rely on any external
libraries, and the hand-written recursive-descent parser consists of 1347
lines of C code that compile to 11.5kB of text.

It has the following features:

  - global configuration of the daemon;
  - configuration of parameters of specific interfaces;
  - route filtering, inspired by gated but more powerful;
  - one-shot monitoring;
  - event-driven monitoring.

The interface is designed to be as exhaustive as possible.  It therefore
exposes a number of internal implementation details that it would not be
useful to standardise.

As you know, babeld is deployed in production.  Here are a few examples of
how our users do monitoring and reconfiguration in production.

1. Static configuration

A number of our users use a subset of the configuration language in static
configuration files.  As far as I can tell, the most common applications
are, in roughly decreasing order:

  - defining the set of active interfaces;
  - changing the link-quality estimation algorithm of specific interfaces
    (notably enabling the optional RTT- and diversity-based algorithms);
  - filtering out aggregated routes or routes subsumed by a default route.

As far as I can tell, our users do not much tweak any of the other
tweakables.  I like to think that this is because Babel is able to adapt
to widely varying network conditions without the need to tweak.

2. Dynamic reconfiguration using static interfaces

The reference implementation of the Homenet protocol suite generates a new
configuration file every time the hnetd daemon detects a configuration
change, and restarts the babeld process.  While a better approach would be
to use the dynamic reconfiguration mechanisms in babeld, this approach is
easy to implement, and appears to be good enough for Homenet.

    https://github.com/sbyx/hnetd

3. Pure dynamic reconfiguration

Nexedi are a French company that use Babel for managing a global-scale
overlay network between datacenters over the public Internet.  Nexedi are
interested in avoiding any form of manual intervention: they do not
manually configure metrics, but instead rely on the Babel-RTT extension to
compute metrics automatically:

   https://tools.ietf.org/html/draft-jonglez-babel-rtt-extension

However, Nexedi sometimes need to bring down a link in their overlay, and
wish to avoid waiting for the protocol to reconverge.  For that, they use
a proprietary configuration interface in order to bring a Babel interface
down before they bring the link down, thus achieving graceful failover
with no packet loss whatsoever.

Nexedi currently use a proprietary management interface, but I am working
with them on getting them to use the normal babeld mechanisms (which is
somewhat involved, since part of their nodes are at customer sites and
therefore a flag day is not possible).

4. one-shot state dumps parsed by a script

The management interface is designed so that its output is trivial to
parse using a script without using any extra libraries.  For example, the
following command line gives a dump of all routes known to the local Babel
daemon:

  (echo dump; echo quit) | nc ::1 33123 | grep '^route add '

People usually use ssh tunnelling in order to dump the state of remote
nodes.

A surprisingly large number of our users perform monitoring using this
kind of approach.  The most ambitious case I am aware of is the Wlan-SI
nodelist, which is a PHP-based website that gives real-time details about
a fairly large hybrid Babel/OLSRv1 network:

    https://nodes.wlan-si.net/

5. event-driven monitoring

The management interface is designed to support event-driven monitoring.
This is used by the "Babelweb" graphic tool:

    http://babelweb.wifi.pps.univ-paris-diderot.fr:8080/


As you can see, we are actively working with our users on management for
Babel.  There is a lot of exciting and novel experimentation going on, and
it is therefore my opinion that it would be a mistake to mandate a single
style of management in rfc6126bis.

Regards,

-- Juliusz