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

[Michael Richardson <[e-mail]>]

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