Re: [6lo] WG last call on draft-ietf-6lo-blemesh-04

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

Hi Rahul,

Once again, thank you very much for your valuable comments!

Please find below my inline responses:

> Hi Carles,
>
> Thank you for your response.
>
> In case of BLE, there are several randomized MAC addresses used. Some of
> them may be short-lived (such as per-connection non-resolvable private
> random address) and recycled very soon. RFC 7668 mentioned two points in
> this context:
> 1. "BLE does not support avoidance or detection of device address
> collisions. However, the 48-bit random device addresses have a very small
> probability of being in conflict within a typical deployment." With mesh,
> is this assumption ok to make?

[CG] In my opinion, the assumption still holds in a mesh scenario. The
(potentially greater) number of nodes one may expect in a practical BLE
mesh scenario would not really invalidate the above assumption.

> 2. Section 3.2.3. of Neighbor Discovery in RFC 7668 explicitly states that
> it did not consider mesh networks. With Mesh, would multi-hop DAD be
> needed ?

[CG] Some mechanism that provides unique addresses is needed. Such
mechanism could be multihop DAD, or it could be based another approach.

> Please find my responses inline..
>
> Thanks,
> Rahul
>
>
>> > by routing protocol. Is my interpretation of the draft correct, or am
>> I
>> missing something fundamentally?
>>
>> Your interpretation that "the draft by itself cannot establish multi-hop
>> comm" is correct.
>
> [RJ] Thank you for the clarification.
>
>>
>> In this regard, the draft stays at the level of what 6LoWPAN (RFC 4944,
>> RFC 6282 and RFC 6775) defines, in the sense that a multihop
>> communication
>> solution is needed, but it is out of scope of the specification.
>>
>> In order to avoid ambiguities in this regard, a proposal for -05 is
>> adding at the
>> end of the abstract and at the end of the Introduction (before 1.1), the
>> following sentence:
>>
>> NEW:
>>    This document does not specify the routing protocol to be used in an
>>    IPv6 mesh over Bluetooth LE links.
>
> [RJ] As you mentioned above, Can we add that "multi-hop communication is
> out of scope of this specification" apart from mentioning that "This
> document does not specify the routing protocol ... "
> The topologies in the document and the title itself makes me believe that
> this document is about achieving multi-hop communication over BLE links.

[CG] I hear you. But perhaps we need to find an alternative way to express
what I understand that you mean. I think "multihop communication" is not
out of scope as such, in the sense that the draft defines functionality
that is necessary (but not sufficient) to enable multihop communication
between two devices running IPv6 over a mesh of BLE links. (In addition,
strictly speaking, multihop DAD, which is in scope of the document, is
some form of "multihop communication".)

[CG] Anyway, I realize that the abstract, for example, is misleading as it
is currently. Here is an update proposal:

OLD:
    This document specifies the mechanisms needed to enable IPv6 over mesh
    networks composed of Bluetooth low energy links [...].

NEW:
    This document specifies mechanisms that are needed to enable IPv6 over
    mesh networks composed of Bluetooth low energy links [...]. This
    document does not specify the routing protocol to be used in an IPv6
    mesh over Bluetooth LE links.

[CG] Would the above be useful to clarify the scope of the draft?

>> > Other review comments:
>> >
>> > 1.       The draft mandates (MUST clause) use of certain 6lo
>> compression
>> > schemes for link-local and global communication. For link-local I
>> > think it might be ok to mandate but for non-local communication
>> > mandating might not be a good idea. For e.g. in case of
>> > 6lo-fragment-forwarding, a client might use non-compressed addresses
>> > so that the fragment sizes don't change en-route.
>>
>> Please note that in RFC 7668, fragmentation is carried out by BLE (by
>> means
>> of L2CAP), i.e. not by the adaptation layer, and the same is assumed in
>> this
>> draft. (However, the assumption is not *written* in the draft, therefore
>> an
>> action point for us is to explicitly state this in -05 !)
>
> [RJ] Yes this assumption can be explicitly stated. This drives away the
> fragmentation point I raised. I checked RFC 7668 and it also has mandated
> such Header Compression scheme and clarified the fragmentation point.
>
>>
>> Other than that, an open question is: is there any reason why the MUST
>> clauses should be lowered to SHOULD?
>> (We would need to know the reason(s) why MUST would not be used...)
>>
>
> [RJ] BLE uses range of link-addresses such as static random, Private
> (resolvable/non-resolvable) random addresses for privacy issues. If the
> connection is short, is it worth doing an explicit NS/NA with ARO to
> register such random-address? It might be better to send uncompressed
> addresses in such cases? The mandate limits the implementation options.

