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

"Liubing (Remy)" <remy.liubing@huawei.com> Fri, 30 October 2020 03:14 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 2FC633A0400; Thu, 29 Oct 2020 20:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 nyqlvJPWklJ3; Thu, 29 Oct 2020 20:14:26 -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 CA01E3A03F4; Thu, 29 Oct 2020 20:14:25 -0700 (PDT)
Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4EA619EB195CE638E208; Fri, 30 Oct 2020 03:14:22 +0000 (GMT)
Received: from lhreml734-chm.china.huawei.com (10.201.108.85) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 30 Oct 2020 03:14:21 +0000
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Fri, 30 Oct 2020 03:14:21 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.202]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0487.000; Fri, 30 Oct 2020 11:14:18 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Kerry Lynn <kerlyn@ieee.org>, Carles Gomez Montenegro <carlesgo@entel.upc.edu>
CC: "6lo@ietf.org" <6lo@ietf.org>, "draft-ietf-6lo-plc@ietf.org" <draft-ietf-6lo-plc@ietf.org>
Thread-Topic: [6lo] Shepherd review of draft-ietf-6lo-plc
Thread-Index: Adargwmv/vuJDA8xQs2hs2gKQZVvfgAsFjSAAIxCqUA=
Date: Fri, 30 Oct 2020 03:14:17 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E013E9D1F@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E013E5AB2@DGGEMM506-MBX.china.huawei.com> <CABOxzu1YFJkPaTzwikoednjTm_6iMu45uJO8BXVZGTAtmDB6EA@mail.gmail.com>
In-Reply-To: <CABOxzu1YFJkPaTzwikoednjTm_6iMu45uJO8BXVZGTAtmDB6EA@mail.gmail.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: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2E013E9D1FDGGEMM506MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/zWiSSGfIn7VzmApkrjfD18ryky4>
Subject: [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: Fri, 30 Oct 2020 03:14:30 -0000

Hello Kerry and Carles,

Thank you very much for your comments.

@Kerry, thank you for sharing your experience in RFC8163. I agree with you that the exiting tools will have to be extended to correctly parse the packet.
Since the L2 is different from specification to specification, the tools need extensions to parse the L2 anyway. For the exiting tools, the modification in the adaptation layer would be much minor compared to the one in the L2.

Best regards,
Remy
发件人: Kerry Lynn [mailto:kerlyn@ieee.org]
发送时间: 2020年10月27日 23:33
收件人: Liubing (Remy) <remy.liubing@huawei.com>
抄送: Carles Gomez Montenegro <carlesgo@entel.upc.edu>; 6lo@ietf.org; draft-ietf-6lo-plc@ietf.org
主题: Re: [6lo] Shepherd review of draft-ietf-6lo-plc

Hi Remy,

I have an alternative suggestion for comment 3; see below...

On Mon, Oct 26, 2020 at 6:30 AM Liubing (Remy) <remy.liubing@huawei.com<mailto:remy.liubing@huawei.com>> wrote:
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<mailto:carlesgo@entel.upc.edu>]
发送时间: 2020年9月2日 17:54
收件人: Liubing (Remy) <remy.liubing@huawei.com<mailto:remy.liubing@huawei.com>>
抄送: draft-ietf-6lo-plc@ietf.org<mailto:draft-ietf-6lo-plc@ietf.org>; 6lo@ietf.org<mailto: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.
My concern with re-interpreting RFC6282 bits for particular 6lo specs is that it
would potentially complicate existing tools like sniffers. One alternative is to
left-justify 12-bit addresses in a 16-bit field and set the high-order four bits to
zero. A similar technique was used for 8-bit MS/TP MAC addresses in RFC8163.
Regards, Kerry

> 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


_______________________________________________
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo