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?