Early Review of draft-ietf-babel-rfc6126bis-04
review-ietf-babel-rfc6126bis-04-rtgdir-early-leymann-2018-05-15-00

Hello,

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

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

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

Comments:
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, …).

Nits:
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 3.8.1.1: “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!

Regards

Nic