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

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Tue, 12 February 2019 12:35 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9A12EB11; Tue, 12 Feb 2019 04:35:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nAvVnh1yX0x; Tue, 12 Feb 2019 04:35:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2725512D826; Tue, 12 Feb 2019 04:35:00 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 2A88FF8650AEE31A3E9C; Tue, 12 Feb 2019 12:34:58 +0000 (GMT)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 12 Feb 2019 12:34:57 +0000
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.233]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0415.000; Tue, 12 Feb 2019 18:04:43 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: "samita.chakrabarti@verizon.com" <samita.chakrabarti@verizon.com>, lo <6lo@ietf.org>, "draft-ietf-6lo-blemesh@ietf.org" <draft-ietf-6lo-blemesh@ietf.org>, Gabriel Montenegro <g.e.montenegro@hotmail.com>
Thread-Topic: [6lo] WG last call on draft-ietf-6lo-blemesh-04
Thread-Index: AdSuIYgabsqcvnWaQDSPCiP0NDhXfAHv1yeAAc3jLAAAYpH+EADhlKOAACgqsRA=
Date: Tue, 12 Feb 2019 12:34:43 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DD9B6A2@BLREML503-MBX.china.huawei.com>
References: <YTOPR0101MB16735C399C58C50856607A79C1830@YTOPR0101MB1673.CANPRD01.PROD.OUTLOOK.COM> <982B626E107E334DBE601D979F31785C5DD7E9C6@BLREML503-MBX.china.huawei.com> <2bfae1995bdde69617ac9a41a405559c.squirrel@webmail.entel.upc.edu> <982B626E107E334DBE601D979F31785C5DD9845D@BLREML503-MBX.china.huawei.com> <842dbc4fb241bb95d9e76358b0e1fa4b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <842dbc4fb241bb95d9e76358b0e1fa4b.squirrel@webmail.entel.upc.edu>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.157.44]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/oXH_qOpi7gryvx02arL3BzN0BK0>
Subject: Re: [6lo] WG last call on draft-ietf-6lo-blemesh-04
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 12:35:03 -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:carlesgo@entel.upc.edu]
> Sent: 12 February 2019 03:44
> To: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
> Cc: samita.chakrabarti@verizon.com; lo <6lo@ietf.org>rg>; draft-ietf-6lo-
> blemesh@ietf.org; Gabriel Montenegro <g.e.montenegro@hotmail.com>
> Subject: RE: [6lo] WG last call on draft-ietf-6lo-blemesh-04
> 
> Hi Rahul,
> 
> Once again, thank you very much for your valuable comments!
> 
> Please find below my inline responses:
> 
> > 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?
> 
> [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.
> 
> > Please find my responses inline..
> >
> > Thanks,
> > Rahul
> >
> >
> >> > 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.
> >
> > [RJ] Thank you for the clarification.
> >
> >>
> >> 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.
> >
> > [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?
> 
> >> > 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 !)
> >
> > [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?
> >> (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.
> 
> [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.
> 
> >> > 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.
> >
> > [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
> 
> 
> >> > 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: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
> >> >
> >>
> >>
> >> _______________________________________________
> >> 6lo mailing list
> >> 6lo@ietf.org
> >> https://www.ietf.org/mailman/listinfo/6lo
> >
>