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

[Pascal Thubert <[e-mail]>]

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