Hi Pascal, There is really misunderstanding here. I'll add explanation inline.
Best Regards, Guangpeng > -----Original Message----- > From: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org> > Sent: Tuesday, August 23, 2022 3:15 PM > To: Liguangpeng (Roc, Network Technology Laboratory) > <liguangp...@huawei.com>; Pascal Thubert (pthubert) <pthub...@cisco.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 again Guangpeng > > Seems that Michael and myself miss something in the address assignment then. > Maybe some text will help the next readers avoid that misunderstanding. > > Say you have this(fig 3 + some nodes) > > > root +--------------------------+ > 1 | append more bits to form > | > O ----+ | brother's address > | > / | \ \ +--------------------------+ > / | \ \ > / | \ \ \ > +---------+ / | \ \ \ > |forwarder| 10 / 11 110\ \ 111 \ XXX > |node | O - O O O O > +---------+/ |\ \ | \ | \ > / | \ \ | \ | \ > / | \ \ O O O O > / | \ \ > 100/ 1010| 101 1011 +--------------+ > O O O O |Prefix is '10'| > /| /| +--------------+ > / | / | > O O O O > 1001 10011 10101 101011 > > > And you add a core switch attached to root (XXX in the picture). How would > you name it? I guessed 1110 because that's what would happen if XXX was > present at the very initial time. Yes, correct. As per Figure 4 in the draft. > But when XXX is finally installed, 111 must already have a child, otherwise > why > should it be there? That child is already 1110, and then there's 1111 etc... 111 is a leaf address, which mean there cannot be child address at any time. In other words, nodes (except root) with address ending with '1' must have no subtree. So 1110 is must not child of 111, it only can be child of '1'(the root). We gave concrete example in the draft to explain how figure 4's algorithm works. See Page 8-9. > > So we have a collision for 1110. I (and I suspect Michael too) expected > renumbering so you get the same addresses whether XXX is plugged at T=0 or > later in the life of the network. > If you have a different plan please document it. As clarified as above, there wouldn't be collision any more. > > Now, say that for operational issues you need to unplug 1011 from 10 and plug > it to 11. Again, from my reading that's renumbering. What's the plan to avoid > it? > This is a reasonable case, but the target new parent is surely not 11. But it may be 110. We have moved solution of this case to another draft, see section 3.2 in https://datatracker.ietf.org/doc/draft-li-nsa-reliability/ . We expect people to input concrete requirements that cause topology change and make the solution work for that. > All the best, > > Pascal > > > > > -----Original Message----- > > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Liguangpeng (Roc, > > Network Technology Laboratory) > > Sent: lundi 22 août 2022 11:04 > > To: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org> > > 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 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
