[Babel-users] Heads up: merged rfc6126bis into master

[Juliusz Chroboczek]

Dear all,

I've just merged the rfc6126bis branch into master.  While we've been
running this code for a few months without issues, it's not had quite
enough testing yet, so beware.  Help with testing will be appreciated.

TL;DR
=====

  - there's a new revision of Babel called RFC 6126bis;
  - the code in master is compatible with both revisions;
  - there will be no flag day, except for source-specific routing;
  - there will be a flag day for source-specific routing;
  - it should be safe to upgrade, please test.


Long version
============

RFC 6126bis is the successor to RFC 6126, which defines the Babel routing
protocol.  It doesn't have an RFC number yet, which is why we call it 6126bis.

   https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis

RFC 6126bis mostly consists of clarifications, tightenings and looseings
of RFC 6126.  However, it introduces three features that are incompatible
with RFC 6126:

  1. mandatory sub-TLVs;
  2. unicast Hellos;
  3. unscheduled Hellos.

Mandatory sub-TLVs are an important feature, one that makes Babel easier
to extend.  The new version of Matthieu's source-specific extension
depends on mandatory sub-TLVs, as well as Gwendoline's extension for
ToS-specific routing, make use of mandatory sub-TLVs.

Unicast and unscheduled Hellos are somewhat more specialised features, and
might be used to improve link-quality estimation in situations where
multicast is either very costly or extremely unreliable.  It might also
improve the security of the protocol in situations where unicast is
cryptographically protected but unicast isn't.

The code that I have just pushed into master will properly parse and act
upon the new features, but will never send any packets that don't comply
with RFC 6126.  Hence, it is compatible with both versions: it is safe to
use the current master in both RFC 6126 or RFC 6126bis networks.


No flag day
===========

There will be no flag day if you're not using source-specific routing.
The code in master (scheduled to be released as 1.8.1) is compatible with
both RFC 6126 and 6126bis, so it should be safe to upgrade.  A future
version of babeld will break compatibility with RFC 6126, but this is not
going to happen too fast.


What about source-specific routing?
===================================

The new version of source-specific routing is not interoperable with the
old version.  If you're using source-specific routing in your network,
you'll need to upgrade all of your routers.

I realise this is unfortunate, but there's really no choice -- the old
version of the source-specific extension is a mess, and, accordingly, the
code is unmaintainable.  The only way we can go forward is by removing the
old code and replacing it with the much more maintainable code that speaks
the new protocol.

The code currently in master still speaks the old version of the extension,
so it will not break your network.  Future versions of babeld will
silently ignore the old extension, so it is safe to upgrade.

Please see Matthieu's presentation for some details:

    https://www.ietf.org/proceedings/99/slides/slides-99-homenet-source-specific-routing-00.pdf


What about other implementations of Babel?
==========================================

BIRD 2.0 speaks RFC 6126bis.

Current sbabeld speaks RFC 6126bis.

The FRR version of Babel speaks RFC 6126.  That needs fixing.

Pybabeld speaks RFC 6126.

-- Juliusz