Re: [Roll] Ticket #10: Closed

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

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
>>