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

["Adrian Farrel" <[e-mail]>]

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