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

Brian E Carpenter <> Sat, 16 August 2014 01:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D76B1A0959; Fri, 15 Aug 2014 18:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5xHOdagvKJen; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E95E1A0953; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: by with SMTP id ey11so4270332pad.24 for <multiple recipients>; Fri, 15 Aug 2014 18:21:02 -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=8JFOC1ieICmhwUeYDHL0ZqqXtOsGSNsBGL+Cnt4sI/U=; b=N1Feyn3iwKQqiBPa4Jzyk89gaaktuP6cSeY4UR/HGwi1Kk3Tzg48QkLpfczYotfi1V nblmXf9fZUcWD+PMrYeE13Ft0nlYPmJIpi9799YayjtZHbWqrQB51O3w5J1TeYxIa3fe 6o/KiEl3oEJ7Qhri4NLlQhAiM//34CfUX3R71TXGng5DUyOJwttw6DKpHBl7H+QE78uv XYslj6el8Zp8wO5oKZhg6zqp4nfDQqAnakDqfYKAa0tXkwyAcBm9mVE62JWCQH+0jrT8 Q3Hslrqqjg5hTCprRmmObFWp0rVNDsujY6h/ACVPbEI45VH8Qj7/OBreXijDOlA8ueBn 3aqQ==
X-Received: by with SMTP id gh6mr16865368pbd.0.1408152062199; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ib5sm9163033pbb.55.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:21:01 -0700 (PDT)
Message-ID: <>
Date: Sat, 16 Aug 2014 13:21:09 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Philip Levis <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: 6man WG <>, Michael Richardson <>, Routing Over Low power and Lossy networks <>, Ole Troan <>
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: Sat, 16 Aug 2014 01:21:04 -0000

On 16/08/2014 12:41, Philip Levis wrote:
> On Aug 11, 2014, at 1:26 PM, Brian E Carpenter <> wrote:
>> Therefore, treating RPL as a special case is the remaining option.
>> But does the ROLL community actually have consensus that they want
>> this special case?
> I'd argue that if you look at the 15+ so years of work into mesh routing on low power and lossy networks, data path validation is a common technique to almost every approach. That is, there is absolutely consensus in the people engineering these protocols that data packets need to carry information about the route so the network can quickly discover and adapt to changes in the topology. The reason is that the topology can change very quickly, on the order of a few tens to hundreds of packets. 
> It turns out that this is very difficult to do efficiently in the IP architecture if you have small packets. HbH headers aren't tiny, and IP-in-IP encapsulation is significant.
> In the broader scope of running IP over LLNs, I think that the ability to encode data path information into IPv6 headers without introducing significant overhead is critical. I therefore think this special case is worth it and important enough. But I also think it's important to very explicitly state that it is an additional special case, e.g., through an Updates:.

Firstly, I think that captures the 6man question: is this special-case
walled-garden exception to RFC 6437 acceptable? My personal answer is
yes; we're here to make things work, not to enforce dogma.

Secondly, here is my reasoning why a formal Updates: 6437 is *not* needed:

A reader of flow-label-for-rpl needs to read RFC 6437 in order to correctly
understand and implement flow-label-for-rpl. So RFC 6437 is correctly a
normative reference.  However, a reader of RFC 6437 has no need to be aware
of flow-label-for-rpl in order to correctly implement RFC 6437 in any non-RPL
node. So I see no logic in saying that flow-label-for-rpl updates 6437.