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

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jan 2018 04:32:02 +0100

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 08 Jan 2018 18:33:29 +0100

Juliusz Chroboczek <[email-masked]> writes:

> 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.

+1 on that assessment :)

-Toke

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 18 Jan 2018 04:38:40 -0500

Toke and Juliusz: 

Before I send my next Babel set of comments, can you tell me what management you want to standardize?  Please choose one of the following options: 

1) None - it is all proprietary 
2) Yang modules - for configuration 
3) Yang modules for monitoring 
4) Specific configuration knobs - not as yang modules. 

Thank you, 
Susan Hares 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Toke Høiland-Jørgensen
Sent: Monday, January 8, 2018 12:33 PM
To: Juliusz Chroboczek; Susan Hares
Cc: [email-masked]; [email-masked]; 'Russ White'; 'Alia Atlas'; Barbara Stark; 'Donald Eastlake'; 'David Schinazi'
Subject: Re: [RTG-DIR] [babel] About Babel management [was: RTG-DIR QA review...]

+1 on that assessment :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 18 Jan 2018 17:30:11 +0100

> Sorry I didn't pick from your 1 - 4 options, but I hope this provides
> you with the information you need?

I'll just add one comment, since Susan might want some more insight into
the culture of this WG.

The main contributors to this WG have been working very hard to establish
a tradition of working code.  I'm fairly positive that every single Babel
draft, whether adopted by this WG or written before the WG was established,
does reflect implementation experience.

We're very serious about that.  For instance, the people working on
DTLS-based Babel security have agreed not to write anything up until we've
got at least one proof-of-concept implementation (hopefully two, fingers
crossed).

I don't think anyone here would be opposed to writing up and standardising
a YANG model for Babel should one be implemented first.  However, since
none of the implementations of Babel speak Netconf, and since until now
the users of Babel have not been asking for Netconf-based management, this
is not something that's likely to happen in the immediate future.

Should we find out that either the users or the implementers are requesting
Netconf, a YANG model would become much more likely.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 18 Jan 2018 14:26:43 +0000

Hi Susan,
I hope Juliusz and Toke don't mind, but I'll provide my thoughts re babel management, as the current author of draft-ietf-babel-information-model.
https://tools.ietf.org/html/draft-ietf-babel-information-model-01 

We agreed to start with an information model, rather than go directly to some management protocol's data model, because babel may be implemented in ISP-supplied CE routers which are almost all managed using BBF TR-069 today. But I understand YANG models are expected to exist for all IETF routing protocols.
By starting with the information model, subsequent BBF and YANG data models can be created that can easily be mapped from one to the other.

The current draft-ietf-babel-information-model has a few parameters that an implementation may choose to allow to be configurable. All are readable.
Statistics (for monitoring) are on the to-do list. 

I have no intention of creating a YANG module (not my specialty and not something I have need of) from this information model. That would need to be an exercise for someone else. I do expect to create the BBF TR-069 data model. In BBF.

Sorry I didn't pick from your 1 - 4 options, but I hope this provides you with the information you need?
Barbara

> From: babel [mailto:[email-masked]] On Behalf Of Susan Hares
> Sent: Thursday, January 18, 2018 4:39 AM
> To: 'Toke Høiland-Jørgensen' <[email-masked]>; 'Juliusz Chroboczek'
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; 'Russ White' <[email-masked]>; 'David
> Schinazi' <[email-masked]>; 'Alia Atlas' <[email-masked]>; 'Donald
> Eastlake' <[email-masked]>; STARK, BARBARA H <[email-masked]>
> Subject: Re: [babel] [RTG-DIR] About Babel management [was: RTG-DIR QA
> review...]
> 
> Toke and Juliusz:
> 
> Before I send my next Babel set of comments, can you tell me what
> management you want to standardize?  Please choose one of the following
> options:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=5533-
> AnnrHe4u9HjLj8J3SX7PX0kKhWwSisuRIrV0SI&s=oh7uMBdX9kqNvQh9wGrec
> HaiJkxhn16tFFSomeH0DQw&e=