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:[email protected]] > ·¢ËÍʱ¼ä: 2020Äê9ÔÂ2ÈÕ 17:54 > ÊÕ¼þÈË: Liubing (Remy) <[email protected]> > ³ËÍ: [email protected]; [email protected] > Ö÷Ìâ: 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 > > > _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
