Re: [6lo] Iotdir last call review of draft-ietf-6lo-blemesh-08

[Carles Gomez Montenegro <[e-mail]>]

Hi Dominique,

Sorry for the late reply, and thanks a lot for your thorough review of the
draft!

We just submitted -09, which aims at addressing the last round of review
comments, including yours:
https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09

Please find below our inline responses to your comments/questions:

> Reviewer: Dominique Barthel
> Review result: Ready with Nits
>
> Thanks for this useful and timely draft.
> I found it ready for publication, but for a few questions/comments, and a
> few
> nits.
>
> Questions
> 1. RFC 2119 is referenced. Shouln't RFC 8174 be referenced as well?

Yes! We added a reference to RFC 8174.

> 2. Section 3.3.2 states "Note that in some cases (e.g. very short-lived
> connections) it may not be worthwhile for a 6LN to send an NS with EARO
> for
> registering its address".
>    It would be useful to describe the consequences of not registering the
>    address. What about reachability from the other end, in case a response
> is
>    expected? DAD?

We added one sentence to explicitly indicate the consequences of not
registering the address:

NEW:
   However, the consequences of not registering the address (including non-
   reachability of the 6LN, and absence of DAD) need to be carefully
   considered.

> 3. Section 3.3.2 states "If the 6LN registers multiple addresses that are
> not
> based on Bluetooth device address using the same compression context, the
> header compression efficiency will decrease".
>    I found this sentence difficult to parse.
>    It seems to summarize considerations developped in Section 3.2.4 of
> RFC7668.
>    If this is true, a reference to that section would help the reader.

Yes, we added that reference. We also changed the "will decrease" to "may
decrease", and briefly explained the reason why:

NEW:
   If the 6LN registers multiple addresses that are not based on the
   Bluetooth device address using the same compression context, the
   header compression efficiency may decrease, since only the last
   registered address can be fully elided (see Section 3.2.4 of RFC
   7668).

> Checking
>    the details of Section 3.2.4 of RFC7668, I realized that I had not
> fully
>    understood it yet. Even though it is a long-published RFC, can you
> educate
>    me on why the address last registered with the ARO gets a better
> compression
>    than other addresses that share the same prefix? For example, see "and
> if
>    SAC=1 and SAM=11, the 6LN MUST have registered the source IPv6 address
> with
>    the prefix related to the compression context, and the 6LN MUST be
> referring
>    to the latest registered address related to the compression context".
> Does
>    it imply that the ARO modifies the 6282 compression context at the 6LR?
> How
>    does the ARO relate to the compression context? A related, and
> striking,
>    sentence in RFC7668 is "The 6LN can register a new address, or
> re-register
>    an expired address, to become able to again fully elide an address",
>    seemingly implying a connection between registration and compression.
> Please
>    advise.

In RFC 7668, which focuses on a star topology where links are formed via
BLE Link Layer connections, a 6LBR that receives a packet from a 6LN knows
that the packet comes from *that* 6LN (since the packet arrives at the
6LBR via a specific BLE Link Layer connection), but the 6LBR does not
necessarily know which is the current non-link-local address of the 6LN.
(The prefix of that address may always be the same, but perhaps the IID
may change somewhat frequently, e.g. for privacy reasons, and the IID may
be independent of the BLE Link Layer connection identifier.) In order to
allow the 6LBR know which is the current non-link-local address, RFC 7668
uses ARO, so that the last registered non-link-local address is the
current one. If the 6LN uses the last registered address, then the IPv6
source address can be (actually is) fully elided, since the 6LBR will be
able to decompress that address (i.e. the 6LBR knows the current
non-link-local address of the 6LN). For previously used 6LN addresses
(which are not the current/last one, but have the same prefix), only the
prefix can be elided.

So, back to your question “why the address last registered with the ARO
gets a better compression than other addresses that share the same
prefix?”, the answer is that header compression exploits not only the 6282
context, but also the underlying star network topology, the fact that
links in that topology are based on connections, and the fact that ARO
provides additional information about which is the current 6LN
non-link-local address in use.

> 4. Section 3.3.3 states "Note that 6CO is not needed for context-based
> compression when a single prefix is used in the network". Can you please
> explain how you do context-based compression without loading the context
> via a
> 6CO? Do you assume the context is pre-provisioned via some out-of-band
> means?

Yes, that is our assumption. We have clarified that in -09:

NEW:
   Note that 6CO is not needed for context-based
   compression when context is pre-provisioned or provided by out-of-
   band means.

> If yes, how is it specific to the case where a single prefix is used in
> the
> network? If no, is it because some registration/compression connection
> that I
> missed (see comment #3)?

It is not specific to the case where a single prefix is used in the
network. The updated text (above) does not mention the single prefix case.

>    RFC 7668 has a MUST instead of a MAY in the sentence "To enable
> efficient
>    header compression, when the 6LBR sends a Router Advertisement it MAY
>    include a 6LoWPAN Context Option (6CO) [RFC6775] matching each address
>    prefix advertised via a Prefix Information Option (PIO) [RFC4861] for
> use in
>    stateless address autoconfiguration". Is this a short sighting of
> RFC7668,
>    that would be worth an update? Or is the MAY specific to the mesh
> version of
>    BLE networks?

I must admit that I don't actually remember why a MUST was used when we
wrote RFC 7668. Perhaps constraining the space of allowed options was
considered valuable for the sake of simplicity.

Perhaps an update might make sense. On the other hand, a set of devices
where there are no 6LRs (i.e., only 6LNs and a 6LBR) implementing
draft-ietf-6lo-blemesh may form a star-topology network supporting
pre-provisioned context or context provided by out-of-band means.

> 5. Section 3.3.3 states "These cases comprise link-local interactions,
> non-link-local packet transmissions originated by a 6LN, and
> non-link-local
> packets intended for a 6LN that are originated or forwarded by a neighbor
> of
> that 6LN".
>    Pretending for a moment that I undestood compression as specified per
> RFC
>    7668, do I understand correctly that, in the BLE mesh, 7668-like
> compression
>    only applies to the first hop from a 6LN or to the last hop toward a
> 6LN,
>    and that any hop beyond that cannot use 7668-like compression? Would
> this be
>    a better text to replace the one I just quoted?

We tried to improve clarity of the text by adding text between
parentheses, as follows.

NEW:
   These cases comprise
   link-local interactions, non-link-local packet transmissions
   originated by a 6LN (i.e. the first hop from a 6LN), and non-link-
   local packets intended for a 6LN that are originated or forwarded by
   a neighbor of that 6LN (i.e. the last hop toward a 6LN).

> Nits:
> - 3.3.2: "For sending Router Solicitations and processing Router
> Advertisements
> the Bluetooth LE hosts MUST, respectively, follow ..."
>    There is no such thing as a BLE host in the Terminology. Do you mean
> "IPSP
>    Node" or "IPv6 host that participates in the BLE mesh"?

We used a form inspired by the latter in -09:

    "... the hosts that participate in an IPv6 mesh over BLE"

> - 3.3.2: "A 6LBR uses the IPSP Router role since the 6LBR is initialized".
> What
> does "is initialized" specifically mean, in this sentence? The 6LN and 6LR
> are
> also initialized at startup, but I guess they lack the state that you
> assume is
> preconfigured in the 6LBR.

We aimed to clarify the meaning of that text as follows.

NEW:
   is initialized, that is, the 6LBR uses both the IPSP Node and IPSP Router
   roles at all times.  See an example in Appendix B.

- 3.3.2: "See an example in the Appendix" -->
> "See
> an example in Appendix B"

Done.

- Appendix A is not referenced anywhere in the
> body
> of the document.

It is now referenced from the last paragraph of Section 2.

Once again, thanks a lot for your detailed and insightful comments!

Cheers,

Carles (on behalf of the authors)