Subject: [babel] draft-ietf-babel-applicability WG Last Call

From: Donald Eastlake <[email-masked]>
Date: Wed, 11 Apr 2018 10:09:30 -0400

This message starts a two week Working Group Last Call on
draft-ietf-babel-applicability-03.txt. The several endorsements posted
in the last 24 hours will also be considered responses to this call.
:-)

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Apr 2018 16:46:54 +0100

Hi,

Thanks for a balanced assessment of Babel. I have a few minor comments
on the current revision.

Cheers,
Adrian

===

The Abstract could usefully say what this document is and does.
The first paragraph of the introduction might serve.

---

The use of the first person plural is not usual in RFCs largely because
it begs the question of who "we" are. Better to use "This document..."

---

1.1
s/traditional distance-vector protocol/distance-vector protocol/

---

1.1
s/two obvious extensions/two extensions/

---

2.1

Suggest to strike the following.

   Given a sufficiently friendly audience, the principles
   behind Babel can be explained in 15 minutes, and a full description
   of the protocol can be done in 52 minutes (one microcentury).

---

2.1

   While
   Babel is a young protocol, there exist four independent
   implementations, including one that was reportedly written and
   debugged in just two nights.

While an RFC is in some sense a snapshot in time, people will read
this document for years to come. You need to reword this accordingly.

It might also benefit from a citation or two.

---

2.2.

   o  strict monotonicity of the metric: M < C + M;

   o  left-distributivity of the metric: if M <= M', then
      C + M <= C + M'.

These may be true statements, but what are M and C and M' ?

---

2.2
OLD
   in contrast to traditional link-state routing protocols
NEW
   in contrast to link-state routing protocols

---

2.2
   This is in contrast to traditional link-state routing
   protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which are
   layered over a reliable flooding algorithm and make stronger
   requirements on the underlying network and metric.

Are OSPF and IS-IS really layered over a flooding algorithm or do they
incorporate the flooding algorithm?

---

The three examples in 2.2 all say "does most probably not". In principle
this is a reasonable thing to say, but it is subjective. It would be
nice to scope "probably" in some way.

I'm personally a little sceptical about the first example because my
experience suggests that coders are fiendishly capable of constructing
bugs that do all manner of unexpected things.

---

2.3

   Remarkably enough, all of the extensions designed to date
   interoperate with the base protocol and with each other.  This,
   again, is a consequence of the protocol design

Then it is not remarkable, then, is it? :-)

---

2.4.1
    a protocol that relies a reliable transport (such as OSPF, IS-IS

I don't think that either OSPF or IS-IS rely on a reliable transport.
Rather, I think they incorporate mechanisms to mitigate or overcome the
effects of an unreliable network.

---

It might be good to discuss the manageability of the protocol

---

Isn't [RFC6126bs] really a normative reference?

> -----Original Message-----
> From: babel [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Sent: 11 April 2018 15:10
> To: Babel at IETF
> Cc: [email-masked]
> Subject: [babel] draft-ietf-babel-applicability WG Last Call
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Apr 2018 20:01:36 +0200

Thanks for your comments, Adrian.  I'll give myself a few days to think
them over.

>    of the protocol can be done in 52 minutes (one microcentury).

Strongly disagree.  Comprehensibility and implementability are important
properties of Babel (second only to the fact that it works).  I'm open to
rewording if you find the current wording overly whimsical.

> I'm personally a little sceptical about the first example [in Section
> 2.2] because my experience suggests that coders are fiendishly capable
> of constructing bugs that do all manner of unexpected things.

This is based on actual experience.  I'll try to reword it, but I stand by
my claim.

For example, an early version of babeld had a bug that randomly corrupted
buffers; with high probability, the corruption happened within an IPv6
address, so nodes would simply learn spurious host routes that would time
out after a few seconds.  (It took us ages to find the bug, in the
meantime we were running with a network populated with occasional
"martians".)

Another example: I've recently introduced a bug in the sending of
triggered updates (fixed in 1.8.1).  The effect was that convergence was
slowed down in some cases, until the next periodic update, but the
loop-avoidance mechanisms were still functional, so not much harm happened.

I'll think about how to reword it, perhaps summarising the two examples
above might be useful.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 12 Apr 2018 20:08:01 +0200

> Isn't [RFC6126bs] really a normative reference?

Donald, please advise.

-- Juliusz

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 12 Apr 2018 22:10:07 +0100

> rewording if you find the current wording overly whimsical.

How about...

Babel is easily comprehensible and implementable. The principles behind Babel
can be quickly explained, and a full description of the protocol takes just 48
pages in [RFC6126bis].

> I'll think about how to reword it, perhaps summarising the two examples

OK. Maybe saying that "The protocol is robust against bugs such as buffer
corruption, message loss, and timer disruption" would cover it?

Cheers,
Adrian

---

From: Gabriel Kerneis <[email-masked]>
Date: Fri, 13 Apr 2018 08:27:41 +0000

> can be quickly explained, and a full description of the protocol takes

This is less whimsical (which is good) but it loses the important aspect of
being precise (that you advocate for in other comments). I'd suggest
something along the lines of:

Babel is easily comprehensible and implementable. The principles behind
Babel have been explained in under-an-hour talks to varied audiences, and a
full description of the protocol takes just 48 pages in [RFC6126bis].

Gabriel