[Roll] Use of flow-label in RPL (LLN) networks

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 12 September 2014 13:42 UTC

Return-Path: <mcr@sandelman.ca>
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 D21AA1A0B7F; Fri, 12 Sep 2014 06:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.553
X-Spam-Level:
X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_NO_TEXT=2, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=no
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 ZU3xs0xAJm5s; Fri, 12 Sep 2014 06:42:25 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0E91A0B75; Fri, 12 Sep 2014 06:42:24 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A68C62002D; Fri, 12 Sep 2014 09:46:58 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3C61563AEB; Fri, 12 Sep 2014 09:42:23 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1BE94637FC; Fri, 12 Sep 2014 09:42:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 12 Sep 2014 09:42:23 -0400
Message-ID: <26959.1410529343@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/cGwwb0_JoBYG59teCAazW9NnIdc
Cc: 6man@ietf.org, 6lo@ietf.org
Subject: [Roll] 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 13:42:27 -0000

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/