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

[John E Drake <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: Saturday, October 20, 2012 2:30 PM
> To: [e-mail]; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Adrian Farrel
> Sent: samedi 20 octobre 2012 21:37
> To: [e-mail]
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Philip Levis
> > Sent: 20 October 2012 14:50
> > To: Pascal Thubert (pthubert)
> > Cc: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll