Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Phil:

It is an implementation decision as long as it does not lead to interop
issue or unwanted behavior, which is probably the case here.
RFC 6550 demands that a node can't stray from the best Rank as computed
amongst parents by more than MaxRankIncrease.
This 3 clauses do not seem to capture this that we are discussing do not
seem to capture this. 
With (my reading of) the text as it stands, it seems that the
implementation has all freedom to select parents and then is given rules
to compute a Rank. 
The resulting Rank could be anything if the parent set as no constraint.


In particular  " The largest  calculated Rank among paths through the
parent set, minus MaxRankIncrease" must be less that the Rank obtained
from the preferred parent, not the final computed Rank.


The node should:
1) Compute the Ranks form its parent set. 
2) Determine a preferred parent as resulting with the lowest Rank (using
the computation described in the previous paragraph)
3) Determine which parents generate a Rank that is between that lowest
Rank and MaxRankIncrease
4) Pick a set of parents between those 

What do you think?

Pascal

-----Original Message-----
From: Philip Levis [mailto:[e-mail]] 
Sent: samedi 7 avril 2012 16:58
To: Pascal Thubert (pthubert)
Cc: Matteo Paris; [e-mail]
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt


On Apr 6, 2012, at 11:18 PM, Pascal Thubert (pthubert) wrote:

> The point is that with this clause the node selects its parents first 
> and its Rank second. The spec recommends picking a preferred parent 
> first, computing the Rank based on the preferred parent, and then only

> consider any node with a lower floor as an acceptable parent. I 
> understand that want to allow reversing that operation, but then that 
> should be an option and text should indicate that using it may augment

> the parent set for some nodes but end up reducing it for others.

Don't you think this is an implementation decision? I tried to write the
specification text to be completely neutral on this matter (as some of
the MRHOF discussions have gone into). The input to DIO generation is a
preferred parent and a parent set; how those two are selected is
complete outside the specification with the caveat that it places some
constraints (MaxRankIncrease).

Phil