[Roll] Ticket #5: Closed

[JP Vasseur <jvasseur at cisco.com>]

Strong consensus towards Option 1.

This closes the ticket #10 and will be reflected in rev-05.

Thanks.

JP.

On Nov 5, 2009, at 8:24 AM, JP Vasseur wrote:

> Dear all,
>
> /co-chair hat off/
>
> We would welcome your opinion on the following issue:
>
> Suppose that a DAG is formed that support OFx. A new node willing to  
> join the DAG does not support OFx but OFy. Note that by OF we  
> actually mean the Objective function and the metric.
>
> We have two options here.
>
> Option 1: The node simply joins the DAG as a leaf. In order words,  
> the node has connectivity since it joins the DAG but will not act as  
> a router for others since it does not understand the OF. Parent  
> selection could be a simply a "random".
>
> Option 2: The node joins the DAG and falls back to the "default"  
> OCP. From there is prolongs the DAG but with OF0 (of course  
> inconsistent metrics are not added). This also means that everynode  
> MUST implement OF0 and that the network may compromise nodes with  
> different OF at some point. Several options even more complex have  
> been discussed where one could use common denominator to get as  
> close as possible to the desired OF, allow a node not to be so  
> "altruistic", ...
>
> My personal view is that OF management can quick get fairly complex  
> and hard to manage. Option 1 is extremely simple and easy to manage.  
> If a node is mis-configured (does not support the OF of the DAG) it  
> can join it as a leaf in order to have connectivity and send an  
> alarm to fix its configuration. We now just need to specify OF in  
> some document and this is it.
>
> Several of you mentioned that they were leaning toward option 1, but  
> could you please express your opinion, we would like to have it  
> solved for the next revision next week.
>
> Thanks.
>
> JP.
>
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll