Hi Pascal, Yes, this looks much better to me. Thanks!
-MSK On Wed, May 15, 2024 at 2:16 AM Pascal Thubert <pascal.thub...@gmail.com> 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 < > nore...@ietf.org> 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 >
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
