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

Brian E Carpenter <> Tue, 05 August 2014 01:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86E251A0ACC; Mon, 4 Aug 2014 18:06:50 -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 76Wz-vSjlwEk; Mon, 4 Aug 2014 18:06:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CBC01A0ACB; Mon, 4 Aug 2014 18:06:48 -0700 (PDT)
Received: by with SMTP id lf10so321625pab.16 for <multiple recipients>; Mon, 04 Aug 2014 18:06:48 -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=q3omwt7IwTjZ2G84U2AQvkDRX6XjIWAp8WbO3+0v+Pw=; b=yG8rrpJHwVj/2VilCTgFCElebPRdky9FV3pqiOYxzQtUTIceIDFE1F7/HAOBG9BKrP cNBhAchk+n/97fuILhXrcV15bsca4dvy4b0DQqcPTUO28gAyutT+3n3AAS3ILs516BzF 0EdCZW6GgOE34xE6I1HvRMFwzAEC0NMd5ozCG4ig9uwFMUm191eOUHk/9oRT6jcsY3s2 TQf1p+41jovPHqb4EZSeEbtTYQtv4q31g8FEDA1DdICkQZ4LBjx18/WCIs35NNyk28TQ QA491yO4U8yZ/J22ypYmWHrfBfEW05Vg8Sj8R8GVJiZQKTTeNOpbdzY4Z+XTyaVL5iAY Q2qg==
X-Received: by with SMTP id w5mr418371pbz.130.1407200807284; Mon, 04 Aug 2014 18:06:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id up2sm115836pbc.21.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 18:06:46 -0700 (PDT)
Message-ID: <>
Date: Tue, 05 Aug 2014 13:06:45 +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: quoted-printable
Cc: Michael Richardson <>, Routing Over Low power and Lossy networks <>, "" <>
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: Tue, 05 Aug 2014 01:06:50 -0000


On 05/08/2014 12:18, Philip Levis wrote:
> On Aug 4, 2014, at 1:44 PM, Brian E Carpenter <> wrote:
>> It also says that there may be stateful ways of using the flow label.
>> It's almost a matter of taste whether the RPL usage is a change to
>> the phrase that you quote, or a stateful usage within an RPL domain
>> (reverting to stateless use when leaving RPL). I agree that the draft
>> could usefully be explicit about this.
> I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6 Flow Label Specification". There doesn't seem to be any text that suggests this restriction is dependent on stateless operation. My interpretation, based on the title and its placement in the document, is that the text in this section applies to any and all uses of the flow label. How am I reading this wrong? Should I be reading the final MUST ("… MUST choose labels that conform to Section 3 of this specification") in Section 4 to implicitly mean that Section 2 doesn't necessarily apply? Or is it optional for stateless as well?

I think you're right that it could have been worded more precisely.
My personal mental model has always included something like the
RPL application (i.e. a specific usage of the flow label within
a closed domain) *and* generic stateless use by default, but I
don't think that model has ever been the general consensus, so
what is supposed to happen at the boundary between such a closed
domain and the rest of the Internet has never been written down.


> My (admittedly naive) reading is that Sections 3 and 4 related to how source nodes choose a flow label. (S2: "To enable Flow-Label-based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow.")  This is distinct from what forwarding nodes do to flow labels, which Section 2 covers. 
> Phil
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------