Re: [Roll] Ticket #10: Closed

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

Hi JP:

I'm anxious that the term of the resolution that you propose (remove OCP
0) opens the way to:

- 2 implementation that could never interop (no ocp in common)
- mandatory config (no working 'out of the box' default behavior)

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