[Babel-users] [babel] Babel to standard

[Russ White]

> Which, if any, of the currently defined extensions should be merged into
the
> base spec?  My opinion is that the extension mechanism should be merged,
> but that the actual extensions should remain separate documents.

I would agree with this assessment -- the extension mechanism should be
merged in the base doc, but any actual extensions should be managed
separately. I would say each proposed extension needs a pretty clear use
case, a specification, and then an implementation report (if available), and
possibly some form of deployment experience draft (if available).

Smaller, more focused chunks are better than the long many page documents
we've been seeing a lot of recently.

> RFC 6126 states that designing a route selection algorithm for Babel is an
> open research problem.  While this is still true, there should be an
> informative appendix that describes the trivial algorithm (just pick the
route
> with the lowest metric) and the time-sensitive algorithm used since
version
> 1.4.0 of babeld since it is simple and appears to work well in practice.

Yes, definitely. Note that choosing a route across two metrics is, as I
understand it, unsolvable. This is the reason EIGRP uses the K values to
merge the metrics the user would like to actually deploy into a single
metric. Note also there needs to be some way to prevent oscillation between
the control plane and the data plane when you start playing with delay,
bandwidth utilization, etc., in the real world. These are nasty problems.

> Incompatible protocol changes
> =============================
> 
> A Babel packet carries a protocol number, which it is possible to increase
if
> the protocol needs to change in an incompatible version.  I'd be opposed
to
> doing that, since it would severely impact the installed base of Babel
routers,
> and could cause a split in the community, as has unfortunately happened
> with the OLSR community.

A protocol version? It would be simpler to have some sort of capabilities
negotiation here, possibly.

> Adding mandatory and transitive bits, as in BGP
> -----------------------------------------------
> 
> There is currently no way to mark a sub-TLV of an Update TLV as mandatory,
> as in BGP.  This has forced us to design the source-specific extension as
using
> a separate TLV, which is not very elegant.  However, the source-specific
> extension would still have required new TLVs for requests.
> 
> Mandatory and transitive bits would make it easier to design an extension
> that does BGP-style communities that are suitable for filtering, a feature
that
> has been requested by both the Italian and Slovenian communities.
> 
> I believe that the doubtful benefits that this provides do not justify an
> incompatible protocol change.

I would disagree... It's better to have some way for a device receiving an
update if it should ignore and potentially send an error, or if it should
try and process. If you don't have mandatory bits, then you don't have a way
to error out of a neighbor relationship. This means the receiver can either
just bounce the relationship and refuse to peer, which is really hard to
troubleshoot, or it can accept and ignore, which can also be really hard to
troubleshoot.

> Source-specific routing uses its own set of TLVs, which are distinct from
the
> base protocol's TLVs.  Merging the two kinds of TLVs would yield a
slightly
> cleaner protocol, but would require putting source-specific routing in the
> base spec.  I like small specs.

I would keep the specs separate, myself.

>   * lower-layer security (e.g. put a frightening guy or gal with
>     a truncheon in front of each Ethernet plug, or use 802.1X);
>   * HMAC authentication (RFC 7298);
>   * Stenberg-style authentication (move everything to unicast except
>     hellos, use DTLS);
>   * use the replay protection from RFC 7298 together with statically keyed
>     IPsec.
> 
> There are different tradeoffs between these techniques (reuse of existing
> libraries vs. compact code, authentication only vs. privacy, etc.), so the
> current plan is to implement them all and let the community decide.  I am
> therefore strongly opposed to putting any security mechanism in the base
> spec.

I would allow separate development in this area -- but it does need to be
done. I would look at requirements and solutions, and make a single
decision. Otherwise you fragment the implementations, as not every one of
these is as easy to implement as it might seem, and you might find holes
that need to be fixed in all four at some point. A single solution is
better, IMHO.

:-)

Russ