[CG] Very good point!

[CG] If a connection is really short (e.g. in an extreme case, only one
data packet is sent), then it is probably not worth doing an NS/NA with
ARO as you say.

[CG] We can then replace the related MUST terms by SHOULD terms, along
with an explanation in the lines of your comment above.

>> > 2.       In section 3.3.2, it says "Implementations of this
>> specification
>> > MUST support the features described in sections 8.1 and 8.2 of RFC
>> > 6775 unless some alternative ("substitute") from some other
>> > specification is supported." I find this confusing. It's a MUST clause
>> > unless something unknown. Can we clarify this?
>>
>> Perhaps we can add "by the implementation" at the end of the sentence
>> you
>> refer to.
>>
>> Please note that the text "mirrors" (almost "copies") the approach taken
>> in
>> RFC 6775. From the latter:
>>
>>    "An implementation of this specification MUST support
>>    those pieces, unless the implementation supports some alternative
>>    ("substitute") from some other specification."
>>
>> The idea is that multihop prefix/context dissemination and multihop
>> Duplicate Address Detection must be supported as per sections 8.1 and
>> 8.2 of
>> RFC 6775, unless another mechanism offering the same functionality is
>> used.
>> This is in RFC 6775, and we also follow the same approach in our draft.
>
> [RJ] Thanks for this clarification. It was certainly not clear to me until
> you mentioned these points of multihop prefix dissemination and multihop
> DAD.
> I think the multihop DAD becomes especially challenging in BLE context
> because of the use of per-connection non-resolvable private random
> address.

[CG] Yes, it may be challenging, at least more than using, e.g., static
random addresses. The recommended time before a new private address is
generated is 15 minutes [Bluetooth 4.2]. I understand the level of
challenge may also depend on the scenario (e.g. node density, network
diameter, etc.). Then, implementers may decide which is the mechanism that
suits best their scenario, since multihop DAD is a "substitutable"
mechanism [RFC 6775].

[CG] Once again, thanks a lot for your comments. We plan to integrate the
updates that result from this discussion in -05.

[CG] Thanks,

[CG] Carles


>> > 3.       Also I think the technique used by BLE-SIG of managed
>> flooding
>> > has its own charms in certain scenarios (especially home scenarios).
>> > Is it possible to contrast this work with that approach? Or do you
>> > think it is out-of-scope?
>>
>> >From the point of view of writing the draft specification, we
>> >understand
>> that the question would be out-of-scope.
>>
>> However, contrasting the Bluetooth SIG controlled flooding approach with
>> the one proposed in our draft is definitely a great research topic. Some
>> of us
>> have in fact started looking at it, and hope to get results within this
>> year.
>>
>> In terms of message count, as in many other "A against B" type of
>> comparison work, the intended scenario, the data message rate (and
>> traffic
>> patterns) and a non-negligible amount of parameter settings will
>> determine
>> which approach is better. Generally speaking, the controlled flooding
>> approach of Bluetooth SIG's "Bluetooth Mesh" may be adequate for smaller
>> networks, while avoiding the need to set up and maintain link layer
>> connections, or use a routing protocol. However, scalability (vs network
>> size) is probably the main issue of Bluetooth Mesh.
>>
>> Quite remarkably, note that, as of today, and as far as I know,
>> Bluetooth
>> Mesh does not support IPv6.
>>
>> ---
>>
>> Once again, thanks for all your comments. Please let us know if our
>> proposals
>> above would address your points.
>>
>> Cheers,
>>
>> Carles (of course, as an I-D coauthor)
>>
>>
>> > Thanks,
>> > Rahul
>> >
>> > From: 6lo [mailto:[e-mail]] On Behalf Of Gabriel
>> > Montenegro
>> > Sent: 17 January 2019 13:00
>> > To: lo <[e-mail]>
>> > Cc: [e-mail]; [e-mail]
>> > Subject: [6lo] WG last call on draft-ietf-6lo-blemesh-04
>> >
>> > I'm initiating WG last call on:
>> >
>> >               IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
>> > https://tools.ietf.org/html/draft-ietf-6lo-blemesh-04
>> >
>> > This last call will be over on Wednesday January 30.
>> >
>> > This draft was dormant for some time awaiting implementation
>> experience.
>> > That went well and validated the spec, but it is especially important
>> > for the WG to get some new reviews on this document.
>> >
>> > Please express your view (even if it's just "it looks fine") on this
>> > document.
>> >
>> > Thanks,
>> >
>> > Chairs
>> > _______________________________________________
>> > 6lo mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/6lo
>> >
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lo
>