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

[Emmanuel Baccelli <[e-mail]>]

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

This is why we propose a companion draft providing source-initiated path
establishment (and yes, a reactive approach is one way to do it ;).

Emmanuel