Subject: Re: [6lo] I-D Action: draft-li-6lo-native-short-address-01.txt

From: Luigi Iannone <[email-masked]>
Date: Thu, 17 Feb 2022 09:25:30 +0100

Hi All,
 
A short follow-up on the progress of NSA.
 
As stated in my last email we are working on a simulation tool to evaluate NSA and compare it to other solution.
The work is progressing steadily and we registered to the hackathon @ IETF 113 
Please see: https://trac.ietf.org/trac/ietf/meeting/wiki/113hackathon <https://trac.ietf.org/trac/ietf/meeting/wiki/113hackathon>
 
Anybody interested is more than welcome to participate.
(and BTW we also welcome more feedback on the draft ;-) )
 
See you in Wien (in person or remotely)
 
Ciao
 
L.

> On 14 Jan 2022, at 15:38, Luigi Iannone <[email-masked]> wrote:
> 
> Hi Carles, Shwetha, 
> 
> Thank you for your email.
> Please find our answer inline.
> 
> Ciao
> 
> L.
> 
>> On 14 Jan 2022, at 13:43, Carles Gomez Montenegro <[email-masked]> wrote:
>> 
>> Hi Luigi, and rest of coauthors,
>> 
>> (CC'ing Pascal and Dominique, who made relevant comments in IETF 111.)
>> 
>> Thanks for the updated version of your draft.
>> 
>> We have a question related with your first point below, and also with the
>> scope of the document (and how it fits the scope of 6Lo):
>> 
>> - Do you envision NSA nodes would need to run a routing protocol at all? 
> [LI] No. NSA nodes do not need to run any routing protocol. If any topology change happens a simple local repair is possible and it is done as part of the discovery of the neighbors. Note that topology changes are a very rare event (see more below).
> 
> 
>> Would the forwarding techniques proposed in your draft be sufficient to
>> allow multihop packet transmission within the NSA domain?
> [LI] Yes, the allocation function proposed in the draft allow a simple and stateless forwarding.
> 
> 
>> 
>> On the other hand, in IETF 111 some concerns were expressed (based on an
>> earlier version of your draft), regarding possible (e.g. renumbering)
>> issues due to topology changes (e.g. due to the dynamics of wireless
>> links, even if nodes might actually be static). We understand that more
>> recent versions of the draft aim to address such issues.
> [LI] Absolutely right. Actually, the revision that we presented at IETF 112 already included a solution covering the rare case of topology changes (renumbering). And in the very last revision post IETF 112,  Pascal did help us in adding text that clarifies NSA applicability for networks that are rather stable, like for instance  PLC wired networks (where topology changes are part of a network maintenance  or upgrade, which is planned and  handled by the admins).     
> 
> 
>> - What do the WG participants who had those concerns (e.g. Pascal,
>> Dominique) think about the latest versions of the draft?  Would the issues
>> be addressed now?
> [LI] We hope so, but we are happy to solve any residual concern :-)
> 
>> 
>> - To the authors: perhaps a bit early at this stage, but do you have any
>> sort of validation (e.g. by simulation or even running code on real
>> devices) of your proposed mechanisms?
> [LI] Short answer is “almost” ;-) 
> We are working on a simulation tool in order to validate the proposal and quantify the benefits. Hopefully we will be able to show something at IETF 113 (finger crossed).
> 
> L.
> 
> 
> 
>> 
>> Thanks,
>> 
>> Shwetha and Carles
>> 
>> 
>> 
>> 
>>> Hi All,
>>> 
>>> We just submitted a new revision of the NSA document.
>>> Thanks for all the received feedback.
>>> 
>>> The main changes concern:
>>> 
>>> - Revising the text throughout the whole document to make clear that we
>>> talk about forwarding operation, not routing (previous text was
>>> misleading), hence completely in the scope of 6lo WG.
>>> 
>>> - Thanks lot  to Pascal T. (whom helped through a long private email
>>> exchange) the applicability of NSA has been clarified by adding text.
>>> Also, text has been added to clarify the properties of the allocation
>>> function, namely the fact that the proposed function is simple but not
>>> optimal and other optimized allocation functions can be developed in the
>>> future (hence the request to IANA to set up a registry for this purpose).
>>> 
>>> While we believe that the document is becoming mature, we still welcome
>>> any feedback people can send us.
>>> 
>>> Thanks
>>> 
>>> Ciao
>>> 
>>> L.
>>> (On behalf of all authors)
>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: [email-masked]
>>>> Subject: I-D Action: draft-li-6lo-native-short-address-01.txt
>>>> Date: 14 December 2021 at 09:33:51 CET
>>>> To: <[email-masked]>
>>>> Reply-To: [email-masked]
>>>> 
>>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> 
>>>> 
>>>>      Title           : Native Short Addressing for Low power and Lossy
>>>> Networks Expansion
>>>>      Authors         : Guangpeng Li
>>>>                        David Lou
>>>>                        Luigi Iannone
>>>>                        Peng Liu
>>>>                        Rong Long
>>>> 	Filename        : draft-li-6lo-native-short-address-01.txt
>>>> 	Pages           : 22
>>>> 	Date            : 2021-12-14
>>>> 
>>>> 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 topology is relatively static where nodes' location is
>>>> fixed and the connection between nodes is rather stable.  The changes
>>>> in the logical topology are only caused by non-frequent disconnection
>>>> in the link due to some reasons.  The specifications details NSA
>>>> address allocation, forwarding mechanism, header format design,
>>>> including length-variable fields, and IPv6 interconnection support.
>>>> 
>>>> 
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-li-6lo-native-short-address/
>>>> 
>>>> There is also an htmlized version available at:
>>>> https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-01
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-li-6lo-native-short-address-01
>> 
>> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 17 Feb 2022 11:11:09 +0100

On 2021-12-14, at 10:09, Luigi Iannone <[email-masked]> wrote:
> 
> While we believe that the document is becoming mature, we still welcome any feedback people can send us.

I haven’t read the new version, but I stick with the observation that the problem/opportunity addressed is already solved with 6lo header compression (and will be more so once we have SCHC header compression in 6lo), and NSA does not have the same desirable properties with respect to preserving IPv6 semantics that the header compression solutions have.

Right now, I would like us to focus on making the SCHC solution really good.
In the end, that may not look very different on the wire from NSA (as far as addresses are concerned — SCHC of course can do more).

Grüße, Carsten

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 17 Feb 2022 13:08:56 +0100

Hi Carsten,

Thanks for your mail.
Please see inline.

Ciao

L.

> On 17 Feb 2022, at 11:11, Carsten Bormann <[email-masked]> wrote:
> 
> I haven’t read the new version,
You should. We did a lot of improvements ;-)

> but I stick with the observation that the problem/opportunity addressed is already solved with 6lo header compression (and will be more so once we have SCHC header compression in 6lo),
Yes, the 6lo header compression is suitable in general for all IoT scenarios. However, this draft is targeting at scenarios and applications with static network topology and stable network connections. 
In those cases, the NSA could bring in even shorter packet header (addressing) and _more_ importantly much simpler (stateless) forwarding mechanism, which will further saves the power consumption of the IoT system.

> and NSA does not have the same desirable properties with respect to preserving IPv6 semantics that the header compression solutions have.
Can you articulate a bit more? Exactly which “desirable property” is present in HC but not in NSA.
I can provide an example of the other way around, NSA provides stateless forwarding, HC does not do that.
The new version of the document (read it :-) ) provides all the details on the operations to be performed on the gateway to translate from NSA to IPv6 and vice versa. 

> Right now, I would like us to focus on making the SCHC solution really good.
I am also willing to help, but one does not exclude the other...

> In the end, that may not look very different on the wire from NSA (as far as addresses are concerned — SCHC of course can do more).
We are coding the simulator exactly to quantify the differences. In certain scenarios NSA provide some advantage.
But do not forget the second important property: stateless forwarding, we believe it is not negligible.

Ciao

L.