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

From: Matteo Paris <[email-masked]>
Date: Tue, 3 Apr 2012 13:46:28 +0000

Hi Phil,

my question boils down to whether RPL requires members of the parent set to have lower DAGRank, or merely lower rank.  My reading of the RPL draft is that all parents must have lower DAGRank.

I get this from two clauses in the RPL draft that I quoted below.  Unfortunately both are confusingly worded.

RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B)."  I believe the intention here was to say "if and only if", otherwise the clause is pointless (trivially true).

RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N)."  Here, a rank is being compared with a DAGRank, which is nonsensical, unless "rank" actually means "DAGRank".  It would be much clearer if it said so explicitly, ie "must be of DAGRank less than DAGRank(N)."  

What is your interpretation -- are parents required to have lower rank or lower DAGRank? Perhaps the confusion is a result of some text accidentally left over from an older version of the draft.

Thanks,
Matteo

PS My emails have not been posting to the list. I'm working on it.

On Mar 16, 2012, at 5:29 PM, Philip Levis wrote:

> 
> On Mar 16, 2012, at 1:44 PM, Matteo Paris wrote:
> 
>> 
>> Hi Phil.  These changes were helpful.  But I am still unclear on the rank computation in section 3.3.  From the RPL draft:
>> 
>> RPL Section 3.5.1:  "DAGRank(rank) = floor(rank/MinHopRankIncrease)"
>> RPL Section 3.5.1:  "A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B)."
>> RPL Section 3.5.2:  "[F]or a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N)."
>> RPL Section 8.2.1:  "A node's rank MUST be greater than all elements of its DODAG parent set."
>> 
>> The rank computation in MRHOF section 3.3 can result in parents P for which DAGRank(P) is not less than DAGRank(N),
>> which would seem to violate the third and fourth clauses above, given the definitions in the first two clauses.
> 
> How? I intended case 2 in 3.3 to cover this. Can you explain the edge case you see where it does not?
> 
>> 
>> One other minor question.  In the sentence, "The second case covers requirement 4..." of MRHOF section 3.3, do you mean requirement 5?
> 
> Yes! It should be requirement 5. I will fix this in the next revision. Thank you for catching it.
> 
> Phil

---

From: Matteo Paris <[email-masked]>
Date: Thu, 5 Apr 2012 15:45:08 +0000

Does anybody know whether RPL parents of a node N must have lower rank than N or lower DAGRank?  The RFC text is unclear (see below).

Thanks,
Matteo

> From: Matteo Paris <[email-masked]>
> Date: April 3, 2012 9:46:28 AM EDT
> To: Philip Levis <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [Roll] New Version Notification - draft-ietf-roll-minrank-hysteresis-of-07.txt
> 
> 
> Hi Phil,
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Apr 2012 09:08:18 -0700

Comments inline

> my question boils down to whether RPL requires members of the parent set to have lower DAGRank, or merely lower rank.  My reading of the RPL draft is that all parents must have lower DAGRank.

I think this reading is correct, but not because of the confusing text you cite.

> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a node B if DAGRank(A) is less than DAGRank(B)."  I believe the intention here was to say "if and only if", otherwise the clause i…

I don't think you want to interpret this sentence as a definition of what "lower rank" means. I have no doubt that many portions of the RPL (or other) specifications do not use the phrase in this way. So it should be interpreted as "if", not "if and only if." Really, this sentence shouldn't be in there.

> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG parent set must be of rank less than DAGRank(N)."  Here, a rank is being compared with a DAGRank, which is nonsensical, unless "rank…

Eh… I think interpreting it as DAGRank conflicts with the DIO processing rules. If you interpret this phrase as all parents must have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1 from

   5.  A node's Rank MUST be greater than all elements of its DODAG
       parent set.

to

   5.  A node's Rank MUST be greater than all elements of its DODAG
       parent set by at least MinHopRankIncrease.

or

   5.  A node's DAGRank MUST be greater than all elements of its DODAG
       parent set.

It's important to note that 3.5.2 says

"When Rank is
   compared, e.g., for determination of parent relationships or loop
   detection, the integer portion of the Rank is to be used."

not

"When Rank is
   compared, e.g., for determination of parent relationships or loop
   detection, the integer portion of the Rank MUST be used. 

> What is your interpretation -- are parents required to have lower rank or lower DAGRank? Perhaps the confusion is a result of some text accidentally left over from an older version of the draft.

