Dear Guangpeng, I'm sorry that the subject is becoming too long to read. However, the issues are still not resolved, and I do think that answering them properly requires taking the whole question, with its history.
In any case, I think that at this point it is clear that a revised document is necessary. Take the necessary time with your co-authors to write a new version and if you need feedback I'll be happy to provide one. I think Pascal is proposing a good way ahead. Best wishes, Alexander On Thu, Aug 25, 2022 at 6:04 AM Liguangpeng (Roc, Network Technology Laboratory) <liguangpeng=40huawei....@dmarc.ietf.org> wrote: > Hi Alexander, > > > > For it is hard for me to trace your discussion, let me list the still open > questions you think here and give some response here. If I lost some, > please raise it. Thanks. > > > > > For me, the prerequisite of any work is the "why". Why is this > technology being developed? Why this choice and not this other one? > > > Without this justification and without use-case, this remains an > academic work. And academic work can be amazing and extremely useful, but > not in the context of 6lo. > > > > I think this email in adoption thread gave a use case. > https://mailarchive.ietf.org/arch/msg/6lo/u5diBHkb8ItQKpXT91f8hng6cok/ . > > > > > 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). > > > > Good question. I have my own understanding of inefficiency cause by extra > hops. I think administrator of network will design the topology according > to the use case. But not forming topology by the technology applied. So if > you want to apply NSA to a huge start topology, please define new AF > function. Just like people need to optimize routing algorithm according to > specific topology. This thought is described in page 10 in the draft. > > > > > Consider the following trivial case, in which you have 100 nodes > connected one after the other: > > > root <-> 1 node <-> 1 node <-> 1 node <-> ... <-> 1 node > > > > Good question too. I think this may be normal topology in lpwan, but it’s > really hard for NSA to get benefit from this topology’s solutions, though > again the specific AF can be designed to work on this topology. > > > > All for all, I think the NSA draft has addressed all fatal issues in the > area it claims. And of course it’s ready for adopted. I also welcome more > interests on using NSA in more areas. Thanks again for review our draft and > raise so valuable questions. > > > > Best Regards, > > Guangpeng > > > > *From:* 6lo <6lo-boun...@ietf.org> *On Behalf Of *Alexander Pelov > *Sent:* Wednesday, August 24, 2022 6:01 PM > *To:* Luigi IANNONE <luigi.iann...@huawei.com> > *Cc:* marinos charalambides <marino...@gmail.com>; 6lo@ietf.org > *Subject:* Re: [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > > > Hi Luigi, > > > > Thanks for the replies! > > > > However, I consider that almost all of the points I raised were left for > later and were not properly addressed. > > When I say "properly addressed", I mean having a more-or-less specific > answer on the substance of the raised question. > > An answer of the type "we'll need to rewrite the section / draft" is good, > in the sense you accept that there is something to be done. This, for me, > means that the questions are still open. > > > > At this point, there are multiple open questions, which are fundamental in > terms of justification, application and operation. > > > > I think the draft needs a major revision which addresses all open > questions, before it can be reconsidered for adoption. > > > > See inline below for detailed follow-up on your answers. > > > > > > On Tue, Aug 23, 2022 at 5:25 PM Luigi IANNONE <luigi.iann...@huawei.com> > wrote: > > Hi Alexander, > > > > Thanks for your reply. > > My detailed comments are inline. > > > > *From:* Alexander Pelov <a...@ackl.io> > *Sent:* Saturday, 20 August 2022 14:47 > *To:* Luigi IANNONE <luigi.iann...@huawei.com> > *Cc:* marinos charalambides <marino...@gmail.com>; 6lo@ietf.org > *Subject:* Re: [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > > > Hi Luigi, > > > > Thanks for your mail! > > See inline. > > > > > > On Fri, Aug 19, 2022 at 10:09 PM Luigi IANNONE <luigi.iann...@huawei.com> > wrote: > > Hi Alexander, > > > > Thanks for your feedback. Please send us the tons of questions you have we > will do our best to answer them. > > > > Thank you for providing some initial reactions to my questions. > > Most of them do remain open, however. > > > > *[LI] I never claimed the contrary.* > > > > > > Yes, we agree here. > > > > > > > > > > > > > > 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. > > > > > > I am sorry, but I have to disagree here. > > There is no clear objective (use-case with specific technical description > and justification that allows us to evaluate this proposal vis-a-vis > 6LoWPAN for example) and as such, no way to achieve rough consensus on > tradeoffs that will have to be made at some point in the future. > > > > *[LI] So we agree to disagree. Certainly there is work to be done to > clarify the use-cases and the applicability scope, but IMO there is enough > meat to decide whether to adopt it or not.* > > > > > > For me, the prerequisite of any work is the "why". Why is this technology > being developed? Why this choice and not this other one? > > Without this justification and without use-case, this remains an academic > work. And academic work can be amazing and extremely useful, but not in the > context of 6lo. > > > > If this work is to be adopted, then it needs to start at the "why". > > I agree with you, in terms of decision - there is no "why" -> for me, the > document cannot be adopted as it is. > > > > > > 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. * > > > > > > This is the only justification provided in the text for this work. > > I think you will need to carefully address this issue in your next version > of the draft, because if there is no justification, then this is a solution > looking for a problem to solve. > > > > *[LI] As stated above we will improve this part.* > > > > > > > > Thank you! > > The core question remains, however, and is a fundamental one. > > > > > > > > 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. > * > > > > > > I've read the high-level descriptions provided in this thread, but none of > them gives any technical reason why there is something to be done. > > How many nodes per deployment? What typical density? Shared medium or not? > Is there Broadcast or not? Duty-cycled radios, Time-slotted, LBT, ... ? > Battery-operated devices or not? What are the operational requirements for > the network - convergence time, failure detection, etc.? How constrained > are the devices in terms of processing power, RAM, etc.? > > This is a non-exhaustive list here, and all these questions are related to > specific design decisions that need to be made for your proposal to be > deployed. > > > > *[LI] You are listing things that are not necessarily pertinent here.* > > > > > > Which one do you consider to be not pertinent? I could think of at least > one example, where some of this (non-exhaustive) list of characteristics of > a network can render a protocol a good or a bad fit for a network. > > > > In any case, the question remains open - in order to understand if what > you are proposing has any benefit, you need to describe the setup. > > > > > > > > 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.)* > > > > The "expected gains" is related to the use-case and the problem you need > to solve. I think before getting into a years-long cycle of > standardization, we need to know if the proposal at hand is something that > cannot be readily achieved by other, already existing ways. RPL was just > the first thing that popped into my mind. I found it strange that no > references and comparisons are given to other routing solutions. > > > > *[LI] I consider my previous answer still valid. We mentioned the benefits > of NSA, we can certainly improve the text. * > > > > > > It's all about trade-offs. > > If you don't have a clear goal to optimize for, it is not clear if a > trade-off is a benefit or a drawback. > > > > > > > > *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. * > > > > > > So, then there is no benefit from the NSA compression? > > Can we then just remove this whole part and stick to the forwarding? > Actually it already feels like the core of the work is mostly on > the forwarding part. > > > > *[LI] I do agree that the text should be updated focusing more on the > stateless forwarding. Compression comes along but is comparable to what is > already existing in terms of size (and in some scenarios is worse). * > > > > > > Ok, this sounds like a major rewrite that needs to take place before > adoption. > > > > > > > > > > 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.* > > > > > > I think it is important to underline that any potential efficiency gains > can disappear in dense networks (> 63 nodes). > > > > *[LI] Why so? The stateless forwarding remains.* > > > > I was under the impression you want some kind of efficiency in terms of > less bytes over the wire. > > > > If you don't care about additional traffic generated by superfluous > message forwarding, then you may be right. > > > > Here I can only say that having additional hops between direct neighbors > seems like a huge inefficiency to me. > > > > > > > > > > Also, this is one of the use-cases you have mentioned as justification of > the draft - PLC, primarily used for Smart Metering. > > > > > > 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.* > > > > So, here the problem is of a different nature. > > The lifetime in 6LoWPAN-ND, and in turn the "Expected Address Lifetime", > is when the child confirms to the parent it has selected - "I'm choosing > you". > > The problem I was pointing out, is that all OTHER potential parents > reserve an address, and they never get any message that they were not > selected. > > > > *[LI] Fair enough, but solving it is no brainer, we can start with a > simple timeout. Yes, it needs to be defined, but this is not a technical > showstopper.* > > > > I don't know if a timer is the appropriate solution. There definitely > needs to be one, but would that be enough to solve this address > saturation? In dense networks a simple timeout will not be enough. > > It depends on the use-case then.. but once you've clarified that out, you > could indeed address this issue much more easily. > > > > > > Given that a node can have a limited number of children (max 63, and gets > lower at every level of the tree), allocating an address and keeping it > indefinitely locks out this particular address from allocating it to > another potential child. > > > > > > 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.* > > > > This is a counter-example of a use-case the draft mentions as applicable > (PLC). If it is not applicable, please remove it from the draft. > > > > *[LI] I have the impression that you assume a specific PLC deployment > which is not necessarily the deployment where NSA shines.* > > > > > > In which PLC deployments does the NSA shine? > > Smart Metering is the major use-case for PLC IOT devices. If it is not > applicable, I think you'll need to explicitly state it. > > > > > > > > Furthermore, even if the storm problem is a problem for everyone, it is a > particularly horrible problem to NSA, because the way addresses are formed. > > > > *[LI] The sentence above is not supported by example below. 2^64 neighbors > can be a huge storm… * > > > > The point here is that 6LoWPAN does not create artificial hops, because of > the way IPv6 addresses are allocated. > > NSA does. > > > > > > In 6LoWPAN the root could have up to ~2^64 neighbors, so after the "storm" > settles, the root can have one-hop communication to all of its neighbors. > > In NSA, the root could have only up to 63 children. And each of them could > have only up to 62 children. BUT, as all of them are neighbors to each > other, a lot of the 63 children will allocate addresses to the same nodes.. > so you will end up with a topology of a ROOT <-> 63 direct children <-> 5-6 > children per node <-> 5-6 children per node <-> ... > > So not only will the NSA take a long time to converge, it will potentially > create 3-4-5-6..-20 hops between the root and its direct neighbours. > > > > *[LI] Big networks will take anyway a long time to converge. You are not > providing any argument that shows that NSA is worse. You are also mangling > two different issues, the path length and neighbor discovery. The former > may happen but it does not mean it happens all the time, the latter is > (again) not specific to NSA. * > > > > Maybe time to converge is a secondary point, maybe not. I can't tell, as I > don't know to which use-case NSA is aimed. > > Both convergence and address allocation blocking are intertwined in NSA. > There's a trade-off to be made. > > > > A path length of several hops between direct neighbors is certainly not > something I have seen other protocols do. > > So, that would be a unique and significant disadvantage of NSA. > > > > In the current state of NSA, it will happen ALL the time there are more > than 63 neighbors. > > It simply CANNOT address more than 63 direct children of the same type > (forwarders/leafs). > > So all other neighbors will HAVE to have a parent, which is not the root.. > so additional superfluous hops. > > > > > > Which actually brings another significant new issue here: > > After the allocation, one of the children of the root will end up with an > address 64 bits long. That means it cannot have any children of its own. > This could lock-out entire subsets of the network! > > > > In fact, under optimal topology and optimal allocation in a network with > forwarder nodes, you can address no more than 2016 nodes in the network. > > > > But it could be worse... much worse. > > Consider the following trivial case, in which you have 100 nodes connected > one after the other: > > root <-> 1 node <-> 1 node <-> 1 node <-> ... <-> 1 node > > > > You cannot address more than the first 63 nodes. Everything else is > unreachable. > > > > > > > > > > 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.* > > > > > > Ok, so that other draft opens so many doors.. so much complexity. Multiple > parallel trees, Message tunneling, etc. Also, it seems to me that you'll > need the Root to know the entire topology for the message tunneling to > work, which I did not see as a requirement for the baseline NSA draft. > > As we do not have any specific characteristics at which NSA is aimed, we > have no way to make decisions. Should you choose Multiple Parallel Trees, > and if so - how many? etc. etc. > > > > *[LI] Fair question to be discussed in the context of the reliability > document.* > > > > These need to be answered, so that NSA is considered as a workable > solution. > > That for me strengthens the case of considering the two documents together. > > > > > > > > I appreciate that you have done an interesting job to outline several > possibilities. > > However, it seems to me that the NSA Reliability draft is of a greater > complexity than this one, and either you need to include one mechanism in > the draft that will be accepted as a WG item, or both should be voted at > the same time. > > > > *[LI] Or we can analyze the trade-offs of the different options and make a > recommendation in the reliability document.* > > *One of the reason why we choose to have a separate document is that at > this stage we are not sure there one solution that can apply in all NSA > scenarios.* > > > > > > You need to first define the scenarios and use-cases, and then apply the > solution to them. > > > > This makes it even clearer to me that you'll need to provide one single > document, which has the scenarios, use-cases AND the reliability part > already integrated. > > > > > > > > > > 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.* > > > > > > Some of the technical questions remain open. The design of the addressing > puts on its own a very strong constraint on the types of deployment. > > > > *[LI] We never claimed something different and Pascal helped in drafting > the applicability scope (which we will rework).* > > > > I'd be happy to reread it in its reworked version. > > > > > > I don't think I have to go through all possible scenarios and find if NSA > has tangible benefits or not. That would be the authors' work. > > > > *[LI] We do not need either to go through all possible scenarios where NSA > is not the best fit (personally I do not see the usefulness). * > > *Even BGP has been proved not to converge in all scenarios and still…* > > > > *The draft does not claim to be a general solution aiming at replacing > existing solutions.* > > *What it says is that in some scenarios (to be better defined) the > solution may bring benefits and it remains compatible with existing > solutions.* > > *(One of the things I would like to do is to define how to use SCHC > context to define a NSA domain.)* > > > > Using SCHC would be the right direction for me, in terms of getting the > compression part clean. > > > > > > *Certainly there is clarification work to be done to improve the text and > fix some points, but nothing unsolvable. * > > > > *Ciao* > > > > *L.* > > > > > > Cheers, > > Alexander > > > > > > > > > > > > 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. * > > > > > > Ok, so to sum up - "few counter examples", "no benefits from the NSA > compression", increasing complexity, almost nonexistent justification, and > use-cases that need to be defined. > > > > The problem is not the volume of the work. It's everything else, plus the > fact that it will require significant work. > > > > Cheers, > > Alexander > > > > > > > > *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 >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
