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