Re: [6lo] Shepherd review of draft-ietf-6lo-plc

"Liubing (Remy)" <remy.liubing@huawei.com> Mon, 26 October 2020 10:30 UTC

Return-Path: <remy.liubing@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 377A13A1A6C; Mon, 26 Oct 2020 03:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 0m4LYstfhTLc; Mon, 26 Oct 2020 03:30:47 -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 6F7E33A156F; Mon, 26 Oct 2020 03:30:47 -0700 (PDT)
Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 275B4811DABF718FA5CF; Mon, 26 Oct 2020 10:30:45 +0000 (GMT)
Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 10:30:43 +0000
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 26 Oct 2020 10:30:43 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.202]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0487.000; Mon, 26 Oct 2020 18:30:38 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: "draft-ietf-6lo-plc@ietf.org" <draft-ietf-6lo-plc@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] Shepherd review of draft-ietf-6lo-plc
Thread-Index: Adargwmv/vuJDA8xQs2hs2gKQZVvfg==
Date: Mon, 26 Oct 2020 10:30:37 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E013E5AB2@DGGEMM506-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.194]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/-_bL8JBAyixNHHZcimFhMY_D_wE>
Subject: Re: [6lo] Shepherd review of draft-ietf-6lo-plc
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: Mon, 26 Oct 2020 10:30:49 -0000

Hello Carles,

I'm really sorry for this late reply. 

It seems that we have reached consensus on 4 of the 5 comments. Please find my new response to your 3rd comment below.

Thank you very much for reviewing.

Best regards,

Remy
-----邮件原件-----
发件人: Carles Gomez Montenegro [mailto:carlesgo@entel.upc.edu] 
发送时间: 2020年9月2日 17:54
收件人: Liubing (Remy) <remy.liubing@huawei.com>
抄送: draft-ietf-6lo-plc@ietf.org; 6lo@ietf.org
主题: Re: [6lo] Shepherd review of draft-ietf-6lo-plc

Hello Remy,

First of all, sorry for the late response.

Thanks for taking my comments into consideration.

Please find below my inline responses (labeled [Carles]):

> Hello Carles,
>
> Thank you very much for your detailed review.

[Carles] You are welcome!

> We accept most of your suggestions.

[Carles] Thanks!

> Meanwhile, items that need further
> discussion are posted below.
>
> 1. This specification provides a brief overview of PLC technologies.
>      Some of them have LLN characteristics, i.e. limited power
>
> Just a weak suggestion: LLN is a recognized term in many domains.
> Nevertheless, feel free to consider using "Constrained-Node Network 
> (CNN) (see RFC 7228).
> [Remy] Maybe LLN is a better choice since it is used in many RFCs in 
> IOT domain as well. Thank you for your suggestion though.

[Carles] Feel free to use the term that you prefer.

> 2.   RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
>         is a layer 3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
>         updates RPL to include reactive, point-to-point, and asymmetric
>         routing.  IEEE 1901.2 specifies Information Elements (IEs) with
>         MAC layer metrics, which can be provided to L3 routing protocol
>         for parent selection.  For IPv6-addressable PLC networks, a
>         layer-3 routing protocol such as RPL and/or AODV-RPL SHOULD be
>         supported in the standard.
>
> Why "SHOULD"?  And if "SHOULD" is the right term here, perhaps add 
> some clarification on reasons or circumstances motivating using a 
> protocol different from RPL and/or AODV-RPL?
> [Remy] Yes, this sentence makes people confused. The reason why "SHOULD"
> is used is that we have other options like L2-routing and LOADng. But 
> this sentence looks redundant now, because the whole section is 
> talking about the three options. Do you think it is OK to remove this sentence?

[Carles] Yes, I agree to remove this sentence.

> 3. IEEE 1901.1 supports 12-bit and 48-bit addresses. Header 
> compression over IEEE 1901.1 will need some form of adaptation, since 
> RFC 6282 refers to 16-bit and 64-bit addresses.
> [Remy] Yes, we need adaptation. How to generate IID from 12-bit 
> (1901.1), 16-bit (G.9903 and 1901.2) and 48-bit address is defined in 
> section 4.1 (Stateless Address Autoconfiguration). And using the same 
> method, the original IPv6 address can be recovered from the L2 
> address. Thus that's where the adaptation is defined. It may be not 
> explicit enough. Actually, the encoding format defined in RFC6282 
> applies to all the PLC technologies mentioned in this draft. The only 
> difference is: for 1901.1, when the SAM or DAM in RFC6282 is set to 2, 
> it means the source or destination IPv6 address is compressed to 12 bits instead of 16bits.

[Carles] In my opinion, adding some more explicit note would be helpful.
[Remy] I propose to add the following specification: 
For IEEE 1901.2 and G.9903, the IP header compression follows the instruction in [RFC6282]. However, additional adaptation MUST be considered for IEEE 1901.1, since it has a short address of 12 bits instead of 16 bits.  The only modification is the semantics of the "Source Address Mode" when set as "10" in the section 3.1 of [RFC6282], which is illustrated as following.

SAM: Source Address Mode:
If SAC=0: Stateless compression

   10:   12 bits.  The first 116 bits of the address are elided. The
         value of the first 64 bits is the link-local prefix padded with
         zeros.  The following 64 bits are 0000:00ff:fe00:0XXX, where
         XXX are the 12 bits carried in-line.

If SAC=1: stateful context-based compression

   10:   12 bits.  The address is derived using context information and
         the 12 bits carried in-line.  Bits covered by context
         information are always used.  Any IID bits not covered by
         context information are taken directly from their corresponding
         bits in the 12-bit to IID mapping given by 0000:00ff:fe00:0XXX,
         where XXX are the 12 bits carried inline.  Any remaining bits
         are zero.

> 4. PAN Coordinator (PANC) and PAN Device.  The PANC is the primary
>    coordinator of the PLC subnet and can be seen as a master node; PAN
>    Devices are typically PLC meters and sensors.  The PANC also serves
>    as the Routing Registrar for proxy registration and DAD procedures,
>    making use of the updated registration procedures in [RFC8505].  IPv6
>    over PLC networks are built as tree, mesh or star according to the
>    use cases.  Every network requires at least one PANC to communicate
>    with each PAN Device.
>
> The last sentence was unclear. Who/What communicates with each PAN 
> Device?
> [Remy] We meant "the PANC communicates with the PAN devices". We try 
> to
> rephrase: Generally, each PLC network has one PANC. In some cases, the 
> PLC network can have alternate coordinators to replace the PANC when 
> the PANC leaves the network for some reason.

[Carles] Your new proposed text looks good to me.

> 5. What is the subnet model for the scenarios illustrated in this 
> section?
> For example, is the "PLC subnet" a multilink subnet? Is each link in 
> the "PLC subnet" a subnet?
> [Remy] It is a multilink subnet, instead of "each link is a subnet".

[Carles] Thanks. Please add some text on this feature to the document.

Best regards,

Carles


> Best regards,
> Remy