Re: [Roll] [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts

"Pascal Thubert (pthubert)" <> Wed, 17 September 2014 07:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C1CE51A0310; Wed, 17 Sep 2014 00:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Status: No, score=-16.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mrSjACaV3H3w; Wed, 17 Sep 2014 00:48:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B2801A00D4; Wed, 17 Sep 2014 00:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1885; q=dns/txt; s=iport; t=1410940122; x=1412149722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ryt3LJpKvDVh2ykmMIUIsRBLuuDXlftDoBR5Rx6Eoj4=; b=FBZQrJCkUBHsw0GCA4Wcr6JqGRVHn7UfiPFIPIcRE+kZ49Gfp3HfWpO1 1NrnnFM9W090OYZL0+lR7moyzPWYjhaxbldyb9V1GYmq07gDHcpV1MX3M MfxtCye9STKShdwg3j9dgWSJvuHIV2NsNdFoSCGgp2v6AYV8HaGZ9+ej9 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,539,1406592000"; d="scan'208";a="78602010"
Received: from ([]) by with ESMTP; 17 Sep 2014 07:48:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s8H7mf7b009611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Sep 2014 07:48:41 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 02:48:41 -0500
From: "Pascal Thubert (pthubert)" <>
To: Carsten Bormann <>
Thread-Topic: [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts
Thread-Index: AQHP0kJzH1qZ2czsj0ybHQLexU1vAZwE7hTQ
Date: Wed, 17 Sep 2014 07:48:40 +0000
Deferred-Delivery: Wed, 17 Sep 2014 07:48: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 <>, "" <>
Subject: Re: [Roll] [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts
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: Wed, 17 Sep 2014 07:48:43 -0000

Hello Carsten:

The split and domain-dependent use of the Flow Label field was still on the table in the RFC 6437 discussions. This was rejected as a general rule but we still need an exception to RFC 6437 for LLNs so let us see what we get there.

I can still agree with you to progress on a 6lo NHC proposal and produce the best personal submission we can for WG evaluation. This in turn does not mean that 6lo will adopt the work or that ROLL will favor that option. 

I suggest we focus discussions on the relevant MLs:
- 6MAN on whether we can avoid having to set and/or carry a field of randomized 20 bits in the LLN  then eventually rewrite it for LLN purpose
- ROLL to decide whether to use a ROLL solution (based on FL is the only one on the table) or wait for 6lo to deliver
- 6Lo to decide whether and how to compress the RPL option (3 proposals on the table)

In any case copying 6TiSCH, which depends on the overall result to deliver the minimal draft, is a good idea.



> -----Original Message-----
> From: Carsten Bormann []
> Sent: mercredi 17 septembre 2014 08:42
> To: Pascal Thubert (pthubert)
> Cc:;
> Subject: Re: [6lo] [6tisch] Fwd: Comparison of 6lo-rpl drafts
> On 17 Sep 2014, at 07:46, Pascal Thubert (pthubert) <>
> wrote:
> > we have one free bit there
> It's not free, all 20 bits of the flow label are the flow label.
> (Again, we can argue dedicating the field that way in 1994, and keeping it
> that way even while nibbling off bits for other uses, was bad protocol design,
> but that's water under the bridge.)
> I would prefer to stop wasting time on trying to hijack the flow label and
> instead finish the work on an NHC representation.
> Grüße, Carsten