Hi Pascal, As you raised before, the redundancy in network is a significant case for the addressing to solve. That's why we wrote another separate draft to discuss this in IETF 114. Multiple L2 MAC addresses may be a solution, but I can not see the whole view of it now.
I also support a permanent address perspective. The NSA is only an alternative to 'freely assigned IPv6 and compression after assign'. Both freely assigned IPv6 and IPv6 derived from NSA can be permanent identifier for a node. The difference is routing like mechanisms are need for NSA only when the topology changes. Comparison to it, routing is necessary all the time for freely assigned IPv6. So I'd like to think NSA is an option to optimize LOWPAN work, especially when the topology is relatively stable. Cheers, Guangpeng > -----Original Message----- > From: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org> > Sent: Tuesday, August 23, 2022 4:34 AM > To: Liguangpeng (Roc, Network Technology Laboratory) > <liguangp...@huawei.com> > Cc: Pascal Thubert (pthubert) <pthub...@cisco.com>; Michael Richardson > <mcr+i...@sandelman.ca>; 6lo <6lo@ietf.org> > Subject: Re: [6lo] Call for WG adoption of > draft-li-6lo-native-short-address-03 > > You read me wrong Guangpeng. > > I’m advocating for multiple NSA L2 addresses to reflect redundancy in the > network. > > And a single IP address that remains even if the network changes and maps all > the MAC addresses. > > The consequence is that the IP must not derive from MAC. > > > Though I agree with Michael that privacy for Ring’s case may not be an issue, > the device needs a permanent address and that cannot be one that depends > on the current topology. > > > Regards, > > Pascal > > > Le 22 août 2022 à 11:04, Liguangpeng (Roc, Network Technology > Laboratory) <liguangpeng=40huawei....@dmarc.ietf.org> a écrit : > > > > Hello Pascal, > > > > Please see inline. > > > > Best Regards, > > Guangpeng > > > >> -----Original Message----- > >> From: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org> > >> Sent: Monday, August 22, 2022 2:18 PM > >> To: Liguangpeng (Roc, Network Technology Laboratory) > >> <liguangp...@huawei.com> > >> Cc: Michael Richardson <mcr+i...@sandelman.ca>; 6lo <6lo@ietf.org> > >> Subject: Re: [6lo] Call for WG adoption of > >> draft-li-6lo-native-short-address-03 > >> > >> Hello Guangpeng > >> > >> If we take the DC sensors as use case and racks are organized in > >> trees, and you add a new rack then there will be renumbering. > > > > No, it doesn't. Just attach this new rack to existing racks and don't move > existing racks to this new rack meanwhile. The latter action is weird and > superfluous. > > > >> > >> This is why it’s safer to use this tech at L2. For the better and the > >> worse IoT standards happen to use the IP address as a node ID. I was > >> there when ISA 100 made that decision and I understand why. I see the > >> same arguments applying in list constrained environments. > >> > >> Now say that NSA is an L2 address or an L2.5 address. You get > >> redundancy by allowing a node to have more than one L2 address. > >> Renumbering is OK by reassigning Mac/IP matches - though it has to be > >> done carefully/transactional my as MACs are reassigned. > >> > > This is why the NSA mechanism try hard to avoid renumbering even sacrifice > the applicability of basic mechanism in wireless network. Here, NSA is part of > IPv6, hence it indeed a L3 address. So, I can not understand why NSA would > map to multiple L2 addresses. > > > >> Do it at L3 and you’re screwed. > >> > > BTW, I think derive IPv6 from L2 is not a reliable assumption considering > privacy issues and fake MAC problems. This is why we need develop a short L3 > address in 6lo. > >> > >> Regards, > >> > >> Pascal > >> > >>> Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology > >> Laboratory) <liguangpeng=40huawei....@dmarc.ietf.org> a écrit : > >>> > >>> Hi Michael, > >>> > >>> Thanks for the clarification. Please see below: > >>>> If I insert a new device in the tree, then all of the tree below > >>>> that device has to renumber. > >>> Technically saying, it may exist but it seems weird to insert a new > >>> device in > >> the middle of the tree. When a user wants a new device, a normal way > >> is append them to the network at the end of an existing rank. > >> Totally, you mentioned a topology change manually, for which we put a > >> sentence in Section 9 of the draft to hightlight this consideration. > >>> > >>>> I also think that it can happen if I add a new device to an existing > >>>> rank. > >>> No, as long as there is enough address for this new device. > >>> > >>> Cheers, > >>> Guangpeng > >>> > >>>> -----Original Message----- > >>>> From: Michael Richardson <mcr+i...@sandelman.ca> > >>>> Sent: Monday, August 22, 2022 12:07 AM > >>>> To: Liguangpeng (Roc, Network Technology Laboratory) > >>>> <liguangp...@huawei.com> > >>>> Cc: Alexander Pelov <a...@ackl.io>; 6lo <6lo@ietf.org> > >>>> Subject: Re: [6lo] Call for WG adoption of > >>>> draft-li-6lo-native-short-address-03 > >>>> > >>>> > >>>> "Liguangpeng (Roc, Network Technology Laboratory)" wrote: > >>>>> Thanks for share of Carpenter's draft. I fully agree with the > >>>>> content of it after a quick read. I think it's for all adoption > >>>>> process, not only for this adoption call. I believe 6lo Chairs' > >>>>> professional actions. > >>>> > >>>>> About the technical related concern: > >>>>>> One concern that I have with NSA is that I think the network can > >>>>>> get renumbered whenever there are new devices. > >>>> > >>>>> Can you explain a little more on how this problem happens? > >>>> > >>>> If I insert a new device in the tree, then all of the tree below > >>>> that device has to renumber. > >>>> I also think that it can happen if I add a new device to an existing > >>>> rank. > >>>> > >>>> > >>>> -- > >>>> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT > >> consulting ) > >>>> Sandelman Software Works Inc, Ottawa and Worldwide > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> 6lo mailing list > >>> 6lo@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lo > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
