Re: [Roll] Ticket #10: Closed

[JP Vasseur <jvasseur at cisco.com>]

So here is the plan for rev-5.

First OCP0 will be removed from the core specification. There will no  
longer be any requirement
for a node to support OCP0. Various OCPs will be defined in separate  
drafts and each node will
be provisioned to support one or more OCPs

If a node receives a DIO referring to an OCP that it does not support/ 
understand, it may join the
DAG as a leaf and log the issue.

In the absence of comments, we will update rev-05 accordingly.

Thanks.

JP.

On Nov 9, 2009, at 11:05 AM, JP Vasseur wrote:

> 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
>
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll