Re: [6lo] review of https://tools.ietf.org/html/draft-ietf-6lo-use-cases-07

Yong-Geun Hong <yonggeun.hong@gmail.com> Wed, 09 October 2019 03:36 UTC

Return-Path: <yonggeun.hong@gmail.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 44B9F1200F5; Tue, 8 Oct 2019 20:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tfyRrogIRPGX; Tue, 8 Oct 2019 20:36:04 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 835CF120019; Tue, 8 Oct 2019 20:36:00 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id t8so451886lfc.13; Tue, 08 Oct 2019 20:36:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HtQ8hesGO0B3ZzMQaXerhtqnsMWhgzdluLy/3oH8U2k=; b=ORt21bVnI2MDkz1zv9mZETqs2miLyJiFfK7I0WSvzKGNWGIvmD7hsCoEeYxjiYePoR qZTuCTWPz4o3pBL4rCehPrA14WqdaopqDLoq0L+J+O+HJAEeOZ/oYR4bXydg3/Cs5q8D K1bIOZ6xhsA0YTg5OCtoWZvaAiq2NKLzKU1M7BeqbXPhQ8ZrstiUfxoX/Q4HTrAv5gZD kMfC0kw0B6D/LMXzc+TQKQ4NMPN0b7fHon+kpVKTmPP4AXQNgCqZZf4X/AicqSAaYJnt oMzwAVjeAXXpvla7sHZTTzFq84ZvyGU/MNLxSN8//q3VCNaPIvMCKxOvg5dNqnrFXFsy crKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HtQ8hesGO0B3ZzMQaXerhtqnsMWhgzdluLy/3oH8U2k=; b=cjzM6GnFdHzu98E9tQkUz7s6XQkcTVgYHSncn1e3hpaQO3lW+3Fi3VPnh+qZ41jPbV 3YuJ1dtAa/oXLiMlFJaA2HG7g0M43Q1j08fVTkpvdzA2i/kHzoLcaIobR6/gkjt6HQlz ZdKy0Ob96PZZPj+0NpWdqEWBKRifscsW6Gj1XXVx+NqJwLpGOFFzsqhrZEaegE0Mj8AJ OHPvXjP8CBDNYl1jYqxJLaKDQL0/CjVaV7DT+Vlg6EgQAW3RnHg1KaKGiAy+74qMeLma O+K0F0vQ8xAmsuhBwm0X33DgCht+C+JoyZh20croLbwHs8SitJJURk7LfU86k+UTIiP7 WlwA==
X-Gm-Message-State: APjAAAWX6njBIkXkDqWcO9VCAVQfcOBOqE8p0Z/LwzafyWd/Fu1+93A3 w12QkixN4tXVsMnY+mW1FvQV6Az+YgcWjWeWjmk=
X-Google-Smtp-Source: APXvYqzQNljE4dSqvWYhQT8xtbRZnK5IsHGQzNRWS0h5PDL7cwaWwP3nm4DtLYlCt9RzgKYp0ZlQxG1SN7cD3YNAmVQ=
X-Received: by 2002:a19:be50:: with SMTP id o77mr619216lff.107.1570592158448; Tue, 08 Oct 2019 20:35:58 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB35655304D665626B7810CC16D89A0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB35655304D665626B7810CC16D89A0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Wed, 9 Oct 2019 12:35:47 +0900
Message-ID: <CACt2foHoaaCqhF8bbxyN63fGdgJx6ZCz97iNgHcDTZK=EVENYg@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "draft-ietf-6lo-use-cases@ietf.org" <draft-ietf-6lo-use-cases@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b101f6059471fbc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/yhhPg5vd4irSdSdQm7aMb-WC_jk>
Subject: Re: [6lo] review of https://tools.ietf.org/html/draft-ietf-6lo-use-cases-07
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: Wed, 09 Oct 2019 03:36:07 -0000

Dear Pascal Thubert.

Thanks for your valuable comments.

These comments looks reasonable and are very helpful to improve the draft.

Please, find response inlines.

I will update the draft with your comments in a next revision.

Best regards

Yong-Geun.

On Wed, Oct 9, 2019 at 1:25 AM Pascal Thubert (pthubert) <pthubert@cisco.com>;
wrote:

> Dear authors:
>
>
>
> Please find some comments below..
>
>
>
> «
>
>     some IEEE 802.15.4 link
>
> “
>
> Please reword to “IEEE Std 802.15.4”  and include a reference. You may
> use
>
>
>
>       <reference anchor="IEEE802154">
>
>          <front>
>
>             <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
>
>             Control (MAC) and Physical Layer (PHY) Specifications for
> Low-Rate
>
>             Wireless Personal Area Networks
>
>             </title>
>
>             <author>
>
>                <organization>IEEE standard for Information
> Technology</organization>
>
>             </author>
>
>             <date/>
>
>          </front>
>
>       </reference>
>
>
>
> Note that Thread and 6TiSCH use 6LoWPAN on 802.15.4 . This is worth
> mentioning. Thread has nice lighting use cases.
>

[Yong-Geun]  Yes. Current draft does't include a reference of "IEEE Std
802.15.4' I will include the reference.


>
>
>
>
> I do not see text on 802.11ah ? There has been 6lo work
> https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-01
>

[Yong-Geun] It is an interesting draft and I acknowledged it. Although it
is a relevant draft with 6lo use cases, we are trying to narrow down the
scope of this draft and we would consider how to handle the draft.

>
>
>
>
> Section 3.6 does not refer to the WIP on PLC:
> https://datatracker.ietf.org/doc/draft-hou-6lo-plc/
>

[Yong-Geun] Yes, it miss the PLC draft and current PLC draft is a WG draft.
I will reflect.


>
>
>
>
> Shouldn’t you have a section on Wi-Sun? see
> https://datatracker.ietf.org/doc/draft-heile-lpwan-wisun-overview/
>
> Note that this is also related to RFC 8036 together with PLC, should also
> be discussed next to your section .6. on Smart Grid
>
>
>

[Yong-Geun] In a previous draft, Wi-Sun and jupitermesh were included. With
the purpose of narrowing down the scope of this draft. we removed a section
on Wi-Sun and jupitermesh, becuase these are mainly based on IEEE 802.15.4.
We would consider how to handle Wi-Sun.

>
>
>
>
>    “
>
>    In the G3-PLC specification, the 6lo adaptation layer utilizes the
>
>    6LoWPAN functions (e.g. header compression, fragmentation and
>
>    reassembly)
>
>       “
>
>     Are you sure of that? I thought they used RFC 8066 to do their stuff
>

[Yong-Geun] I will check again.

>
>
> In section 5
>
>
>
> “
>
>       6LoWPAN requires that IPv6 Neighbor Discovery
>
>       for low power networks [RFC6775 <https://tools.ietf.org/html/rfc6775>] be used for autoconfiguration of
>
>       stateless IPv6 address assignment.  Considering the energy
>
>       sensitive networks [RFC6775 <https://tools.ietf.org/html/rfc6775>] makes optimization from classical
>
>       IPv6 ND [RFC4861 <https://tools.ietf.org/html/rfc4861>] protocol.
>
>
>
> “
>
>
>
> This text is a bit off: On the one hand autoconf is defined in RFC 4862.
> On the other hand RFC 8505 updates RFC 6775. It forgets to mention the
> obvious, which is to must IPv6 (RFC 8200)
>
> Then there’s more to be said about the support of IPv6 by the 6lo node.
> E.g., support of host functions in RFC 8200 like the capability to ignore
> consumed routing headers and HbH options. This become useful when combined
> with RPL, and a ref to
> https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo would be useful.
>
> I’d suggest:
>
>
>
> “
>
>       6LoWPAN developed a new version of IPv6 ND [RFC 4861, RFC 4862]
>
>      that relies on a proactive registration to avoid the use of
>
>       multicast. 6LoWPAN ND [RFC 6775, RFC 8505] inherits from IPv6 ND
>
>       for mechanisms such as SLAAC and NUD, but uses a unicast method
>
>       for DAD, and avoids multicast lookups from all nodes by using
>
>       non-onlink prefixes. A 6LN is also expected to be an IPv6 host
>
>       per [RFC 8200] which means it should ignore consumed routing
>
>       headers and HbH options; when operating in a RPL [RFC 6550]
>
>       network, it is also beneficial to support IP-in-IP encapsulation
>
>       [draft-ietf-roll-useofrplinfo]. the 6LN should also support
>
>       RFC 8505 and use it as the default ND method.
>
> “
>
>
>

[Yong-Geun] Thanks for your good suggestion. I will reflect.


>
>
> Voila, great doc by the way : )
>
>
>
> Pascal
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>