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>
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]
> 发送时间: 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.
>
> 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
> https://www.ietf.org/mailman/listinfo/6lo
>