Re: [Roll] using the flow label instead of hop by hop

What if an end-host outside the RPL instance wants to use a flow label for its own purposes? It might think that a flow denotes a stream of associated packets to a node within a RPL instance, not the OF that instance happens to use. 

Phil

On Oct 23, 2012, at 4:41 AM, Pascal Thubert (pthubert) wrote:

> Hi:
> 
> <I answered to John from my phone but then realized that I did not copy the list.>
> 
> In short: The packets carried within an instance share a characteristic which the OF optimizes for. 
> The OF determines a RPL topology and thus how the flow that is tagged with that instance is processed in the network. 
> For flows to be processed differently one may different instances.
> 
> Considering how open the definition of flow in 2460 is, this fits. 
> 
> The rank stretches that a bit since it qualifies where the flow is in the Network. 
> Then again RFC 2460 is open enough not to bar anything. 
> 
> Rather, the spirit is for us to do something useful with this field in the forwarding plane and that is exactly what this proposal is doing .
> 
> Cheers,
> 
> Pascal
> 
> 
> -----Original Message-----
> From: John E Drake [mailto:jdrake@juniper.net] 
> Sent: lundi 22 octobre 2012 21:15
> To: Pascal Thubert (pthubert); adrian@olddog.co.uk; roll@ietf.org
> Subject: RE: [Roll] using the flow label instead of hop by hop
> 
> Pascal,
> 
> So the information that you are carrying in the IPv6 label field has nothing to do with IPv6 labels?  So, why is this not an egregious hack?
> 
> Yours irrespectively,
> 
> John
> 
> 
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 
>> Of Pascal Thubert (pthubert)
>> Sent: Saturday, October 20, 2012 2:30 PM
>> To: adrian@olddog.co.uk; roll@ietf.org
>> Subject: Re: [Roll] using the flow label instead of hop by hop
>> 
>> Adrian,
>> 
>> This draft is not mpls. This draft is about carrying the RPL info 
>> (rank, instance, flags) in the flow label as opposed to the HbH which 
>> incurs additional header + eventually tunneling.
>> My other draft on fragment forwarding has a lot more to do with label 
>> switching since the first fragment lays a label that the other 
>> fragments follow. But then we are not using the flow label but a 
>> 6LoWPAN datagram identifier tag.
>> 
>> Cheers,
>> 
>> Pascal
>> 
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 
>> Of Adrian Farrel
>> Sent: samedi 20 octobre 2012 21:37
>> To: roll@ietf.org
>> Subject: Re: [Roll] using the flow label instead of hop by hop
>> 
>> Speaking as an individual and without an implementation...
>> 
>> Isn't this MPLS?
>> Hasn't the routing area looked at the idea of using the IPv6 flow 
>> label for labelled forwarding more than once in the past?
>> Hasn't the conclusion always been that you could do it, but you would 
>> have to be sure that you were not overloading the field?
>> And hasn't the resulting discussion led to a debate on the value of 
>> label stacks and the impracticality of label stacks using the flow 
>> label?
>> 
>> Cheers,
>> Adrian
>> 
>>> -----Original Message-----
>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf 
>>> Of Philip Levis
>>> Sent: 20 October 2012 14:50
>>> To: Pascal Thubert (pthubert)
>>> Cc: roll@ietf.org
>>> Subject: Re: [Roll] using the flow label instead of hop by hop
>>> 
>>> On Oct 20, 2012, at 1:19 AM, Pascal Thubert (pthubert) wrote:
>>> 
>>>> Phil;
>>>> 
>>>> There is indeed lot of pressure for this in terms of header sizes 
>>>> and energy
>>> consumption in the *real world*.
>>> 
>>> I'm personally concerned about header sizes and energy consumption 
>>> in The Matrix. Because I don't live in the real world. Oh, wait, 
>>> sorry,
>> I
>>> do. Can you
>> walk
>>> me through the quantitative reasoning that a few bytes of header 
>>> will increase energy consumption? It the belief that it will lead to 
>>> sub-packet
>> fragmentation in
>>> some non-amortized sense? Generally speaking, in low power wireless 
>>> networks, energy consumption is dominated by idle listening and 
>>> communication latency/interval support, not the length of packets. 
>>> Of course there is a
>> spectrum
>>> of low power approaches and their point on that spectrum. Are you 
>>> thinking of one in particular?
>>> 
>>> Could implementers who are encountering this pressure comment? I'm a 
>>> sucker for and easily swayed by quantitative data as well as 
>>> first-hand rather than second-hand reports.
>>> 
>>>> And there is no hack in the proposed solution.
>>>> Simply we believe more in practical engineering and ML discussions 
>>>> than we
>>> trust in crystal balls.
>>> 
>>> *coughs politely* I believe in very practical engineering that 
>>> considers long
>> term
>>> consequences. Solving a problem a certain way now might cause 
>>> significant problems in the future. I agree this is a tradeoff -- in 
>>> my personal opinion,
>> nothing
>>> more, the tradeoff on this one is 100% clear.
>>> 
>>> Phil
>>> 
>>> ------
>>> 
>>> Philip Levis
>>> President, Kumu Networks
>>> Associate Professor, Stanford University 
>>> http://csl.stanford.edu/~pal 
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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