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

[Markus Stenberg]

On 9.6.2016, at 18.55, Juliusz Chroboczek <jch at pps.univ-paris-diderot.fr> wrote:
> 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.

Disclaimer: You know I am not big fan of the current encoding :)

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

I like this.

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

I prefer the latter as well. I suspect compression rates are not deal breaker and defining leakage so that it works also in presence of future AEs is bit iffy. e.g. can you do it only in AEs increasing order or..? :-p (if you assume people implement AEs in definition order)

Cheers,

-Markus