Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Aug 2014 03:19:12 +0200

On 13 Aug 2014, at 01:38, Brian E Carpenter <[email-masked]> wrote:

> Can you perhaps clarify the exact question you are asking 6man?

Well, I’m not Ines, but I’m trying to find out why we are in this peculiar position of discussing this draft right now.

ROLL has a routing protocol that requires some data to be shipped around together with IP packets.
RFC 6553 and 6554 define ways to do this that are consistent with the IP architecture.
Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, and in this area of application, that matters.

Normally, the next step would have been looking at ways to do header compression.
We did talk about compressing ROLL, but with a view to compressing the (control plane) ROLL messages, not so much about the (data plane) IP packets themselves.  GHC is trying to be a reasonably useful, but also reasonably general way to do the control plane messages.

For the data packets, the flow label (and its now predominant non-use) provides an attractive hole in the IPv6 packets to ship around the RFC 6533 information, but not the RFC 6554 information.
In 6lo networks, normally RFC 6282 compresses away empty flow labels, but it is cheap to put them in, so a flow label really only costs 3 bytes (instead of 8 bytes RFC 6553 costs).  The most useful information from RFC 6553 can be stuffed into 19 bits, as demonstrated by the draft we are discussing here.

RFC 6282 has extension points (GHC uses one of them), but not really useful ones for the ROLL data plane.
So it appears it never occurred to us that the best way to handle these 19 bits is to actually sidestep RFC 6282, and use the existing extension points of RFC 4944.  Until Laurent showed one way of doing this.  I just went from there and did a strawman using Laurent’s idea for compressing the RFC 6553 option, in a way that is as efficient as (or, in most cases, actually more efficient than) using the flow label hole.

So to me it seems there no longer is a good technical argument to ask 6man to liberate the flow label for carrying RFC 6553.
But that is maybe something that should now be discussed between 6lo and ROLL; I don’t think that this is a 6man issue (unless the answer is a simple “sure, go ahead, take it, we don’t need it any more anyway”, which is not what I have perceived RFC 6437 to say).
When 6lo and ROLL have generated consensus on the need to do this, we may or may not want to go back to 6man and actually pry that flow label hole out of your fingers.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Aug 2014 16:48:06 +0000

Hello Carsten:

In my view, this work is not competing with 6lo: for the specific value of keeping the draft whatever 6lo decides to do:

- If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved. There is no way a device will waste 20 bits for a random that has no value inside the LLN. The text tells the RPL root to set the flow label.

- If this draft is not adopted, the root of the LLN will have to forward the flow label coming from the Internet down to the end destination device, deep in the mesh, wasting 20 bits in each frame. These is a waste that 6lo compression will not be allowed to legally elide if today we decide that we do not allow it. Note: even if the correspondent sets the FL to zeroes to help the LLN, there is no way to guarantee that the flow label will not be set on the way since that much is lawful. 

- If the draft is not adopted, existing usages in shipping standards that incorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes the way ISA100.11a uses the flow label for a stateful flow identification within the ISA100 domain.

- If the draft is not adopted, we have no leverage over WCI that is defining the backbone router for ISA100.11a devices. The draft indicates that the root should ensure that the flow label is correctly set when going outside, which is a minor increment to WCI, if pushed in due time with a proper RFC number that demands it. 

The need for this work was agreed at ROLL. We need a better solution than available, for application in RPL domains, that are often but not necessarily congruent with 6LowPAN domains.

I'm fully supportive to have a 6lo compression that will improve the situation for a 6lowpan network, and at this point we have 3 proposals on the table, Laurent's, yours, and mine, which is to have a routing dispatch for route-over in parallel to the mesh dispatch that is mesh-under. I do hope we create a momentum there and converge. But there is no guarantee.

All in all, I will not drop something that works now, with running code and all, and reached last call status, against the sirens of a compression that will not solve the issues above.

Cheers,

Pascal

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: mercredi 13 août 2014 03:19
> To: Routing Over Low power and Lossy networks
> Cc: Ines Robles; 6man WG; [email-masked] WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> Well, I'm not Ines, but I'm trying to find out why we are in this peculiar
> position of discussing this draft right now.
> 
> We did talk about compressing ROLL, but with a view to compressing the
> (control plane) ROLL messages, not so much about the (data plane) IP
> packets themselves.  GHC is trying to be a reasonably useful, but also
> reasonably general way to do the control plane messages.
> 
> For the data packets, the flow label (and its now predominant non-use)
> provides an attractive hole in the IPv6 packets to ship around the RFC 6533
> information, but not the RFC 6554 information.
> In 6lo networks, normally RFC 6282 compresses away empty flow labels, but
> it is cheap to put them in, so a flow label really only costs 3 bytes (instead of
> 8 bytes RFC 6553 costs).  The most useful information from RFC 6553 can be
> stuffed into 19 bits, as demonstrated by the draft we are discussing here.
> 
> So it appears it never occurred to us that the best way to handle these 19
> bits is to actually sidestep RFC 6282, and use the existing extension points of
> RFC 4944.  Until Laurent showed one way of doing this.  I just went from
> there and did a strawman using Laurent's idea for compressing the RFC 6553
> option, in a way that is as efficient as (or, in most cases, actually more
> efficient than) using the flow label hole.
> 
> So to me it seems there no longer is a good technical argument to ask 6man
> to liberate the flow label for carrying RFC 6553.
> But that is maybe something that should now be discussed between 6lo and
> ROLL; I don't think that this is a 6man issue (unless the answer is a simple
> "sure, go ahead, take it, we don't need it any more anyway", which is not
> what I have perceived RFC 6437 to say).
> When 6lo and ROLL have generated consensus on the need to do this, we
> may or may not want to go back to 6man and actually pry that flow label
> hole out of your fingers.
> 
> Grüße, Carsten
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Ralph Droms <[email-masked]>
Date: Wed, 13 Aug 2014 15:49:45 -0400

On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis <[email-masked]> wrote:

> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> This seems to me to be the strong technical argument in favor of the draft. While Carsten's approach seems better technically, it only works for 6lowpan, and RPL should be independent of the underlying link layer.

Could we consider Carsten's approach a compression mechanism for the RPL information options, rather than a replacement, thereby allowing a one-to-one translation between compressed mode on 6lowpan networks and uncompressed mode in other networks?

- Ralph

> Phil
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Wed, 13 Aug 2014 12:07:04 -0700

On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

> If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved.

Pascal, I'm trying to reconcile your claim that the goal of 6437 is to allow enclosed networks to use the flow label with Brian's statement

> Actually that's why I don't want to see a formal
> update to 6437, because the only rational update would be to allow
> any closed domain to invent its own usage. We had that argument at
> length during the development of 6437, and decided against it.

Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 13 Aug 2014 12:11:48 -0700

Phil

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2014 08:52:56 +1200

>> length during the development of 6437, and decided against it.

Right. I'm drawing a very subtle line between (a) stating an exception
to 6437 for this particular usage and (b) opening the door to other
usages. Since 6man clearly didn't want (b) during the development of
6437 I think we do need to limit ourselves to (a).

    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Aug 2014 23:02:30 +0200

>> This seems to me to be the strong technical argument in favor of the draft. While Carsten's approach seems better technically, it only works for 6lowpan, and RPL should be independent of the under…

The transport of RPL specific information for data plane packets already *is* independent of the underlying link layer, as specified in RFC 6553 and RFC 6554.  All we are talking about here is an optimization for those (for 6553, specifically; actually 6554 is probably the one even more in need).

> Could we consider Carsten's approach a compression mechanism for the RPL information options, rather than a replacement, thereby allowing a one-to-one translation between compressed mode on 6lowpan…

Indeed, that is probably the best way to view this approach.
(In the next version of the draft, I’ll emphasize this.)

My assumption here is:
— Any subnet that could not live with transporting RFC 6553 as is, i.e. 8 bytes extra compared to the flow label approach (for uncompressed packets*), already needs (and, at this point, has) a header compression solution for the expansive IPv6 header anyway.
  So adding RFC 6553 compression to that solution is the natural approach.
— All subnets that can live with the IPv6 header as is, also can live with RFC 6553 as is.

This argument is on a technical level.
I’m not talking about cognitive dissonance**) here, or political issues.
If there are important political issues (I have no idea what the ISA100/WCI talk is about), they probably need to be brought out in the open here.

Grüße, Carsten

*) less difference for header-compressed packets, e.g., 5 bytes for 6lo.
**) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, section 2.6

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Aug 2014 08:54:33 +0000

Agreed, Ralph.

The work at 6lo would result in a one-to-one equivalence between a compressed and an uncompressed packet, including the case where the packet has a RPL option, or a RH. The flow label draft makes equivalent a packet with a 0 flow label and a RPL option, and a packet with a flow label set as indicated, so it is effectively another form of compression that is applicable in any RPL domain, but only compresses the RPL option.

If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo way against the flow label way.

Cheers,

Pascal

> From: 6lo [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: mercredi 13 août 2014 21:50
> >> The need for this work was agreed at ROLL. We need a better solution
> than available, for application in RPL domains, that are often but not
> necessarily congruent with 6LowPAN domains.
> >
> > This seems to me to be the strong technical argument in favor of the draft.
> While Carsten's approach seems better technically, it only works for
> 6lowpan, and RPL should be independent of the underlying link layer.
> 
> Could we consider Carsten's approach a compression mechanism for the RPL
> information options, rather than a replacement, thereby allowing a one-to-
> one translation between compressed mode on 6lowpan networks and
> uncompressed mode in other networks?
> 
> - Ralph
> 
> >
> > Phil

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 11:05:12 +0200

> If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo way against the flow label way.

It is a bit more complicated.

If both representations of the RFC 6553 information are in use:
A compressor may need to decide whether a flow label present in an uncompressed packet is an RFC 3697 flow label or one of these.
A decompressor may need to decide whether the information is to be represented in canonical RFC 6553 form or making use of the flow label hack.

In any case, I’m not a big fan of providing two different ways of doing the same thing, at different layers.
In particular not in the constrained environment.

I really would like to hear a technical argument why the flow label hack is needed.
(Or a political one, if that is the reason.)

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Aug 2014 10:07:03 +0000

> I really would like to hear a technical argument why the flow label hack is needed.

? Then you probably missed most of my mail from yesterday ?
? The sentence is a rhetorical abuse - like "our just cause" as opposed to "our cause is just" which can be argued -, and there is no consensus that the flow label technique is a hack ?
 
Answering both pending mails from you; I'll rephrase, but please give a second glance at my previous mail where I made 4 points and you responded to only one.

In short, a 6lo compression draft will not achieve all the purposes of the draft, it will not achieve the same compression, and the use case will not be fully congruent.

For instance, the draft is asking 6MAN the right to reset a flow label at the ingress RPL domain. Without this right, a flow label coming from the Internet will be transported in the RPL domain or (more probably) implementation will voluntarily fail to conform 6437, and elide them regardless. I'd rather have a realistic rule that sets the expectations right.

We disagree on the argument that both approaches save the same bits and always result in frames of a same size is technically incorrect. In the scenario above, the flow label draft saves 20 bits that a 6lo compression cannot save without the blessing that is being asked here, and the 6lo approach will need signaling bits that are implicit in the flow label, thus consuming extra space. OTOH, the 6lo approach could compress the instanceID and save bits there - not sure I'd play more with the rank as your version suggests. 

Another disagreement is on your assumption that compression is the only reason for preferring the flow label technique. We have an IOS implementation that is not for use in 6LoWPAN networks, and relies on the (stateful) storing mode. HbH has known issues in classical routers, makes the header chain longer and requires silicon processing or punt, so there are reasons not to use it there either. OTOH making a routing decision that takes the flow label into account is quite natural, this is what load balancers will do at the core. We have prototyped indexing the VRF with the RPL instance in the flow label, and it works like a charm.

And even if compression is the reason why the flow label is used, RPL is a rather new routing protocol and we do not know what the world will make of it. For all I know it may be deployed in RoHC environments to aggregate femtocell traffic for instance. Assuming that the compression will always be 6LoWPAN is short sighted.

And there is no "politics", but external SDOs that base their work on our RFCs and that we need to treat with all respect. Facts:
- ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a stateful indicator of the flow (called a contract ID). We need to be clear on how we position this WRT 6437 now that we shipped it. The draft makes that legal, as long as we extend the RPL domain to an ISA100 domain as well.
- We can promote behaviors in WCI (e.g. reset the flow label to something valuable to the Internet at large at the backbone router) but then we need to document them in an RFC that they can reference.

I agree that multiple techniques is not a good idea, mostly in LLNs. Sadly the HbH is already there, uncompressed, and implemented in shipping devices. So the argument would stall the situation and we cannot have that. What I'd rather do is have the 6lo proposal converge the format with the FL, so the logic to parse is common. Finding it in the packet is not the complex piece anyway.

If we still disagree then we can talk one-to-one, the lists are probably overwhelmed with this thread, and come back when we reach an agreement. We can also talk about the compression logic if you like. I can setup a webex.

Cheers,

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: jeudi 14 août 2014 11:05
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms; Routing Over Low power and Lossy networks; Ines Robles;
> 6man WG; [email-masked] WG
> A compressor may need to decide whether a flow label present in an
> uncompressed packet is an RFC 3697 flow label or one of these.
> A decompressor may need to decide whether the information is to be
> represented in canonical RFC 6553 form or making use of the flow label hack.
> 
> In any case, I'm not a big fan of providing two different ways of doing the
> same thing, at different layers.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Aug 2014 10:28:36 +0000

We can live with this Brian, 

but then I can we add at least an ISA100.11a network? ISA100.11a was designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to indicate which flow a packet belongs to. In more details, devices are provisioned with per-flow behavior (including routing) and settings in what is called a contract. The contractID is carried in the IPv6 flow label.

If so should we name ISA100 specifically or use a more vague description like a "RPL or similar LLN domain" 
We'll note that resetting an flow label that comes from the Internet is a generic need is that flow label was set according to 6437, cannot be trusted to be untempered with, 

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: mercredi 13 août 2014 22:53
> To: Philip Levis
> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
> [email-masked] WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> >> If this draft is not adopted, the flow label from LLN will probably stay all
> zeroes as it is today and the goal of 6437 will not be achieved.
> >
> > Pascal, I'm trying to reconcile your claim that the goal of 6437 is to
> > allow enclosed networks to use the flow label with Brian's statement
> >
> >> Actually that's why I don't want to see a formal update to 6437,
> >> because the only rational update would be to allow any closed domain
> >> to invent its own usage. We had that argument at length during the
> >> development of 6437, and decided against it.
> >
> > Phil
> 
> Right. I'm drawing a very subtle line between (a) stating an exception to 6437
> for this particular usage and (b) opening the door to other usages. Since
> 6man clearly didn't want (b) during the development of
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 13:29:20 +0200

> ? The sentence is a rhetorical abuse - like "our just cause" as opposed to "our cause is just" which can be argued -, and there is no consensus that the flow label technique is a hack ?

Oh, OK, I was using this as a technical term.  The Internet works because of a set of hacks piled on hacks.
Generally, most people would agree that an instance of “there are some bits that aren’t used very much — lets put our stuff there” is a hack.
But we don’t need consensus on that word, in particular if you perceive it as pejorative.

> For instance, the draft is asking 6MAN the right to reset a flow label at the ingress RPL domain. Without this right, a flow label coming from the Internet will be transported in the RPL domain or…

OK.  That is a completely different thing.
I certainly would support a “license to drop” draft that says “a highly constrained network can discard the information in flow labels”.
(Maybe with some more context.  Just as RFC 6282 allows discarding UDP checksums in certain well-defined cases.)

But that is not an argument at all for storing anything different in those 20 bits.

> Another disagreement is on your assumption that compression is the only reason for preferring the flow label technique. We have an IOS implementation that is not for use in 6LoWPAN networks, and re…

Now it gets interesting.
I have another draft whose main content could be summarized as “hop-by-hop options don’t seem to work, now what”.
So why did we do RFC 6553?  That was a big mistake, no?
We need to do the things hop-by-hop options were defined for, for a number of purposes.  
This is not being helped by usurping the last free 20 bits in the header for one, and only one, of those purposes.

> And even if compression is the reason why the flow label is used, RPL is a rather new routing protocol and we do not know what the world will make of it. For all I know it may be deployed in RoHC e…

Since ROHC is all about flows, it indeed is very good in completely compressing away static flow labels.
ROHC also is very good in completely compressing away static extension headers.
I haven’t done the math, but I don’t see a winning argument here.
In any case, my argument was that the header compression scheme should handle this, and, either way, ROHC already does!

More importantly, if RPL becomes applicable outside the constrained environment, the arguments that are being made about the requirements of (stubby) constrained environments no longer apply.

In any case: YAGNI.

> - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a stateful indicator of the flow (called a contract ID). We need to be clear on how we position this WRT 6437 now that we shipp…

I don’t know that a ISA100.11a contract ID is compatible with the proposed flow-label encoding of RFC 6553.
But support for this usage could go with “license to drop” into a draft about constrained node network usage of flow labels.
(In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing here; it mentions ISA100.11a only in the introduction.)

> - We can promote behaviors in WCI (e.g. reset the flow label to something valuable to the Internet at large at the backbone router) but then we need to document them in an RFC that they can referen…

That seems to be the above argument about “license to drop", which is again completely independent from the desire to compress RFC 6553.

                                  .oOo.

I won’t continue belaboring this on the three mailing lists here.
(One reason being that I’m going on vacation.)

My main point for 6man was that going down the “let’s appropriate the flow label for this” route is not at all inevitable.
(There also are some good contributions from this discussion for the ongoing quest for a good, deployable use for flow labels.)

For 6lo, the observation is that there is a place for header compression beyond RFC 6282, and that it is easy to get even better compression for RFC 6553 in the RFC 4944 framework.

For ROLL, my advice would be to take another look at RFC 6554, and see how that would be compressed in a 6lo context.  Most importantly, is there really a need for the “segments left" construction, or can the waypoints be discarded once visited.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Aug 2014 12:20:54 +0000

And my conclusion to 6MAN is that the changes of rules that are requested in the draft are useful whether or not people are willing to use the flow label as the transport for the RPL option inside the RPL domain. Since this is the question on the table for 6MAN, I think that the answer is now clearly a yes.
  
Left will be the conclusion on whether the use of the flow label to carry the RPL option is a good idea or not. I guess the answer belongs to ROLL and the last call there.
If Carsten's arguments prevail, I can extract the 6553 compression from the draft to keep the new rules separate from the particular usage of transporting 6553 flow information. 

Cheers,

Pascal

> Sent: jeudi 14 août 2014 13:29
> > ? The sentence is a rhetorical abuse - like "our just cause" as opposed to
> "our cause is just" which can be argued -, and there is no consensus that the
> flow label technique is a hack ?
> 
> Generally, most people would agree that an instance of "there are some bits
> that aren't used very much - lets put our stuff there" is a hack.
> But we don't need consensus on that word, in particular if you perceive it as
> pejorative.
> 
> > For instance, the draft is asking 6MAN the right to reset a flow label at the
> ingress RPL domain. Without this right, a flow label coming from the Internet
> will be transported in the RPL domain or (more probably) implementation
> will voluntarily fail to conform 6437, and elide them regardless. I'd rather
> have a realistic rule that sets the expectations right.
> 
> I certainly would support a "license to drop" draft that says "a highly
> constrained network can discard the information in flow labels".
> (Maybe with some more context.  Just as RFC 6282 allows discarding UDP
> checksums in certain well-defined cases.)
> 
> > Another disagreement is on your assumption that compression is the only
> reason for preferring the flow label technique. We have an IOS
> implementation that is not for use in 6LoWPAN networks, and relies on the
> (stateful) storing mode. HbH has known issues in classical routers, makes the
> header chain longer and requires silicon processing or punt, so there are
> reasons not to use it there either. OTOH making a routing decision that takes
> the flow label into account is quite natural, this is what load balancers will
> do at the core. We have prototyped indexing the VRF with the RPL instance
> in the flow label, and it works like a charm.
> 
> Now it gets interesting.
> I have another draft whose main content could be summarized as "hop-by-
> hop options don't seem to work, now what".
> > And even if compression is the reason why the flow label is used, RPL is a
> rather new routing protocol and we do not know what the world will make
> of it. For all I know it may be deployed in RoHC environments to aggregate
> femtocell traffic for instance. Assuming that the compression will always be
> 6LoWPAN is short sighted.
> 
> I haven't done the math, but I don't see a winning argument here.
> In any case, my argument was that the header compression scheme should
> handle this, and, either way, ROHC already does!
> 
> More importantly, if RPL becomes applicable outside the constrained
> environment, the arguments that are being made about the requirements of
> (stubby) constrained environments no longer apply.
> 
> In any case: YAGNI.
> 
> > And there is no "politics", but external SDOs that base their work on our
> RFCs and that we need to treat with all respect. Facts:
> > - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a
> stateful indicator of the flow (called a contract ID). We need to be clear on
> how we position this WRT 6437 now that we shipped it. The draft makes
> that legal, as long as we extend the RPL domain to an ISA100 domain as well.
> 
> I don't know that a ISA100.11a contract ID is compatible with the proposed
> flow-label encoding of RFC 6553.
> But support for this usage could go with "license to drop" into a draft about
> constrained node network usage of flow labels.
> (In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing here;
> it mentions ISA100.11a only in the introduction.)
> 
> > - We can promote behaviors in WCI (e.g. reset the flow label to something
> valuable to the Internet at large at the backbone router) but then we need
> to document them in an RFC that they can reference.
> 
> That seems to be the above argument about "license to drop", which is
> again completely independent from the desire to compress RFC 6553.
> 
>                                   .oOo.
> 
> I won't continue belaboring this on the three mailing lists here.
> (One reason being that I'm going on vacation.)
> 
> My main point for 6man was that going down the "let's appropriate the flow
> label for this" route is not at all inevitable.
> (There also are some good contributions from this discussion for the ongoing
> quest for a good, deployable use for flow labels.)
> 
> For 6lo, the observation is that there is a place for header compression
> beyond RFC 6282, and that it is easy to get even better compression for RFC
> 6553 in the RFC 4944 framework.
> 
> For ROLL, my advice would be to take another look at RFC 6554, and see how
> that would be compressed in a 6lo context.  Most importantly, is there really
> a need for the "segments left" construction, or can the waypoints be
> discarded once visited.
> 
> Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Aug 2014 21:59:46 +0200

I have updated the RPL Information Header draft (new title, old draft name*):
Thank you all for a lot of helpful input.

Htmlized:       http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-bormann-6lo-rpl-mesh-01

This now contains a lot more discussion and background information about what it is trying to do.
(There are no technical changes from the Aug 01 version -00, but there is a second page describing it in more detail.)

This draft is both intended as a response to the WGLC referenced in the subject and as a proposal to the 6lo working group to pick this up as a working group item.  (Clearly, if we do this, we’ll want lots of input from ROLL whether we are doing the right thing, while it is 6lo’s job to do the thing right.  No changes to the IP architecture are required, so there is no need to bother 6man with this work.)

Heads up: I’ll have limited E-Mail access Aug 16 to Sep 3.

Grüße, Carsten

*) There is always so much confusion when a draft name is changed and the numbering starts at -00 again.
We can choose a better draft name for draft-ietf-6lo-___, if and when we get there…

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Aug 2014 08:18:26 +1200

On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
> but then I can we add at least an ISA100.11a network? ISA100.11a was designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to indicate which flow a packet belongs to. 

I have no idea what ISA100.11a is or which organisation developed
it, but it sounds like a violation of the flow label standard at that
time (RFC 3697). If I'd known about it, we would probably have included
it in the menagerie of RFC 6294.

There's not much the IETF can do about other organisations that
misuse our standards, although indeed we sometimes need to
document such cases.

   Brian

In more details, devices are provisioned with per-flow behavior (including routing) and settings in what is called a contract.
The contractID is carried in the IPv6 flow label.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 15 Aug 2014 08:51:38 +0000

Hello Brian

I do not think that ISA10011.a violates RFC 3697. What exactly made you believe so?

For all I know ISA100 does everything by the book. Note that ISA100 does not update a non zero FL on the fly since it is not set by a source outside the LLN if that is your concern.

OTOH It may violate RFC 6437 in that the flow is not a random but a value attributed by a PCE called system manager (along rules in section 4). As things stand, we'd certainly want the backbone router at LLN egress to rewrite the FL in packets towards the Internet with a randomized per flow value.

It will violate RFC 6437 because if the flow label is set by a router in the Internet - or an updated source that complies to 6437-, the backbone router at LLN Ingress will rewrite it.

Both issues are addressed in my draft for a RPL domain. An RFC will also hint a revision of the backbone router that it should rewrite the FL on outgoing packets.

What do you think?

Pascal

> Le 14 août 2014 à 22:18, "Brian E Carpenter" <[email-masked]> a écrit :
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Aug 2014 13:12:54 +1200

> I do not think that ISA10011.a violates RFC 3697. What exactly made you believe so?

I was over-interpreting what you wrote, I guess. It's true that 3697 was rather
vague about what it called "flow state establishment methods" and permitted
both sequential and pseudo-random flow label values. Is the ISA10011.a
on line somewhere?

> Both issues are addressed in my draft for a RPL domain. An RFC will also hint a revision of the backbone router that it should rewrite the FL on outgoing packets.

I think that Phil's last message frames the question to 6man correctly,
so I will respond to him...

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Aug 2014 18:07:47 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > And my conclusion to 6MAN is that the changes of rules that are
    > requested in the draft are useful whether or not people are willing to
    > use the flow label as the transport for the RPL option inside the RPL
    > domain. Since this is the question on the table for 6MAN, I think that
    > the answer is now clearly a yes.

Should we split the issue up?
1) blessing/permission/exception to reset flow label within an LLN,
   (which would include simply setting it to zero so it can be compressed
   out)

2) a document on how to compress 6553 HbH into ?flow-label vs ?6lo-HC.

   I am not enthusiastic about multiple ways.
   We will have an existing problem of figuring out 6553 vs new-way,
   and also noting that some nodes will needed to continue to speak 6553
   on some links anyway (backhaul ethernet).

    >> it mentions ISA100.11a only in the introduction.)

My understanding is that ISA100.11a uses the flow label to pick a path,
but not in a way that involves rewritting it on each hop in the LLN.
Please correct me if I'm wrong; it seems that document (1) is needed to
retro-actively bless ISA100.11a usage :-)

[I'm writing this on a rainy Saturday afternoon, at a friend's house,
playing 1st Ed AD&D, and my two characters are unconcious... so when I use
the term "bless"... you'll understand the context]

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Aug 2014 18:12:09 -0400

Carsten Bormann <[email-masked]> wrote:
    > This draft is both intended as a response to the WGLC referenced in the
    > subject and as a proposal to the 6lo working group to pick this up as a
    > working group item.  (Clearly, if we do this, we’ll want lots of input
    > from ROLL whether we are doing the right thing, while it is 6lo’s job
    > to do the thing right.  No changes to the IP architecture are required,
    > so there is no need to bother 6man with this work.)

I think that we still need a blessing to reset the flow label to zero upon
entering the LLN, so that it can be nicely compressed out.  I think that we
have that blessing.   Please see my other email suggesting a split.

    > Heads up: I’ll have limited E-Mail access Aug 16 to Sep 3.

In your absense I am interested to hear from others about any preference
about technical solutions.  Please speak up.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Aug 2014 10:06:12 +0000

Hello Michael;

The discussion was difficult enough with 2 WGs (just keeping clear on which WG was asked what question).
Now Carsten has broadened the discussion to 6lo and thus the complexity. 
In practice the discussion also impacts 6TiSCH because 6TiSCH will ship the minimal RPL over TSCH to IESG this year (draft-ietf-6tisch-minimal).

I'm not fan of 2 ways either. But we have to face that unless we keep the HBH-based approach only (which is doubtlessly the worst possible outcome), then we are already in that situation for some implementation(s).

For the lack of any other (pending) RFC, the 6TiSCH minimal draft will have point on the HbH-based approach and that approach will spread to 6TiSCH as well, where it hurts the most due to the very small frame size. And then there will have to be a deprecation and a migration to whatever ROLL and 6lo decide to do. I'd rather have the starting point be the flow label and then decide if we really want something else for 6TiSCH, what that something else is and if that something else is actually beneficial, which is not a done deal yet.

In any fashion, I think that we all agree that we need 6MAN to allow the border router (RPL root) to update the Flow Label. So I'm in full agreement with you that the complexity we are now facing can be better addressed by splitting the draft. One 6MAN-only draft that allows ROLL to do what the current draft does, and one ROLL draft that does it. At that point it will be up to ROLL (only) to standardize the second draft immediately or to wait and see whatever progress happens at 6lo.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: dimanche 17 août 2014 00:08
> Cc: 6man WG; [email-masked] WG
> My understanding is that ISA100.11a uses the flow label to pick a path, but
> not in a way that involves rewritting it on each hop in the LLN.
> [I'm writing this on a rainy Saturday afternoon, at a friend's house, playing
> 1st Ed AD&D, and my two characters are unconcious... so when I use the
> term "bless"... you'll understand the context]
> 
> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Aug 2014 12:51:41 +0000

Hello Brian:

I do not think that you can freely download the specification. You probably need membership first. The links exist from the Wikipedia page but they are broken. Same goes for the IEC version which is IEC 62734, but if you have access to the IEC then the current work is here http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=65C&format=pdf&type=_CDV&file=735ea.pdf

Quotes: 

"The ContractID is associated with a particular D-route. This may be used when a particular graph or source D-route is intended to provide a defined level of service"

"FlowLabel: The lower order 16 bits of the FlowLabel shall be set to ContractID. The higher order 4 bits shall be all zeros. This field shall only be present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC encoding."

Note that the 6TiSCH architecture echoes this design, and a d-route is very similar to a 6TiSCH track.

For the sake of history and to my best knowledge, ISA100.11a was the first industrial standard to adopt IPv6 for process control applications (control loops and monitoring). 
It is effectively enabling IP in the control network, which is an historical step toward the IT/OT convergence, that is the Industrial equivalent of voice and video convergence over IP.

And also to my best knowledge and conforming RFC 3697, ISA100.11a does not mute the Flow Label inside the network, as Michael points out. Only when the additional backbone Router functionality is defined does the problem of rewriting come into play at the Backbone Router (same position as RPL root). For all I know this work is taking place at the Wireless Compliance Institute, WCI, but I do not have the latest.

Cheers,

Pascal

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: samedi 16 août 2014 03:13
> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines Robles;
> 6man WG; [email-masked] WG
> vague about what it called "flow state establishment methods" and
> permitted both sequential and pseudo-random flow label values. Is the
> ISA10011.a on line somewhere?
> 
> > For all I know ISA100 does everything by the book. Note that ISA100 does
> not update a non zero FL on the fly since it is not set by a source outside the
> LLN if that is your concern.
> >
> > OTOH It may violate RFC 6437 in that the flow is not a random but a value
> attributed by a PCE called system manager (along rules in section 4). As
> things stand, we'd certainly want the backbone router at LLN egress to
> rewrite the FL in packets towards the Internet with a randomized per flow
> value.
> >
> > It will violate RFC 6437 because if the flow label is set by a router in the
> Internet - or an updated source that complies to 6437-, the backbone router
> at LLN Ingress will rewrite it.
> >
> > Both issues are addressed in my draft for a RPL domain. An RFC will also
> hint a revision of the backbone router that it should rewrite the FL on
> outgoing packets.
> >
> > What do you think?
> 
> I think that Phil's last message frames the question to 6man correctly, so I
> will respond to him...
> 
> Regards
>     Brian
> >
> > Pascal
> >
> >>> but then I can we add at least an ISA100.11a network? ISA100.11a was
> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label
> to indicate which flow a packet belongs to.
> >> I have no idea what ISA100.11a is or which organisation developed it,
> >> but it sounds like a violation of the flow label standard at that
> >> time (RFC 3697). If I'd known about it, we would probably have
> >> included it in the menagerie of RFC 6294.
> >>
> >> misuse our standards, although indeed we sometimes need to document
> >> such cases.
> >>
> >>   Brian
> >>
> >>
> >> In more details, devices are provisioned with per-flow behavior (including
> routing) and settings in what is called a contract.
> >>> We'll note that resetting an flow label that comes from the Internet
> >>> is a generic need is that flow label was set according to 6437,
> >>> cannot be trusted to be untempered with,
> >>>
> >>> Cheers,
> >>>
> >>> Pascal
> >>>
> >>>
> >>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man
> >>>> WG; [email-masked] WG
> >>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437
> >>>>> is to allow enclosed networks to use the flow label with Brian's
> >>>>> statement
> >>>>>
> >>>>>> because the only rational update would be to allow any closed
> >>>>>> domain to invent its own usage. We had that argument at length
> >>>>>> during the development of 6437, and decided against it.
> >>>>> Phil
> >>>> Right. I'm drawing a very subtle line between (a) stating an
> >>>> exception to 6437 for this particular usage and (b) opening the
> >>>> door to other usages. Since 6man clearly didn't want (b) during the
> >>>> development of
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [email-masked] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Aug 2014 08:31:45 +1200

Hi Pascal,

If we're really going to discuss this, we need the IAB to establish
liaison and get the right to let us all see the specification. I'm not
going to spend my time speculating about a secret document. However,
the bit you quote: "FlowLabel: The lower order 16 bits of the FlowLabel
shall be set to ContractID. The higher order 4 bits shall be all zeros."
certainly seems to violate RFC 6437. Whether it violated the somewhat
confused situation left by RFC 2460 and RFC 3697 is less clear. I have
no recollection of anybody from ISA or IEC talking to the IETF about
this issue.

Regards
   Brian

On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
>>>>>> -