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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Oct 2012 11:41:16 +0000

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

---

From: John E Drake <[email-masked]>
Date: Tue, 23 Oct 2012 12:40:01 +0000

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

Yours irrespectively,

John

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Tuesday, October 23, 2012 4:41 AM
> To: John E Drake; [email-masked]; [email-masked]
> The OF determines a RPL topology and thus how the flow that is tagged
> with that instance is processed in the network.
> 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
> 
> 
> 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
> 
>

---

From: Philip Levis <[email-masked]>
Date: Tue, 23 Oct 2012 08:41:35 -0700

What if an end-host outside the RPL instance wants to use a flow label for its own purposes? It might think that a flow denotes a stream of associated packets to a node within a RPL instance, not the OF that instance happens to use. 

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Oct 2012 17:49:19 +0000

Phil,

The flow label is not protected by any IPSec so it cannot be used as a backchannel end-to-end. Now that would be a hack. 
And it is not for node to node communication but for node to network communication. That, in fact, would be a bad idea when destination options can be used safely.
Over the core internet, 6MAN has specified how the flow label is supposed to be set and it is the responsibility of the root that an outgoing packet.
On incoming packets, a normal host ignores the flow label that it cannot trust anyway. The RPL root will flush it and use it as RPL requires within the RPL domain.

Cheers,

Pascal

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: mardi 23 octobre 2012 17:42
To: Pascal Thubert (pthubert)
Cc: John E Drake; [email-masked]; [email-masked]
Subject: Re: [Roll] using the flow label instead of hop by hop

Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 23 Oct 2012 13:49:23 -0700

> The flow label is not protected by any IPSec so it cannot be used as a backchannel end-to-end. Now that would be a hack. 

What do you mean, a backchannel? 

> Over the core internet, 6MAN has specified how the flow label is supposed to be set and it is the responsibility of the root that an outgoing packet.

I'm not sure I understand what you're saying. Can you summarize how 6MAN has specified it is supposed to be set? I thought I understood their recommendations (from when we last had this discussion) but maybe it has changed. My concern is that a node sets the flow label to communicate some information and RPL throws it away. At the very least, we now need RPL to somehow figure out how to set the flow label for packets leaving the LLN: this is a form of protocol translation and so, while not impossible or impermissible, worries me.

> On incoming packets, a normal host ignores the flow label that it cannot trust anyway. The RPL root will flush it and use it as RPL requires within the RPL domain.

Just because a field doesn't have integrity protection doesn't mean that it can't and won't be used. I mean, are you suggesting that the recommendations for the flow label no longer follow RFC3697: 

   "The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."

Phil

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 Oct 2012 18:45:54 +0100

Hi Pascal,

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

> Sent: 23 October 2012 12:41
> 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.
> 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
> 
> 
> 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
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Oct 2012 06:53:11 +0000

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:[email-masked]] 
Sent: mercredi 24 octobre 2012 19:46
To: Pascal Thubert (pthubert); 'John E Drake'; [email-masked]
Subject: RE: [Roll] using the flow label instead of hop by hop

Hi Pascal,

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

the
> with
that
> The rank stretches that a bit since it qualifies where the flow is in 
> the
Network.
forwarding
to do
> > (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 
> > 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?
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf Of Philip Levis
> > > > There is indeed lot of pressure for this in terms of header 
> > > > sizes and energy
> > > 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
> > > Could implementers who are encountering this pressure comment? I'm 
> > > a sucker for and easily swayed by quantitative data as well as 
> > > > Simply we believe more in practical engineering and ML 
> > > > discussions than we
> > > trust in crystal balls.
> > >
> > > significant problems in the future. I agree this is a tradeoff -- 
> > > in my personal opinion,
> > nothing

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 08:10:02 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:

    PT> The flow label is not protected by any IPSec so it cannot be
    PT> used as a backchannel end-to-end. Now that would be a hack.  

I'm not sure where a back/convert channel is mentioned in the thread.

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 08:16:56 -0400

Adrian Farrel <[email-masked]> wrote:
    AF> I guess I need to look at this in more detail (it always helps to read the
    AF> draft) this still sounds exactly like label switching.

It sure looks like it at first.

However, labelled switching uses the label to get across a series of
routers.. The label mostly denotes a specific path which the source has
chosen.  Labelled switching is therefore a form of source route (except
that the source route is abstracted).

The presence of this label in RPL does not pick a route, rather it picks
one routing table among many.  It is therefore more akin to the DSCP
than the MPLS label, but even that's not correct.

RPL is doing storing mode (LPM at each hop), or non-storing mode (source
routing) at each hop regardless of the label.  The label picks a DODAG.
It's probably more relevant to storing mode where there is an evaluation
(longest-prefix-match) at each hop, and when there are multiple DODAG,
there are multiple fib.

-- 
Michael Richardson
-on the road-

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Oct 2012 13:50:28 +0100

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

> Sent: 25 October 2012 07:53
> To: [email-masked]; 'John E Drake'; [email-masked]
> 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.
identify the
> flow and direct the forwarding decision made at the next router.

---

From: John E Drake <[email-masked]>
Date: Thu, 25 Oct 2012 14:14:55 +0000

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

> Sent: Thursday, October 25, 2012 5:50 AM
> To: 'Pascal Thubert (pthubert)'; John E Drake; [email-masked]
> 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.
> 
> (Which is entirely different from considering whether this is a good
> idea or not, on which I have no position :-)
> 
> Adrian
> 
> > *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.
> >
> > IOW, the instance is more like a topology index for the RIB/FIB
> lookup
> > that
> still
> > needs to take place.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> > I guess I need to look at this in more detail (it always helps to
> read
> > the
> > 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
> >
> > > The rank stretches that a bit since it qualifies where the flow is
> > > in the
> > Network.
> > > > Behalf Of Pascal Thubert (pthubert)
> > > > 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
> > > >
> > > > Behalf Of Adrian Farrel
> > > > 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
> > > >
> > > > > 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
> > > > > will increase energy consumption? It the belief that it will
> > > > > lead to sub-packet
> > > > fragmentation in
> > > > > 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.
> > > > >
> > > > > significant problems in the future. I agree this is a tradeoff
> > > > > -- in my personal opinion,
> > > > nothing

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2012 11:04:55 -0400

Philip Levis <[email-masked]> wrote:

    PL> What if an end-host outside the RPL instance wants to use a flow
    PL> label for its own purposes? It might think that a flow denotes a
    PL> stream of associated packets to a node within a RPL instance, not
    PL> the OF that instance happens to use.  

I presume that this end-host is interacting with the LLN in some way
(or the question is irrelevant)
When the packets arrive at the gateway, a 6in6 header is added.