IETF Logo Mail Archive

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

Philip Levis <pal@cs.stanford.edu> Sat, 02 August 2014 06:02 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 179C91B2901; Fri, 1 Aug 2014 23:02:25 -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 Kyjw9tq6FDD0; Fri, 1 Aug 2014 23:02:22 -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 979831B28FC; Fri, 1 Aug 2014 23:02:19 -0700 (PDT)
Received: from [76.14.66.110] (port=58043 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 1XDSOY-0003Nm-NU; Fri, 01 Aug 2014 23:02:19 -0700
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
Date: Fri, 01 Aug 2014 23:02:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A7F73B7-FCDC-44C6-99A5-FBA0EBFBC27D@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
To: Pascal Thubert <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/lW37ZjpQRLKnxFUkzFxrwXIisL0
Cc: roll Lossy networks <roll@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: Sat, 02 Aug 2014 06:02:26 -0000

On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

> Phil,
> 
> Though I attended the discussions and have a clear reading of this work I'll certainly defer to Brian on whether there is a violation or not. 
> 
> OTOH you need to understand that there is no need for a bis to update a MUST in an RFC. We recognize the imperfection in our work and are always ready to revise and amend after due consideration.
> 
> This process takes is another RFC and best judgement from the original group that the new text is indeed valuable and not breaking the original objectives.
> 
> We are going through that process.


If the proposal is to have an Updates: 6437 (such that someone looking up 6437 will see a forward reference and know there's an update), I'm all in favor! That seems entirely reasonable. In that way, as I've always said, I think using the flow label is an excellent solution. I just also think doing so is significant in the context of 6437 and so should correctly acknowledge so. Someone reading 6437 should be able to easily learn there's another exception. It seems like an Updates: would do that well. 

That being said, I don't think the energy claims in the current document will hold up to much experimental scrutiny or actual network measurements. Xavier's back-of-the-envelope calculations don't include preambles, slot padding, or idle listening. TSCH is nice in that it has much lower idle listening costs than ad-hoc algorithms, but they are far from zero. Reducing overhead is valuable due to the corresponding increase in MSS and reduced memory pressure: the energy argument is a red herring.

Phil

v2.23.0 | Report a Bug | By Email