Re: [Roll] Ticket #10: Closed

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

Just game boys would all support the same OCP. Game boy + PSP may indeed
not support the same one. 
For me this is interop, and does not happen by magic. People that want
their device to interoperate have to check they implement the same
things. Otherwise IETF ends up mandating that all device implement the
same OCP, same instance, as well as the same transport, the same
application layer protocol, the same application, same security, the
same data structures.... For me this is the role of an application
specific SDO/Forum.

Best,
Julien

> -----Original Message-----
> From: Pascal Thubert (pthubert) 
> Sent: lundi 9 novembre 2009 13:56
> To: Julien Abeille (jabeille); JP Vasseur (jvasseur)
> Cc: 'roll WG'
> Subject: RE: [Roll] Ticket #10: Closed
> 
> Hi Julien:
> 
> How do I form a network of game boys is my question. 
> 
> Pascal
> 
> >-----Original Message-----
> >From: Julien Abeille (jabeille)
> >Sent: lundi 9 novembre 2009 13:34
> >To: Pascal Thubert (pthubert); JP Vasseur (jvasseur)
> >Cc: roll WG
> >Subject: RE: [Roll] Ticket #10: Closed
> >
> >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
> >>
>