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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 5 Feb 2019 12:32:58 +0100

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:[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
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Thu, 7 Feb 2019 09:06:13 +0000

Hi Carles,

Thank you for your response.

In case of BLE, there are several randomized MAC addresses used. Some of them may be short-lived (such as per-connection non-resolvable private random address) and recycled very soon. RFC 7668 mentioned two points in this context:
1. "BLE does not support avoidance or detection of device address collisions. However, the 48-bit random device addresses have a very small probability of being in conflict within a typical deployment." With mesh, is this assumption ok to make?
2. Section 3.2.3. of Neighbor Discovery in RFC 7668 explicitly states that it did not consider mesh networks. With Mesh, would multi-hop DAD be needed ?

Please find my responses inline..

Thanks,
Rahul

> > by routing protocol. Is my interpretation of the draft correct, or am I
> missing something fundamentally?
> 

[RJ] Thank you for the clarification.

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

[RJ] As you mentioned above, Can we add that "multi-hop communication is out of scope of this specification" apart from mentioning that "This document does not specify the routing protocol ... " 
The topologies in the document and the title itself makes me believe that this document is about achieving multi-hop communication over BLE links.

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

[RJ] Yes this assumption can be explicitly stated. This drives away the fragmentation point I raised. I checked RFC 7668 and it also has mandated such Header Compression scheme and clarified the fragmentation point.

> (We would need to know the reason(s) why MUST would not be used...)

[RJ] BLE uses range of link-addresses such as static random, Private (resolvable/non-resolvable) random addresses for privacy issues. If the connection is short, is it worth doing an explicit NS/NA with ARO to register such random-address? It might be better to send uncompressed addresses in such cases? The mandate limits the implementation options.

> > 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?
> 
> Please note that the text "mirrors" (almost "copies") the approach taken in
> RFC 6775. From the latter:
> 
> 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.

[RJ] Thanks for this clarification. It was certainly not clear to me until you mentioned these points of multihop prefix dissemination and multihop DAD.
I think the multihop DAD becomes especially challenging in BLE context because of the use of per-connection non-resolvable private random address.

> > 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?
> 
> 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.
> 
> Once again, thanks for all your comments. Please let us know if our proposals
> above would address your points.
> 
> Cheers,
> 
> > That went well and validated the spec, but it is especially important
> > for the WG to get some new reviews on this document.
> >

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 11 Feb 2019 23:14:25 +0100

Hi Rahul,

Once again, thank you very much for your valuable comments!

Please find below my inline responses:

> In case of BLE, there are several randomized MAC addresses used. Some of
> them may be short-lived (such as per-connection non-resolvable private
> random address) and recycled very soon. RFC 7668 mentioned two points in
> this context:
> 1. "BLE does not support avoidance or detection of device address
> collisions. However, the 48-bit random device addresses have a very small
> probability of being in conflict within a typical deployment." With mesh,
> is this assumption ok to make?

[CG] In my opinion, the assumption still holds in a mesh scenario. The
(potentially greater) number of nodes one may expect in a practical BLE
mesh scenario would not really invalidate the above assumption.

> 2. Section 3.2.3. of Neighbor Discovery in RFC 7668 explicitly states that
> it did not consider mesh networks. With Mesh, would multi-hop DAD be
> needed ?

[CG] Some mechanism that provides unique addresses is needed. Such
mechanism could be multihop DAD, or it could be based another approach.

> [RJ] As you mentioned above, Can we add that "multi-hop communication is
> out of scope of this specification" apart from mentioning that "This
> document does not specify the routing protocol ... "
> The topologies in the document and the title itself makes me believe that
> this document is about achieving multi-hop communication over BLE links.

[CG] I hear you. But perhaps we need to find an alternative way to express
what I understand that you mean. I think "multihop communication" is not
out of scope as such, in the sense that the draft defines functionality
that is necessary (but not sufficient) to enable multihop communication
between two devices running IPv6 over a mesh of BLE links. (In addition,
strictly speaking, multihop DAD, which is in scope of the document, is
some form of "multihop communication".)

[CG] Anyway, I realize that the abstract, for example, is misleading as it
is currently. Here is an update proposal:

OLD:
    This document specifies the mechanisms needed to enable IPv6 over mesh
    networks composed of Bluetooth low energy links [...].

NEW:
    This document specifies mechanisms that are needed to enable IPv6 over
    mesh networks composed of Bluetooth low energy links [...]. This
    document does not specify the routing protocol to be used in an IPv6
    mesh over Bluetooth LE links.

[CG] Would the above be useful to clarify the scope of the draft?

>> means
> [RJ] Yes this assumption can be explicitly stated. This drives away the
> fragmentation point I raised. I checked RFC 7668 and it also has mandated
> such Header Compression scheme and clarified the fragmentation point.
>
>>
> [RJ] BLE uses range of link-addresses such as static random, Private
> (resolvable/non-resolvable) random addresses for privacy issues. If the
> connection is short, is it worth doing an explicit NS/NA with ARO to
> register such random-address? It might be better to send uncompressed
> addresses in such cases? The mandate limits the implementation options.

[CG] Very good point!

[CG] If a connection is really short (e.g. in an extreme case, only one
data packet is sent), then it is probably not worth doing an NS/NA with
ARO as you say.

[CG] We can then replace the related MUST terms by SHOULD terms, along
with an explanation in the lines of your comment above.

> [RJ] Thanks for this clarification. It was certainly not clear to me until
> you mentioned these points of multihop prefix dissemination and multihop
> DAD.
> I think the multihop DAD becomes especially challenging in BLE context
> because of the use of per-connection non-resolvable private random
> address.

[CG] Yes, it may be challenging, at least more than using, e.g., static
random addresses. The recommended time before a new private address is
generated is 15 minutes [Bluetooth 4.2]. I understand the level of
challenge may also depend on the scenario (e.g. node density, network
diameter, etc.). Then, implementers may decide which is the mechanism that
suits best their scenario, since multihop DAD is a "substitutable"
mechanism [RFC 6775].

[CG] Once again, thanks a lot for your comments. We plan to integrate the
updates that result from this discussion in -05.

[CG] Thanks,

[CG] Carles

>> of us

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Tue, 12 Feb 2019 12:34:43 +0000

Thank you Carles. The NEW updates that you mentioned below sounds fine.
All my comments are addressed.

> -----Original Message-----
> From: Carles Gomez Montenegro [mailto:[email-masked]]
> Sent: 12 February 2019 03:44
> To: Rahul Arvind Jadhav <[email-masked]>
> Cc: [email-masked]; lo <[email-masked]>; draft-ietf-6lo-
> [email-masked]; Gabriel Montenegro <[email-masked]>
> Subject: RE: [6lo] WG last call on draft-ietf-6lo-blemesh-04
> 
> Hi Rahul,
> 
> > In case of BLE, there are several randomized MAC addresses used. Some
> > of them may be short-lived (such as per-connection non-resolvable
> > private random address) and recycled very soon. RFC 7668 mentioned two
> > points in this context:
> > collisions. However, the 48-bit random device addresses have a very
> > small probability of being in conflict within a typical deployment."
> > With mesh, is this assumption ok to make?
> 
> > 2. Section 3.2.3. of Neighbor Discovery in RFC 7668 explicitly states
> > that it did not consider mesh networks. With Mesh, would multi-hop DAD
> > be needed ?
> 
> >> > by routing protocol. Is my interpretation of the draft correct, or
> >> > am
> >> I
> >> 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:
> > [RJ] As you mentioned above, Can we add that "multi-hop communication
> > is out of scope of this specification" apart from mentioning that
> > "This document does not specify the routing protocol ... "
> > The topologies in the document and the title itself makes me believe
> > that this document is about achieving multi-hop communication over BLE
> links.
> 
> out of scope as such, in the sense that the draft defines functionality that is
> necessary (but not sufficient) to enable multihop communication between
> two devices running IPv6 over a mesh of BLE links. (In addition, strictly
> speaking, multihop DAD, which is in scope of the document, is some form of
> "multihop communication".)
> 
> [CG] Anyway, I realize that the abstract, for example, is misleading as it is
> currently. Here is an update proposal:
> 
> OLD:
> >> > 6lo-fragment-forwarding, a client might use non-compressed
> >> > addresses so that the fragment sizes don't change en-route.
> >>
> >> 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 !)
> >
> > [RJ] Yes this assumption can be explicitly stated. This drives away
> > the fragmentation point I raised. I checked RFC 7668 and it also has
> > mandated such Header Compression scheme and clarified the
> fragmentation point.
> >
> >>
> >> Other than that, an open question is: is there any reason why the
> >> MUST clauses should be lowered to SHOULD?
> > (resolvable/non-resolvable) random addresses for privacy issues. If
> > the connection is short, is it worth doing an explicit NS/NA with ARO
> > to register such random-address? It might be better to send
> > uncompressed addresses in such cases? The mandate limits the
> implementation options.
> 
> [CG] Very good point!
> 
> [CG] If a connection is really short (e.g. in an extreme case, only one data
> packet is sent), then it is probably not worth doing an NS/NA with ARO as you
> say.
> 
> >> > 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:
> >>
> > [RJ] Thanks for this clarification. It was certainly not clear to me
> > until you mentioned these points of multihop prefix dissemination and
> > multihop DAD.
> [CG] Yes, it may be challenging, at least more than using, e.g., static random
> addresses. The recommended time before a new private address is
> generated is 15 minutes [Bluetooth 4.2]. I understand the level of challenge
> may also depend on the scenario (e.g. node density, network diameter, etc.).
> Then, implementers may decide which is the mechanism that suits best their
> scenario, since multihop DAD is a "substitutable"
> mechanism [RFC 6775].
> 
> >> 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.
> >>
> >> 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
> >> Quite remarkably, note that, as of today, and as far as I know,
> >> Bluetooth Mesh does not support IPv6.
> >>
> >> ---
> >>
> >> > 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Feb 2019 14:05:48 +0000

Dear all

Sorry for being late. I support the publication of this document at  this time.
Minor comments;

Section 3.2.2:  RFC 8505 updates RFC 6775 and should be referenced instead for the DAD operation and the formats being used, which are modified.

  *   With RFC 8505 link local addresses are not registered, which is exactly what you want here, no need to specify it.
  *   The EUI-64 field is now called ROVR. It is

You may think about recommending an optional support for AP-ND (draft-ietf-6lo-<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-08>ap-nd-08<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-08>)as well, this provides address security I the mesh.

All the best,

Pascal

From: 6lo <[email-masked]> On Behalf Of Gabriel Montenegro
Sent: jeudi 17 janvier 2019 06: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.

Please express your view (even if it's just "it looks fine") on this document.

Thanks,

Chairs

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 13 Feb 2019 19:32:08 +0100

Dear Pascal,

Thank you very much for your support and for your comments.

We'll definitely take into account your comments when preparing -05.

Cheers,

Carles

> Section 3.2.2:  RFC 8505 updates RFC 6775 and should be referenced instead
> for the DAD operation and the formats being used, which are modified.
>
>
>   *   With RFC 8505 link local addresses are not registered, which is
> exactly what you want here, no need to specify it.
> You may think about recommending an optional support for AP-ND
> (draft-ietf-6lo-<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-08>ap-nd-08<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-08>)as
> well, this provides address security I the mesh.
>
> All the best,
>
> Pascal
>