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
