Re: [6lo] FW: New Version Notification for draft-li-6lo-native-short-address-00.txt

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

Hi Michael,

Thanks for your comments. Please see reply prepending with [G. Li].



> but since this is yet another constrained network protocol, are there commitments to write code?

> For OpenWSN, Contiki-NG, RIOT-OS, Linux, *BSD, FreeRTOS,  Thread...?

[G. Li] We are working on a sample code on Contiki, a version on Linux is in our plan.



> I see in your draft that you have comparison against current 6lowpan, and that it is a few bytes shorter, but I didn't yet read deep enough to understand how often it is shorter, and if there were cases that were simply not supported, or if they wind up longer.

[G. Li] I took an sample topology from a paper(Fig. 1 in https://ieeexplore.ieee.org/document/5971218 ). If I try to allocate NSA for that topology, we can get result shown in following picture. As we can see that the longest addresses take 6 bits each. In this typical case, we can achieve packet header (as described in Figure 2 of NSA document) and it’s shorter than 6lowpan.

[cid:image002.png@01D7CD07.C22AD0D0]



> I see the bit pattern at the beginning that means it could operate in the same network as 6lowpan, but it seems that every node that forwards will need to understand the new format before it can be turned on.

[G. Li] By this version, we decide to apply for a whole page (IANA section in this document & rfc8025), so it Should be a new protocol than LOWPAN. They will not operate in the same network except gateways exist.



> I'm unaware of a large need to renumber.

> Maybe that's a result of lack of IPv6 deployment.

[G. Li] As described in Abstract " This document focuses on carrying IP packets across a LLN (Low power and Lossy Network), in which the nodes' location is fixed and changes in the logical topology are caused only by unstable radio connectivity (not physical mobility).", we designed a complement routing solution other than renumbering the nodes for 'logical topology change'.



Thanks again for the comments. Please let me know if there are further questions.



Regards,

Guangpeng Li



> -----Original Message-----

> From: Michael Richardson <[e-mail]>

> Sent: Wednesday, October 27, 2021 9:49 PM

> To: [e-mail]; Liguangpeng (Roc, Network Technology Laboratory)

> <[e-mail]>

> Subject: Re: FW: New Version Notification for

> draft-li-6lo-native-short-address-00.txt

>

>

> "Liguangpeng (Roc, Network Technology Laboratory)" asked me to review

> draft-li-6lo-native-short-address-00 and to post to 6lo.

>

>     > update the draft a lot and get support from China Mobile.

>

> but since this is yet another constrained network protocol, are there

> commitments to write code?

> For OpenWSN, Contiki-NG, RIOT-OS, Linux, *BSD, FreeRTOS,  Thread...?

>

> I see in your draft that you have comparison against current 6lowpan, and that

> it is a few bytes shorter, but I didn't yet read deep enough to understand how

> often it is shorter, and if there were cases that were simply not supported, or if

> they wind up longer.

>

> I see the bit pattern at the beginning that means it could operate in the same

> network as 6lowpan, but it seems that every node that forwards will need to

> understand the new format before it can be turned on.

>

> It seems really late in the day for a new mechanism.

>

>     > Thirdly and most importantly, to avoid drawbacks brought by

>     > renumbering, we added a new mechanism to avoid the renumbering

> during

>     > the topology change, by adding/updating routing entries along the

>     > affected path. The cost is comparable with the local repair of

>     > RPL. Routing related procedures is refined according to this design,

>     > see Section 5, 6 and 8.

>

> I'm unaware of a large need to renumber.

> Maybe that's a result of lack of IPv6 deployment.

>

> --

> Michael Richardson <[e-mail]<mailto:[e-mail]>>   . o O ( IPv6 IøT consulting )

>            Sandelman Software Works Inc, Ottawa and Worldwide

>

>

>