[6lo] Re: Murray Kucherawy's No Objection on draft-ietf-6lo-multicast-registration-18: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

Hi Pascal,

Yes, this looks much better to me.  Thanks!

-MSK

On Wed, May 15, 2024 at 2:16 AM Pascal Thubert <[e-mail]>
wrote:

> Hello Murray
>
> Many thanks for your review!
>
> I'd rather keep that SHOULD and explain what happens when that is not done
> (network takes time to recover, packets are lost). Rationale: In a very low
> power LLN, the 6LN may be sleeping for a long time and will miss the async
> messages anyway, so sending them could be a pure energy waste in some
> environments. To your point also I made the all nodes multicast a MUST
> since I'm not aware of any standard work that would create a mcast group
> for all 6LNs attached to this 6LR. SHould that happen, the MUST will be
> overruled by that newer standard.
>
> I got some parallel feedback on the clarity of the operation in that
> section. I rewrote is a bit to be more specific. Net net:
>
> before
> "
>
>       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.
>
> "
>
> after:
> "
>           A router that wishes to refresh its state, e.g., upon reboot or
> in
>       any situation where it may have missed a registration or lost a
>       registration state, SHOULD send an asynchronous NA(EARO) with this
>       new status value.  Failure to do so will delay the recovery of the
>       network till the next periodic registration by the attached 6LNs
>       and packets may be lost till then.  That asynchronous multicast
>       NA(EARO) MUST 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.  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.
>
>       The asynchronous multicast NA(EARO) indicating a "Registration
>       Refresh Request" MAY be reissued a few times within a short
>       period, to increase the chances that the message is received by
>       all registered nodes despite the unreliable transmissions within
>       the LLN; the TID MUST be incremented each time.  The receiver 6LN
>       MUST consider that multiple NA(EARO) messages indicating a
>       "Registration Refresh Request" from the same 6LR received within
>       that short period with comparable (their absolute difference is
>       less than SEQUENCE_WINDOW, see section 7.2 of [RFC6550]) and
>       increasing TID values are in fact indicative of the same request;
>       the 6LN MUST process one and only one of the series of messages.
>       If the TIDs are desynchronized (not comparable), or decreased,
>       then the NA(EARO) is considered as a new request and it MUST be
>       processed.
>
>       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.  By default the TID initial setting after boot is 252, the
>       SEQUENCE_WINDOW is 4, the duration of the short period is 10
>       seconds, the interval between retries is 1 second, and the number
>       of retries is 3.  To reach 255 at boot time, the sender MAY either
>       issue at least 4 NA messages, skip a TID value, or start with a
>       value that is more than 252.  The best values for the short
>       period, the number of retries, and the TID initial setting depend
>       on the environment and SHOULD be configurable.
>  "
>
> Works?
>
> Pascal
>
>
> Le jeu. 2 mai 2024 à 08:45, Murray Kucherawy via Datatracker <
> [e-mail]> a écrit :
>
>> Murray Kucherawy has entered the following ballot position for
>> draft-ietf-6lo-multicast-registration-18: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> In Section 7.3:
>>
>>    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
>>
>> "SHOULD" gives me a choice.  So if I want to refresh my state, but I
>> don't do
>> those things, has my state still been reset?  I'm not sure you want SHOULD
>> here, and it feels like at least one of these needs to be MUST, or you
>> could
>> just change "SHOULD send" to "sends" to make it normal behavior when
>> wants to
>> reset state.
>>
>> In Section 2.3, you define these terms, but never use them: 6BBR, AMC,
>> AMR.
>>
>>
>>
>>
>
> --
> Pascal
>