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?
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 ?
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.
>
> > 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.
>
> > 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.
>
> > 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:[email protected]] On Behalf Of Gabriel
> > Montenegro
> > Sent: 17 January 2019 13:00
> > To: lo <[email protected]>
> > Cc: [email protected]; [email protected]
> > 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/6lo
> >
>
>
> _______________________________________________
> 6lo mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
