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

Philip Levis <> Fri, 01 August 2014 16:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8782A1A00E2; Fri, 1 Aug 2014 09:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ppxLHhoWdeuz; Fri, 1 Aug 2014 09:50:28 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7C881A00B5; Fri, 1 Aug 2014 09:50:28 -0700 (PDT)
Received: from ([]:53072 helo=[]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <>) id 1XDG2E-000594-7j; Fri, 01 Aug 2014 09:50:26 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <>
In-Reply-To: <>
Date: Fri, 01 Aug 2014 09:21:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Pascal Thubert <>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 5c460fe7d3aaafaf78d72307c0bc7e10
X-Mailman-Approved-At: Fri, 01 Aug 2014 11:46:10 -0700
Cc: Brian Haberman <>, "" <>, Michael Richardson <>, roll <>, Ines Robles <>, Bob Hinden <>, "Ole Troan (otroan)" <>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>, Brian E Carpenter <>
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: Fri, 01 Aug 2014 16:50:36 -0000

On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <> wrote:

> FYI, it will break nothing since there is no assumption in the Internet that the flow label will be carried unchanged. Consistently, there is no native way to secure the flow label to make sure it was not tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP transport mode). 
> The last call at 6MAN is where I expect problems with the use of the flow label field in this draft to be pointed at. I'm happy to report that there was no trace of bigotry there, all the contrary. 6MAN will confirm whether this draft conforms the spirit of the existing RFCs and so far I gathered, from all but you, that it does

Pascal, I don't think this is a question of spirit or anything. I mean, I'll repeat, 6437 states

"A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1."

If the point is that experience and use and the spirit of the flow label has changed from this MUST, then we should explicitly state so. I'm not arguing that the above prescription is right; but it's what's written. What worries me is the idea of directly contradicting the text of a prior RFC (the one explicitly on flow labels, no less), without correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST!

I've always thought that using the flow label in this way within an LLN is a good idea. The problem is that you can't do so without violating a MUST in the RFC that specifies how flow labels are used. It sounds like the letter of that document doesn't match the spirit of it -- so let's fix the letter, so it says what was intended! Why is there such recalcitrance to do so? Or provide any quantitative basis for the claims of battery power? You've been proposing this for nearly 4 years now...

I personally see two reasonable ways forward:

1) (As Carsten mentioned) Update 6437 to embrace these new and valuable uses of the flow label.

2) Provide evidence that using the flow label in this way would provide significant enough gains that violating a MUST in the RFC specifying the flow label is worth it.

It seems like you're advocating a third:

3) Violate a MUST in the RFC specifying how the flow label is used without any evidence that the actual energy savings are significant.

As for what I'm trying to achieve, that's pretty simple. I think it's a terrible mistake for a standards body as important as the IETF to rely on the spirit of the standard rather than the letter of the standard, especially when they contradict. If you are one of the hundreds of thousands of network engineers and software developers who work in the Internet, you can't know that a bunch of people in a meeting decided that the spirit of a specification differs from its text. All you have to go on is the text. When the founder of the next YouTube or Instagram or Google or Nicira takes my class and I ask them to write their code to follow an RFC (which I currently do), what should I tell them MUST means?