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

[Juliusz Chroboczek <[e-mail]>]

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
> many nodes)?

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?

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

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