[Roll] RtgDir Early review: draft-ietf-roll-rnfd-02

[Victoria Pritchard <[e-mail]>]

Hello

I have been selected to do a routing directorate “early” review of this
draft.
https://datatracker.ietf.org/doc/draft-ietf-roll-rnfd/

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for publication
to the IESG. The early review can be performed at any time during the
draft’s lifetime as a working group document. The purpose of the early
review depends on the stage that the document has reached.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-roll-rnfd-02
Reviewer: Victoria Pritchard
Review Date: 27/11/2023
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG.

In general, I found this to be well written, though some things explained
later in the draft would have helped understanding if explained earlier,
and a few points don't have the reason explained, which I think would also
help. Some clarification in these areas would be nice to include.

Comments/questions below.

Kind regards,
Victoria.


3 - "each node running RNFD" - Would all nodes need to participate? I
suppose the benefit would be limited if not? Also, if not all nodes
participate, some will continue to advertise a finite rank, would this
cause others to think the root is there? Maybe that's no worse than without
RNFD... those nodes using RNFD will look at the CFRCs and the LORS value,
assuming enough nodes are participating.

3.2 - negativeCFRC - says that this shows "sentinels that have considered
or still consider the root node as dead" - given the description in 5.2
that a node can go from LOCALLY DOWN to UP by re-adding itself to the
positive CFRC, i.e. they dont still consider it down, this might be phrased
better as "sentinels that consider, or have previously considered, the root
node as dead".

Similarly, positiveCFRC counts the number of times sentinels have
considered the root node as alive. A count in the positive CFRC doesnt mean
its still considered alive, as there could be a matching bit in the
negativeCFRC. As the last paragraph says, it's the difference between
positive and negative which shows how many sentinels consider the root as
alive.

4.2 What's the significance of having bit lengths be prime numbers?
Why if all positive bits are 1, should all negative bits also be 1? Is this
to indicate "globally down" as referred to in 5.3? i.e. using all the bits
not only the "prime number" of bits.
self() - selects the bit uniformly at random - will multiple sentinel nodes
select the same bit? Especially when nearing saturation?
Why 63% for saturation? Is it related to the probability of 2 sentinels
choosing the same bit?

5.1 Based on later discussion about the CFRC length, I assume the node
cannot send any CFRCs until it has received a message containing them, so
that it knows the length of the fields?

5.1 when changing role to acceptor, the rules state but dont explain why
the node MUST NOT modify its values, in particular negativeCFRC. I think
it's because the correct setting is already applied? (e.g. if already
globally down or locally down, the negativeCFRC has already been updated)

5.2 - paragraph that mentions "previous conditions 2-4": Why wouldn't it be
able to set LORS back to UP if the saturation was already over 63%
(condition 2)? Makes sense that saturation would mean the CFRC can't be
added to, but if the root is deemed to be up, why can't the node hold that
state locally? Does it have any impact if this remains at LOCALLY DOWN?

5.2 final paragraph
To re-add itself, it sets a new (uniformly selected) bit in the positive
CFRC?

If saturated is TRUE, does this mean the number of bits is almost used up?
Is 63% then a 'sensible' value, based on the fact that a number of
sentinels could be updating the CFRC at any one time and the saturation
value could end up well above 63% when all the updates are distributed?

If many sentinels have reported that the root is down, and then want to
report it back up, is there a risk that the saturation point will be
reached and they wont be able to add themselves to the positive CFRC again?
(Answered later - CFRC length can be extended - could consider reordering
these sections).

5.4 The DODAG root chooses bit length for the CFRCs? Does it start with
CFRCs set to zero? Does the root have to advertise the number of bits
before any nodes can become a sentinel? How does it increase the number of
bits (what are the CFRC values set to when it increases?), and how do the
sentinels react?

If a node didnt add itself to the positive CFRC because the saturation was
true, should it then add itself if it sees the number of bits increase (and
the saturation has gone back below the threshold)?

5.4, 5.5, 5.6, seem in the wrong order... questions I had while reading the
early sections were answered later. e.g. 5.4 - how do the nodes react when
the root changes the number of bits?

5.6 - how does the root extend the number of bits, does it merge from any
heard bits already or start fresh from CFRCs with all bits set to zero? If
a node receives a CFRC with more bits, how does it know which is its bit to
set? Can it assume its previous counter is not present when it adds itself
again as detailed in 5.6?

6. If the positive CFRC becomes saturated with little or no increase in
negative CFRC, wouldn't that mean the network is behaving well, and all the
sentinels say the root is alive? Would issuing a new DODAG version disrupt
things unnecesaarily? Or would it mean only the closest/fastest nodes would
have become sentinels, and is it then better to use the probablilty
mechanism to get a different spread of sentinels?