Hi Éric, Thanks a lot for your comments, very helpful. And we will reflect your comments in the next version. Please see my response in line.
Regards, Derek -----邮件原件----- 发件人: Éric Vyncke via Datatracker [mailto:[email protected]] 发送时间: 2021年8月10日 13:45 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Carles Gomez <[email protected]>; [email protected]; [email protected] 主题: Éric Vyncke's Discuss on draft-ietf-6lo-plc-06: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-6lo-plc-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. Special thanks to Carles Gomez for his shepherd's write-up, which contains a good summary of the WG consensus *BUT* it does not mention that the IEEE normative references are not free. Strange that Carles' email address, [email protected], is not in the datatracker status page. Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated), and some nits. Please also address Dave Thaler's INT-DIR review at: https://datatracker.ietf.org/doc/review-ietf-6lo-plc-06-intdir-telechat-thaler-2021-08-06/ (some of my DISCUSS points are coming from Dave's review) I hope that this helps to improve the document, Regards, -éric == DISCUSS == Is there any reason why the IETF Last Call https://mailarchive.ietf.org/arch/msg/6lo/f59y8rMg-p_aCKYSSEtBzoJK4qQ/ did not mention that the two IEEE normative references were behind a paywall ? It prevented some more detailed reviews and is an important fact. [Derek] You can access the standard online through “ACCESS VIA SUBSCRIPTION” if your IEEE member or institution supplied IEEE Xplore credentials. here are the corresponding links for the two IEEE standards: IEEE1901.1 (https://ieeexplore.ieee.org/document/8360785), IEEE 1901.2 (https://ieeexplore.ieee.org/document/6679210). How can a PLC node distinguish between an IPv6 PDU and a non-IPv6 PDU ? I.e., is there the equivalent of a EtherType in a layer-2 PLC PDU ? Then, this should be mentioned in this document else some text explaining why it is not required would be welcome. Especially when the normative IEEE references are not freely available. [Derek] Very good question. RFC7973 define a Ethertype of " A0ED" for Dispatch header of LoWPAN encapsulation, and this information can be carried in the IE field in the MAC header of IEEE1901.2 or G.9903. And regarding IEEE1901.1, the IP packet type has been defined with the corresponding MAC Service Data Unit (MSDU) type value 49. And the 4-bit Internet Protocol version number helps to distinguish between IPv4 PDU and IPv6 PDU. -- Section 4.1 -- I am repeating here Dave Thaler's point 1) as it is completely unclear to me how the shared secret/version number are shared and provisioned, this could prevent interoperation hence my DISCUSS. While I appreciate that the nodes are constrained, some warnings about having a *single global IPv6 address* should be written or if the spec supports more than one global IPv6 address per node, then the current text must be changed. [Derek] please refer to Remy's response to Dave. : ) Actually we don't prevent to have multiple IPv6 addresses at the same time. We will change it to plural. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == A generic and probably naive question of mine: how can a PLC node (which has access to electrical power) can be qualified as 'low power' ? [Derek] 6lo refers to “IPv6 over Networks of Resource-constrained Nodes”. For PLC nodes, e.g. power meters, the characteristics of resource constrained are reflected in 1. Hardware resources such as CPU and memory are limited, usually for cost saving considerations 2. Power saving is a general requirement of PLC nodes. For example, power grid companies need to maintain a huge number of power meters, and the extra power consumption of each meter will bring about a significant increase in the total cost 3. The PLC link status is easy to change in case of link noise, such as the influence of household microwave ovens on power meters, which can be a manifestation of "lossy“. In this case, lowering the Layer 2 MTU can be applied to alleviate packet loss. -- Section 2 -- Please add references to the IEEE references before using them in the table 1. [Derek] Thanks! We will reflect this comment in the next version. -- Section 3.1 -- Is the I-D limited to TCP & UDP only ? (based on figure 1 even if later RPL is mentioned) [Derek] Not limited to TCP & UDP, we will modify it to “TCP/UDP/other” in Figure 1. Thanks for your comment. -- Section 3.4 -- While not required, an expansion of "LOAD" as in "LOADng" will probably be welcome by readers. [Derek] Thanks! We will reflect this comment in the next version. -- Section 4.1 -- Strongly suggest to show the 48-bit pseudo MAC address before showing the generated 64-bit address, which looks like the old EUI-64 generation. Should there be some explanation about the lack of U/L bit flapping in this algorithm ? [Derek] Thanks! We will reflect these two comment in the next version. Same comment for the 12-bit address. [Derek] Thanks! The same response as above. Should there be some explanations about NID and TEI? Notably about how they are provisioned and how can collision be prevented. [Derek] I agree. Such description is needed, and that is why you have the following two questions. We will add some description. "A PLC host SHOULD use the IID derived from the link-layer short address to configure the IPv6 address used for communication with the public network" Is the above text about how to provision the IP address ? E.g., via stateful DHCPv6 ? [Derek] Yes, this section is about IPv6 stateless address autoconfiguration, and this paragraph is discussing the scenario where the PLC node communicates with devices outside the PLC subnet. -- Section 4.3.1 -- "In order to avoid the possibility of duplicated IPv6 addresses, the value of the NID MUST be chosen so that the 7th and 8th bits of the first byte of the NID are both zero." I failed to understand the reasoning in the above text: how can a reduction of entropy decrease the risk of collision ? [Derek] Different PAN coordinators generate NID and negotiate with each other to avoid NID conflicts, and then each PAN coordinator is responsible for allocating TEI to new PLC device in each PLC subnet. In this case every PLC device has the unique TEI in a PLC subnet, and has the unique [NID, TEI] among different PLC subnets. Thus the derived IPv6 address is supposed to be unique. However, because the NID bit6 & bit7 are set to zero, in this case PLC devices with the same TEI under different subnets have a chance of IPv6 address conflict. So it is suggested for the PAN coordinators to avoid using the bit6 & bit7 when generating the NID. Please also specify the receiver's behavior when the padding is not 0 (probably 'ignore'). [Derek] Thanks! We will reflect this comment in the next version. Rather than using "7th and 8th bits" please use "bits 6 and 7". [Derek] Thanks! We will reflect this comment in the next version. -- Section 4.3.2 -- Same comments as for section 4.3.1 [Derek] Thanks! The same response. -- Section 4.4 -- "Although PLC devices are electrically powered, sleeping mode SHOULD still be used for power saving." Suggest to add some justification for the "SHOULD" or at least explain when a PLC device may not use the sleeping mode. [Derek] Thanks. We will modify the description. Take power meters as an example, the use of sleep mode will be affected by the business model, and the prepaid mode and postpaid mode have different requirements for the data collection frequency of power meters. The logical flow is weird in §4 " Duplicate Address Detection (DAD) MUST NOT be utilized. Otherwise, the DAD MUST", i.e., with a "MUST NOT" there should be no "Otherwise" :-) The "MUST NOT" is probably a "SHOULD NOT" ? [Derek] It is a mistake. The "MUST NOT" here should be corrected as "SHOULD NOT"????? -- Section 5 -- Nice and interesting section, may I suggest to move it earlier in the document ? Just after the introduction for example. [Derek] Thanks! We will reflect this comment in the next version. Figure 6 does not have any node "A" or "B" while the § before mentions those node names. [Derek] Thanks! We will reflect this comment in Figure 6 in the next version. == NITS == I find it strange that some acronyms are sometimes expanded in the text *and* in the terminology (e.g., MTU) while others are not (e.g., PANC). [Derek] Thanks! We will reflect this comment in the next version. -- Section 3.3 -- Is "adapt" the right word in "For this reason, fragmentation and reassembly is required for G.9903-based networks to adapt IPv6." [Derek] Thanks for your comments, and we will find a better word. what about "implement"? -- Section 3.4 -- My eyebrows raised when reading "L2 routing"... as "routing" for me is usually reserved for layer 3 and above. [Derek] It refers to mesh under. We will modify the description. Thanks. -- Section 4.4 -- s/For IPv6 address prefix dissemination/For IPv6 network prefix dissemination/ ? [Derek] It should be "for IPv6 prefix dissemination". We will modify the description. Thanks. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
