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

[Philip Levis <[e-mail]>]

On Apr 8, 2012, at 10:00 AM, Pascal Thubert (pthubert) wrote:

> 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?

This is an implementation decision. I can imagine other algorithms, e.g., where if the best Rank and next best Rank differ by more than MaxRankIncrease, the node chooses to advertise a worse Rank than the preferred parent provides.

Phil