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
