Re: [Roll] updating DAO caches (was Re: Something to ADD)

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

Hi Jonathan and Michael.

Both the source route and the DAO depend on the DAG specification.
The other way around, the DAG specification does not depend on them.

And arguably, one deployment could use source route only whereas
Another that needs all end to end connectivity would use DAO states
Yet another could take an unspecified-yet limited P2P solution to
compute only required on-demand constrained routes.

Even more fun, it is very possible to mix DAO states into a source route
network.

Since we have not designed a more specific on demand P2P solution, or
even proven that 
the existing MANET solutions are not enough for the job, I can only
infer that the best 
contender is probably DYMO, in which case it has no dependency at all.
      
Since we already took the path of not having a minimum Interop set in
one spec by removing OCP0, 
* I have no philosophical opposition in splitting the draft to make the
DAO separate.
* Also make a source route document that can work with no states
  yet explains how the DAO states can compress the source route when
they are present 
* Then study the applicability of existing on demand protocol and see
what we need to do there.

From there, the applicability statement will have to guide us in which
sets we need to pick in an implementation.

But those documents should still make a consistent set, for instance for
the purpose of loop detection.

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Jonathan Hui
>Sent: mardi 17 novembre 2009 18:07
>To: Michael Richardson
>Cc: roll at ietf.org
>Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
>
>
>On Nov 17, 2009, at 9:02 AM, Michael Richardson wrote:
>
>>>>>>> "Jonathan" == Jonathan Hui <jhui at archrock.com> writes:
>>    Jonathan> I'll have to admit that I'm not yet convinced of the
>>    Jonathan> benefits in storing DAO state as it currently exists in
>>    Jonathan> the draft.  It seems like a mediocre attempt to optimize
>>    Jonathan> point-to-point routing and something that folks wanting
>>    Jonathan> P2P support aren't satisfied with.  If that is the
>>    Jonathan> end-goal, then we should be developing better
mechanisms.
>>    Jonathan> For now, we are focusing on one-to-many and many-to-one.
>>    Jonathan> And, I see more benefits to simply maintaining state at
>>    Jonathan> the root.
>>
>> Thus, my proposal to forbid storing of state in intermediate nodes
>> (at least in the base protocol) since it causes externalities.
>>
>> Perhaps someone can some up with a way to store some state (but not
>> the
>> DAOs) in such a way that does not impose externalities that need to
be
>> communicated in the protocol.
>
>Yes.  Sorry for not stating it clearly.  I also propose to remove the
>ability to store downwards routing state at intermediate nodes from
>the base RPL document.  A P2P proposal that satisfies the application
>requirements should be dealt with in a separate draft.
>
>--
>Jonathan Hui
>
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll