Subject: [babel] Applicability statement for Babel

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 15 Feb 2016 15:52:20 +0100

Dear Alia, dear all,

I've just submitted

  https://tools.ietf.org/html/draft-chroboczek-babel-applicability-00

which a very rough draft of an applicability statement for Babel.  I've
done my best to be concise, I've managed to stick to 1.5 pages (not
counting boilerplate and references).  It's a -00, and we have some time
left before Buenos Aires, so contributions, criticisms and even outright
disagreements are very much welcome at this stage.

Russ, could you please check whether I'm citing the right document for
EIGRP?

Thanks,

-- Juliusz

---

From: Alia Atlas <[email-masked]>
Date: Thu, 25 Feb 2016 13:00:26 -0500

Hi Juliusz,

Thanks for writing this draft.   So, if I can summarize briefly from it:
    a) Babel can deal with prefix-based addressing as well as flat
addressing.
    b) Because Babel is distance-vector, it can deal with unstable metrics.
    c) It is small and has little configuration, so works well in unmanaged
small networks.
    d) Babel is not a good fit for large stable networks (IS-IS or OSPF
better) or low-power
        networks (due to periodic updates) or pure mesh networks (better
protocols exist).

Regards,
Alia

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 25 Feb 2016 20:11:39 +0100

Hi Alia,

Thanks for the (almost perfect) summary.  I'll try to produce a -01 with
the few points you didn't find clear.

> b) Because Babel is distance-vector, it can deal with unstable metrics.

Babel can deal with unstable metrics for many reasons, most notably due to
its loop-avoidance properties but also to the ability to delay "minor"
updates (which is due to loop avoidance) and the lack of a traumatic
active phase.  Thanks for the comment, it makes me realise that this needs
to be spelled out.

> Babel is not a good fit for large stable networks (IS-IS or OSPF better)

Or EIGRP, which produces minuscule amounts of control traffic while giving
more flexibility in filtering and aggregation.  I'm not going to spell
that out in -01, since that would belong in an EIGRP applicability
statement.

> pure mesh networks (better protocols exist).

I think Babel is fine for pure meshes, it's just that the niche is already
occupied by a very reasonable protocol (OLSRv2 with DAT, OLSRv2 is
standards track, DAT is experimental).  Here's some recent experimental
data where Babel is compared against a number of specialised mesh
protocols (including OLSRv2 with DAT):

   http://battlemesh-test-docs.readthedocs.org/en/latest/v8/2-the-crossed-streams-jeopardy.html

I'll add some references on this subject in -01.

Thanks for your help,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 29 Feb 2016 19:11:57 +0100

It's only once in 4.12 years that one has a chance to submit a draft on
a 29th of February.

  https://tools.ietf.org/html/draft-chroboczek-babel-applicability-01

-- Juliusz

---

From: Gabriel Kerneis <[email-masked]>
Date: Mon, 29 Feb 2016 19:22:03 +0100

>   https://tools.ietf.org/html/draft-chroboczek-babel-applicability-01

Looks good. A couple nits:

Babel is able to deal with both classical, prefix-based ("Internet-style")
> routing and flat ("mesh-style") over non-transitive link technologies.

I believe you still want "routing" in the second part (deleted by mistake?).

albeit

This introduces a contradiction, whereas there is none ("a more efficient
replacement" is not incompatible "with good support for wireless links",
quite the reverse).

 Best,
Gabriel