Published as -12. Enjoy Thanksgiving ! > -----Original Message----- > From: Falendysz, Gene <gene.falend...@itron.com> > Sent: mardi 22 novembre 2022 17:44 > To: Pascal Thubert (pthubert) <pthub...@cisco.com>; fa...@wi-sun.org; > 6lo@ietf.org > Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast- > registration-11 > > Looks good. > > Gene Falendysz > Office:(864)718-6676 / Mobile: (864)723-1395 > > -----Original Message----- > From: Pascal Thubert (pthubert) <pthub...@cisco.com> > Sent: Tuesday, November 22, 2022 10:57 AM > To: Falendysz, Gene <gene.falend...@itron.com>; fa...@wi-sun.org; > 6lo@ietf.org > Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast- > registration-11 > > Hello Gene > > I recrafted a bit changing the default to 252 so the try plus the 3 > retries ensure that the TID leaves the straight part of the lollipop. > The meaning has not changed though, just clarification. > > > Does the below still work? - I added surrounding text to get the > complete > picture: > > " > * A new ARO Status is introduced to indicate a "Registration > Refresh > Request" (see Table 9). > > This status is used in asynchronous NA(EARO) messages to indicate > to peer 6LNs that they are requested to reregister all addresses > that were previously registered to the originating node. The NA > message may be sent to a unicast or a multicast link-scope > address > and should be contained within the L2 range where nodes may > effectively have registered/subscribed to this router, e.g., a > radio broadcast domain. > A device that wishes to refresh its state, e.g., upon reboot if > it > may have lost some registration state, SHOULD send an > asynchronous > NA(EARO) with this new status value. That asynchronous multicast > NA(EARO) 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. > > The TID field in the multicast NA(EARO) is the one associated to > the Target and follows the same rules as the TID in the NS(EARO) > for the same Target, see section 5.2 of [RFC8505]. It is > incremented by the sender each time it sends a new series of NS > and/or NA with the EARO about the Target. By default the TID > initial setting is 252. The TID indicates a reboot when it is in > the "straight" part of the lollipop, between the initial value > and > 255. After that the TID remains below 128 as long as the device > is alive. An asynchronous multicast NA(EARO) with a TID below > 128 > MUST NOT be considered as indicating a reboot. > > In an unreliable environment, the asynchronous multicast NA(EARO) > message MAY be resent in a fast sequence for reliability, in > which > case the TID MUST be incremented each time. If the sender is a > 6LN that also registers the Target to one or more 6LR(s), then it > MUST reregister before the current value of the TID and the last > registered value are no more comparable, see section 7.2 of > [RFC6550]. > > The multicast NA(EARO) SHOULD be resent enough times for the TID > to be issued with the value of 255 so the next NA(EARO) after the > initial series is outside the lollipop and not confused with a > reboot. A 6LN that has recently processed the multicast NA(EARO) > indicating "Registration Refresh Request" ignores the next > multicast NA(EARO) with the same status and a newer TID received > within the duration of the initial series. > > By default, the duration of the initial series is 10 seconds, the > interval between retries is 1 second, and the number of retries > is > 3. The best values for the duration, the number of retries and > the TID initial setting depend on the environment and SHOULD be > configurable. > " > > All the best > > Pascal > > > -----Original Message----- > > From: Falendysz, Gene <gene.falend...@itron.com> > > Sent: vendredi 18 novembre 2022 21:21 > > To: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org>; > > Pascal Thubert (pthubert) <pthub...@cisco.com>; 6lo@ietf.org > > Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast- > > registration-11 > > > > That sounds like it will work. Thanks for addressing our use case. > > > > Gene Falendysz > > Office:(864)718-6676 / Mobile: (864)723-1395 > > > > -----Original Message----- > > From: Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org> > > Sent: Friday, November 18, 2022 9:46 AM > > To: Falendysz, Gene <gene.falend...@itron.com>; Pascal Thubert > > (pthubert) <pthub...@cisco.com>; 6lo@ietf.org > > Subject: [EXTERNAL] RE: [6lo] WG Last Call on > > draft-ietf-6lo-multicast- > > registration-11 > > > > Oh! > > > > Well, at least there's text for that. The next paragraph is about > > incrementing the TID when resending, but not the way a real TID > > operates, quoting " > > In an unreliable environment, the multicast NA(EARO) message > may > > be resent in a fast sequence, in which case the TID must be > > incremented each time. A 6LN that has recently processed the > > NA(ARO) ignores the NA(EARO) with a newer TID received within > the > > duration of the fast sequence. That duration depends on the > > environent and has to be configured. By default, it is of 10 > > seconds. > > " > > > > Now that I think about it I should make it compliant with real TID > > operations (https://urldefense.com/v3/__https://www.rfc- > > editor.org/rfc/rfc6550*section-7.2__;Iw!!F7jv3iA!wbY9lpxIso9IuZ2- > > > gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2x > > r wNVr9LKz_KgE$ ) so the 6LN/LFN would figure it is no more in sync > > with the 6LR/FFN just because the two sequence numbers are determined > > not to be comparable. > > > > If that fits your need I can update the text in that direction, say > > that the 6LR sets the TID field in the broadcast NA(EARO) like it > > would for NS(EARO), following section RPL 7.2, that there should be > > several in a short time after reboot, and that the 6LN keeps track of > > the 6LR TID, and considers that he needs to reregister if the TID in > a > > new NA is not comparable. > > > > Would that help? > > > > Pascal > > > > > > > -----Original Message----- > > > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene > > > Sent: vendredi 18 novembre 2022 15:16 > > > To: Pascal Thubert (pthubert) > <pthubert=40cisco....@dmarc.ietf.org>; > > > 6lo@ietf.org > > > Subject: Re: [6lo] WG Last Call on > > > draft-ietf-6lo-multicast-registration-11 > > > > > > Hi Pascal, > > > The problem I am trying to solve is that currently Wi-SUN FAN is > > > specifying that once a node responds to a NA(EARO) (request to > > > reregister) it ignores all others for 5 minutes. This is to > minimize > > > flooding. The problem with that approach is that it is not uncommon > > > for a meter to experience several power cycles when reclosers are > > > trying to isolate a fault in the grid. The 5 minute ignore period > > > would mean that it is possible for a node to ignore a valid > request. > > I > > > am hoping that the TID can be used to indicate when the request is > > new > > > and not a repeat of the previous request, incrementing with each > > power cycle. > > > > > > Best regards, > > > > > > Gene Falendysz > > > Office:(864)718-6676 / Mobile: (864)723-1395 > > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) > > > <pthubert=40cisco....@dmarc.ietf.org> > > > Sent: Friday, November 18, 2022 6:09 AM > > > To: Falendysz, Gene <gene.falend...@itron.com>; 6lo@ietf.org > > > Subject: [EXTERNAL] RE: [6lo] WG Last Call on > > > draft-ietf-6lo-multicast- > > > registration-11 > > > > > > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6l > > > > o_ > > > > > > _;!!F7jv3iA!2dS7DeAq_Z8s7nFEQvpxqz9CB5Y0xD_qNKbFXdvDCZlojcAAwhaYzTc3 > > > > xI HLxzOK2fsFC0RdZQnaC06SZJTsmxKezgtL4lyvhas$ > > > > > > _______________________________________________ > > > 6lo mailing list > > > 6lo@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo_ > > > _;!!F7jv3iA!wbY9lpxIso9IuZ2- > > gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9 > > > D2MFMLzzuK5OFVpBEIDo6N8JdY2xrwNVr9Hugb8SQ$
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
