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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 17 August 2014 19:58 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 DD9711A6FCF; Sun, 17 Aug 2014 12:58:12 -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 xP3WD53madc4; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77731A0AA3; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id y10so6241236pdj.28 for <multiple recipients>; Sun, 17 Aug 2014 12:58:10 -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=NpWmIR4H2InPyhtgEmo2FAQzRlXEVF03ACMf4v0NNTQ=; b=0InAO5GLB0+m2lgPSmCf7/VorbkQyZVcq2bT8a/5lUnqMTDbMOcaRxqGnYAeraOKM2 cGcGETCCoMuNsK1wjrCYzFP6ABkjIF5Tc/XgitPjuxbOMAGjCbLdu6NPASGHgTe4a6Ts Q6njxudkfpj9z8y02W+v/C3WITM6Cl50LspcjbYSS0wjYDmmu57ehFhWF08/Fy1X5Hww Dt09gIvUcDTBIlZMBQgiWTxY3j+zpPCre5JTWzUDjdR9OcuKvf7hzLvog8qIUKFoN8z5 IoiHY73f3bhsnNSEIbTxCJffG0lj0GTiA7ZD4e9Pwe41465QzH7lG42KtHZb3Ksq/e50 UQig==
X-Received: by 10.69.20.11 with SMTP id gy11mr29540063pbd.28.1408305490215; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from [192.168.178.23] (58.199.69.111.dynamic.snap.net.nz. [111.69.199.58]) by mx.google.com with ESMTPSA id qb2sm14094392pbb.0.2014.08.17.12.58.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 12:58:09 -0700 (PDT)
Message-ID: <53F10959.2000102@gmail.com>
Date: Mon, 18 Aug 2014 07:58:17 +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> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net>
In-Reply-To: <53F07B55.7050708@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/yGf5T0eplP_uLzcSWbrHYcnm7LA
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: Sun, 17 Aug 2014 19:58:13 -0000

On 17/08/2014 21:52, Ray Hunter wrote:
>> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
>> 16 August 2014 21:55
>> 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).
> But inside an RPL domain, you cannot use any RFC's that reference the
> flow label as per 6437, because all of the entropy has gone.

Correct. But isn't that a trade-off that might be reasonable in
the low-power lossy environment? (That's not intended as a rhetorical
question - I just don't have enough knowledge of that environment
to answer it.)

> 
> And what happened to our end to end architecture?

There are various views of what e2e means, but I still like the
phrase "certain required end-to-end functions can only be performed
correctly by the end-systems themselves". Load balancing and adaptive
routing are not actually e2e functions in that sense.

> I just do not like the concept of parsing a packet, and then having to
> determine the semantics of the contents of a particular field based on a
> "domain" that is not carried anywhere in the packet.

I see the objection, but we've been doing it for years; diffserv does
it by definition.

   Brian

> e.g. think about decoding offline captures

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