[Babel-users] Redefining the encoding of source-specific updates

Juliusz Chroboczek jch at pps.univ-paris-diderot.fr
Thu Jun 9 15:55:04 UTC 2016


Dear all,

Matthieu and I are considering changing the encoding of source-specific
updates in an incompatible manner.  We haven't decided anything yet,
here's a summary of our thinking.

The current encoding of source-specific updates is described in

  https://tools.ietf.org/html/draft-boutier-babel-source-specific-01

In short, a source-specific update is carried by a new TLV type, which is
silently ignored by non-source-specific implementations.  There are two
other new TLV types, for requests for source-specific routes.

Note that source-specific updates cannot be encoded as an ordinary update
with a sub-TLV for the source, since Babel lacks a mandatory bit: the
sub-TLV would be discarded by non-source-specific routers, and the update
would be mis-interpreted, leading to routing pathologies.

Now Babel uses a single Update TLV for both IPv4 and IPv6; IPv4 is
distinguished from IPv6 by the AE, which is a one-octet field with values
1 for IPv4 and 2 for IPv6.  See Section 4.1.3 of RFC 6126.  Unknown TLVs
are silently discarded according to RFC 6126 (although Matthieu has noted
a bug in the implementation with this).

The idea would be to encode source-specific updates using the existing
Update TLV, with two new AE values for v4 source-specific and v6
source-specific.  This avoids the need for three new TLVs, and
significantly simplifies the packet parser.

There are some minor complications; the structure of the Update TLV
changes, but only for the new AEs (so compatibility is preserved).
Additionally, there are some complications with address compression (do we
organise a leak of information between different AEs, or do we make
compression completely independent?  the latter is simpler and cleaner, so
I tend to favour it, while the former gives slightly better compression).

Opinions?

-- Juliusz



More information about the Babel-users mailing list