Dear Guangpeng, Thanks for your reply!
I'll start with what I wrote earlier - it is important to define which scenarios/use-cases are the goal of this draft, and what are the benefits for these scenarios/use-cases. The analysis you provide is interesting, but I cannot really connect it to the real deployment that is expected. I'd be happy to discuss specific scenarios/use-cases that come from a real-world need. In any case, I think these are required before accepting the draft as a WG item. Thanks Guangpeng for your mail! Cheers, Alexander On Sat, Aug 20, 2022 at 4:00 AM Liguangpeng (Roc, Network Technology Laboratory) <liguangp...@huawei.com> wrote: > Hi Alexander, > > > > Thank you for reviewing our draft so detailed, it’s indeed helpful. Above > Luigi’s reply, just complement some points on technical section. > > > > About the address length, I think you fully understand this draft, and you > should know that the average length of all packets’ header is significant, > but not the longest ones. To demonstrate the average length of this draft, > I made a presentation during IETF 113( > https://datatracker.ietf.org/meeting/113/materials/slides-113-6lo-native-short-address-for-lln-expansion-demo-00 > ). Hope this helps to understand. > > > > About the inefficiency in your raised counter examples, that may be issues in > wireless network due to lack of management of topology. For most of wired > networks, administrators can plan the topology in advance according to scale > of network(here tree topology is best for NSA). Even if the line topology is > employed, the NSA approach can adopt suitable allocation function to achieve > efficiency. In the draft, we only give the default allocation function in > order to make the draft clear. But we leave a sentence to state “The > Allocation Function can be different from the one defined in Figure 4, but > all nodes know which one to use by configuration. The use of one and only > one AF is allowed in an NSA domain.” If the line topology is important and > you are interested in this part, I am pleasure to collaborate with you on a > new separate draft to standardize new allocation function. > > > > Cheers, > > Guangpeng > > > > *From:* 6lo <6lo-boun...@ietf.org> *On Behalf Of *Luigi IANNONE > *Sent:* Saturday, August 20, 2022 4:10 AM > *To:* Alexander Pelov <a...@ackl.io>; marinos charalambides < > marino...@gmail.com> > *Cc:* 6lo@ietf.org > *Subject:* Re: [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > > > Hi Alexander, > > > > Thanks for your feedback. Please send us the tons of questions you have we > will do our best to answer them. > > > > In general I think that the concerns that you are expressing can be solved > during the normal life cycle of a draft as a WG item. > > > > A few more specific comments inline. > > > > Ciao > > > > Luigi > > > > *From:* 6lo <6lo-boun...@ietf.org> *On Behalf Of *Alexander Pelov > *Sent:* Friday, 19 August 2022 17:03 > *To:* marinos charalambides <marino...@gmail.com> > *Cc:* 6lo@ietf.org > *Subject:* Re: [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > > > Dear all, > > > > I have a lot of questions and some serious issues with the applicability > and the general description of the solution. > > *So, there are two reasons for which I am against adoption of this > document.* > > > > *Justification and use-case* > > In terms of the positioning of this draft and justification of the work, > both 6LoWPAN and SCHC are cited. Yet, the only justification of why this > new work was proposed is "there could be more simplified solutions". > > I'd say that firstly there is no proof in the draft that the proposed > solution is simpler. As far as I can understand the draft, it is heavily > underspecified, so knowing its full complexity is difficult at that time. > Plus, what is "simpler"? > > > > *[LI] I agree that the text is unclear and misleading. We will revise this > part of the text making sure there is no benefits overclaiming. * > > > > > > Secondly, which are the use-cases and the justifications that cannot be > met by the currently existing solutions? I have a difficulty with the > notion of ""topology is static, where nodes' location is fixed, and the > connection between nodes is also rather stable.". PLC or wireless, the > channel is fluctuating, conditions change, devices restart, or go offline.. > Unless you have point-to-point links, in which case you rarely care about > compression (unless in LPWANs where you have SCHC). The claim is that > "generic IOT solutions" can be improved, but in this document there are no > examples of what specific use-case would benefit, e.g. what size (number of > nodes, size of the tree, etc.). > > > > *[LI] This thread contains a few emails referring to use-cases. Those > might not be relevant to you, but they are for those who posted the emails. > * > > > > > > Given that the draft deals heavily with forwarding as well, I think a > comparison with RPL should also be provided, along with the expected gains. > Why can't we have an Objective Function that defines Tree-like behavior, > and let RPL solve the routing? > > > > *[LI] The document never claims that NSA solve problems that cannot be > solved in other ways. Yes, you can do a lot of things with RPL. It does not > mean that it has to remain the only solution given that IMO there are a few > people here that are interested in this alternative solution.* > > *As for the comparison with RPL, that is more of an academic approach that > a real requirement for a draft. * > > *(Your question is valid and hopefully, with a bit more time we will be > able to publish an academic paper on the topic.)* > > > > *Technical* > > On the technical side, I have a ton of questions and remarks, > > > > *[LI] Please send them to us. * > > > > > > but I'll start with the most obvious ones (please correct me if my > understanding is wrong): > > The short addresses in your packet format may take 1 byte, 3 bytes (1 to > indicate 2B for the short address), 5 bytes (1 to indicate 4B for the short > address) or more. By looking at the way short addresses are allocated, we > will get in the 3B range after only 8 children, and will get in the 5B > range after only 16 children. This to me is comparable to what 6LoWPAN does > from the beginning. > > > > *[LI] Yes it is comparable, which makes NSA no less good. * > > > > > > Given the restriction of 64 bits for the size of short addresses, and the > forwarding algorithm, you can have only 63 child nodes of a parent node. > That means, that if you have 100 neighbor nodes (say, one Border Router and > 99 devices in a datacenter, which may directly reach the BR), your > algorithm will artificially introduce 1 hop, so that there is a forwarder > which can provide addresses to the ones beyond the first 63. That seems > like a very serious inefficiency, which completely negates any potential > gains (which are there only for the first 8 children). > > > > *[LI] The draft never claim to be the best solution in any scenario > (beside, note that you just did give a use-case….).* > > *There are other scenarios where NSA definitely is not the best fit, it > does not make the whole solution technically invalid. * > > *You just provided one possible counter example.* > > > > > > > > Bootstrapping the network is underspecified. When a forwarding node > receives an AR (Address Request), it will allocate an address, send the > Address Assignment (AA), and keep this allocation for how long? > > > > *[LI] NSA leverages on 6LOWPAN-ND, and includes an explicit “Expected > Address Lifetime”. Please have a look and send any concern you may have.* > > > > Given that the child node may have selected another parent node, this > needs to be handled in some way. In a PLC network, you can have hundreds of > Smart Meters around a Data Concentrator. There is a storm of AR in the > beginning, and the first 63 forwarders will get their allocation from the > root, but the next hundreds will each allocate slots in the addressing list > of the first ones that got addresses.. and so forth and so forth. You'll > need to run simulations here, but I think it is a real danger that the > network will end up with a huge depth, and lots of > allocated-but-unused addresses high on the tree. > > > > *[LI] The storm problem above is not specific to NSA. Can happen with > other technologies. This is again a single counter example that does not > make NSA technically invalid.* > > > > The draft does not address any topology change scenario. Moving subtrees > around a tree needs to be handled in some way or other. What happens if a > node restarts, then requests an address and obtains a different parent? How > would it indicate to its children (which it doesn't know anymore, by the > way), that they need to get new addresses? And how does it indicate that > change to the Border Router (root), which MAY have some External IPv6 > addresses mapped to the short addresses in the network? And so on. > > > > *[LI] That is correct and the topic is so important that we prepared a > different document discussing exactly these points.* > > *I would really appreciate your feedback on that one.* > > > > > > All in all, I have listed some of the important technical problems I see > for the moment. > > > > *[LI] I would rephrase the above as “a few counter example where NSA is > not the best solution”, I do not see important technical drawbacks in your > email.* > > > > > > But even before solving all of them - what would be the justification of > this significant work that needs to be handled by the WG? > > > > *[LI] I am not sure I understand the question. Are you saying that there > so much to do that the WG should not do it? * > > *It looks a bit awkward since adoption should be driven on something else > that work volume IMO.* > > *Beside I have the impression a few here are ready to do it. * > > > > *Ciao* > > > > *Luigi* > > > > > > Cheers, > > Alexander > > > > > > > > > > On Fri, Aug 19, 2022 at 2:25 PM marinos charalambides <marino...@gmail.com> > wrote: > > Hello, > > > > I would also like express my support for the adoption of this draft as it > provides a better solution for wired IoT applications as stated in the 6lo > use case draft. > > > > Thanks, > > -Marinos > > > > > > On 16 Aug 2022, at 03:08, Kiran Makhijani <kiran.i...@gmail.com> wrote: > > Hello, > I have quickly skimmed through the document and would like to see this > work progress. > > I see that the focus is mainly on wireless constrained devices, however, > in industrial networks with field devices it is useful to have short and > variable addressing schemes on a factory floor. Variable addressing > approach is more interesting here because, on one side the controllers may > use IPv6 addresses and field-devices on the other end can very well be > shorter addresses. > > I support this document and wouldn't mind contributing to the alignment > with above mentioned scenario. > > Cheers, > > Kiran > > > ------------------------------ > > *From:* Carles Gomez Montenegro [mailto:carle...@entel.upc.edu > <carle...@entel.upc.edu>] > > *Sent:* Monday, August 1, 2022, 7:58 AM > > *To:* 6lo@ietf.org > > *Subject:* [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > > > Dear 6lo WG, > > > > This message starts a call for WG adoption for > > draft-li-6lo-native-short-address-03. > > > > (Link below: > > https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03) > > > > Considering that some folks may be on vacation currently or in the next > > few days, the call will end on the 22nd of August, EOB. > > > > Please state whether you are in favor of adopting this document. > > > > Also, any comments you may have, and/or expressions of interest to review > > the document, will be very much appreciated. > > > > Thanks, > > > > Shwetha and Carles > > > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo > > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
