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

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Tue, 05 February 2019 09:19 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 99ABB124D68 for <6lo@ietfa.amsl.com>; Tue, 5 Feb 2019 01:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 gUqdrE4tYnfi for <6lo@ietfa.amsl.com>; Tue, 5 Feb 2019 01:19:33 -0800 (PST)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60737130E0E for <6lo@ietf.org>; Tue, 5 Feb 2019 01:19:32 -0800 (PST)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x159JTQo057032; Tue, 5 Feb 2019 10:19:30 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 0CF581D53C1; Tue, 5 Feb 2019 10:19:29 +0100 (CET)
Received: from 82.2.125.120 by webmail.entel.upc.edu with HTTP; Tue, 5 Feb 2019 10:19:29 +0100
Message-ID: <9f6ab8cb75e043f561a80e18a7e5629b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <25fb202b-ba4a-0e89-5f0c-619ad80f87e2@tuni.fi>
References: <25fb202b-ba4a-0e89-5f0c-619ad80f87e2@tuni.fi>
Date: Tue, 05 Feb 2019 10:19:29 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: "Bilhanan Silverajan (TAU)" <bilhanan.silverajan@tuni.fi>
Cc: "6lo@ietf.org" <6lo@ietf.org>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.2 at dash
X-Virus-Status: Clean
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Tue, 05 Feb 2019 10:19:30 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/NvuEg6y7Lj5Ievyih15CJ2UlL4U>
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, 05 Feb 2019 09:19:37 -0000

Hi Bill,

First of all, thank you very much for your valuable comments, and sorry
for the delay.

Please find below inline responses to your comments:

> Hi all,
>
> I read the draft and I think this is an important work particularly to
> extend RFC 7668 from its existing star topology. I have the following
> comments:
>
> * In several places, the phrase "IPv6 over mesh networks composed of BLE
> links" is used. In others, the phrase "IPv6 mesh over Bluetooth LE" is
> used, while I also discovered "IPv6-enabled mesh of Bluetooth LE links".
> I think the authors should settle on one phrase (my preference would be
> "IPv6 mesh over BLE links") to avoid confusion that the draft is about
> deploying IPv6 over the recently standardised BLE mesh technology.

Agreed. Our upcoming update of the draft (-05) will show "IPv6 mesh over
BLE links" as the only term used.

> * Section 1 has the following sentence: "However, subsequent Bluetooth
> specifications allow the formation of extended topologies [BTCorev4.1],
> such as the mesh
>     topology." What extended topologies from the BT Core document are
> relevant for the mesh described in this document, which didn't exist
> when RFC 7668 became available? If none, I suggest removing this
> sentence (and perhaps avoiding the issue mentioned in the next bullet
> point).

In fact, none, since Bluetooth 4.1 was already out when RFC 7668 became
available.

As per your suggestion, the following would be our planned change:

OLD:
   Bluetooth 4.0 only supports Bluetooth LE
   networks that follow the star topology.  In consequence, RFC 7668 was
   specifically developed and optimized for that type of network
   topology.  However, subsequent Bluetooth specifications allow the
   formation of extended topologies [BTCorev4.1], such as the mesh
   topology.  The functionality described in RFC 7668 is not sufficient
   and would fail to enable IPv6 over mesh networks composed of
   Bluetooth LE links.

NEW:
   Bluetooth 4.0 only supports Bluetooth LE
   networks that follow the star topology.  In consequence, RFC 7668 was
   specifically developed and optimized for that type of network
   topology.  However, the functionality described in RFC 7668 is not
   sufficient and would fail to enable an IPv6 mesh over BLE links.

> * Bluetooth SIG deprecated the Bluetooth Core Specification 4.1
> mentioned in the previous point was very recently (actually, yesterday).
> Perhaps this should be taken into account?

Great point.

At the very least, we need to remove [BTCorev4.1] from the "Normative
references" section of the draft. Probably, it can still be included in
the "Informative references" section, since the historic information in
Section 2 about version 4.1 opening the door to topologies beyond the star
topology is still correct.

Then, in the first paragraph of section 2, the first "Bluetooth 4.1"
instance can now be replaced by "Bluetooth 4.1 (now deprecated)".

Also,

OLD:
   Consistently with Bluetooth 4.1, a device may implement both roles
   simultaneously.

NEW:
   Consistently with Bluetooth 4.1 and subsequent Bluetooth versions
   (e.g. Bluetooth 4.2 [BTCorev4.2] or subsequent), a device may
   implement both roles simultaneously.

... with [BTCorev4.2] being added as a normative reference.

Please let us know if the above proposed changes would address your concerns.

> Otherwise the draft is in good shape and is ready for submission to IESG.

Once again, thank you very much for your comments, and for your support.

Cheers,

Carles


> Best regards,
>
> Bill
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>