[6lo] comments on draft-hou-6lo-plc-04

"Chenlihao (Lihao, IP Technology Research Dept NW)" <lihao.chen@huawei.com> Thu, 18 October 2018 06:47 UTC

Return-Path: <lihao.chen@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 1EAE3128A6E for <6lo@ietfa.amsl.com>; Wed, 17 Oct 2018 23:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 bjXlTAo8j7u7 for <6lo@ietfa.amsl.com>; Wed, 17 Oct 2018 23:47:42 -0700 (PDT)
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 6A039128766 for <6lo@ietf.org>; Wed, 17 Oct 2018 23:47:42 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 89CBAEF3E87B4 for <6lo@ietf.org>; Thu, 18 Oct 2018 07:47:39 +0100 (IST)
Received: from DGGEMI421-HUB.china.huawei.com (10.1.199.150) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 18 Oct 2018 07:47:26 +0100
Received: from DGGEMI523-MBX.china.huawei.com ([169.254.6.22]) by dggemi421-hub.china.huawei.com ([10.1.199.150]) with mapi id 14.03.0399.000; Thu, 18 Oct 2018 14:47:23 +0800
From: "Chenlihao (Lihao, IP Technology Research Dept NW)" <lihao.chen@huawei.com>
To: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: comments on draft-hou-6lo-plc-04
Thread-Index: AdRmrikovygv8CO8QGiILzdXNMQstQ==
Date: Thu, 18 Oct 2018 06:47:22 +0000
Message-ID: <12E1A4464B8C5C43A3A4B6B61F7DC60C0199AAEA@dggemi523-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.162.209]
Content-Type: multipart/alternative; boundary="_000_12E1A4464B8C5C43A3A4B6B61F7DC60C0199AAEAdggemi523mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/EQmCRsZPcTuYhjVs-Al0kaBTnb8>
Subject: [6lo] comments on draft-hou-6lo-plc-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: Thu, 18 Oct 2018 06:47:45 -0000

Hello authors,

I think this draft gives a good guideline for IPv6 adaptation on PLC. The draft has a quite complete description. However, some points need to be clarified. Please find my comments below.

- The preface of the section 3 is not well organized. The content of the two paragraphs seems to be relevant, but the features of the same PLC technology are not in the same paragraph.

- It is reasonable that different PLC technologies have different terminologies, but the draft should build up a mapping between them. For example, in section 4.3, 1901.1 uses NID and TEI, while 1901.2 uses PAN ID and Device ID.

- For Fragmentation and Reassembly, the draft says that "the number of data octets of the PHY payload can change dynamically based on channel conditions", thus even for IEEE 1901.1 and 1901.2, the MTU can be lower than 1280 bytes. But the second paragraph says that fragmentation and assembly MUST NOT be used. Any contradiction here?

- The "charging station to EV communication" use case may not be appropriate for using ADOV-RPL in PLC tree network. Since the charging station and the EV are directly connected to each other, it should be parent to child communication instead of P2P.


Cheers,
Lihao