Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

["Liguangpeng (Roc, Network Technology Laboratory)" <[e-mail]>]

Dear Alexander,


I think the use case document in 6lo is adequate to record the scenarios. (see 4.1 in https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/ ) . For instance, the real world use case provided by Rong Long earlier in ML should be included by “Smart thermostats, air conditioning, and heat controls” item.



BTW, the NSA solution employs LOWPAN compression with some adaption due to adopting native short address. So some scenarios for 6lo are the target of NSA.



There should be more opportunities to discuss how NSA document works in real world after it’s adopted as WG item. After all,  who will care about an individual draft how to be used even it had been presented four times in IETF meeting, right? :-)

Cheers,
Alexander

From: Alexander Pelov <[e-mail]>
Sent: Saturday, August 20, 2022 9:05 PM
To: Liguangpeng (Roc, Network Technology Laboratory) <[e-mail]>
Cc: 6lo <[e-mail]>; Luigi IANNONE <luigi.iannone=[e-mail]>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Luigi IANNONE
Sent: Saturday, August 20, 2022 4:10 AM
To: Alexander Pelov <[e-mail]<mailto:[e-mail]>>; marinos charalambides <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Alexander Pelov
Sent: Friday, 19 August 2022 17:03
To: marinos charalambides <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
Sent: Monday, August 1, 2022, 7:58 AM
To: [e-mail]<mailto:[e-mail]>
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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6lo