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

"Pascal Thubert (pthubert)" <> Sun, 10 August 2014 17:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 762B91A0470; Sun, 10 Aug 2014 10:05:45 -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 wp9DyDK7ExnF; Sun, 10 Aug 2014 10:05:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A3E91A0465; Sun, 10 Aug 2014 10:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2649; q=dns/txt; s=iport; t=1407690343; x=1408899943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CMXbo64V9nzRzIRAx8nC5eVBs7dzRZcmgode8wOu/rE=; b=EiWDcCjEJLzPS4YKpM2gDQ2Q8lt5xTmoXu5r3XdlE/qghALJPP4Cq0DW BT0XsnfsXsM7xRm5NNBJGVOX96+jre+Ea3GKrkht30aWhNmKzVQ8xMkDC /aMZpTv1ErTycaqQlH6Chq2zQ0wWDjIrAXf7rL7SC2Xm8MRggpvi1JPAA E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAAym51OtJA2B/2dsb2JhbABagw1SV8xlCodIAYEHFneEBAEBAwEBAQFrCwULAgEIRicLJQIEDgWIOggNwSIXjxkzB4MvgR0FkRmEJYZxgVeTJINcbA
X-IronPort-AV: E=Sophos;i="5.01,837,1400025600"; d="scan'208";a="346448595"
Received: from ([]) by with ESMTP; 10 Aug 2014 17:05:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s7AH5fYp008745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 17:05:41 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 10 Aug 2014 12:05:34 -0500
From: "Pascal Thubert (pthubert)" <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPtLgxSf6MzwEzQpSdG5woHqaOoJvKESgJ
Date: Sun, 10 Aug 2014 17:05:34 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Roll] 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: Sun, 10 Aug 2014 17:05:45 -0000

Hi Carsten

I think you jumped too quickly on my suggestion at 6lo.

It makes a lot of sense to work on a 6lo routing dispatch and in particular enable the compression of all RPL artifacts. 

It will take some time to figure out what goes in there but my suggestion at 6lo includes routing header compression, RPL option, but also source destination if we decide to route fragments. 

I hope this happens and I'll see with Laurent if we use a respin of his draft or I start a new one.

This work will be beneficial in the long run, but doubly fails to address the issues at stake here:

- the draft proposes to update the rules in 6437 with stateful and with domain scoped operations. This is used by the draft itself but also by published and deployed standards that came up before 6437 (eg ISA100.11a) and we are now acknowledging and legalizing a de facto situation.

- it will take a year or 2 at best to agree on the new routing dispatch and its operation. We need an improvement now. And btw we cannot necessarily assume 6lo together with RPL, I know of at least one RPL implementation that does not use that compression. 

Finally, Using a dispatch for the RPL option alone seems like a waste, but that is a discussion for 6lo. I'll publish there when I'm back from vacations.


> Le 10 août 2014 à 18:29, "Carsten Bormann" <> a écrit :
> So far, we have mainly discussed the need for an optimization (it seems we now agree there is a need) and the interaction between the normative components of RFC 6437 and those of the draft at hand.
> I’d now like to bring up a different question:
> Is this the right approach?
> I have written up what appears to be a more natural approach in the strawman draft:
> Why are we doing the flow-label thing and not the more natural thing?
> [ ] because the flow label hack works on packets that leave the 6lo networks.
>    • but do we really need to optimize this on the non-6lo networks?
> [ ] because the flow label hack has been around for a while and is now cast in stone.
>    • is it?
> [ ] because there is a flaw with the way this has been integrated into the 6lo framework.
>    • ______ (fill in the flaw)
> [ ] because ______ (fill in the reason)
> Inquiring minds want to know.
> Grüße, Carsten
> _______________________________________________
> Roll mailing list