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

Ray Hunter <v6ops@globis.net> Fri, 15 August 2014 19:49 UTC

Return-Path: <v6ops@globis.net>
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 958C01A0406; Fri, 15 Aug 2014 12:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.67
X-Spam-Level:
X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 oS3lrnMJ7-Uq; Fri, 15 Aug 2014 12:49:51 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC6861A0404; Fri, 15 Aug 2014 12:49:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 96E8787153A; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL1gd1XAlV1i; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:b577:54cb:5162:9077]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3F5F9871519; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Message-ID: <53EE6441.1000908@globis.net>
Date: Fri, 15 Aug 2014 21:49:21 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Carsten Bormann <cabo@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> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/Vyjxz6RedaxbPkXAM-Xb4OOaxfY
X-Mailman-Approved-At: Fri, 15 Aug 2014 23:54:21 -0700
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, 15 Aug 2014 19:49:52 -0000


Carsten Bormann wrote:
> 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
>
>
+1

Apologies for tardy response (holidays)

After reading the draft it seems to me that what is being attempted is
1) to add some stuff to the IPv6 header that is RPL domain specific
2) to reduce the overall packet length to reduce active radio time and 
thus save energy
by
3) overloading an existing well-defined and used IPv6 header field

My simple logic tells me that
1) could be best solved at an architecture level via an extension header 
http://tools.ietf.org/html/rfc2460#page-11 + 
http://tools.ietf.org/html/rfc7045
2) could be best solved at an architecture level via IP header 
compression http://tools.ietf.org/html/rfc2507.html with or without 
additional tweaks
and that overloading an opaque field in 3) by incorporating values with 
low entropy (as per the RPL flow label) gives additional security risks 
to http://tools.ietf.org/html/rfc7098

So what's wrong with my simple logic?

"But if we consider the whole RPL domain as a large virtual host from 
the standpoint of the rest of the Internet" would suggest to me that the 
cost of stripping out the additional IPv6 hop by hop extension header at 
the edge of the domain is a bogus argument, as you'll anyway have to 
provide some adaption and security at the root of each RPL domain to 
detect and bounce spoofed RPL Information from entering, or private RPL 
Information leaking out of each domain. Whether this domain-specificRPL 
Information is encoded in an explicit hop by hop option or an overloaded 
flow label would seem largely irrelevant to that operation at the RPL 
root (especially since the RPL root anyway has to be a high power node 
to be able communicate with the rest of the Internet).

IMHO If you overload the flow label you're looking at creating an 
incompatible walled garden, with competing IETF standards that are 
mutually exclusive.

-- 
Regards,
RayH