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

From: "Chenlihao (Lihao, IP Technology Research Dept NW)" <[email-masked]>
Date: Thu, 18 Oct 2018 06:47:22 +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

---

From: S.V.R.Anand <[email-masked]>
Date: Thu, 18 Oct 2018 09:54:07 +0000

Dear Authors,

I went through the draft and I think it is useful. Wish to share my initial
thoughts on the text.

- According to my understanding, the draft covers IEEE 1901.1, IEEE 1901.2 and
  ITU-T G.9903 PLC standards together. After glancing through ITU-T G.9903
  specification it appears that the 6LoWPAN adaptation is already defined there.
  It would be nice if the draft covers those aspects that highlight the major
  differences that are not covered by ITU-T G.9903. If the difference is not
  substantial, the draft can just focus on IEEE 1901.1, IEEE 1901.2.

- Since routing aspects are outside the scope of 6Lo charter, wonder how
  important is the routing protocol section for the draft. Of course, LOADng is
  deeply embedded into ITU-T G.9903 in the form of mesh under routing. Let me know
  what you think.

- Informative reference to LOADng can be included.

- Refer to the following text in Section 3.

  "A routing protocol (e.g., RPL [RFC6550] or AODV-RPL
  [I-D.ietf-roll-aodv-rpl]) at the Network layer is optional according to the
  IEEE 1901.1 and IEEE 1901.2 PLC standards mentioned in this document."

  Depending on the way the reader reads it, the above sentence can be
  interpreted as "IEEE 1901.1 and IEEE 1901.2 PLC standards are specifically
  saying RPL and AODV-RPL are optional". Further, "according to the IEEE 1901.1
  and IEEE 1901.2 PLC standards mentioned in this document" can be read as the
  document is defining its own version of IEEE 1901.1 and IEEE 1901.2 PLC
  standards. Can you rephrase it ?

- Refer to the text in Section 4.

  "However, due to the different characteristics of the PLC media, the 6LoWPAN
   adaptation layer cannot perfectly fulfill the requirements."

   At this point of the draft, it is not clear what the requirements are. It is
   better to substantiate with few unfulfilled requirements that provide 
   motivatation for the draft.

Regards
Anand

---

From: "Liubing (Remy)" <[email-masked]>
Date: Sat, 20 Oct 2018 06:41:20 +0000

Dear Lihao,

Thank you for your comments. Please find my responses inline.

Best regards,
Remy

From: 6lo [mailto:[email-masked]] On Behalf Of Chenlihao (Lihao, IP Technology Research Dept NW)
Sent: Thursday, October 18, 2018 2:47 PM
To: [email-masked]
Subject: [6lo] comments on draft-hou-6lo-plc-04

Hello authors,

- 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.
[Remy] Good point, we will revise these two paragraphs.
- 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.
[Remy] Yes, we will add a mapping table of the terminologies. In section 4.3, as the two LLAs are designed separately for IEEE1901.1 and 1901.2 & G.9903, we can use the a PLC's own terminology in its related LLA. Does it make sense?
- 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?
[Remy] I think there is a misunderstanding here. It is the PHY packet size that can change. Since the data link layer has the capability of fragmentation and Reassembly, as long as the MAC is capable to support 1280 bytes, there is no need to have the fragmentation in the adaptation layer. We will clarify this point. Thanks for indicating.
- 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.
[Remy] You are right about this. EV charging is not a good example for mesh network. We will delete it.

Cheers,
Lihao

---

From: "Liubing (Remy)" <[email-masked]>
Date: Sat, 20 Oct 2018 06:56:58 +0000

Dear Anand,

Thank you very much for your review. Please find my responses below.

Best regards, 
Remy

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of S.V.R.Anand
> Sent: Thursday, October 18, 2018 5:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [6lo] Comments on draft-hou-6lo-plc-04
> 
> Dear Authors,
> 
[Remy]It is true that ITU-T G.9903 has included the selections from RFC4944 and RFC6282 in the body text. Thus the related description is normative. In our draft, the G.9903 related contents, such as stateless address autoconfiguration, LL address, unicast address mapping and header compression, are well aligned with ITU-T standard. What is in our draft but not in ITU-T G.9903: neighbor discovery protocols in RFC6775 and RFC6775-update, the new outcome of 6lo. As for the two IEEE standards, the description on IPv6 adaptation does not cover all the aspects, and is included as annexes, thus not formal standards. In this draft, we are aiming to provide an overall design of PLC IPv6 adaptation layer based on IETF standards and their modifications.

>  [Remy] The description on routing protocols is just informative as a part of the PLC technology overview. Thus we put it in section 3 instead of section 4.

>  [Remy] Thanks for pointing it out. We need to rephrase it: A routing protocol MAY be required in tree and mesh topologies.  The routes can be built in mesh-under mode at layer 2 or in route-over mode at layer 3.

>  [Remy] Good point! For example, the stateless address autoconfiguration and unicast address mapping defined in RFC4944 can't be used for IEEE 1901.1 due to the different L2 address format. Thus modifications are needed to adapt IEEE1901.1.

> Regards
> Anand
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: sajjad akbar <[email-masked]>
Date: Mon, 22 Oct 2018 10:33:32 +1100

Hello authors,

The draft is much more clear than its initial version. Good work. I would
suggest you to clear the discussion about fragmentation. In the current
version its little confusing, for example you can clearly describe either
itstransport layer or MAC layer fragmentation. Even if you are not using
you can eliminate confusing text.

Regards
Sajjad

On Thu, Oct 18, 2018 at 5:47 PM Chenlihao (Lihao, IP Technology Research
Dept NW) <[email-masked]> wrote:

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

---

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 23 Oct 2018 02:07:09 +0000

Hello Sajjad,

Many thanks to your comments. We have uploaded the 05 version of the draft. The modification is based on the previous comments that we received these days. The fragmentation section is also clarified. Please go check if the 05 version meets your expectation.

Regards,
Remy

From: 6lo [mailto:[email-masked]] On Behalf Of sajjad akbar
Sent: Monday, October 22, 2018 7:34 AM
To: Chenlihao (Lihao, IP Technology Research Dept NW) <[email-masked]>
Cc: lo <[email-masked]>
Subject: Re: [6lo] comments on draft-hou-6lo-plc-04

Hello authors,

The draft is much more clear than its initial version. Good work. I would suggest you to clear the discussion about fragmentation. In the current version its little confusing, for example you can clearly describe either itstransport layer or MAC layer fragmentation. Even if you are not using you can eliminate confusing text.

Regards
Sajjad

On Thu, Oct 18, 2018 at 5:47 PM Chenlihao (Lihao, IP Technology Research Dept NW) <[email-masked]<mailto:[email-masked]>> wrote:
Hello authors,

- 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

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo