Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <26959.1410529343@sandelman.ca>
Date: Fri, 26 Sep 2014 10:19:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <484D9E4C-3202-4E04-984B-43914D6D7897@cs.stanford.edu>
References: <26959.1410529343@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/QwhNXcK-6Sxd7uyTagZq01--4ic
Cc: roll@ietf.org
Subject: Re: [Roll] Use of flow-label in RPL (LLN) networks
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>

On Sep 12, 2014, at 6:42 AM, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:

> There are two paths for forward (perhaps more):=20
>  A. adopt draft-thubert-6man-flow-label-for-rpl, incorporate 6man =
feedback,
>     publish (perhaps add to ROLL milestones)=20
>  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=20

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.=20

Phil=