I suspect Pascal and I are going to disagree on this, but my interpretation is that 3.5.2 doesn't mandate that a node advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. 8.2.2.1 was written pretty carefully so that a node with a preferred parent of Rank a and a backup parent of Rank b (b>a) would not have to always advertise b + MinHopRankIncrease, but rather at least b+1.

It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL should mandate that behavior.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Apr 2012 18:18:03 +0200

Hello Matteo and Phil

> What is your interpretation -- are parents required to have lower rank
or lower DAGRank? Perhaps the confusion is a result of some text
accidentally left over from an older version of the draft.

I suspect Pascal and I are going to disagree on this, but my
interpretation is that 3.5.2 doesn't mandate that a node advertise a
Rank which is at least MinHopRankIncrease greater than all of its
parents. 8.2.2.1 was written pretty carefully so that a node with a
preferred parent of Rank a and a backup parent of Rank b (b>a) would not
have to always advertise b + MinHopRankIncrease, but rather at least
b+1.

It is useful to note that the MRHOF Rank calculation algorithm *does*
cause a node to advertise a Rank which is at least MinHopRankIncrease
greater than all of its parents. But I don't think RPL should mandate
that behavior.

[Pascal] The intent in that example was that the node should advertise a
rank that is both more than (b+1) and more than (a +
MinHopRankIncrease). 
The reasons is that the preferred parent is the reference for Rank
computation (to stay true to the metrics), but all parents must has a
rank that is more than that of the node (to build DAGs which is the way
RPL uses to avoid loops). 

So I think we agree in fact....

Cheers,
 
Phil
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Apr 2012 09:21:18 -0700

> RPL uses to avoid loops). 

OK, sounds like we agree. Matteo, does this answer your question?

Phil

---

From: Matteo Paris <[email-masked]>
Date: Fri, 6 Apr 2012 13:57:32 +0000

Hi Phil.  Thanks for the reply.  I too would prefer if parents were only required to have lower rank, not lower interger portion of rank.  Unfortunately that is not how the RFC reads.  All of 3.5.1 "Rank Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining that ranks should be compared using only their integer portions.  You quoted another excellent example below.  As another example, 3.5.2 also spends a paragraph clarifying that nodes should not route through a node with equal DAGRank (equal integer portion of rank), which is to say that parents must have lower integer part.  

As it stands, I think the only logically consistent way to read the spec is to compare ranks as prescribed in 3.5.1 and 3.5.2.  Note that doing so does not logically conflict with 8.2.1 case 5, it simply modifies its meaning.  Only if we entirely ignore those two sections, can we then compare ranks in the more sensible way that we all prefer.  If that is the desire, we should submit an RFC errata.  In its current state I do not believe a first time reader of the RFC can know that 3.5.1 and 3.5.2 do not apply.

> It is useful to note that the MRHOF Rank calculation algorithm *does* cause a node to advertise a Rank which is at least MinHopRankIncrease greater than all of its parents. But I don't think RPL sh…

Case 2 of 3.3 in MRHOF says:

2.  The Rank of the member of the parent set with the highest
      advertised Rank plus one

In order for the MRHOF algorithm to cause a node to advertise a rank which is at least MinHopRankIncrease greater than all of its parents, this sentence must be changed to say "The Rank of the member of the parent set with the highest advertised Rank plus MinHopRankIncrease."

Matteo

---

From: Philip Levis <[email-masked]>
Date: Fri, 6 Apr 2012 07:42:14 -0700

Pascal wrote the text in 3.5, and it seems like he doesn't agree with your interpretation...

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Apr 2012 17:12:12 +0200

So maybe that's the +1 that's unclear. Let's dig a bit:

Initially the Rank was one octet and things were simple.

We extended it to 2 octets to allow for a better truthfulness for some
metrics when we add ranks up. 

Trouble, that could make the rank very sensitive and the structure
unstable. To avoid that we defined a rough comparison and to do so we
picked a decimal part and a floor. 

With that rough comparison, a 2 bytes rank would slightly fluctuate
without changing the nodes relationship. Unless it fluctuates at the
decimal boundary and that's when the hysteresis helps you.

So in the end we end up with a decimal part to play additions with, but
the integral part of the rank is the piece used for orienting the DAG.
That's the whole point of having a decimal part and all those macros.

So a node can have a parent that has its rank +1 but not all nodes with
rank+1 can be parent. You need to reach the next floor. What's needed is
less than min increase but usually more than 1.

Until late in the process we could use nodes of same integral floor for
forwarding, but that was removed from the spec. This is something that
is dearly missed in the environment I'm familiar with.

