Re: [Roll] Ticket #10: Closed

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

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

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