Early Review of draft-ietf-babel-rfc6126bis-04

Request Review of draft-ietf-babel-rfc6126bis
Requested rev. no specific revision (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-04-16
Requested 2018-03-21
Requested by Alia Atlas
Authors Juliusz Chroboczek, David Schinazi
Draft last updated 2018-05-15
Completed reviews Rtgdir Early review of -04 by Susan Hares (diff)
Opsdir Early review of -04 by Mehmet Ersue (diff)
Rtgdir Early review of -04 by Nicolai Leymann (diff)
Genart Last Call review of -10 by Russ Housley (diff)
Secdir Last Call review of -10 by Charlie Kaufman (diff)
Rtgdir Telechat review of -11 by Yingzhen Qu (diff)
Assignment Reviewer Nicolai Leymann
State Completed
Review review-ietf-babel-rfc6126bis-04-rtgdir-early-leymann-2018-05-15
Reviewed rev. 04 (document currently at 17)
Review result Has Issues
Review completed: 2018-05-15



I have been selected to do a routing directorate “early” review of this draft.

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-babel-rfc6126bis-04.txt
 Reviewer: Nicolai Leymann
 Review Date: 15.05.2018
 Intended Status: Standards Track

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

In general the draft is well written and uses a clear language.  Explanation of technical details are sufficient and understandable. The abstract is a bit short and should also explain in which kind of environments babel is expected to be used (e.g. home networks, …). An example with a “real world babel network” included in the introduction would make the context more clear. It is also not clear which typical network size is being expected (number of devices).

From my experience running and managing a routing protocol inside an typical end-users network is complex, especially in failure scenarios (if something goes wrong or if an device is misbehaving).  End users are usually not experienced routing experts and tend to call the ISP in most of the cases. So for me one of the major open question is, how is the network is being managed and what possibilities are offered to trouble shoot failures.

Section 3: The use of “multicast” and “unicast” in the context of hellos is a bit misleading. There are Multicast Hellos, Unicast Hellos and Multicast Hellos over Unicast. Which seqn number is used if Multicast over Unicast Hello is send?
Section 3.1: Any assumptions on the maximum size of the UDP datagrams?
Section 3.2.5: How is the timer set, is there a list with default values?
Section 3.4.1: Multicast Hellos to Multicast and Unicast addresses. Should be clarified earlier in the document. Terminology is a bit confusing.
Section 3.5.3: What are the use cases for Babel? How large is a large Babel Network (how many nodes)?
  - Later in the document (section 6) it is stated that Babel is insecure. For a large network security is an issue and needs to be addressed. I might be ok to not implement
    any security mechanisms in a relatively small home network but for a large network it’s mission critical to have a stable, secure and reliable routing mechanism.
Section 3.7: What is a “multicast package” in this context? Is the transport always with an multicast destination address?
Page 29: “recently forwarded” and “sufficiently large”; what values do I use here?
Page 31, Section 4: which well-know multicast address is being used?
Page 48, Section 6: As mentioned earlier, security is an issue and should be addressed in more detail. If Babel is insecure in itself an attacker being connected to a Babel network can bring down the whole network. Typical security mechanism used in larger networks might not be applicable to home network (e.g. due to the complexity, need for management, …).

The mix of “SHOULD”/”SHOULD NOT” and “RECOMMENDED/NOT RECOMMENDED” is a bit confusing. My proposal is to use one of the pairs and not to mix them.
“Routing Table” and “Route Table” are used. Choose one ;)

Page 5, Section 2: Reference to Bellman-Ford protocol would be nice
Page 5, Section 2.2: D(A) and NH(A) are explained, but not D(S) (which is the third piece of data out of two)
Page 11, “router-id change Section 3.7.2 » sounds if something is missing
Page 28, Section “if such a route does not it must” (something is missing)
Page 39: AE values 1 and 3 should be explained for better readability (1=IPv4, 3=llIPv6)

I hope this helps to improve the draft and to move it forward!