Re: [Roll] updating DAO caches (was Re: Something to ADD)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi JP, all,

I agree that we should keep DAOs in RPL. A routing protocol that
installs routes in one direction only makes no sense to me. By the way
if in a deployment some do not want to store DAOs, they can.

Best,
Julien

> -----Original Message-----
> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On 
> Behalf Of JP Vasseur (jvasseur)
> Sent: jeudi 19 novembre 2009 13:19
> To: Richard Kelsey
> Cc: roll at ietf.org
> Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
> 
> 
> On Nov 19, 2009, at 12:01 PM, Richard Kelsey wrote:
> 
> >> From: JP Vasseur <jvasseur at cisco.com>
> >> Date: Thu, 19 Nov 2009 11:36:49 +0100
> >>
> >> On Nov 17, 2009, at 5:38 PM, Jonathan Hui wrote:
> >>
> >>> I'll have to admit that I'm not yet convinced of the benefits in 
> >>> storing DAO state as it currently exists in the draft.  [...]
> >>>
> >> I do agree with the first statement but not with the second 
> >> paragraph.
> >> I do see several deployment cases where no storing DAO 
> would lead to 
> >> extremely sub-optimal paths and even more importantly traffic 
> >> congestion when getting closer to the root of course.
> >
> > Can you share these cases with us?  I agree with Jonathan 
> that storing 
> > DAO states will typically not provide much improvement in 
> P2P routing.
> 
> Sure. I'll take the example of an inter primary+secondary 
> substation network (could be the smart metering network) that 
> supports traffic for various purposes:
> meter read-out, DA alarms, ... etc. Thus traffic of various nature:  
> P2MP, MP2P
> and P2P. There are many such networks where not storing DAO 
> just does not work since all P2P traffic will have to transit 
> via the root (unacceptable delays for
> alarms) and the traffic around the root will be way too high.
> 
> This is why I am saying that having an RFC that forms a DAG 
> that cannot be used for outward traffic is a non-starter.
> 
> >
> >> I do see several deployment cases where no storing DAO 
> would lead to
> >> extremely sub-optimal paths and even more importantly traffic
> >> congestion when getting closer to the root of course. This is true
> >> with several networks where the amount of P2P traffic may ned up  
> >> being
> >> not so negligible. The beauty with the current spec is 
> that it allows
> >> both deployment models.
> >
> > It claims to allow both, but fails to actually do so.  That
> > is the point of the example that I gave and the reason I
> > keep going on about this.  While the draft says that
> > intermediate nodes can cache DAOs, it doesn't say how those
> > caches are updated after a node changes parents.  And
> > however this is done, we need to avoid the cost of sending
> > cache updates in the absense of any actual caches.
> 
> Yes I agree with you on this and this is why DAO packing is also  
> important.
> Thus I would propose to all work on this and make it work 
> while still  
> allowing
> some nodes to not store any DAO is they want to of course.
> 
> Does that make sense ?
> 
> Cheers.
> 
> JP.
> 
> >
> >                                 -Richard Kelsey
> 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.