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

"Pascal Thubert (pthubert)" <> Mon, 18 August 2014 10:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C19881A03A7; Mon, 18 Aug 2014 03:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.569
X-Spam-Status: No, score=-14.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, 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 wGfMG2m53rdu; Mon, 18 Aug 2014 03:06:15 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDA611A03A6; Mon, 18 Aug 2014 03:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3633; q=dns/txt; s=iport; t=1408356376; x=1409565976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sBLDQrNzuw5RnVjBaLMW5qHxdD0jl6tnDGod3YtooL8=; b=TdTw+1cO2UafMqjBVz/+PUGubZhbZxKahwsaaRZ/U+qxoj7CVDTGp4pB kav3CqtF+ya/RCrnFIXGSq6GBrr3QGOjPg6KGiWZZMFMTdwM3XjwwzLua x6zEgm2g3yrB41GUT4hqxI+Erw3Y/LvKlcvkVWFOl51ndHSZLJfQwd7WA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,885,1400025600"; d="scan'208";a="348273976"
Received: from ([]) by with ESMTP; 18 Aug 2014 10:06:15 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s7IA6DfQ021839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 10:06:13 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 05:06:13 -0500
From: "Pascal Thubert (pthubert)" <>
To: Michael Richardson <>, Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPuswKNbfwRx2Yk0qsf2NSaa5I/A==
Date: Mon, 18 Aug 2014 10:06:12 +0000
Deferred-Delivery: Mon, 18 Aug 2014 10:06:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <E045AECD98228444A58C61C200AE1BD842D3E864@xmb-rcd-x01> <>
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: "" <>, 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: Mon, 18 Aug 2014 10:06:16 -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.



> -----Original Message-----
> From: ipv6 [] On Behalf Of Michael Richardson
> Sent: dimanche 17 août 2014 00:08
> To: Routing Over Low power and Lossy networks
> Cc: 6man WG; WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> Pascal Thubert (pthubert) <> 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 <>, Sandelman Software Works
> -= IPv6 IoT consulting =-