Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Carsten Bormann <cabo@tzi.org> Wed, 13 August 2014 01:19 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 B391E1A6F87; Tue, 12 Aug 2014 18:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] 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 GnPSxfmrmhZp; Tue, 12 Aug 2014 18:19:21 -0700 (PDT)
Received: from 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 6E5C41A6F86; Tue, 12 Aug 2014 18:19:21 -0700 (PDT)
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 informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7D1JEe9009134; Wed, 13 Aug 2014 03:19:14 +0200 (CEST)
Received: from [192.168.217.145] (p54890709.dip0.t-ipconnect.de [84.137.7.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65C986F; Wed, 13 Aug 2014 03:19:13 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <53EAA58D.4060401@gmail.com>
Date: Wed, 13 Aug 2014 03:19:12 +0200
X-Mao-Original-Outgoing-Id: 429585552.308666-c9e5bc6724d010c898925a744d2346d9
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/gnHDkAd7cWgb91jc-OvDGCNRqmc
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
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: Wed, 13 Aug 2014 01:19:23 -0000

On 13 Aug 2014, at 01:38, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Can you perhaps clarify the exact question you are asking 6man?

Well, I’m not Ines, but I’m trying to find out why we are in this peculiar position of discussing this draft right now.

ROLL has a routing protocol that requires some data to be shipped around together with IP packets.
RFC 6553 and 6554 define ways to do this that are consistent with the IP architecture.
Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, and in this area of application, that matters.

Normally, the next step would have been looking at ways to do header compression.
We did talk about compressing ROLL, but with a view to compressing the (control plane) ROLL messages, not so much about the (data plane) IP packets themselves.  GHC is trying to be a reasonably useful, but also reasonably general way to do the control plane messages.

For the data packets, the flow label (and its now predominant non-use) provides an attractive hole in the IPv6 packets to ship around the RFC 6533 information, but not the RFC 6554 information.
In 6lo networks, normally RFC 6282 compresses away empty flow labels, but it is cheap to put them in, so a flow label really only costs 3 bytes (instead of 8 bytes RFC 6553 costs).  The most useful information from RFC 6553 can be stuffed into 19 bits, as demonstrated by the draft we are discussing here.

RFC 6282 has extension points (GHC uses one of them), but not really useful ones for the ROLL data plane.
So it appears it never occurred to us that the best way to handle these 19 bits is to actually sidestep RFC 6282, and use the existing extension points of RFC 4944.  Until Laurent showed one way of doing this.  I just went from there and did a strawman using Laurent’s idea for compressing the RFC 6553 option, in a way that is as efficient as (or, in most cases, actually more efficient than) using the flow label hole.

So to me it seems there no longer is a good technical argument to ask 6man to liberate the flow label for carrying RFC 6553.
But that is maybe something that should now be discussed between 6lo and ROLL; I don’t think that this is a 6man issue (unless the answer is a simple “sure, go ahead, take it, we don’t need it any more anyway”, which is not what I have perceived RFC 6437 to say).
When 6lo and ROLL have generated consensus on the need to do this, we may or may not want to go back to 6man and actually pry that flow label hole out of your fingers.

Grüße, Carsten