Re: [Roll] FW: New Version Notification for draft-thubert-roll-fundamentals-01

Hi Zach,

On Apr 11, 2009, at 9:07 AM, Zach Shelby wrote:

> Richard,
>
> Richard Kelsey wrote:
>>   From: Philip Levis <pal@cs.stanford.edu>
>>   Date: Fri, 10 Apr 2009 06:52:04 -0700
>>   On Apr 9, 2009, at 1:59 AM, Pascal Thubert (pthubert) wrote:
>>   > Basically, since we have a depth, we have feasible parents  
>> (of     > lesser depth) and siblings (of same depth). The draft  
>> suggests that     > we can select any parent to forward on a per  
>> packet basis using the     > best metric or more advanced load  
>> balancing functionality; if that     > fails then we can use a  
>> sibling with some basic loop avoidance like     > poison return or  
>> more advanced path vector (for hydrophiles).
>>   Here's a URL to a paper that describes one way to solve this  
>> problem,     using the techniques I mentioned a few weeks ago and  
>> touched on in my     talk in SF:
>>   http://sing.stanford.edu/pubs/ctp.pdf
>> Good stuff.  Relating this back to the Routing Fundamentals
>> draft, it seems clear that ROLL will most likely use trees
>> for at least some routing, and while Router Advertisements
>> can be used to build trees, it will be good if tree
>> building and/or maintenance can be performed independently
>> of Router Advertisements.  They add too much overhead
>> to make it easy to react quickly to changing conditions.
>
> Don't think of router advertisements as overhead - as we are working  
> with IP networks you will always have RAs as they are an integral  
> part of network bootstrapping and maintenance (Neighbor Discovery).  
> As you have RAs anyways, you might as well piggyback some tree  
> information. Trickle can also be used to optimize the RA traffic to  
> an appropriate level.
>
> The same can be said about other ND traffic in these networks such  
> as NS/NAs (IPv6), or RR/RCs (in 6LoWPAN). If you have the ND traffic  
> anyways, piggybacking is good.
>
> That said, I do see the need for carrying metric information (as  
> done in the CTP protocol Phil is referencing) in data traffic (using  
> an IPv6 hop-by-hop option) especially for very dynamic networks. I  
> had this in mind when we wrote the Routing Fundamentals draft as an  
> option. From my practical experience it is useful, and only needs to  
> be applied to 1-10% of data packets depending on how dynamic the  
> network is.
>

I do agree with you ... Just a word of cautious though. Piggybacking  
can be an interesting option but we need to be a bit careful at not  
spreading out routing control plane traffic in N existing protocols.  
In this particular I do not want to wait for traffic to make my  
routing decision.

Cheers,

JP.

> - Zach
>
>
>>                                   -Richard Kelsey
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>
> -- 
> http://zachshelby.org - My blog “On the Internet of Things”
> Mobile: +358 40 7796297
>
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
>
> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll