Dear all. I have read the draft and I think this draft is well described. It looks fine to me.
Best regards. Yong-Geun. On Sun, Jan 27, 2019 at 8:09 PM Rahul Arvind Jadhav <[email protected]> wrote: > 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 >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
