Subject: [babel] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 12:38:09 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-babel-applicability-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 2.1. This section makes a number strong claims that I would
recommend be tempered:

-- Per the sentence, “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)”, what does this mean? 
If this is to suggest to the reader that they too can learn Babel in 15
minutes, it is unconvincing and reads like a marketing statement.

-- Per the phrase, “…including one that was reportedly written and debugged in
just two nights“, this statement is not convincing without context.

-- Per the sentence, “In addition to the above, our implementation experience
indicates that Babel tends to be robust with respect to bugs: more often than
not, an implementation bug …”, this text is an improvement over -07 (thank
you), but I still view this as a high risk, anecdotal claim.  I strongly
recommend it be removed.

(2) Section 2.2.  This section uses the designation of “strong” vs. a “weak”
property.  Where are those defined?

(3) Section 2.2.  Per the sub-bullets of “These weak requirements make Babel a
robust protocol …”, what assurance does the phrase “does most likely not”
suggest?  Furthermore, the claim that implementation bugs won’t collapse the
network based on an uncited “extensive” experience seems too strong of claim.

(4) Per Section 3.1.  How big is a “medium-sized hybrid network”?

(5) Per Section 3.1.  What are “meshy wireless bits”?

(6) Section 3.2.  Is there a citation for the successful deployment in “large
scale overlay networks, built out of thousands of tunnels spanning continents”?

(7) Section 3.4. The utility of Babel in small and home offices surprised me as
I wasn't expecting such networks to mix IPv4 and v6; and use an IGP.

(8) Section 5.  Per the sentence “Due to its simplicity, Babel-HMAC  …”, I’m
not sure that simplicity should be driving the choice of the security
properties.  It seems like it should be the security requirements.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 17 Aug 2019 21:30:32 +0200

> minutes, it is unconvincing and reads like a marketing statement.

I stand by my claim.  I've done it multiple times, last time was back in
July at Battlemesh, and a good part of the audience got it.

> just two nights“, this statement is not convincing without context.

It happened at an IETF meeting.  The author was Markus Stenberg.  Please
indicate precisely what additional context you would expect.

> you), but I still view this as a high risk, anecdotal claim.  I strongly

I've removed this paragraph.  (I stand by my claim, but I've removed it
from the document.)

> property.  Where are those defined?

https://en.wiktionary.org/wiki/weak#English meaning 9.

This is standard usage in mathematics.

> network based on an uncited “extensive” experience seems too strong of claim.

The part about bugs has been removed.

> (4) Per Section 3.1.  How big is a “medium-sized hybrid network”?

Covering a small European country and parts of its neighbours:

  https://wlan-si.net/en/map/

> (5) Per Section 3.1.  What are “meshy wireless bits”?

I believe the formulation is clear, and I like it.

> (6) Section 3.2.  Is there a citation for the successful deployment in
> “large scale overlay networks, built out of thousands of tunnels
> spanning continents”?

Nothing that I can cite.  The sentence in the draft was painstakingly
negotiated with the CEO of the company who run the network.

  https://re6st.nexedi.com/

> (7) Section 3.4. The utility of Babel in small and home offices
> surprised me as I wasn't expecting such networks to mix IPv4 and v6; and
> use an IGP.

Do you wish me to remove this bit?  I only have two examples:

  - Dave Taht's network, which is used to cover a camping;
  - my home network.

> properties.  It seems like it should be the security requirements.

Can we please agree to disagree on this subject?

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sat, 17 Aug 2019 12:55:49 -0700

>   - Dave Taht's network, which is used to cover a camping;

I'm not sure what you mean by IGP? Having any commonly deployed IGP is a boon
when you can't/don't want to bridge networks together.

My original babel network was deployed in Nicaragua, some pics and
discussion of that are here:
https://www.youtube.com/watch?v=Wksh2DPHCDI&t=3s and it also goes into
the diffulties with
wifi multicast and bridging and the state of the queuing issues wifi
had at the time (now fixed)

The campground network here (it's not "my" network, but lupin lodge's
( https://www.google.com/maps/place/Lupin+Lodge/@37.1702044,-121.9809242,1374m/data=!3m1!1e3!4m8!3m7!1s0x808e37c562ac66c3:0xedf7d1fb2e08927d!5m2!4m1!1i2!8m2!3d37.1699311!4d-121.9784355
)had very difficult requirements - to cover 110 acres and multiple
office buildings there was a mix of p2p radios and APs and multiple
touch down points to wired (comcast) networks.  This is in part where
babel's source specific routing feature exists and where it was first
tested.

Lots of ravines. Redwoods...

It was very mesh because trees fall, power lines fail, random people
unplug things to plug
in their hair dryers, it's a pretty hostile environment that always
needed to have two or
more paths to everything so I could fix it at leisure.

At one point it was vastly more complicated than it is now, had about
36 radios in the field and 70 in the lab.
Lab's shuttered... there's a vpn in place (also babeld) to connect
multiple edge points....

It ran ipv6 and ipv4 up until recently but as one sad example, I had
to kill the ipv6 support I'd had running everywhere as netflix started
blocking the hurricane tunnel for it, and there is not as yet a good
distribution mechanism across a
network this meshy for dynamic ipv6 addresses I now get from comcast.

 babel was (and still is) the only protocol and daemon I'd ever found
that could do both ipv6 and ipv4 in very limited
memory on the radios (32MB ram) I started with. Even today more than
32MB ram is uncommon in outdoor
wireless APs (although 802.11s has come pretty far along, I still
don't think it suitable for this application)

 Anyway, having "a" routing protocol that worked well to connect up
wireless and wired links always seemed a goodness
for n networks as n > 5 and redundancy required.

I wish I knew what aruba did these days.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 18 Aug 2019 12:27:57 +0200

>   - Dave Taht's network, which is used to cover a camping;

I do this as well; including bridging multiple physical locations over
VPN tunnels, and multi-homing my laptop; all using Babel... :)

-Toke

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 19 Aug 2019 15:22:14 +0200

> On 17. Aug 2019, at 21:30, Juliusz Chroboczek <[email-masked]> wrote:
> 

How did you evaluate that a “good part of the audience got it”. If you cannot evaluate this appropriately, I would also call it a marketing statement...