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

Ray Hunter <v6ops@globis.net> Sat, 16 August 2014 06: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 C15691A702C; Fri, 15 Aug 2014 23:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level:
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, 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 XwfX6C6_oUnF; Fri, 15 Aug 2014 23:49:48 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9995A1A0830; Fri, 15 Aug 2014 23:49:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9584F87153A; Sat, 16 Aug 2014 08:49:47 +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 ceeOCizm1C5a; Sat, 16 Aug 2014 08:49:47 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:2c3d:d324:45ec:29d7]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4041C870025; Sat, 16 Aug 2014 08:49:47 +0200 (CEST)
Message-ID: <53EEFEEE.8020505@globis.net>
Date: Sat, 16 Aug 2014 08:49:18 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Philip Levis <pal@cs.stanford.edu>
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> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
In-Reply-To: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/HOt2EeFsMpcgtt1J25t7FREewMY
X-Mailman-Approved-At: Fri, 15 Aug 2014 23:54:21 -0700
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@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: Sat, 16 Aug 2014 06:49:50 -0000

> Philip Levis <mailto:pal@cs.stanford.edu>
> 16 August 2014 02:33
>
> 1) There is an extension header already; the problem is that it can 
> introduce a significant (ballpark estimates are, in well engineered 
> networks, up to 5-10%) cost. The proposal is to replace the extension 
> header with using the flow label.
>
> 2) There'a already significant IP header compression in the cases 
> we're talking about.
>
> Phil

I'm sympathetic to the needs of low power devices.

However, to be clear, we are reengineering a standards track document 
that is around 2 years old (http://tools.ietf.org/html/rfc6553), and 
which works technically, and we are proposing an additional encoding of 
exactly the same information to achieve theoretical efficiency gains 
that are still only rough estimates?

Where's the experimental proof that this will really pay off in 
increased battery life?

You write "replace". Will 6553 now be deprecated?

If not we'll have:

6553 to carry RPL information as an option header.

draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a 
flow label

flow label information used to select patch and load balancing in 
multi-path networks. e.g.
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
http://tools.ietf.org/html/rfc6438
http://tools.ietf.org/html/rfc7098

I do not see that these applications for this one field are mutually 
compatible, and worse still, the only way to decode the semantics of the 
overloaded field is by applying some unknown external context ("within 
RPL domain"/ "on the Internet").

The hidden "cost" here is that we will have 3 different overlapping 
solutions = code bloat and potentially a lot of additional processing to 
locate the correct information and then process it, which is also a hit 
on energy efficiency.

IMHO the bar should be pretty high for accepting this proposal, as it is 
not actually solving a tangible issue.

Also my prediction of the next request for field overloading will be:
My ISP only delegates one /64 with PD
I have multiple links in my Homenet
All my media is EUI48 based. No one really uses EUI64.
I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for 
routing in Homenet by encoding a (V)LAN ID in it.
It's OK though. Homenet is a walled garden and I'll rewrite the field at 
the exit so no one will ever know.


As an alternative: if this information is really RPL specific, why not 
just add the RPL Information as a tag to the front of the packet e.g. 
via an MPLS label?

MPLS labels are only 4 octets, and are designed to be very efficient and 
fast.
You can easily strip them at egress, and munge it/set it on ingress.
It's clear where an MPLS domain ends and starts: no chance of RPL 
information leaking onto the Internet, or entering from the Internet.
The MPLS label also transports the 20 bits of information you need.
MPLS labels are at a clear fixed position in the packet and are easy and 
efficient to parse.
You could also then nest RPL domains if you ever wanted to do that.
It's also extensible, as you can push more labels on the stack in the 
future if you ever want to extend the RPL Information transported, 
whereas the flow label is a single fixed field.
It does not require any new standard, except maybe an informational RFC 
on how to encode the RPL Information into MPLS labels.
And it doesn't overload anything.

regards,

> Ray Hunter <mailto:v6ops@globis.net>
> 15 August 2014 21:49
>
>
>
> +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