Re: [Roll] Comments on draft-dt-roll-p2p-rpl-01

Hi,

On Jun 17, 2010, at 9:42 AM, Emmanuel Baccelli wrote:

> Hi JP,
>
>
>
>>
>> JP> Again, to be accurate, there are no MUST requirements listed in
>> these ID that are not satisfied by RPL (with regards to the  
>> aforementioned
>> issues). I am NOT saying that the proposed mechanism is not useful
>>
>> (by all means), just that the statement above is not correct.
>>
>>
>> [ABR:]
>> I have to disagree.
>>
>>
>> RFC5826 says:
>>
>> The routing protocol MUST converge within 0.5 seconds if no nodes
>>    have moved (see Section 3.2 for motivation).
>>
>>    The routing protocol MUST converge within four seconds if nodes  
>> have
>>    moved to re-establish connectivity within a time that a human
>>    operator would find tolerable as, for example, when moving a  
>> remote
>>    control unit.
> Not quibbling at all. But to be perfectly accurate this does not  
> translate into "a reactive protocol
> is needed". Once again (not to make sure that there is no  
> confusion), I am not trying to say that
> this complementary mechanism is not useful.
>
>
>
>
> Quite right. But I think we are rather getting to the point raised  
> by Dave in yesterday's virtual meeting, i.e. we need to decide :
> (i) what minimum functionalities are needed in the basic RPL spec,
> (ii) what extra functionalities we want to specify in companion  
> documents.
>
> So the point that is made here, rather than saying "a reactive  
> protocol is needed", is saying:
> (i) source-initiated path establishment is required by some  
> applications,
> (ii) this functionality does not belong in the basic RPL spec
>

I did look at it and it seems that the demarcation line is pretty  
clear. So far, your ID does not
require an RPL core specification modification but this is important  
to know if you think otherwise.

> This is why we propose a companion draft providing source-initiated  
> path establishment

I was just pointing out that the MUST listed the requirements were not  
the way to justify it.
If there is a WG consensus to use this approach, we will standardize it.

Cheers.

JP.

> (and yes, a reactive approach is one way to do it ;).
>
> Emmanuel
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll