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

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

Adrian,

It's pretty consistent with the re-definition of the IPv6 label as a flow label in the RFC that Pascal mentioned previously.

Yours irrespectively,

John


> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Thursday, October 25, 2012 5:50 AM
> To: 'Pascal Thubert (pthubert)'; John E Drake; [e-mail]
> Subject: RE: [Roll] using the flow label instead of hop by hop
> 
> Hi,
> 
> This and Michael's follow-up are helpful.
> 
> My take-away is that this is a place to put information that will be
> used during the routing process, but that the forwarding decision will
> not be made on this information in isolation.
> 
> That makes my "overlap with label switching" concern go away.
> 
> (Which is entirely different from considering whether this is a good
> idea or not, on which I have no position :-)
> 
> Adrian
> 
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> > Sent: 25 October 2012 07:53
> > To: [e-mail]; 'John E Drake'; [e-mail]
> > Subject: RE: [Roll] using the flow label instead of hop by hop
> >
> > I  certainly agree with a good number of your words, Adrian.
> > *We are indeed talking about a label that is applied to a packet.
> > *It is a label that is related to the flow, and determined by the
> instance ID.
> > *It is information that will be used for the routing decision at each
> > hop in
> the LLN.
> >
> > Which means that the flow label in the routing header is the perfect
> > place for
> it.
> >
> > I am still unsure what  the relation you make with label switching.
> > The
> distinction
> > I'm making is as follows:
> > *In this proposal there is no switching of tags, since the instance
> is
> conserved in
> > the label. Only some metadata is mutable.
> > *there is no switching packets either, RPL routing still takes place
> > at every
> hop
> > which involves a route lookup.
> > *and there is no switched path to follow with the label, but a
> > topology -a
> RIB- to
> > be determined.
> >
> > IOW, the instance is more like a topology index for the RIB/FIB
> lookup
> > that
> still
> > needs to take place.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[e-mail]]
> > Sent: mercredi 24 octobre 2012 19:46
> > To: Pascal Thubert (pthubert); 'John E Drake'; [e-mail]
> > Subject: RE: [Roll] using the flow label instead of hop by hop
> >
> > Hi Pascal,
> >
> > Speaking as an individual and without an implementation...
> >
> > I guess I need to look at this in more detail (it always helps to
> read
> > the
> > draft) this still sounds exactly like label switching.
> > That is some value of a label is applied to a packet and that label
> > will
> identify the
> > flow and direct the forwarding decision made at the next router.
> > Furthermore, the label may be modified hop by hop.
> >
> > The "overloading" of information into the label doesn't get away from
> > the fact that it is a label applied to a packet.
> >
> > Cheers,
> > Adrian
> >
> > > -----Original Message-----
> > > From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> > > Sent: 23 October 2012 12:41
> > > 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
> 
>