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

["Carles Gomez Montenegro" <[e-mail]>]

Hello Rahul,

First of all, sorry for the delay, and thanks a lot for your valuable
comments!

Please find below inline responses to your points:

> 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?

Your interpretation that "the draft by itself cannot establish multi-hop
comm" is correct.

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.

> 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 !)

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...)


> 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.

> 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:[e-mail]] On Behalf Of Gabriel Montenegro
> Sent: 17 January 2019 13:00
> To: lo <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo
>