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

"Pascal Thubert (pthubert)" <> Thu, 09 July 2015 09:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F0E41A8923; Thu, 9 Jul 2015 02:34:58 -0700 (PDT)
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 TGlCcqLrrrdK; Thu, 9 Jul 2015 02:34:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F14331A8961; Thu, 9 Jul 2015 02:34:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3053; q=dns/txt; s=iport; t=1436434497; x=1437644097; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hvCSKl1u/z7R5R/Co+NFWU03qhPcjkT+ncaMpYRtuvA=; b=WNjyJOMn9ehf8FyX9lfVoEl8A5uDsaYgGz2DPJlAkOeqAucjTNrnFmXk Atm9/8txPyTxqfQEzGaOk9nrlVOuSpEcTOxQMBzYJw9pF/IexW1ZkS+tu zvCwcdXRvthXr1GBeIxewNiKywUcj1Vr5qn5XwqyjqqdRlT63TM5WTzI1 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="13920050"
Received: from ([]) by with ESMTP; 09 Jul 2015 09:33:33 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t699XXDl030834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 09:33:33 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 04:33:33 -0500
From: "Pascal Thubert (pthubert)" <>
To: Routing Over Low power and Lossy networks <>, "" <>, "" <>
Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.txt
Thread-Index: AQHQuPgRmtFqvPNrqkuLEPE0AutfC53S3Kew
Date: Thu, 9 Jul 2015 09:33:32 +0000
Deferred-Delivery: Thu, 9 Jul 2015 09:32:46 +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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-04.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: Thu, 09 Jul 2015 09:34:58 -0000

Hello Timothy:

The premise is that you do not get a stack to work with another by magic, and an ISA100.11a  implementation would not work with ZigBee IP even if both claim 6loWPAN. There will soon be a fourth generation of 802.15.4 and you know that there are many variations on what you do in there, including TSCH, frame formats, you name it.

One must have a clear definition of what to pick from the standards at all layers to achieve interworking, and a conformance body is required that will validate a given profile and provide a stamp that guarantees interop. 

I saw opposition on option 1 from 2 camps, neither of which, I understand, is compatible with RFC 4944 by the book or could interop with ZigBee IP, for instance. Either they use Mesh header to put stuff that is not a MAC address, or they use escape encoding that was never standardized. All in all, they would not be able to forward a packet from one another though they certainly work perfectly fine if the subnet is a silo. 

If we get rid of the fantasy that there's a single 6LoWPAN network, and that all devices can plug into it, then we see that there will be multiple bodies like ZigBee IP defining profiles and ensuring connectivity of compliant implementations. A device would be designed for one such profile, where the use of either legacy mesh or option 1 would be enforced. Or a device could be compliant with multiple such profiles in which case there would be a need for configuration or discovery.

To your question, I do not think that the particular use of the dispatch would be discovered on the fly, but rather imposed in the beacons. If we take that path we could define ways to do that.

But there's a more complex opposition against option 1, more difficult to debate technically, and that is the political side, having to go and defend the case against other bodies outside the IETF. So the authors were asked to provide additional options, which are additions to the protocol. Do you have any advice on them?



> -----Original Message-----
> From: Roll [] On Behalf Of Timothy J. Salo
> Sent: mardi 7 juillet 2015 23:01
> To: Routing Over Low power and Lossy networks;
> Subject: Re: [Roll] FW: New Version Notification for draft-thubert-6lo-
> routing-dispatch-04.txt
> > Please consider those options, and come discuss them at 6Lo:
> >
> >        Option 1 considers that a network where this specification applies
> >        is physically separate from a network where the Mesh Header
> >        defined in [RFC4944] is used.  With that assumption, the Mesh
> >        Header dispatch space can be reused.
> How is this configured?  Does it require manual configuration?
> Or, can it be reliably detected automatically?
> -tjs
> _______________________________________________
> Roll mailing list