Hello Authors-of-BLEMesh,
Thank you for this work. This work establishes a different way of handling the
BLE-mesh scenario and contrasts the approach taken by Bluetooth SIG of using
managed flooding for multi-hop comm.
As I understand, the work tries to "enable a BLE-mesh" using the 6lo extensions
for address registration and prefix handling. I think it is better to clarify
that the draft by itself cannot establish multi-hop comm but just provides
guidelines to use 6lo in multiple hops. To establish routing tables at multiple
hops, we still need a routing protocol atop. I understand that the draft does
not specify a routing protocol but it gives a feeling that you can have
multi-hop comm with this draft alone. One example is, the draft explains
address registration at one-hop but a 6LBR would not receive address
registrations of 6LN/6LR located more than one hop away and thus downstream
traffic won't work unless routing protocol is deployed. There are other issues
such as loop avoidance that can be handled only by routing protocol. Is my
interpretation of the draft correct, or am I missing something fundamentally?
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.
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?
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?
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
