Applicability of the Babel Routing Protocol
draft-ietf-babel-applicability-10

(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.

Juliusz,

Thank you for addressing my previous DISCUSS. I have edited my position to "no objection".

-éric

== (previous) DISCUSS ==

-- Section 2.2 --

The 'bug resistance' property of Babel was perhaps learned during the implementation, but, I wonder whether the document may simply state 'robust with respect to bugs', this is quite a strong statement that needs to be backed by facts or proof.

== COMMENTS ==

The title of the document is about 'applicability'; but, should it also include 'use cases' in the title ?

-- Section 3.1 --

The 2nd paragraph is too dense: should explain why Babel is a good fit.

-- Section 5 --

Comparison between HMAC & DTLS variants is probably irrelevant in this document. Though, a use case with security in mind would be benefitial.

Also, the comparison should include all aspects including confidentiality and anti-reply for both HMAC & DTLS.

== NITS ==

-- Section 2.2 --

As I am not a native English speaker, I wonder whether 'light' should not be preferred to 'weak' in "These weak requirements make Babel a robust protocol"

-- Section 3.1 --

Suggest to change the section name into "Diverse networks" or "heterogenous networks".

Thanks for writing this.

I find the use of "we" and "our" odd for a consensus document. I think the document would be improved if these used the document itself as the subject (e.g., "this document describes" instead of "we describe").

I think the claims made in the bulleted list at the end of Section 2.2 need citations.

No blocking comment:  

Given the different environments where Babel can be used, it would be ideal if Operational Guidance for future deployments was provided.  For context, please see my ballot for draft-ietf-babel-applicability: https://mailarchive.ietf.org/arch/msg/babel/o-yj5D9vXa2Th9orObWDh-heEU8

I agree with several other ADs that the document tries too hard to be a marketing brochure.  I do not find that sufficiently objectionable to interfere, but it would be nice to tone it down a bit.

When a use case calls for all nodes to participate in the IGP (as
opposed to just connecting to a local point of access and letting that
router run the IGP, there may be privacy considerations regarding the
mobility/connectivity of individual nodes in the information conveyed
over the routing protocol.  It would be good to acknowledge that such
use cases may exist (or disclaim applicability to them) in this
document.

Section 1.1

It's probably worth expanding DSDV on first use.

Section 2.2

(side note: this is probably just me coming from an abstract
math/topology background and not a routing background, but the term
"non-transitive link" puzzles me a little bit.  My understanding of the
non-transitivity property is that if A has a link to B, and B has a link
to C, then it's not necessarily the case that A can get traffic to/from
C via B.  But that seems like more of a property of the node policy or
other constraints on B than of any particular link.  I can live with
being puzzled, here, but if there's a quick explanation, I'd be
interested in hearing it.)

Section 2.3

   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: in order to check that two extensions to the Babel
   protocol are interoperable, it is enough to verify that the
   interaction of the two does not violate the base protocol's
   assumptions.

As another reviewer noted, "interoperable" doesn't seem like quite the
right word; "compatible" seems potentially more appropriate, or perhaps
"usable with each other".

Section 2.4.3

   Babel's loop-avoidance mechanism relies on making a route unreachable
   after a retraction until all neighbours have been guaranteed to have
   acted upon the retraction, even in the presence of packet loss.
   Unless the optional algorithm described in Section 3.5.5 of
   [RFC6126bis] is implemented, this entails that a node is unreachable
   for a few minutes after the most specific route to it has been
   retracted.  [...]

Section 3.5.5 of draft-ietf-babel-rfc6126bis-07 seems to discuss two
different mechanismis to guarantee that no neighbor is using the current
node as next-hop for prefix P.  (1) is that the operation being referred
to here, and (2) if so, should this be "one of the mechanisms"?
Basically, I'm not sure I'm chasing the reference in the way intended.

Section 5

I think we need to couch the "most deployments" language with something
like "at the time of this writing" -- there's no guarantee that it will
remain true in perpetuity.

Given, e.g., https://www.krackattacks.com/, it's unclear to me that it's
reasonable to continue to claim that WPA2 provides a way to secure a
link layer.  (WPA3 is not shaping up to do much better, given https://www.schneier.com/blog/archives/2019/04/vulnerabilities_7.html .)

Agree with Eric, I think the document is a bit over zealous in it's claims and phrasing, e.g. "where traditional routing protocols
give up." One could say "where traditional routing protocols do not perform as well." As there are always tweaks to be made for the "traditional" to meet application needs and so avoid the fork lift of a new protocol.

Thanks for writing this document and the recent updates. While it is an easy read, I agree with others that there might still be some case where maybe benefits are overstated, e.g. sec 2.1 is not very objective and only provides basically two anecdotes. Other examples are these sentences:

"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 does not violate the properties on which
   Babel relies, and therefore slows down convergence or causes sub-
   optimal routing rather than causing the network to collapse."

or 

"No other routing protocol known to us is similarly robust and
   efficient in this particular kind of topology."
(also still one "us" here)

I agree with several of my co-ADs that this document reads a lot like marketing but I don’t feel strongly enough about it to ask for specific changes.