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

Philip Levis <pal@cs.stanford.edu> Tue, 05 August 2014 00:19 UTC

Return-Path: <pal@cs.stanford.edu>
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 3FED81A0AB5; Mon, 4 Aug 2014 17:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 5Vakddq1MdTs; Mon, 4 Aug 2014 17:18:58 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC76C1A0010; Mon, 4 Aug 2014 17:18:58 -0700 (PDT)
Received: from [76.14.66.110] (port=52151 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XESSv-00019f-5Q; Mon, 04 Aug 2014 17:18:57 -0700
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53DFF0BD.8020409@gmail.com>
Date: Mon, 04 Aug 2014 17:18:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> <53DFF0BD.8020409@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/akI8C62fbhPvpG5K1EYrZXdRSOg
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "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: Tue, 05 Aug 2014 00:19:00 -0000

On Aug 4, 2014, at 1:44 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> 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?

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