Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04

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

Hello Michael 

I guess that’s because we have different usages in mind.

For one thing we are building a DAG bot a tree and the intention is effectively to forward via multiple parents at the same time, and receive from multiple parents as well. 

The preferred parent is useful in the Rank computation and event horizon, but it is not the only next hop.

Second is that the in non storing the child accepting a join does not create state in the parent. So even if the parent is saturated the child might be ok. So why should the parent affect the child ? And then nodes often reparent. Too late the node has children should he abandon them now that the new preferred parent does not want any?

More subtle there’s the point that the new status option should not affect routing. If the value changes the capability of this node to have children isn’t that an incentive to move?

The real bottle neck for traffic is  usually the usage of the radio to the root. If that is saturated we’ll have more complex issues than birth control. Maybe rate control. Maybe incentive to emigrate. All that is interesting but beyond this draft.

On the other hand the global knowledge of the dag status is useful not just to join a dig but also to leave it for a least loaded one.

I believe that the root perspective without a change is what keeps the draft simple… 

Take care,

Pascal

> Le 11 août 2021 à 02:26, Michael Richardson <[e-mail]> a écrit :
> 
> 
> Pascal Thubert \(pthubert\) <pthubert=[e-mail]> wrote:
>> With 2) different parents may give different values for the same
>> sequence. Which should our node pick? The one from the preferred
>> parent? Or should the node reparent to the best offer? There’s
>> complexity and consequences to that decision of picking one value. And
>> then no way to know the abstract desirability of the next dodag since
>> the value from the root is lost.
> 
> A node should only care about the value from the preferred parent.
> These values should never affect parent selection, but just be about other
> nodes either enrolling, or joining this PANID.
> 
> So I don't understand what you write.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll