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

Carles Gomez Montenegro <> Wed, 02 September 2020 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 454B43A0F8E; Wed, 2 Sep 2020 02:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h-plxbDHMjCf; Wed, 2 Sep 2020 02:54:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 022873A0F86; Wed, 2 Sep 2020 02:54:34 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0829sPOo028448; Wed, 2 Sep 2020 11:54:25 +0200
Received: from ( []) by (Postfix) with ESMTP id 2BCF61D53C1; Wed, 2 Sep 2020 11:54:24 +0200 (CEST)
Received: from by with HTTP; Wed, 2 Sep 2020 11:54:25 +0200
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Wed, 02 Sep 2020 11:54:25 +0200
From: Carles Gomez Montenegro <>
To: "Liubing (Remy)" <>
Cc: "" <>, "" <>
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: ACL matched, not delayed by milter-greylist-4.3.9 ( []); Wed, 02 Sep 2020 11:54:25 +0200 (CEST)
Archived-At: <>
Subject: Re: [6lo] Shepherd review of draft-ietf-6lo-plc
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Sep 2020 09:54:37 -0000

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.

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


> Best regards,
> Remy