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

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 17 Jan 2019 05:00:17 +0000

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

---

From: 최영환 <[email-masked]>
Date: Fri, 25 Jan 2019 07:12:09 +0000

Dear all,

I’ve read the draft (-04), and it looks fine for me. :)

BRs,
Younghwan

From: 6lo <[email-masked]> On Behalf Of Gabriel Montenegro
Sent: Thursday, January 17, 2019 2:00 PM
To: lo <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [6lo] WG last call on draft-ietf-6lo-blemesh-04

I’m initiating WG last call on:

Please express your view (even if it’s just “it looks fine”) on this document.

Thanks,

Chairs

---

From: "Houjianqiang (Derek)" <[email-masked]>
Date: Fri, 25 Jan 2019 09:50:06 +0000

+1

I have read the draft several times before, and I think it is a very useful work. The current version also looks good for me.

Regards,
Derek

From: 최영환 [mailto:[email-masked]]
Sent: Friday, January 25, 2019 3:12 PM
To: Gabriel Montenegro <[email-masked]>; lo <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6lo] WG last call on draft-ietf-6lo-blemesh-04

Dear all,

I’ve read the draft (-04), and it looks fine for me.. :)

BRs,
Younghwan

From: 6lo <[email-masked]<mailto:[email-masked]>> On Behalf Of Gabriel Montenegro
Sent: Thursday, January 17, 2019 2:00 PM
To: lo <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [6lo] WG last call on draft-ietf-6lo-blemesh-04

Thanks,

Chairs

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sun, 27 Jan 2019 11:08:24 +0000

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-masked]] On Behalf Of Gabriel Montenegro
Sent: 17 January 2019 13:00
To: lo <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [6lo] WG last call on draft-ietf-6lo-blemesh-04

Thanks,

Chairs

---

From: Yong-Geun Hong <[email-masked]>
Date: Mon, 28 Jan 2019 16:51:59 +0900

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-masked]>
wrote:

> 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-masked]] *On Behalf Of *Gabriel
> Montenegro
> *Sent:* 17 January 2019 13:00
> *To:* lo <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [6lo] WG last call on draft-ietf-6lo-blemesh-04
>
>
>
> 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.
>
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>