Thank you Carles. The NEW updates that you mentioned below sounds fine. All my comments are addressed.
> -----Original Message----- > From: Carles Gomez Montenegro [mailto:[email protected]] > Sent: 12 February 2019 03:44 > To: Rahul Arvind Jadhav <[email protected]> > Cc: [email protected]; lo <[email protected]>; draft-ietf-6lo- > [email protected]; Gabriel Montenegro <[email protected]> > Subject: RE: [6lo] WG last call on draft-ietf-6lo-blemesh-04 > > 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:[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
