Subject: [babel] About Babel-RTT

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Jul 2020 18:26:17 +0200

Dear Ronald,

[Both Babel MLs in CC]

At the WG meeting, you asked about the future of the Babel-RTT draft.

The protocol extension isn't going away.  It's been used in production for
many years at Nexedi, where it works beautifully.  No other production-quality
routing protocol known to me has this kind of automation.

As to the draft, the situation is somewhat less good.  Baptiste Jonglez,
who did the initial implementation, does not appear to be interested in
working on the subject.  The current draft merely describes the packet
format, it doesn't fully describe the algorithms needed to make it work
well.  As to the algorithms, we did determine experimentally that they
work well, but we haven't been able to get a satisfactory theoretical
explanation of why that is the case.

So in order to make it into a peer-reviewed paper or an internet-draft,
I would need help from a competent dynamic systems theorist.  Any help
with that would be welcome.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Jul 2020 10:08:04 -0700

I'll note that while a theoretical explanation/study sounds interesting,
it's not required for publication of an IETF document. The fact that
there is a real-world deployment of this technology is much more
useful to me than whether or not it's theoretically sound. So I'd be
in favor of advancing the document without the theoretical analysis,
if someone has the time to document the "algorithms needed to
make it work well" in the draft.

Note that I do not qualify as a "competent dynamic systems theorist",
I am merely an engineer that likes protocols that work, like Babel :-)

David

On Tue, Jul 28, 2020 at 9:26 AM Juliusz Chroboczek <[email-masked]> wrote:

> _______________________________________________
> Babel-users mailing list
> [email-masked]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Jul 2020 19:54:30 +0200

> it's not required for publication of an IETF document.

In my opinion, without a theoretical understanding, it is difficult to
provide adequate guidance to implementers.

We have a deep theoretical understanding of what makes Babel work.  This
is why we can say with confidence that implementations MUST evaluate the
feasibility condition and that the metric MUST be stricly monotonic, but
we can safely leave the details of the route selection algorithm to the
implementation.

Not so with Babel-RTT.  We've got an implementation that has been shown to
work, but we have no precise ide which parts of the implementation are
important and which are coincidental.  In this situation, I don't feel
confident to write up a protocol description.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 28 Jul 2020 20:09:39 +0200

> provide adequate guidance to implementers.

Since I'm in a chatty mood, I'll give another example.

While both RFC 2328 and Moy's book are written in a very simple engineering
style, there is some reasonably solid theory behind OSPF, which at least
some OSPF specialists don't appear to fully appreciate.  For example, the
topological restrictions on area adjacency are pretty much the weakest
conditions that avoid counting to infinity, and the extreme care given to
the flooding subprotocol indicates a good understanding of the consequences
of desynchronised LSDBs.

I'm deeply convinced that there is no such thing as sound engineering
without a solid theoretical base.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 Jul 2020 23:24:03 -0400

Given that it is deployed and working well but not well understood,
this seems like an excellent candidate for an Experimental RFC, which
is what the expired draft here
https://www.ietf.org/archive/id/draft-ietf-babel-rtt-extension-00.txt
is targeted for. Presumably the experiment would be to try variations
in different deployments.

If even experimental is considered too ambitious, it could be just an
informational document to make a record of the known good deployment.
(Either experimental or informational would work as the basis to
allocate the required code point.)

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]