Re: [Roll] [6lo] Use of flow-label in RPL (LLN) networks

Ralph Droms <rdroms.ietf@gmail.com> Fri, 12 September 2014 14:14 UTC

Return-Path: <rdroms.ietf@gmail.com>
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 98B8D1A086B; Fri, 12 Sep 2014 07:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI0ODbf0P83F; Fri, 12 Sep 2014 07:14:51 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C72D1A06D8; Fri, 12 Sep 2014 07:14:45 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id x3so906434qcv.30 for <multiple recipients>; Fri, 12 Sep 2014 07:14:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=dU2M95S5XKP5Y8r/apEmLPXK2RvEbKuo+IGA2eSTpM0=; b=Y0FOALV9H4b8NS2yotzmANN9+yV3Ti4DzlEZ66LWvZsIsmbfOhg+uL7XZTYoScGCJs mibrm7mK0MsNjjDDoxuWy02v55lueqSgd+DA4L/arES+x0/rmW1aI0q3Tzm6pvrPUKnr O55Pg/9ZDP+Z6Mf0Mh3SywXqrN7RKI0Ny0hcsWICnkn2EwETjQFGqwUTwcp/7bBOGPxc ljG0vnJA/HJ06UX0L/Xsdq3w01AsZvznXZ+adQ0spwBcjoxOqb4GlfEAfvBAJAy2nxTv QsiD1Z5LXjL004QlxNzMOy9V+5nFBlDcC63Cb1dHhRYByTXJh13nqCbeEopTflJACr0z 2dlQ==
X-Received: by 10.140.44.98 with SMTP id f89mr7512354qga.44.1410531284412; Fri, 12 Sep 2014 07:14:44 -0700 (PDT)
Received: from [10.180.222.223] ([166.170.34.200]) by mx.google.com with ESMTPSA id w8sm3026679qgw.46.2014.09.12.07.14.42 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 07:14:43 -0700 (PDT)
References: <26959.1410529343@sandelman.ca>
Mime-Version: 1.0 (1.0)
In-Reply-To: <26959.1410529343@sandelman.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <A23C2A23-D841-4476-BB2F-8D12B23FA223@gmail.com>
X-Mailer: iPhone Mail (11D257)
From: Ralph Droms <rdroms.ietf@gmail.com>
Date: Fri, 12 Sep 2014 10:14:39 -0400
To: Michael Richardson <mcr+ietf@sandelman.ca>
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/bRFGQ_bPdJYsuhqF9wDs97nMRTw
Cc: "roll@ietf.org" <roll@ietf.org>, "6man@ietf.org" <6man@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [6lo] Use of flow-label in RPL (LLN) networks
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: Fri, 12 Sep 2014 14:14:57 -0000

Seems to me this doc could be judged to be in scope of the 6man charter.  As this document was to be joint last called in both 6man and roll, and considering bringing docs to the IESG is usually preferred over AD sponsorship, I suggest that 6man consider taking this doc.

- Ralph

> On Sep 12, 2014, at 9:42 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> PROPOSED LAST CALL QUESTION on draft-flow-label
> 
> Background: at IETF90, at the ROLL WG meeting it was agreed that the
> flow-label draft could go as an AD sponsored draft, as the ROLL WG would
> otherwise be shutting down, and the flow-label work was not quite in
> charter.  The plan was to have a joint last call between 6man and ROLL, and
> if the parties agreed, that the document would advance as an AD sponsored
> draft.
> 
> A LC was issued in August 2014, and there was some discussion.
> Three tickets were opened to track issues:
> 
> http://tools.ietf.org/wg/6man/trac/ticket/5 - Evidence about energy
>                                              consumption
> http://tools.ietf.org/wg/6man/trac/ticket/6 - Updates: 6437 (if approved) -
>                                              add section with explanation
> http://tools.ietf.org/wg/6man/trac/ticket/7 - Relation with RFC 6294
> http://tools.ietf.org/wg/6man/trac/ticket/8 - relation with
>                                              draft-bormann-6lo-rpl-mesh-00
> 
> It is the opinion of the ROLL co-chairs that we got a pretty good consensus
> that use of the flow-label in the manner proposed was acceptable.  Further
> that it was acceptable to reset/change the flow label upon entering an LLN,
> and it was also reasonable to reset the flow label to  value (as if it had
> been zero) upon exiting the LLN, for the benefit for the core Internet.  We
> are going to call this part of the consensus "6man blessing"
> 
> We also feel that there was consensus that the RFC6553 Hop-by-Hop header is
> energy inefficient, and a mistake.
> 
> draft-bormann-6lo-rpl-mesh proposes a different way to encode the InstanceID
> (a constant) and Rank (a value which changes hop by hop) using the 6lowpan HC
> mechanisms.  This mechanism is equivalently efficient as
> draft-thubert-6man-flow-label-for-rpl, provided that the flow label is zero, 
> and HC can compress it out.  
> 
> draft-bormann-6lo-rpl-mesh therefore depends upon 6man  to reset the flow
> label upon entering/exiting the LLN. The ROLL co-chairs did not come to the
> conclusion that there was a compelling technical reason to use the flow label
> or the HC option expressed.  There was also not any clear support or
> discussion about the benefits of either mechanism outside of the authors of
> each draft; the co-chairs, taking advice from
> http://tools.ietf.org/html/rfc7282 (On Consensus and Humming in the IETF), 
> section 2, concluded that we have essentially an A or B situation.  
> We also took in account that perhaps mid-summer August was not the best time
> to solicit opinions. 
> 
> There are two paths for forward (perhaps more): 
>  A. adopt draft-thubert-6man-flow-label-for-rpl, incorporate 6man feedback,
>     publish (perhaps add to ROLL milestones) 
>  B. create a 6man-flow-label considerations in LLNs document, taking just
>     the issues about resetting flowlabel to zero, and negotiate who (6lo vs
>     ROLL) will adopt draft-bormann-6lo-rpl-mesh 
> 
> What we are looking for is not a process discussion at this point
> (if you think we should add a C, please unicast the chairs).
> 
> So we are also not looking "I like X" comments, but rather "mechanism Y does
> not work because of Z".  (see RFC7282 if you like)
> 
> This is not a WGLC or a Consensus call, we are interested in discussion.
> 
> Having said that, we are sensitive to the fact that 6tisch would like to
> specify *a* solution sooner.  So there is no end date, but we sure 
> would like to hear from people by 2014-09-30.
> 
> This discussion should please occur on the ROLL mailing list.
> 
> Ines and Michael.
> 
> -- 
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works 
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo