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

"Pascal Thubert (pthubert)" <> Wed, 03 December 2014 23:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6B5901ACEDF; Wed, 3 Dec 2014 15:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 rrQhaqjFTdyA; Wed, 3 Dec 2014 15:37:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A27821A1B93; Wed, 3 Dec 2014 15:37:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9848; q=dns/txt; s=iport; t=1417649832; x=1418859432; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vaafSvkC2Kd5RxSG8wdCSHTthOZGJdm5o7m/FQEJl5U=; b=ayJRJHR5hYPFY7JTBK0jcpjFGCxBKnL+rAv0zsdVtoiVXWcVCvxB0sj4 ENK15Q5GnZ+d79P09825NIS5gexl3XuTC/uaEJrJ/q1aKnDRdFeReqg8u ptTZIAfwuYCpI9z6Vd3s7Bao8bVdcBfUJif3nR5tmN+YwaawpKkSNPPHa g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,511,1413244800"; d="scan'208,217";a="377700820"
Received: from ([]) by with ESMTP; 03 Dec 2014 23:37:11 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sB3NbACn004074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 23:37:10 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 17:37:10 -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/yZFWZX4Jx0ey0wgAPpEACAAH86VIACcTaAgAM5E1A=
Date: Wed, 3 Dec 2014 23:37:10 +0000
Deferred-Delivery: Wed, 3 Dec 2014 23:37:00 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A88B15xmbrcdx01ciscoc_"
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: Wed, 03 Dec 2014 23:37:14 -0000

Hello Martin:

One question inspired by this is how would newer dispatch implementations deploy to a legacy dispatch network?  Imagine a large open network spanning a city, with multiple versions of 6lo, and multiple routing protocols running on top.  It's a very academic, futuristic example, but triggers some basic questions like: how is versioning handled in 6lo?  I believe versioning in 6lo currently is always done at deployment time.  It may be worth considering a way to add an optional version dispatch in RHI to signal what version of 6lo is being used, so mixed version networks in the future can have a better chance of coexisting.

[PT] Well, as long as we route, we can interconnect different networks. These could be different technologies like PLC and 15.4, or these could be two 802.15.4 networks, one using the RFC 4944 MH and the other using the LoRH. As long as the IPv6 packet is reformed, routed, and then recompressed to adapt to the 6Lo compression of the outgoing link, we are safe.

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

Only HC1 and HC2 were deprecated from RFC4944 as far as I know.  Deprecating those was the right decision.  There may be more in RFC4944 that can be changed or improved, but the point is that the assumption must be that most of it is in use today, and consideration for those networks that use it should be made.  It sounds like you have been making those considerations, which is appreciated.

[PT] Thanks to you for a large piece.