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-gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2xrwNVr9LKz_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
