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

Carsten Bormann <cabo@tzi.org> Fri, 01 August 2014 11:24 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 28E871A0A99; Fri, 1 Aug 2014 04:24:06 -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 8JlMv16c09kM; Fri, 1 Aug 2014 04:24:04 -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 13D3A1ABB18; Fri, 1 Aug 2014 04:24:03 -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 s71BNliK010532; Fri, 1 Aug 2014 13:23:47 +0200 (CEST)
Received: from [192.168.217.106] (p5489377C.dip0.t-ipconnect.de [84.137.55.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D3147F2E; Fri, 1 Aug 2014 13:23:46 +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: <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
Date: Fri, 1 Aug 2014 13:23:44 +0200
X-Mao-Original-Outgoing-Id: 428585024.77831-f8a90d73a64f26af62a888953db75812
Content-Transfer-Encoding: quoted-printable
Message-Id: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/L-bTu_3NaiSEZUWDUqZdEwgomF4
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@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: Fri, 01 Aug 2014 11:24:06 -0000

On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:

> 
> Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN. 

No.  With IPHC, the flow label has always been there, it just was transmitted in a very compressed form.

I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries.  So much for O, R, F, and rank.  Putting the VLAN (“instance ID”) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.

Now, I’m not saying any of this new architecture is wrong.  I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization.  (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.)

The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”.  Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it.  So the evolution just eats it.  Teachable moment.

Grüße, Carsten