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

Brian E Carpenter <> Sun, 17 August 2014 19:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DD9711A6FCF; Sun, 17 Aug 2014 12:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xP3WD53madc4; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A77731A0AA3; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: by 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;; 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 with SMTP id gy11mr29540063pbd.28.1408305490215; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id qb2sm14094392pbb.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 12:58:09 -0700 (PDT)
Message-ID: <>
Date: Mon, 18 Aug 2014 07:58:17 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: roll <>, "" <>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>
>> 16 August 2014 21:55
>> Ray,
>> On 16/08/2014 18:49, Ray Hunter wrote:
>>>> Philip Levis<>
>>>> 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 (, 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.
>>> 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.


> 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<>
>>>> 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 +
>>>> 2) could be best solved at an architecture level via IP header
>>>> compression 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
>>>> 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.
>>>> ------------------------------------------------------------------------
>> ------------------------------------------------------------------------