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

"Pascal Thubert (pthubert)" <> Thu, 14 August 2014 10:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 79B571A09D2; Thu, 14 Aug 2014 03:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ENvdtvLcENSR; Thu, 14 Aug 2014 03:07:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 754E21A09C5; Thu, 14 Aug 2014 03:07:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5263; q=dns/txt; s=iport; t=1408010826; x=1409220426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RNg38Eg5JNCEkmYIuYcGjF95xx47XC6PnXyV6dBcl/s=; b=MlD09D7fZVpPC0vcoJ+RZXiRPRSg8OeVOokS+mUtHpQQ+Kw429ju/NJs 5+jLr4nOx/5UXkgqhwlRy7/XGYVzL9ZrLr1NmUwLMaT1yuZNONfI6Kdej Ip02orrYUvtX8kS0DPV/ge026jtvauPWiLMgsQ4tU6z1qn72ipJz+/rG/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="347484258"
Received: from ([]) by with ESMTP; 14 Aug 2014 10:07:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s7EA74Gq028321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 10:07:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 05:07:04 -0500
From: "Pascal Thubert (pthubert)" <>
To: Carsten Bormann <>
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAHkPgwFAAB9osA=
Date: Thu, 14 Aug 2014 10:07:03 +0000
Deferred-Delivery: Thu, 14 Aug 2014 10:06:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Routing Over Low power and Lossy networks <>, Ines Robles <>, 6man WG <>, " WG" <>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Aug 2014 10:07:11 -0000

Hello Carsten:

> 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.



> -----Original Message-----
> From: Carsten Bormann []
> 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; WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) <>
> wrote:
> > 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