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

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 <rahul.jadhav@huawei.com>
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:6lo-bounces@ietf.org] *On Behalf Of *Gabriel
> Montenegro
> *Sent:* 17 January 2019 13:00
> *To:* lo <6lo@ietf.org>
> *Cc:* draft-ietf-6lo-blemesh@ietf.org; samita.chakrabarti@verizon.com
> *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
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>