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

Carsten Bormann <cabo@tzi.org> Thu, 14 August 2014 11:29 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 E46891A0A76; Thu, 14 Aug 2014 04:29:36 -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 OyFTuiGtKncu; Thu, 14 Aug 2014 04:29:35 -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 2826B1A0A7E; Thu, 14 Aug 2014 04:29:34 -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 s7EBTNRL026812; Thu, 14 Aug 2014 13:29:23 +0200 (CEST)
Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 098D9952; Thu, 14 Aug 2014 13:29:21 +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: <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com>
Date: Thu, 14 Aug 2014 13:29:20 +0200
X-Mao-Original-Outgoing-Id: 429708560.40719-59d134129f8d411f3519afd44c8fa26e
Content-Transfer-Encoding: quoted-printable
Message-Id: <9051878F-04DC-4FAD-BE53-056826FD1070@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> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/818yOwO8LsTXv5LiSo4dd_r-9vA
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
Subject: Re: [Roll] [6lo] 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: Thu, 14 Aug 2014 11:29:37 -0000

>> I really would like to hear a technical argument why the flow label hack is needed.
> 
> ? Then you probably missed most of my mail from yesterday ?
> ? The sentence is a rhetorical abuse - like "our just cause" as opposed to "our cause is just" which can be argued -, and there is no consensus that the flow label technique is a hack ?

Oh, OK, I was using this as a technical term.  The Internet works because of a set of hacks piled on hacks.
Generally, most people would agree that an instance of “there are some bits that aren’t used very much — lets put our stuff there” is a hack.
But we don’t need consensus on that word, in particular if you perceive it as pejorative.

> For instance, the draft is asking 6MAN the right to reset a flow label at the ingress RPL domain. Without this right, a flow label coming from the Internet will be transported in the RPL domain or (more probably) implementation will voluntarily fail to conform 6437, and elide them regardless. I'd rather have a realistic rule that sets the expectations right.

OK.  That is a completely different thing.
I certainly would support a “license to drop” draft that says “a highly constrained network can discard the information in flow labels”.
(Maybe with some more context.  Just as RFC 6282 allows discarding UDP checksums in certain well-defined cases.)

But that is not an argument at all for storing anything different in those 20 bits.

> Another disagreement is on your assumption that compression is the only reason for preferring the flow label technique. We have an IOS implementation that is not for use in 6LoWPAN networks, and relies on the (stateful) storing mode. HbH has known issues in classical routers, makes the header chain longer and requires silicon processing or punt, so there are reasons not to use it there either. OTOH making a routing decision that takes the flow label into account is quite natural, this is what load balancers will do at the core. We have prototyped indexing the VRF with the RPL instance in the flow label, and it works like a charm.

Now it gets interesting.
I have another draft whose main content could be summarized as “hop-by-hop options don’t seem to work, now what”.
So why did we do RFC 6553?  That was a big mistake, no?
We need to do the things hop-by-hop options were defined for, for a number of purposes.  
This is not being helped by usurping the last free 20 bits in the header for one, and only one, of those purposes.

> And even if compression is the reason why the flow label is used, RPL is a rather new routing protocol and we do not know what the world will make of it. For all I know it may be deployed in RoHC environments to aggregate femtocell traffic for instance. Assuming that the compression will always be 6LoWPAN is short sighted.

Since ROHC is all about flows, it indeed is very good in completely compressing away static flow labels.
ROHC also is very good in completely compressing away static extension headers.
I haven’t done the math, but I don’t see a winning argument here.
In any case, my argument was that the header compression scheme should handle this, and, either way, ROHC already does!

More importantly, if RPL becomes applicable outside the constrained environment, the arguments that are being made about the requirements of (stubby) constrained environments no longer apply.

In any case: YAGNI.

> And there is no "politics", but external SDOs that base their work on our RFCs and that we need to treat with all respect. Facts:
> - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a stateful indicator of the flow (called a contract ID). We need to be clear on how we position this WRT 6437 now that we shipped it. The draft makes that legal, as long as we extend the RPL domain to an ISA100 domain as well.

I don’t know that a ISA100.11a contract ID is compatible with the proposed flow-label encoding of RFC 6553.
But support for this usage could go with “license to drop” into a draft about constrained node network usage of flow labels.
(In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing here; it mentions ISA100.11a only in the introduction.)

> - We can promote behaviors in WCI (e.g. reset the flow label to something valuable to the Internet at large at the backbone router) but then we need to document them in an RFC that they can reference.

That seems to be the above argument about “license to drop", which is again completely independent from the desire to compress RFC 6553.

                                  .oOo.

I won’t continue belaboring this on the three mailing lists here.
(One reason being that I’m going on vacation.)

My main point for 6man was that going down the “let’s appropriate the flow label for this” route is not at all inevitable.
(There also are some good contributions from this discussion for the ongoing quest for a good, deployable use for flow labels.)

For 6lo, the observation is that there is a place for header compression beyond RFC 6282, and that it is easy to get even better compression for RFC 6553 in the RFC 4944 framework.

For ROLL, my advice would be to take another look at RFC 6554, and see how that would be compressed in a 6lo context.  Most importantly, is there really a need for the “segments left" construction, or can the waypoints be discarded once visited.

Grüße, Carsten