Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: babeld-1.9.0
Date: Sun, 4 Aug 2019 19:27:46 -0700	[thread overview]
Message-ID: <CAA93jw76hup6L5itJfNNARwNdyQHKZ88qVnzk-NO6JK5dxwPEA@mail.gmail.com> (raw)
In-Reply-To: <874l2ws9te.wl-jch@irif.fr>

---------- Forwarded message ---------
From: Juliusz Chroboczek <jch@irif.fr>
Date: Sun, Aug 4, 2019 at 6:03 PM
Subject: [Babel-users] ANNOUNCE: babeld-1.9.0
To: <babel-users@lists.alioth.debian.org>


Dear all,

Babeld-1.9.0 is available at

  https://www.irif.fr/~jch/software/files/babeld-1.9.0.tar.gz
  https://www.irif.fr/~jch/software/files/babeld-1.9.0.tar.gz.asc

For more information about babeld and the Babel routing protocol, please see

  https://www.irif.fr/~jch/software/babel/

New features
============

This release accumulates all the changes made since November 2018; as
such, it contains a number of new features.

The sending of data over unicast has been entirely reworked, and it is now
as efficient as sending data over multicast.  As a consequence, it is now
possible to configure babeld to send all data except Hellos over unicast.
Say:

    default unicast true

This might (or might not) yield better results when running over a link
layer with bad support for multicast (such as WiFI).  More experimentation
is needed.

Redistribution has been reworked to work in n log n time (it used to be
quadratic).  It is now possible to redistribute tens of thousands of
routes.  (Thanks to Dave Taht for pointing out the issue.)

We are now less aggressive at sending triggered updates and route
requests; while this slows down reconvergence after a mobility event, it
makes the protocol much less noisy, and ends up speeding things up after
a network meltdown.  (Thanks to Teco Boot for pointing out the issue.)

It is now possible to set the preferred source address for routes
installed in the kernel.  See the "pref-src" option in the manual page.
(Thanks to Killian Lufau.)

Other branches
--------------

A lot of the recent work on babeld has been happening in other branches
that haven't been merged yet.  Of particular interest are two security
extensions.

The branch "hmac" implements symmetric authentication,

  git clone -b hmac https://github.com/jech/babeld

This is work in progress, but it has received a fair amount of testing,
and we are rather optimistic about its security.  This is joint work with
Clara Do and Weronika Kolodziejak, and is described in detail in

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

The branch "dtls2" implements Babel over DTLS:

  git clone -b dtls2 https://github.com/MisterDA/babeld

This is a more ambitious extension, that provides asymmetric keying,
authentication and confidentiality.  It is due to Antonin Decimo and David
Schinazi.  The protocol is described in

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


Incompatible changes
====================

New (mostly compatible) protocol revision
-----------------------------------------

As some of you may know, the Babel protocol has been undergoing some minor
changes as part of the IETF standardisation process.  The new revision is
provisionally known as "RFC 6126bis", while the old revision is known as
"RFC 6126".

Babeld-1.9.0 uses the new features of RFC 6126 bis, and might therefore
fail to interoperate with versions older than 1.8.1.  The per-interface
option "rfc6126-compatible" can be used to force babeld to speak the older
protocol.

In short, you should either

  * make sure that all your routers run babeld-1.8.1 or later; or
  * add "default rfc6126-compatible true" to babeld.conf on the routers on
    which you install 1.9.0.

Please be aware that option "rfc6126-compatible" disables some features,
most notably source-specific routing.

Source-specific routing
-----------------------

While the core protocol has remained mostly stable, we have completely
reworked the protocol for source-specific routing:

  * babeld-1.9.0 will ignore any source-specific routes announced by
    babeld-1.8.5 and earlier;
  * babeld-1.8.1 through 1.8.5 will ignore any source-specific routes
    announced by babeld-1.9.0.

If your network relies on source-specific routing, you might temporarily
loose connectivity with the wide Internet as you update your routers.  You
should retain connectivity within your network, so there should be no need
to climb up any trees.


The full changelog follows.

Enjoy,

-- Juliusz

4 August 2019: babeld-1.9.0

  * Reworked buffering of unicast packets to use a per-neighbour buffer
    rather than a single buffer per interface.  This makes unicast as
    efficient as multicast, at the cost of slightly higher memory usage.
  * Added option "unicast" that allows sending most TLVs over unicast.
    This is necessary for the DTLS extension.
  * Implemented parsing of unicast Hellos.  This makes it possible to
    interoperate with neighbours that only speak unicast (e.g. over some
    kinds of tunnels that only do unicast).
  * Implemented sending of unscheduled unicast Hellos.  This makes the
    RTT extension work over unicast too.
  * Reworked the xroute data structures to use binary search and
    linear-time comparison.
  * Don't attempt to modify the rp_filter sysctl if it already has the
    desired value; this makes it possible to run babeld in an
    unpriviledged container.  Thanks to Christof Schulze.
  * Reinstated logging of late hellos.  Thanks to Dave Taht.
  * Don't send wildcard requests or Hellos to newish nodes.  This makes
    acquisition of new neighbours slower, but drastically reduces noise at
    startup.  Thanks to Teco Boot.
  * Remove an arbitrary limit on the number of interfaces.  Thanks to
    Christof Schulze.
  * Removed class E from martian filter.  Thanks to Dave Taht.
  * Added the ability to set the preferred source address in install filters.
    Thanks to Killian Lufau.
  * Fixed a number of read-only buffer overflows.  Thanks to Leo Stefanesco.

_______________________________________________
Babel-users mailing list
Babel-users@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

           reply	other threads:[~2019-08-05  2:27 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <874l2ws9te.wl-jch@irif.fr>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw76hup6L5itJfNNARwNdyQHKZ88qVnzk-NO6JK5dxwPEA@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox