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 protected]> 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 protected]> >> 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 protected] >>>> Subject: I-D Action: draft-li-6lo-native-short-address-01.txt >>>> Date: 14 December 2021 at 09:33:51 CET >>>> To: <[email protected]> >>>> Reply-To: [email protected] >>>> >>>> >>>> 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 >> >> >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
