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

[Carsten Bormann <[e-mail]>]

On 13 Aug 2014, at 01:38, Brian E Carpenter <[e-mail]> 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