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

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:6lo-bounces@ietf.org] 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; 6lo@ietf.org WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> 
> On 13 Aug 2014, at 01:38, Brian E Carpenter <brian.e.carpenter@gmail.com>
> 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
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo