Re: [Roll] Ticket #10: Closed

["Julien Abeille (jabeille)" <jabeille at cisco.com>]

Hi Pascal, JP, 

> -----Original Message-----
> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: lundi 9 novembre 2009 12:25
> To: JP Vasseur (jvasseur)
> Cc: roll WG
> Subject: Re: [Roll] Ticket #10: Closed
> 
> 
> >Here is another way to look at it. You simply configure an 
> OCP and all 
> >nodes willing to participate to a DAG have to implement that 
> same OCP.
> >
> Simply configure... 
> 
> In industrial, tools for doing that will certainly exist. 
> What about game boys and McDo toys? Can't they do RPL?
> 
> 
> >If you mandate the use of an OCP like the OCP0, that also means that 
> >ALL nodes MUST implement OCP0, even if they do not want to implement 
> >that OCP.
> 
> Yes, that was the goal. Making it fairly simple but 
> implemented in every node so if I buy something from brand A 
> and something from brand B, I'm sure there's at least one OCP 
> that both implement.
> 
The root has to be configured. If it sends OCPx in the DIO, the game boy
will join as a leaf anyway

Again, I do not think this is worth extra code on a node.

> Doesn't that scare you that we allow for 2 RPL-compliant 
> nodes to be by design unable to talk together whatever the 
> way we configure them? 
> 
> >
> >In other words, this is a trivial implementation issue easy to fix:
> >specify the OCP to use
> >on the node.
> 
> The OCP must be implemented in the node first. There's code 
> associated to it.
> 
> It makes sense that an implementation should have a mechanism 
> to add more OCPs over time, and that's what I indicated by 
> calling OCPs plug-ins.
> 
> Pascal
> 
> 
> >
> >> Is that really what this group wants?
> >>
> >> Pascal
> >>
> >>> -----Original Message-----
> >>> From: roll-bounces at ietf.org 
> [mailto:roll-bounces at ietf.org] On Behalf 
> >>> Of
> >> JP Vasseur (jvasseur)
> >>> Sent: lundi 9 novembre 2009 11:59
> >>> To: roll WG
> >>> Subject: Re: [Roll] Ticket #10: Closed
> >>>
> >>> 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
> >>>
> >>> _______________________________________________
> >>> 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
>