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

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

Right, once explained in the proper context the proposal makes perfect sense.

Yours irrespectively,

John


> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Tuesday, October 23, 2012 4:41 AM
> To: John E Drake; [e-mail]; [e-mail]
> Subject: RE: [Roll] using the flow label instead of hop by hop
> 
> 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:[e-mail]]
> Sent: lundi 22 octobre 2012 21:15
> To: Pascal Thubert (pthubert); [e-mail]; [e-mail]
> 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: [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
> 
>