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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 16 August 2014 19:55 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 168BA1A01FF; Sat, 16 Aug 2014 12:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, SPF_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 4bwwnHugpsFl; Sat, 16 Aug 2014 12:55:03 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EF01A01E5; Sat, 16 Aug 2014 12:55:03 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id r10so5085267pdi.6 for <multiple recipients>; Sat, 16 Aug 2014 12:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yqkvNql2yfGUXXQZLiuv3+oqHvdPB7VTDCG0TY3B+w0=; b=cYyPAUGU9mrXSerCfVAC+7Dju7eJj+L46wzla6QvYJD/q6JDdDHWLa9jCqeMUibunR sHx6HM00pLNuofi1imtW+85cmSgz/FpghaDciTpREx2pjazY4Y90qGXp78x0YzV41AgA iH8lsb1kKbPuK8hjarYgeCh2yFhIBJCHtDUlIpHbm9uezezrlCymCnq0wlmg90HNEqQy SmRLvAGS5Z0WO0s1RaS8Kb4P5WwVYBeKcT4opNiPcr0sIjOc0h6TYZxh2sBMIiv5XGE9 poNP0l1qVqDixrj5HZ4nYQ96BQS9DjnzBOWXk+xB8GRfRq1lucKqUrYJDDU/lOqjI2bI XQJg==
X-Received: by 10.66.159.8 with SMTP id wy8mr22606819pab.17.1408218901413; Sat, 16 Aug 2014 12:55:01 -0700 (PDT)
Received: from [192.168.178.23] (128.198.69.111.dynamic.snap.net.nz. [111.69.198.128]) by mx.google.com with ESMTPSA id h5sm1153264pdn.83.2014.08.16.12.54.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 12:55:00 -0700 (PDT)
Message-ID: <53EFB719.70508@gmail.com>
Date: Sun, 17 Aug 2014 07:55:05 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>
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> <53EEFEEE.8020505@globis.net>
In-Reply-To: <53EEFEEE.8020505@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ybcg7F3sgOnV9yej6CaLREk_aq4
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: Sat, 16 Aug 2014 19:55:05 -0000

Ray,

On 16/08/2014 18:49, Ray Hunter wrote:
>> 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").

No, I don't see a problem there. The boundary of a RPL domain is
very well defined and flow-label-for-rpl clearly specifies that
outside that boundary, RFC 6437 applies (which enables RFC 6438
and 7098).

> 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.

Whether ROLL wants to endorse alternative methods within RPL
domains is not a 6man question.
> 
> 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.

Nice strawman, but why is it relevant? There's no need to rewrite
the bits, BTW. As RFC 7136 says:
"However, the method of generating IIDs for specific link types MAY
define some local significance for certain bits... the whole IID value
MUST be viewed as an opaque bit string by third parties, except possibly
in the local context."

   Brian

> 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.
>>
>> ------------------------------------------------------------------------
> 
>