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

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> JP Vasseur
> Sent: Thursday, November 19, 2009 5:37 AM
> To: Jonathan Hui
> Cc: roll@ietf.org
> Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
> 
> 
> On Nov 17, 2009, at 6:56 PM, Jonathan Hui wrote:
> 
> >
> > On Nov 17, 2009, at 9:20 AM, Pascal Thubert (pthubert) wrote:
> >
> >> 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.  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.  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.
> 
> I'm with you, well as someone used to work on MPLS, no surprise.
> But still that does not solve the traffic matrix issue: not storing
> DAO leads to all traffic transiting via the root, which is not
> acceptable in many networks.

Agreed. The emphasis needs to be on ensuring that we can reduce the DAO
update information overhead which benefits networks in which nodes can
maintain state as well as those in which only the root stores state. I still
believe that there can be a DAO specification in which nodes that do not
store state can include Reverse Route info that can then be alternately
removed by state-maintaining nodes and added by stateless nodes as the DAO
information is passed inward towards the root (to the highest rank
state-maintaining common ancestor node that sits above an old and new
parent).

> 
> >
> > --
> > Jonathan Hui
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll