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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Tue, 27 October 2020 13:43 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 3CC2F3A0D44; Tue, 27 Oct 2020 06:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 jwLyVy8o2NKV; Tue, 27 Oct 2020 06:43:47 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 C5C4F3A0D72; Tue, 27 Oct 2020 06:43:44 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 09RDhEnF033093; Tue, 27 Oct 2020 14:43:14 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 1FF341D53C1; Tue, 27 Oct 2020 14:43:13 +0100 (CET)
Received: from 10.192.137.220 by webmail.entel.upc.edu with HTTP; Tue, 27 Oct 2020 14:43:14 +0100
Message-ID: <33cb7273031c35e9b1ec6041f6b65e95.squirrel@webmail.entel.upc.edu>
In-Reply-To: <BB09947B5326FE42BA3918FA28765C2E013E5AB2@DGGEMM506-MBX.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E013E5AB2@DGGEMM506-MBX.china.huawei.com>
Date: Tue, 27 Oct 2020 14:43:14 +0100
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Liubing (Remy)" <remy.liubing@huawei.com>
Cc: "draft-ietf-6lo-plc@ietf.org" <draft-ietf-6lo-plc@ietf.org>, "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.3 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 100:47:18 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Tue, 27 Oct 2020 14:43:16 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/i_vcElnX717XJxbQ-61GCP_sgQo>
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: Tue, 27 Oct 2020 13:43:57 -0000

Hello Remy,

Thanks for your response.

I have reviewed your response to my 3rd comment below. Your proposed new
text looks good to me.

Thanks,

Carles



> 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
>
>
>