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

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

Hi Jonathan

>> When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH
>> (source route)), you see the source route RH2/4 grow upon movement
and
>> quickly shrink again as the NINA (DAO) states are reestablished.
>> When things are stable you only see as many entries as non DAO
capable
>> nodes along the path. In my case, the source route is done on a MIP/
>> NEMO
>> tunnel, so the RH states are stored in eth binding cache on the home
>> agent. But we could store that at the root with exactly the same
>> process.
>> I can demo that next time we meet if you wish.
>>
>> http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header
>> details the RRH, since there is not LSRR in IPv6.
>>
>> Note that in our case, the information in the header should be
locally
>> significant, like a label.
>
>Here lies the disconnect. 

With the draft, not between us :)

>                          The real benefit of storing state among
>nodes within the network is to reduce the size of the source route
>header not some attempt to support point-to-point traffic.  

I'm sure we agree here. 

I'd add that we get a unoptimized P2P if we are willing to have *all* 
nodes support states. Otherwise you get something quite silly.

That unoptimized P2P has interesting characteristics, in particular 
it is very resilient to movement. 

We should not bar that feature, just understand what it is good at 
and what it not so suited for. Like Jerry's problem.

>                                                          If you buy
>that, then the mechanism to establish such state could be much better
>than what's currently defined in the draft.  In particular, there are
>some interesting things we could achieve if we start treating next-hop
>information using locally significant labels rather than globally
>significant IP addresses, as you suggested.  But if done properly, I
>think we can specify such a mechanism as an optimization to basic
>source-route/record-route.

Looks good. The main consequence that I see at first glance is that 
The DAO should be sent to only one parent, because maintaining multiple
Source route path down the DAG makes little sense for reasons discussed
Earlier in this list (combinatory explosion, no end to end retries...)

Would you agree on that?

Pascal