Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
> Sent: vendredi 18 novembre 2022 21:21
> To: Pascal Thubert (pthubert) <pthubert=[e-mail]>;
> Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> 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:[phone] / Mobile: [phone]
> 
> -----Original Message-----
> From: Pascal Thubert (pthubert) <pthubert=[e-mail]>
> Sent: Friday, November 18, 2022 9:46 AM
> To: Falendysz, Gene <[e-mail]>; Pascal Thubert
> (pthubert) <[e-mail]>; [e-mail]
> 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-
> gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2xr
> 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 <[e-mail]> On Behalf Of Falendysz, Gene
> > Sent: vendredi 18 novembre 2022 15:16
> > To: Pascal Thubert (pthubert) <pthubert=[e-mail]>;
> > [e-mail]
> > 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:[phone] / Mobile: [phone]
> >
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) <pthubert=[e-mail]>
> > Sent: Friday, November 18, 2022 6:09 AM
> > To: Falendysz, Gene <[e-mail]>; [e-mail]
> > 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 <[e-mail]> On Behalf Of Falendysz, Gene
> > > Sent: jeudi 17 novembre 2022 15:44
> > > To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]
> > > 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:[phone] / Mobile: [phone]
> > >
> > >
> > > _______________________________________________
> > > 6lo mailing list
> > > [e-mail]
> > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6l
> > > o_
> > >
> _;!!F7jv3iA!2dS7DeAq_Z8s7nFEQvpxqz9CB5Y0xD_qNKbFXdvDCZlojcAAwhaYzTc3
> > > xI HLxzOK2fsFC0RdZQnaC06SZJTsmxKezgtL4lyvhas$
> >
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo_
> > _;!!F7jv3iA!wbY9lpxIso9IuZ2-
> gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9
> > D2MFMLzzuK5OFVpBEIDo6N8JdY2xrwNVr9Hugb8SQ$