Cheers;

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: vendredi 6 avril 2012 16:42
To: Matteo Paris
Cc: [email-masked]
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

Pascal wrote the text in 3.5, and it seems like he doesn't agree with
your interpretation...

Phil

On Apr 6, 2012, at 6:57 AM, Matteo Paris wrote:

> 
> Hi Phil.  Thanks for the reply.  I too would prefer if parents were
only required to have lower rank, not lower interger portion of rank.
Unfortunately that is not how the RFC reads.  All of 3.5.1 "Rank
Comparison" and 3.5.2 "Rank Relationships" are devoted to explaining
that ranks should be compared using only their integer portions.  You
quoted another excellent example below.  As another example, 3.5.2 also
spends a paragraph clarifying that nodes should not route through a node
with equal DAGRank (equal integer portion of rank), which is to say that
parents must have lower integer part.  
> 
> As it stands, I think the only logically consistent way to read the
spec is to compare ranks as prescribed in 3.5.1 and 3.5.2.  Note that
doing so does not logically conflict with 8.2.1 case 5, it simply
modifies its meaning.  Only if we entirely ignore those two sections,
can we then compare ranks in the more sensible way that we all prefer.
If that is the desire, we should submit an RFC errata.  In its current
state I do not believe a first time reader of the RFC can know that
3.5.1 and 3.5.2 do not apply.
> In order for the MRHOF algorithm to cause a node to advertise a rank
which is at least MinHopRankIncrease greater than all of its parents,
this sentence must be changed to say "The Rank of the member of the
parent set with the highest advertised Rank plus MinHopRankIncrease."
>>> my question boils down to whether RPL requires members of the parent
set to have lower DAGRank, or merely lower rank.  My reading of the RPL
draft is that all parents must have lower DAGRank.
>>> I get this from two clauses in the RPL draft that I quoted below.
Unfortunately both are confusingly worded.
>>> 
>>> RPL Section 3.5.1 says: "A node A has a rank less than the rank of a
node B if DAGRank(A) is less than DAGRank(B)."  I believe the intention
here was to say "if and only if", otherwise the clause is pointless
(trivially true).
>> 
>> I don't think you want to interpret this sentence as a definition of
what "lower rank" means. I have no doubt that many portions of the RPL
(or other) specifications do not use the phrase in this way. So it
should be interpreted as "if", not "if and only if." Really, this
sentence shouldn't be in there.
>> 
>>> 
>>> RPL Section 3.5.2 says "[F]or a node N, all parents in the DODAG
parent set must be of rank less than DAGRank(N)."  Here, a rank is being
compared with a DAGRank, which is nonsensical, unless "rank" actually
means "DAGRank".  It would be much clearer if it said so explicitly, ie
"must be of DAGRank less than DAGRank(N)."  
>> 
>> Eh... I think interpreting it as DAGRank conflicts with the DIO 
>> processing rules. If you interpret this phrase as all parents must 
>> have a lower DAGRank, this strengthens bullet number 5 of 8.2.2.1 
>> from
>> 
>>> What is your interpretation -- are parents required to have lower
rank or lower DAGRank? Perhaps the confusion is a result of some text
accidentally left over from an older version of the draft.

---

From: Matteo Paris <[email-masked]>
Date: Fri, 6 Apr 2012 15:24:35 +0000

Hi Pascal,

> is dearly missed in the environment I'm familiar with.

So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the same
integral floor for forwarding?

Matteo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Apr 2012 19:11:39 +0200

Hi Matteo:

I agree that sections 3.5.1 and 3.5.2 prohibit using a parent of the
same integral floor for forwarding.
This is the state of the spec and there is no erratum in there.

We lost that capability late in the process. You might find the history
associated to the word "sibling".
We removed siblings to seek maximum simplicity. For nodes more capable,
they could be reintroduced. 
The point is that for siblings, we'll have to define something new to
avoid long loops. 

Maybe we could write an experimental addition?

Cheers,

Pascal

-----Original Message-----
From: Matteo Paris [mailto:[email-masked]] 
Sent: vendredi 6 avril 2012 17:25
To: Pascal Thubert (pthubert)
Cc: Philip Levis; <[email-masked]>
Subject: Re: [Roll] New Version Notification

Hi Pascal,

> Until late in the process we could use nodes of same integral floor 
> for forwarding, but that was removed from the spec. This is something 
> that is dearly missed in the environment I'm familiar with.

So you agree that sections 3.5.1 and 3.5.2 prohibit using a parent of
the same integral floor for forwarding?

Matteo

