Subject: [RTG-DIR] RtgDir Early review: draft-ietf-babel-rfc6126bis-04.txt

From: <[email-masked]>
Date: Tue, 15 May 2018 15:40:26 +0000

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 29 May 2018 18:02:02 +0200

Dear Nic,

Thank you very much for your review, and sorry for the delay replying --
it's exam time here at Babel Towers.

> Section 3: The use of “multicast” and “unicast” in the context of hellos is a bit
> misleading.

I agree.  We've puzzled over that for a while, and couldn't find a better terminology.

> There are Multicast Hellos, Unicast Hellos and Multicast Hellos over
> Unicast.  Which seqn number is used if Multicast over Unicast Hello is
> send?

I've clarified this.

> Section 3.1: Any assumptions on the maximum size of the UDP datagrams?

Beginning of Section 4.  I've added a forward-reference.

> Section 3.2.5: How is the timer set, is there a list with default values?

It doesn't matter -- "on the order of minutes" is good enough in this
case.  The (informative) Appendix B gives sample values (3 minutes in this
case).

> Section 3.4.1: Multicast Hellos to Multicast and Unicast addresses. Should be clarified
> earlier in the document. Terminology is a bit confusing.

Yeah, the terminology is confusing, but as mentioned before, we couldn't
agree on a better one.

> Section 3.5.3: What are the use cases for Babel? How large is a large Babel Network (how

That's draft-ietf-babel-applicability, I'd rather not give any figures in
this docuemnt.

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

We agree, and we're currently working on defining security mechanisms for
Babel.  The plan is to refer to the security document once it's finalised.

> Section 3.7: What is a “multicast package” in this context? Is the
> transport always with an multicast destination address?

I'm not sure I understand.  "Multicast packet" is shorthand for "an IP
packet with a multicast destination address".  The choice of multicast
vs. unicast is described in the second paragraph of Section 3.1.

> Page 29: “recently forwarded” and “sufficiently large”; what values do I use here?

I've clarified.

> Page 31, Section 4: which well-know multicast address is being used?

I'm not sure I understand.  The "well-known Babel multicast address" is
the address assigned by IANA for Babel.

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

Yes, we're working on that.

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

I most humbly disagree.

> “Routing Table” and “Route Table” are used. Choose one ;)

This is deliberate.  The "route table" is the data structure described in
Section 3.2.6.  "Routing table" is a generic term.

> Page 5, Section 2: Reference to Bellman-Ford protocol would be nice

What do you suggest?

> is the third piece of data out of two)

Disagree.  A ranges over all routers, including S.  ("Every node A maintains ... D(A)")

> Page 11, “router-id change Section 3.7.2 » sounds if something is missing

Reworded, thanks.

> Page 28, Section 3.8.1.1: “if such a route does not it must” (something is missing)

Reworded, thanks.

> Page 39: AE values 1 and 3 should be explained for better readability (1=IPv4, 3=llIPv6)

Done.

Thanks for your help,

-- Juliusz