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

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Mon, 18 Oct 2021 13:11:41 +0000

Hi all,
Thanks for feedbacks from Pascal, Dominique, Carles and others. After we (three new authors and I) discussed the solution (original draft is draft-li-native-short-address-00) after communicating with Pascal and Carles, some significant modifications were made.

First of all, the document clarifies that NSA is suitable for Low power and Lossy Networks and every NSA node may be aware of IPv6 address of them. So the NSA technology fall into the scope of 6lo working group. 

Secondly, in this document, we generalized the address allocation function definition and added description of '4.1 NSA addresses and IPv6 Addresses' and 'Limitation of Number of Children Node'. Those should be sufficient to distinguish the NSA allocation from algorithms like IEEE 802.15.5 and its variants. 

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.

We also modify IANA part to apply for new registry and ICMP NSA control message. Considering lacking of large bulk of dispatch type space in page 0&1, we suggest to apply for dispatch type values in Page 10. 

Please have a look at this document and do not hesitate to reply here if you have comments

Best regards,
Guangpeng

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, October 18, 2021 9:00 PM
To: Zhe Lou <[email-masked]>; Liguangpeng (Roc, Network Technology Laboratory) <[email-masked]>; Luigi IANNONE <[email-masked]>; Peng Liu <[email-masked]>; Zhe Lou <[email-masked]>
Subject: New Version Notification for draft-li-6lo-native-short-address-00.txt

A new version of I-D, draft-li-6lo-native-short-address-00.txt
has been successfully submitted by Guangpeng Li and posted to the IETF repository.

Name:		draft-li-6lo-native-short-address
Revision:	00
Title:		Native Short Addressing for Low power and Lossy Networks Expansion
Document date:	2021-10-18
Group:		Individual Submission
Pages:		21
URL:            https://www.ietf.org/archive/id/draft-li-6lo-native-short-address-00.txt
Status:         https://datatracker.ietf.org/doc/draft-li-6lo-native-short-address/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address

Abstract:
   This document specifies mechanisms of NSA (Native Short Address) that
   enables IP packet transmission over links where the transmission of a
   full length address may not be desirable.  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).  The specifications include NSA allocation, routing
   mechanisms, header format design including length-variable fields,
   and IPv6 interconnection support.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2021 09:48:44 -0400

"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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Liguangpeng (Roc, Network Technology Laboratory)" <[email-masked]>
Date: Fri, 29 Oct 2021 12:58:46 +0000

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.

> 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.

> 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

> From: Michael Richardson <[email-masked]>

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

> To: [email-masked]; Liguangpeng (Roc, Network Technology Laboratory)

> <[email-masked]>

> Subject: Re: FW: New Version Notification for

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

> 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.

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

> during

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