> So in the end we end up with a decimal part to play additions with, 
> but the integral part of the rank is the piece used for orienting the
DAG.
> rank+1 can be parent. You need to reach the next floor. What's needed 
> rank+is
> Until late in the process we could use nodes of same integral floor 
> for forwarding, but that was removed from the spec. This is something 
> that is dearly missed in the environment I'm familiar with.
> 
> Cheers;
> 
> Pascal
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Philip Levis
> quoted another excellent example below.  As another example, 3.5.2 
> also spends a paragraph clarifying that nodes should not route through

> a node with equal DAGRank (equal integer portion of rank), which is to

> say that parents must have lower integer part.
>> 

> set to have lower DAGRank, or merely lower rank.  My reading of the 
> RPL draft is that all parents must have lower DAGRank.
>>> 
> node B if DAGRank(A) is less than DAGRank(B)."  I believe the 
> intention here was to say "if and only if", otherwise the clause is 
> pointless (trivially true).
>>> 

> parent set must be of rank less than DAGRank(N)."  Here, a rank is 
> being compared with a DAGRank, which is nonsensical, unless "rank" 
> actually means "DAGRank".  It would be much clearer if it said so 
> explicitly, ie "must be of DAGRank less than DAGRank(N)."
>>> 
> preferred parent of Rank a and a backup parent of Rank b (b>a) would 
> not have to always advertise b + MinHopRankIncrease, but rather at 
> least
> b+1.
>>>

---

From: Matteo Paris <[email-masked]>
Date: Fri, 6 Apr 2012 19:03:42 +0000

Thanks Pascal.

Back to the original subject, this requires a change to MRHOF section 3.3 case 2 to ensure that a node's rank does not have the same integral floor as any of its parents:

I can think of three possible changes, listed in increasing order of the amount added to the highest advertised Rank:

2a. The Rank of the member of the parent set with the highest advertised Rank, rounded to the next higher integral Rank, ie, to MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).

2b. The Rank of the member of the parent set with the highest advertised Rank plus MinHopRankIncrease.

2c. The Rank associated with the path through the member of the parent set with the highest advertised Rank.

Matteo

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

Hi Matteo:

Cheers,

Pascal

-----Original Message-----
From: Matteo Paris [mailto:[email-masked]]
Sent: vendredi 6 avril 2012 17:25
To: Pascal Thubert (pthubert)
Cc: Philip Levis; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] New Version Notification

Hi Pascal,

Matteo

So a node can have a parent that has its rank +1 but not all nodes
with
rank+1 can be parent. You need to reach the next floor. What's needed
rank+is
less than min increase but usually more than 1.

Cheers;

Pascal

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf
Of Philip Levis
Sent: vendredi 6 avril 2012 16:42
To: Matteo Paris
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Roll] New Version Notification
-draft-ietf-roll-minrank-hysteresis-of-07.txt

Phil

It is useful to note that the MRHOF Rank calculation algorithm
*does*
cause a node to advertise a Rank which is at least MinHopRankIncrease
greater than all of its parents. But I don't think RPL should mandate
that behavior.

Matteo

Comments inline

Hi Phil,

my question boils down to whether RPL requires members of the
parent
set to have lower DAGRank, or merely lower rank.  My reading of the
RPL draft is that all parents must have lower DAGRank.

I think this reading is correct, but not because of the confusing
text you cite.

RPL Section 3.5.1 says: "A node A has a rank less than the rank of
a
node B if DAGRank(A) is less than DAGRank(B)."  I believe the
intention here was to say "if and only if", otherwise the clause is
pointless (trivially true).

to

or

"When Rank is

not

"When Rank is

It is useful to note that the MRHOF Rank calculation algorithm
*does*
cause a node to advertise a Rank which is at least MinHopRankIncrease
greater than all of its parents. But I don't think RPL should mandate
that behavior.

Phil

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Fri, 6 Apr 2012 14:15:12 -0700

Of the three, 2a is closest to the intention of the original text in 8.2.1, 2b is the simplest. I think 2c is a bad idea. I'd argue for 2a.

Ugh -- can't believe leftover text from siblings is getting us like this, defining terms outside of terminology. Given that 3.5 gives you no way to talk about the full floating point Rank, I wonder if there are other gotchas in the text. The intention of 8.2.1 point 5 was to be for the Rank value, not DAGRank. But if any reasonable reading of the RFC says otherwise….

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 7 Apr 2012 08:18:15 +0200

Hi Phil

I agree that 2.a is closest to the intent that I read there. OTOH I do
not necessarily agree with that intent. 

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.

Reversing the chicken and an egg leads to a Rank that is not true to the
preferred path metric, and greedy behaviors in general. This has been
discussed at length in the mailing list.
Till late in the process, siblings were the way to 1) augment the parent
set and 2) allow more solutions for more nodes. 
There are use cases in the real world that demand 2 forwarding solutions
for all nodes, so one way or another we'll have to introduce something
like siblings to serve them with RPL.

As we are at it , shouldn't:
" The largest    calculated Rank among paths through the parent set,
minus MaxRankIncrease" 
be
" The smallest calculated Rank among paths through the parent set, minus
MaxRankIncrease" 

At which point I would also indicate for clarity that this rule ends up
pruning parents from the original set.

Finally RFC 6550 does not come on your way to talk about the full
floating point Rank. RFC 6550 says:
"When an Objective Function computes Rank, the Objective Function
operates on the entire (i.e., 16-bit) Rank quantity. When Rank is
compared, e.g., for determination of parent relationships or loop
detection, the integer portion of the Rank is to be used.
"

So all the discussion/additions etc... about Rank value in an OF is on
the full 16 bits and we do not make any rounding error there.
This is true till we get to compare Ranks for parent relationship. 

Pascal

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: vendredi 6 avril 2012 23:15
To: Matteo Paris
Cc: Pascal Thubert (pthubert); <[email-masked]>
Subject: Re: [Roll] New Version Notification

Of the three, 2a is closest to the intention of the original text in
8.2.1, 2b is the simplest. I think 2c is a bad idea. I'd argue for 2a.

Ugh -- can't believe leftover text from siblings is getting us like
this, defining terms outside of terminology. Given that 3.5 gives you no
way to talk about the full floating point Rank, I wonder if there are
other gotchas in the text. The intention of 8.2.1 point 5 was to be for
the Rank value, not DAGRank. But if any reasonable reading of the RFC
says otherwise....

Phil

On Apr 6, 2012, at 12:03 PM, Matteo Paris wrote:

> 
> Thanks Pascal.
> 
> Back to the original subject, this requires a change to MRHOF section
3.3 case 2 to ensure that a node's rank does not have the same integral
floor as any of its parents:
> I can think of three possible changes, listed in increasing order of
the amount added to the highest advertised Rank:
> 
> 2a. The Rank of the member of the parent set with the highest
advertised Rank, rounded to the next higher integral Rank, ie, to
MinHopRankIncrease * (1 + floor(Rank/MinHopRankIncrease)).
>> We lost that capability late in the process. You might find the 
>> history associated to the word "sibling".
>> We removed siblings to seek maximum simplicity. For nodes more 
>> capable, they could be reintroduced.

>>> for forwarding, but that was removed from the spec. This is 
>>> something that is dearly missed in the environment I'm familiar
with.

>>> unstable. To avoid that we defined a rough comparison and to do so 
>>> we picked a decimal part and a floor.
>>> 

>>> rank+1 can be parent. You need to reach the next floor. What's 
>>> rank+needed is
>>> for forwarding, but that was removed from the spec. This is 
>>> something that is dearly missed in the environment I'm familiar
with.

>>> that ranks should be compared using only their integer portions.  
>>> You quoted another excellent example below.  As another example, 
>>> 3.5.2 also spends a paragraph clarifying that nodes should not route

>>> through
>>> spec is to compare ranks as prescribed in 3.5.1 and 3.5.2.  Note 
>>> that doing so does not logically conflict with 8.2.1 case 5, it 
>>> simply modifies its meaning.  Only if we entirely ignore those two 
>>> sections, can we then compare ranks in the more sensible way that we
all prefer.
>>> cause a node to advertise a Rank which is at least 
>>> MinHopRankIncrease greater than all of its parents. But I don't 
>>> think RPL should mandate that behavior.
>>>> 
>>> which is at least MinHopRankIncrease greater than all of its 
>>> parents, this sentence must be changed to say "The Rank of the 
>>> member of the parent set with the highest advertised Rank plus
MinHopRankIncrease."

>>> rank or lower DAGRank? Perhaps the confusion is a result of some 
>>> text accidentally left over from an older version of the draft.
>>>>> 

>>> cause a node to advertise a Rank which is at least 
>>> MinHopRankIncrease greater than all of its parents. But I don't 
>>> think RPL should mandate that behavior.
>>>>> 
>>>>> Phil
>>>> 
>>>> 
>>>

---

From: Philip Levis <[email-masked]>
Date: Sat, 7 Apr 2012 07:57:36 -0700

> 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