Subject: [babel] Minor edits to draft-ietf-babel-rfc6126bis-02

From: David Schinazi <[email-masked]>
Date: Wed, 28 Jun 2017 18:27:50 -0700

Hi Juliusz,

I sent out a PR with a flurry of minor edits to the doc:
https://github.com/jech/babel-drafts/pull/5/files <https://github.com/jech/babel-drafts/pull/5/files>

Let me know what you think.

Thanks,
David Schinazi

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 29 Jun 2017 21:28:06 +0200

> https://github.com/jech/babel-drafts/pull/5/files

I did some cherry picking.  Here's the hunks that I've rejected.  Please
let me know if I've missed anything else.

> -<date day="19" month="June" year="2017"/>
> +<date/>

I prefer to edit the date manually whenever I submit a new I-D.  Sorry.

> -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> -document are to be interpreted as described in <xref target="RFC2119"/>.</t>
> +"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> +"OPTIONAL" in this document are to be interpreted as described in <xref
> +target="RFC2119"/>.</t>

Let's leave the boilerplate as it stands.

> -updates.</t>
> +updates.  Note that the IHU and update timers may be part of the neighbour
> +table if the Babel node is sending those TLVs over unicast.</t>

Right.  But the way you've inserted it seems a little bit of an
afterthought.  At any rate, the Unicast Hellos stuff needs more work.

> +<t>Note that the source (prefix, plen, router-id) in the route table is
> +not a reference to a source in the source table since their seqnos and
> +metrics can differ.</t>

That's not correct.  (prefix, plen, router-id) is a reference to the
sourge table.  The point here is that there are two (seqno, metric)
pairs -- the route's distance, in the route table, and the feasibility
distance, in the source table.

Since this is one of the main insights behind Babel, it does deserve being
stressed, so perhaps something like

  Note that there are two (seqno, metric) pairs associated to each
  route -- the route's distance, in the route table, and the feasibility
  distance, stored in the source table and shared between all routes with
  the same source.

But I'm not sure that we've introduced the notion of distance (a (seqno,
metric) pair) at that point, and I'm too tired to check.

> -target="PACKETBB"/>.</t>
> +target="PACKETBB"/>.  Babel only supports one method of address
> +compression, which is the Omitted field of the Update TLV (<xref
> +target="update"/>).</t>

Seems redundant to me.  If you really think it's needed, please put it
earlier in the paragraph.

> -ignored.</t>
> +ignored.  An IHU TLV with AE set to 0 MUST NOT be sent to a multicast
> +address.</t>

Disagree.  An IHU TLV with AE 0 is perfectly valid, although NOT
RECOMMENDED.

> +a new TLV, or by adding a new sub-TLV to an existing TLV.  If an extension
> +makes incompatible changes to the meaning of a TLV, it should use a
> +mandatory sub-TLV to ensure that the whole TLV is thrown away if the
> +extension data is not understood.  New TLVs should only be used when the
> +extension adds semantics that do not map to existing TLVs.</t>

I'm keeping this around, for when I rewrite this section.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 29 Jun 2017 15:11:17 -0700

> On Jun 29, 2017, at 12:28, Juliusz Chroboczek <[email-masked]> wrote:
> 

Sure, no strong preference.

> Let's leave the boilerplate as it stands.

There is a verified erratum on RFC 2119 that I believe we should follow
because of how obvious it is.
https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499 <https://www.rfc-editor.org/errata_search.php?rfc=2119&eid=499>
> afterthought.  At any rate, the Unicast Hellos stuff needs more work.

I tried to mimic the "Note that" at the end of the Neighbour Table section that
adds guidance for implementors as an afterthought. That said, this is unrelated to
unicast Hellos, my implementation sent IHU unicast from the start.

> metric) pair) at that point, and I'm too tired to check.

Feasibility distance is defined as (seqno, metric) in Section 2.4 / 2.5,
the Data Structures are in Section 3.2 so we're good.
In a way those are somewhat equivalent, you can have a pointer to the
source table or keep the router ID here and use it as a lookup key into the
source table. Your text allows both and clears my confusion.

> earlier in the paragraph.

For some strange reason figuring out what "address compression"
means in this spec was a pain point for me when first implementing.
I saw the PACKETBB reference and ended up trying to figure out
how to plumb PACKETBB into Babel TLVs. Maybe we could replace
that reference with one to the encoding of Update TLVs section, and
only mention PACKETBB in the Acknowledgments section (the one
that thanks people, not TLV type 3).

> Disagree.  An IHU TLV with AE 0 is perfectly valid, although NOT

What's the benefit of allowing these? They break bidirectional reachability
detection -- if one node's wireless radio is stronger than another and packets
only flow in one direction, bad things will happen.

> I'm keeping this around, for when I rewrite this section.

Sounds good, I wasn't very happy with my text but wanted to make sure we
update that section to properly reflect mandatory sub-TLVs.

Thanks,
David Schinazi