Hello Gene: The intention in the TID is to sequence the mobility of the target address exposed in NS(EARO). NA (EARO) is supposed to respond unicast to the NS(EARO), or be used as an asynchronous response to that NS. IOW, this broadcast NA about target=self is new, and the fields have no specified meaning / behavior.
Certainly the expectation is that the TID field would still contain a TID associated with the target address, and I'll be happy to write that if you have a case. I did not see one so I just applied the "reserved" behaviour. Is it your intention that the TID is the same as in NA(EARO) and reflects a counter that the router maintains for its LLA? All the best; Pascal > -----Original Message----- > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene > Sent: jeudi 17 novembre 2022 15:44 > To: Pascal Thubert (pthubert) <pthub...@cisco.com>; 6lo@ietf.org > Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11 > > Hi Pascal, > In section 7.3 is this statement: > "That asynchronous NA(ARO) SHOULD be sent to the all-nodes link scope > multicast address (FF02::1) and Target MUST be set to the link local > address that was exposed previously by this node to accept registrations, > and the TID MUST be set to 0." > Why the "and the TID MUST be set to 0"? We need the TID to do duplicate > detection on the asynchronous NA(ARO). > In the metering world it is not uncommon for a node to power cycle several > times as reclosers try to isolate faults. > > Cheers, > > Gene Falendysz > Office:(864)718-6676 / Mobile: (864)723-1395 > > > _______________________________________________ > 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
