Subject: [babel] Éric Vyncke's No Objection on draft-ietf-babel-rfc6126bis-11: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 05 Aug 2019 00:01:53 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-rfc6126bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Dear authors,

Thank you for the work put into this document and its companion documents. The
text is usually clear and explanations are concise and easy to understand. I
have nevertheless some COMMENTs and a few NITs.

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --

In the properties bullet points, "its diameter" is it about the loop diameter
or the network diameter? I suspect the latter but this is ambiguous IMHO.

-- Section 3 --

It is unclear by reading "The protocol encoding is slightly more compact when
router-ids are assigned in the same manner as the IPv6 layer assigns host IDs."
whether EUI-64 is referred here. I also fail to see in section 4.6.7 (router-id
TLV) what is the encoding benefit?

-- Section 3.1 --

Should there be a mention of maximum UDP datagram size? and some words on
layer-3 fragmentation ? I understand that section 4 has a section on this, so,
perhaps refer already to that section for completeness ?

-- Sections 3.2.3 and 3.2.4 --

Does a dual-stack host have to send 2 hello? One on each protocol stack (v6 or
v4) ? Unclear from the explanation.

-- Section 3.4.2 --

It is unclear to me whether a link to a neighbor (router-id) can have different
cost based on the v6 or v4.

-- Section 4 --

Is there a reason why the well-known ports and multicast group addresses are
not spelled out in this section ? They only appear in the IANA considerations
section.

Also, should the hello be sent over v6 _AND_ v4 ?

-- Section 4.2 --

No a real comment, just an appreciation of your humor: "The arbitrary but
carefully chosen value 42" ;-) you made my Monday morning !

-- Section 4.4 --

Is there any reason why the 'mandatory bit' does not appear in the packet
structure?

-- Section 4.6.2 --

Is there any reason why the "MBZ" is not expanded ? Must Be Zero ?

-- Section 4.6.3 --

I wonder how the receiver could estimate the propagation time (in each
direction BTW) + queuing time + whatever delay...

-- Section 4.6.7 --

Should the router-id field length be repeated here as well ?

== NITS ==

-- Section 1.1 --

Rather than using 'naive' to describe RIP, let's rather use 'trivial' or
'simple' ;-)

s/the routers involved participate/the involved routers participate/  ?

-- Section 3.2.6 --

Suggest to use '0xffff' rather than 'FFFF' and be consistent in the use of
lowercase / uppercase for hexadecimal numbers.

-- Section 4.5 --

Parsing "since for correct parsing it must be identical across implementations"
is not easy... a comma would be welcome.

-- Section 4.6.3 --

s/receiver send/receiver sends/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 05 Aug 2019 13:59:00 +0200

Dear Eric,

Thank you very much for your detailed review.  Since your nits are
(thankfully) fairly minor, I'll be fixing them in the git repository[1] and
only submit a new revision at a later time.

[1] https://github.com/jech/babel-drafts

> or the network diameter? I suspect the latter but this is ambiguous IMHO.

The former.  Reworded.

> TLV) what is the encoding benefit?

Flag "R" in the Update TLV.  It allows copying the router-id from the
advertised prefix.  This is dramatically effective in mesh networks (where
each node advertises its own loopback address), not so much in traditional
prefix-based networks.

I've added a forward ref.

> perhaps refer already to that section for completeness ?

We're already referring to it ("as described in Section 4 below").
I don't think it is worth overloading this section any further.

> v4) ? Unclear from the explanation.

As far as the protocol is concerned, both deployment models are possible:

  - the BGP-style double-stack model, where a single protocol instance
    (running over IPv4 or IPv6) carries both IPv4 and IPv6 routes;
  - the "ships in the night" model, where two protocol instances are run,
    one over IPv4, one over IPv6.

In the double-stack model (which is what all current implementations
implement), a single IPv6 hello is sent.  I'm not sure if this should be
spelled out explicitly -- FWIW, none of the Babel implementers had any
trouble with that.

(In principle, the protocol could be run directly over the link layer,
IS-IS style, which could perhaps be useful in some IoT-style scenarios.
It could even use different encapsulations on different interfaces, for
example UDP/IPv6 over a tunnel but raw Ethernet over a physical interface.
However, since this has never been implemented, this draft doesn't allow
that kind of operation.)

> It is unclear to me whether a link to a neighbor (router-id) can have
> different cost based on the v6 or v4.

Not in the double-stack model, no.  There's a single cost per neighbour.

The same effect, however, can be achieved by computing different metrics
for different address families, i.e. by using the address family as
a parameter in the metric computation described in Section 3.5.2 -- this
is analoguous to using different prepending rules in BGP.  This is
implemented by both babeld and BIRD.

> not spelled out in this section ? They only appear in the IANA considerations

I prefer to avoid duplication to the extent possible.

> Also, should the hello be sent over v6 _AND_ v4 ?

Not in the double-stack deployment model, no.

> Is there any reason why the 'mandatory bit' does not appear in the packet

The mandatory bit is considered as part of the Type, i.e., the first
mandatory sub-TLV number is 128; I don't think there's a way to express
that in a packet diagram.

I've clarified the wording and left the packet diagram unchanged.

> Is there any reason why the "MBZ" is not expanded ? Must Be Zero ?

Done.

> direction BTW) + queuing time + whatever delay...

The intent here is that the sender uses a reasonable margin.  For example,
the reference implementation uses a margin equal to interval/3.

I don't want to give any advice here, since we don't currently have a lot
of implementation experience with ACKs in Babel (the mechanism is
currently only used by the optional algorithm described in the second
bullet point in Section 3.5.5, and this is only implemented in BIRD).

> Should the router-id field length be repeated here as well ?

No.

> Rather than using 'naive' to describe RIP, let's rather use 'trivial' or

I most humbly disagree.  "Naive" here applies to "distance-vector protocol",
meaning that RIP uses the "naive distance-vector", i.e. distance vector
with no additional mechanisms.

> s/the routers involved participate/the involved routers participate/  ?

I most humbly disagree.

> lowercase / uppercase for hexadecimal numbers.

I've switched to uppercase throughout.

> is not easy... a comma would be welcome.

This sentence has been shot, and replaced by a shorter one.

> s/receiver send/receiver sends/

Disagree, this is in the conjunctive.

Thanks again for your review,

-- Juliusz

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 5 Aug 2019 12:55:20 +0000

Juliusz,

Thank you for the prompt reaction. I agree with all your points (even when you disagree with me ;-) ) except on the one-below: dual-stack Babel or "ships in the night". Please state somewhere that the two options are available; perhaps by simply copying the text of your reply in your document.

Bien à toi

-éric

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 05 Aug 2019 16:34:34 +0200

> Please state somewhere that the two options are available; perhaps by
> simply copying the text of your reply in your document.

I've added the following paragraph to Section 3.1:

   The protocol's control traffic can be carried indifferently over IPv6
   or over IPv4, and prefixes of either address family can be announced
   over either protocol.  Thus, there are at least two natural
   deployment models: using IPv6 exclusively for all control traffic, or
   running two distinct protocol instances, one for each address family.
   The exclusive use of IPv6 for all control traffic is RECOMMENDED,
   since using both protocols at the same time doubles the amount of
   traffic devoted to neighbour discovery and link quality estimation.

List: this adds a SHOULD to the draft.  Since this reflects implementation
practice, I am fairly confident that it also reflects our consensus, please
yell if I'm wrong.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Aug 2019 19:44:33 -0400

Speaking as an individual, I'm OK with that addition.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 07 Aug 2019 12:56:53 +0200

> Speaking as an individual, I'm OK with that addition.

Me too (I do think I suggested dropping v4 support completely at some
point ;)).

-Toke