Re: [Roll] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt

"Pascal Thubert (pthubert)" <> Sun, 30 November 2014 09:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0C6EB1A1A2E; Sun, 30 Nov 2014 01:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4ip_7SSZf0QR; Sun, 30 Nov 2014 00:59:58 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2B5C1A1A29; Sun, 30 Nov 2014 00:59:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4666; q=dns/txt; s=iport; t=1417337998; x=1418547598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g8sB9JbFiFr0UE8/Ix/SLgeZyW1P4UNsXt4uiqnOtLY=; b=RbApkfrcriEcMCSkRG3gUqtxJf1v7Fcdm9R9btraD+AEei68Oh5Fzua3 eq3S+oQg+/zlOYk/bFQ+CXdSNAJSIIxgOUt28EYCSwkBCXxiaQihrXxzE GaipSOB0jEHLHrX18IRn0lJwSqAO2DYuN4rFPj+debXVJtJgntvHtnvlv Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,486,1413244800"; d="scan'208";a="101248696"
Received: from ([]) by with ESMTP; 30 Nov 2014 08:59:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sAU8xuob006554 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 08:59:57 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 02:59:56 -0600
From: "Pascal Thubert (pthubert)" <>
To: Martin Turon <>
Thread-Topic: [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
Thread-Index: AQHQCkcKV0+2qTicPkyTS/yZFWZX4Jx0ey0wgAPpEACAAH86VA==
Date: Sun, 30 Nov 2014 08:59:55 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
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] [6tisch] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
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, 30 Nov 2014 09:00:00 -0000

Hi Martin,

The discussion already caused a rethinking of the idea. If it is not enough we can dig further.

The idea as presented in the draft now is not to deprecate the mesh header but to allow in a different network to use the bits differently knowing that devices will have to be homogeneous inside one network.

You were the advocate to protect the future by not consuming too many bits in the NHC proposal. You also realize that the mesh header consumes 1/3 of the whole dispatch space, without a way to extend what's done inside. This is not protecting the future.

The new proposal allows to encode the existing MH with limited change but now it is extensible. The price to pay is different network. And the question to the group is whether that is acceptable.

Even if there are implementations today, RFC 4944 is not an internet std and we have just seen the very beginning of the IoT. Better fix things now than later...


> Le 29 nov. 2014 à 20:24, Martin Turon <> a écrit :
> Hi Pascal,
> I thought the call where this idea of overloading the mesh header was presented was met with general discontent.  
> Also, the rfc4944 calls it the mesh header, it isn't called the mesh-under header.  The mesh header is very much in use today, and not purely for mesh-under conceptual designs.  
> I would be wary of proposals that greatly alter the 6lo header, especially the dispatch bits, rather than extend it in very general ways.
> Martin
>> On Nov 27, 2014, at 6:03 AM, "Pascal Thubert (pthubert)" <> wrote:
>> Dear all:
>> This is a response to the question about the compression of RFC 6553 on top of RFC 6554.
>> It seems exaggerated to consume a dispatch type for the RPL option only. 
>> But here, we introduce a routing header which is the equivalent of the mesh header in RFC 4944; we propose a compressed TLV format that can encode RH3, RPL option, IP-in-IP, and is further extensible, for instance for upcoming  BIER.
>> As it goes, the mesh header consumes 1/3 of all the 6LoWPAN addressable space for application only in Mesh-under. 
>> This draft reuses that space in Route-over with the assumption that Route-over will not co-exist in a sma enetwork with Mesh-under encoded in the RFC 4944 fashion.
>> If there is effectively a need for co-existence, devices have to implement the new Mesh-under format that is also proposed in the draft.
>> Comments welcome,
>> Pascal
>> -----Original Message-----
>> From: [] 
>> Sent: jeudi 27 novembre 2014 14:36
>> To: Pascal Thubert (pthubert); Pascal Thubert (pthubert); Laurent Toutain; Carsten Bormann; Laurent Toutain; Dr. Carsten Bormann
>> Subject: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
>> A new version of I-D, draft-thubert-6lo-routing-dispatch-00.txt
>> has been successfully submitted by Pascal Thubert and posted to the IETF repository.
>> Name:        draft-thubert-6lo-routing-dispatch
>> Revision:    00
>> Title:        A Routing Header Dispatch for 6LoWPAN
>> Document date:    2014-11-25
>> Group:        Individual Submission
>> Pages:        19
>> URL:  
>> Status:
>> Htmlized:
>> Abstract:
>>  This specification provides a new 6LoWPAN dispatch type for use in
>>  Route-over and mixed Mesh-under and Route-over topologies, that
>>  reuses the encoding of the mesh type defined in RFC 4944 for pure
>>  Mesh-under topologies.  This specification also defines a method to
>>  compress RPL Option (RFC6553) information and Routing Header type 3
>>  (RFC6554), an efficient IP-in-IP technique and opens the way for
>>  further routing techniques.  This extends 6LoWPAN Transmission of
>>  IPv6 Packets (RFC4944), and is applicable to new link-layer types
>>  where 6LoWPAN is being defined.
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
>> The IETF Secretariat
> _______________________________________________
> 6tisch mailing list