Subject: Re: [Roll] proposal for DAOs in non-caching DODAGs

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 14:35:15 -0500 (CDT)

> 
> The mechanism used to elevate a neighbor to a candidate parent status is clearly out of scope for the RPL draft. But, the draft should mention the properties that a candidate parent must satisfy. I think this is what Pascal is saying and I agree with it.

[Phil] What properties are they? This sounds like an implementation decision to me. 

[Mukul] I think the property is:

A node may consider a neighbor as a candidate parent only if:

1) the node knows the relevant local cost required to evaluate the neighbor's suitability as a parent as per the objective function; or
2) the neighbor's DIO carries the information about such cost; or
3) the node is willing to assume a value for such cost.

I dont think that it is an implementation decision. I think that it qualifies as part of "how the protocol works".

Thanks
Mukul
 
[Phil]
There seems to be a tension between writing the draft to tell coders how to implement the protocol and writing the draft to specify how the protocol works for the purpose of interoperability. I thought a Proposed Standard RFC is the latter? Implementation guidance seems like an informational RFC topic.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 31 Mar 2010 13:33:13 -0700

> I dont think that it is an implementation decision. I think that it qualifies as part of "how the protocol works".

By "candidate parent" I assume you mean member of the parent set?

Let me try to reword this -- for a node A to consider a node B in its parent set, then it must be able to compute its DAGRank if B were the next hop. 

I'm not sure I understand the concern. Is it that if this isn't stated explicitly, then an implementation might put a neighbor in the parent set for which it cannot compute DAGRank from the OF? How would it ever compute its own DAGRank? Can you explain the failure condition?

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 15:37:39 -0500 (CDT)

> By "candidate parent" I assume you mean member of the parent set?

No. I mean a neighbor that is a candidate to become a parent. It is not yet a parent.

Thanks
Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 31 Mar 2010 15:48:55 -0500 (CDT)

Sorry for the previous incomplete response.

>I'm not sure I understand the concern. Is it that if this isn't stated explicitly, then an implementation might put a neighbor in the parent set for which it cannot compute DAGRank from the OF? How…

Consider the situation where node A receives a DIO from node B and knows the cost of link B->A (either it already knew this cost or DIO carries this cost or it assumes a value for this cost) but not that of link A->B. Then, node A may be able to compute its DAG rank via node B and thus possibly select node B as a DIO parent. But, even if B becomes a DIO parent, A should not consider B as a candidate for DAO parenthood because A does not know the cost of link A->B.    

Thanks
Mukul

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

---

From: Philip Levis <[email-masked]>
Date: Wed, 31 Mar 2010 13:56:38 -0700

> Consider the situation where node A receives a DIO from node B and knows the cost of link B->A (either it already knew this cost or DIO carries this cost or it assumes a value for this cost) but no…

So a node A MUST NOT select node B as a parent if the OF cannot compute the DAGRank of the resulting route?

Phil