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

Carsten Bormann <cabo@tzi.org> Mon, 01 December 2014 17:03 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 6DDB81A6FFA; Mon, 1 Dec 2014 09:03:56 -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 JMOE7B1RuovV; Mon, 1 Dec 2014 09:03:54 -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 5D0A81A6FA9; Mon, 1 Dec 2014 09:03:54 -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 sB1H3j8F005191; Mon, 1 Dec 2014 18:03:45 +0100 (CET)
Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (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 D55A331; Mon, 1 Dec 2014 18:03:44 +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: <CAH=LnKR5xQCDZuWygTJ6mDEOHmxDEgkDwRD2Xy72b-EZNXQ5OQ@mail.gmail.com>
Date: Mon, 1 Dec 2014 18:03:43 +0100
X-Mao-Original-Outgoing-Id: 439146223.499436-2156969aa0126bde1b27d069e54934b3
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CFC155E-AC8C-41B2-94C1-CDD30A64ECFD@tzi.org>
References: <20141127133537.6084.69209.idtracker@ietfa.amsl.com> <E045AECD98228444A58C61C200AE1BD848A7DE36@xmb-rcd-x01.cisco.com> <5A4C4F93-2667-4510-8193-F0201219F816@nestlabs.com> <239401C5-C9B7-4368-8008-164F902C68AD@tzi.org> <CAH=LnKR5xQCDZuWygTJ6mDEOHmxDEgkDwRD2Xy72b-EZNXQ5OQ@mail.gmail.com>
To: Martin Turon <mturon@nestlabs.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HK2LPVi9iU3I99J4gklyswnn1Mc
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] [6lo] [6tisch] 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: Mon, 01 Dec 2014 17:03:56 -0000

On 01 Dec 2014, at 17:52, Martin Turon <mturon@nestlabs.com> wrote:
> 
> Hi Carsten,
> 
> Yes, section 11 refers to the mesh header defined in section 5, but does not claim exclusive use of it.

No, but then section 5.2 points to section 11 for further explanation what the Mesh Header is about.

> My point really is to inspire people to rethink the long held dogma that the mesh header and mesh-under are synonymous, and counter proposed text that codifies that view.

What I was trying to say is that 4944 was written from that view, and, while it is interesting to open up the semantics of the header, this would actually be a change already.

> They need not be viewed that way, and my reading of RFC4944 doesn't mandate that the two be equivalent.  In fact, "Appendix A. Alternatives for Delivery of Frames in a Mesh", covers some of the alternate use cases, design ideas, and pros/cons of using the mesh header at layer 2 or 3.

Right.  The problem really is that 4944’s Mesh Header is very inflexible: It only provides (1) a (limited) hop count, (2) a source MAC address, and (3) a destination MAC address.  Whether that is useful depends a lot on what your meshing protocol does; 4944 was rather speculative here.
Pascal’s idea is to open up the Mesh Header and make it extensible, so it can still carry the three items the old Mesh Header could carry, but can add and remove items, as needed by the forwarding mechanism.  This is achieved by going the TLV route.  It would be rather inefficient to leave the old inflexible Mesh Header consuming 1/3 of the dispatch space, requiring more bytes for the new one: so Pascal proposes reusing the space in networks configured that way.

(RFC7400 6CIOs might be useful for achieving that configuration in an automatic way, or not; this hasn’t been thought through.)

Grüße, Carsten