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

Carsten Bormann <cabo@tzi.org> Tue, 02 December 2014 05:41 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89ED91A00F8; Mon, 1 Dec 2014 21:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWxyGe1CYHV0; Mon, 1 Dec 2014 21:41:24 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10391A00BF; Mon, 1 Dec 2014 21:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sB25fKOO014781; Tue, 2 Dec 2014 06:41:20 +0100 (CET)
Received: from [192.168.217.149] (p5489116E.dip0.t-ipconnect.de [84.137.17.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 188452C7; Tue, 2 Dec 2014 06:41:20 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CADhXe51mQxTFO5K2bD1gYhWWW7TgjoCJzY7Un5dFru1caV2ntA@mail.gmail.com>
Date: Tue, 02 Dec 2014 06:41:17 +0100
X-Mao-Original-Outgoing-Id: 439191677.728692-52ef31a553036c03175302fd51915bd8
Content-Transfer-Encoding: quoted-printable
Message-Id: <669B55DF-4250-4E45-B55F-03F705F4DFB0@tzi.org>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <85AC0776-88D7-4019-8BB1-B0E13B9F3E64@cisco.com> <CADhXe51mQxTFO5K2bD1gYhWWW7TgjoCJzY7Un5dFru1caV2ntA@mail.gmail.com>
To: James Woodyatt <jhw@nestlabs.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/oBQXg3wfzSm_n_QYZLgSDAtCLhM
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6tisch] [6lo] FW: New Version Notification for draft-thubert-6lo-routing-dispatch-00.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Dec 2014 05:41:25 -0000

On 01 Dec 2014, at 20:20, James Woodyatt <jhw@nestlabs.com> wrote:
> 
> RFC 4944 is a Proposed Standard, which puts it into the same category as "Transmission of IPv6 Packets over Ethernet Networks" [RFC 2464], 

That argument would be more convincing if the situations were indeed comparable.

RFC 2464 is the basis for widely deployed plug-and-play interoperability.
*That* is what makes it mostly immutable, not the standards status.
(Which probably should be upgraded to match reality.)

With RFC 4944, we haven’t reached that level of interoperability yet.
In particular, there is *no* way to achieve out-of-the-box interoperability with the old mesh header — there is no defined way to use it, or even to find out that (and how) it should be used.
So you already have to add configuration (as in, "use mesh forwarding mechanism X") to use it.
Pascal’s proposal does not change this situation one iota: It doesn’t jeopardize interoperability where there was interoperability before.

(Note also that we already discarded LOWPAN_HC1 and LOWPAN_HC2 from RFC 4944 and replaced them with RFC 6282.)

Again, I believe we need to learn more about those reported usages of the old Mesh Header before we can meaningfully continue this argument.

Grüße, Carsten