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

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Sep 2014 09:42:23 -0400

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 <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Sep 2014 10:14:39 -0400

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 <[email-masked]> wrote:
> 
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Philip Levis <[email-masked]>
Date: Fri, 26 Sep 2014 10:19:08 -0700

>     ROLL) will adopt draft-bormann-6lo-rpl-mesh 

B is a better approach. draft-bormann-6lo-rpl-mesh does not require any updates, changes, notes, or deviations to RFC6437. I originally said that I thought the reasoning behind draft-thubert-6man-flow-label-for-rpl (improved energy efficiency due to reduced header overheads) was sufficient to warrant a second case in which the flow label was not preserved end-to-end. But that was under the assumption that we had to twiddle with the flow label in this way. If we can achieve the same goals without doing so, that is a technically superior solution.

In short, draft-bormann-6lo-rpl-mesh is more efficient (uses fewer bits) than draft-thubert-6man-flow-label-for-rpl. Furthermore, unlike draft-thubert-6man-flow-label-for-rpl it complies with RFC6437 and requires no exceptions.

I understand that there is a sense of time pressure here, but I think that, in the context of standards, expediency is not a good motivation for decision making. I.e., it's better to have a better standard that will stick and become the solid technical basis for decades to come, rather than get something out quick that we'll have to redo. 

Phil