Subject: [Roll] call for consensus for the RPL RPI / RH3 compression

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 17 Dec 2014 08:29:53 +0000

Dear WG :

We are now in last call for draft-ietf-6tisch-minimal-04 which describes an interoperable operation of RPL over 802.15.4e TSCH.
In order to guarantee interop, the draft must indicate which compression technique to use for the RPL option, and, if any, the RH3 as well.

The question was apparently solved at the ROLL meeting in Toronto, and we were going to use the IPv6 flow label to carry the RPI, with no compression for the RH3.
Adrian noted that since this is a deviation to RFC 6437, we should go to 6MAN to validate. We went to 6MAN in April (https://tools.ietf.org/html/draft-thubert-6man-flow-label-for-rpl) and got support from Brian Carpenter. The ask in 4 points was discussed again in Hawaii. But still no final decision to date that we could reset/reuse the flow label in LLNs.

Considering the lack of progress at 6MAN earlier in the year, we studied an alternate compression technique for the RPI at 6lo (https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc). Decision in Hawaii was that the NHC draft could not be accepted as is, since we should compress also the RH3, and without a clear view of how that would happen, the details of the NHC compression could not be determined. So the NHC approach was abandoned and we proposed a new 6lowpan routing header that would reuse for Route-over the 1/3 of the total dispatch space that is used for Mesh header in Mesh-under (https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch). There were interesting discussions and an update but there we are, no WG document anywhere that we can reference, and no consensus that 6lo will adopt that work.

Yet we need to choose one compression for the minimal version that we will submit to IESG. At some point we hoped that the NHC would cut it but as I said, the meeting in Hawaii left us with little hope that this would happen. So what should we do now? I think we need to call to 6lo and 6MAN for a decision on the topics we have been asking. And since a decision may not come in time, we also need to define our default.

My personal take is lex parsimoniae. By default, we should fall back to the simplest to implement, which is also the least change in existing implementations, and that is the original flow label approach; and I'm calling the group for consensus on that default approach.

What do you think?

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Dec 2014 11:39:17 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > We are now in last call for draft-ietf-6tisch-minimal-04 which
    > describes an interoperable operation of RPL over 802.15.4e TSCH.

...

    > My personal take is lex parsimoniae. By default, we should fall back to
    > the simplest to implement, which is also the least change in existing
    > implementations, and that is the original flow label approach; and I'm
    > calling the group for consensus on that default approach.

    > What do you think?

Not wearing any hat: I'm personally happy with the flow label approach.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 18 Dec 2014 21:28:40 +0100

Hi,

my 5 cents. I like flow label, but we (at 6tisch) discussed for a very long
time the approach to be taken (NHC and lately the new draft that also
compresses RH3). I will support it (flow label) but IMHO we have to make
sure there is no other thing we can do to make the current proposal at 6lo
to move forward or at least get strong arguments against it. In terms of
coherence, NHC it seems a more natural way to go as we are extending the
use of the dispatch and headers are all parsed following a coherent rule.

regards,
Xavi

2014-12-18 17:39 GMT+01:00 Michael Richardson <[email-masked]>:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Dec 2014 09:17:29 +0100

On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Decision in Hawaii was that the NHC draft could not be accepted as is, since we should compress also the RH3, and without a clear view of how that would happen, the details of the NHC compression could not be determined. So the NHC approach was abandoned

That is not at all what I recollect from Hawaii.

The current smorgasbord is:

— various ways to hijack the flow label (dead)
— the 6553-NHC proposal
— ideas for a new mesh header

I’m not going to beat the dead horse of the flow label hijack.

The 6553-NHC proposal mainly needs a decision between the three variants (flip a coin, if need be).
If time is of the essence, 6553-NHC is the natural thing to do.
We can always do an RFC 6554 NHC compression separately.

The MH proposal is forward-looking and probably the right thing for the evolution of 6lo, but probably also not compatible with a tight time schedule.

Now, what is the rush?
RFC 6553/6554 do exist.

So we get to choose between rushing 6553-NHC to completion or using 6553/6554 for now and doing the MH work right (or. more likely than just the first, both).
I don’t have an opinion on wether we need to rush 6553-NHC, but if we need to rush anything, this one it is.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Dec 2014 11:59:44 +0000

The rush Carsten, 

is that the document that will be the base for the 6TiSCH interop test in Prague is now in last call, and that document refers to the NHC draft.
The question is what should it refer to, and whatever it refers to should be stable and implementable by now.

Just the first (per your words) is just fine with me. 

Cheers,

Pascal

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: vendredi 19 décembre 2014 09:17
> To: Routing Over Low power and Lossy networks
> Cc: [email-masked]; [email-masked]; [email-masked]; 6lo-
> [email-masked]
> Subject: Re: [Roll] call for consensus for the RPL RPI / RH3 compression
> 
> > Decision in Hawaii was that the NHC draft could not be accepted as is,
> > since we should compress also the RH3, and without a clear view of how
> > that would happen, the details of the NHC compression could not be
> > determined. So the NHC approach was abandoned
> 
> — various ways to hijack the flow label (dead) — the 6553-NHC proposal —
> ideas for a new mesh header
> 
> The MH proposal is forward-looking and probably the right thing for the
> evolution of 6lo, but probably also not compatible with a tight time schedule.
> 
> Now, what is the rush?
> RFC 6553/6554 do exist.
> 
> So we get to choose between rushing 6553-NHC to completion or using
> 6553/6554 for now and doing the MH work right (or. more likely than just the
> first, both).
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Brian Haberman <[email-masked]>
Date: Fri, 19 Dec 2014 08:25:44 -0500

Pascal,

On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:
> The rush Carsten,
> 
> is that the document that will be the base for the 6TiSCH interop
> test in Prague is now in last call, and that document refers to the
> NHC draft. The question is what should it refer to, and whatever it
> refers to should be stable and implementable by now.

So, do you view the code for the interop being "set in stone"?  As
Adrian pointed out, the interop could be a way to work out the tradeoffs
of these multiple approaches.  That is, running code leads to an IETF
specification rather than the other way around.

Regards,
Brian

>> -----Original Message----- From: Roll
>> [mailto:[email-masked]] On Behalf Of Carsten Bormann Sent:
>> vendredi 19 décembre 2014 09:17 To: Routing Over Low power and
>> Lossy networks Cc: [email-masked];
>> [email-masked]; [email-masked]; 6lo- 
>> [email-masked] Subject: Re: [Roll] call for consensus for
>> the RPL RPI / RH3 compression
>> 
>>> Decision in Hawaii was that the NHC draft could not be accepted
>>> as is, since we should compress also the RH3, and without a clear
>>> view of how that would happen, the details of the NHC compression
>>> could not be determined. So the NHC approach was abandoned
>> 
>> — various ways to hijack the flow label (dead) — the 6553-NHC
>> proposal — ideas for a new mesh header
>> 
>> The 6553-NHC proposal mainly needs a decision between the three
>> variants (flip a coin, if need be). If time is of the essence,
>> 6553-NHC is the natural thing to do. We can always do an RFC 6554
>> NHC compression separately.
>> 
>> The MH proposal is forward-looking and probably the right thing for
>> the evolution of 6lo, but probably also not compatible with a tight
>> time schedule.
>> 
>> Now, what is the rush? RFC 6553/6554 do exist.
>> 
>> So we get to choose between rushing 6553-NHC to completion or
>> using 6553/6554 for now and doing the MH work right (or. more
>> likely than just the first, both). I don’t have an opinion on
>> wether we need to rush 6553-NHC, but if we need to rush anything,
>> this one it is.
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________ Roll mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Dec 2014 15:01:28 +0000

That's interesting, Brian.

We decided that for completeness of its expression of the RPL operation, the draft should provide a pointer on the way the RPL info is carried.
We need a minimum set of common stuff to interop and the way to express the RPL information is one. We can live with any default as long as everyone implements it.
Now if optionally people support additional ways to make comparisons with that reference, that would certainly be good, if the question is still open at that time.
All in all, if you agree, we can progress the draft in IESG review leaving that particular reference open to be changed till later in the process?

Pascal

> From: Brian Haberman [mailto:[email-masked]]
> Sent: vendredi 19 décembre 2014 14:26
> To: Pascal Thubert (pthubert); Routing Over Low power and Lossy networks
> > is that the document that will be the base for the 6TiSCH interop test
> > in Prague is now in last call, and that document refers to the NHC
> > draft. The question is what should it refer to, and whatever it refers
> > to should be stable and implementable by now.
> 
> So, do you view the code for the interop being "set in stone"?  As Adrian pointed
> out, the interop could be a way to work out the tradeoffs of these multiple
> approaches.  That is, running code leads to an IETF specification rather than the
> other way around.
> 
> Regards,
> Brian
> 
> >
> >> -----Original Message----- From: Roll [mailto:[email-masked]]
> >> On Behalf Of Carsten Bormann Sent:
> >> vendredi 19 décembre 2014 09:17 To: Routing Over Low power and Lossy
> >> networks Cc: [email-masked]; [email-masked];
> >> [email-masked]; 6lo- [email-masked] Subject: Re: [Roll] call
> >> for consensus for the RPL RPI / RH3 compression
> >>
> >>> Decision in Hawaii was that the NHC draft could not be accepted as
> >>> is, since we should compress also the RH3, and without a clear view
> >>> of how that would happen, the details of the NHC compression could
> >>> not be determined. So the NHC approach was abandoned
> >>
> >> 6553-NHC is the natural thing to do. We can always do an RFC 6554 NHC
> >> compression separately.
> >>
> >> 6553/6554 for now and doing the MH work right (or. more likely than
> >> just the first, both). I don’t have an opinion on wether we need to
> >> rush 6553-NHC, but if we need to rush anything, this one it is.
> >>
> >> Grüße, Carsten
> >>

---

From: Brian Haberman <[email-masked]>
Date: Fri, 19 Dec 2014 10:14:56 -0500

On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:
> We decided that for completeness of its expression of the RPL
> operation, the draft should provide a pointer on the way the RPL info
> is carried. We need a minimum set of common stuff to interop and the
> way to express the RPL information is one. We can live with any
> default as long as everyone implements it. Now if optionally people
> support additional ways to make comparisons with that reference, that
> would certainly be good, if the question is still open at that time. 
> All in all, if you agree, we can progress the draft in IESG review
> leaving that particular reference open to be changed till later in
> the process?

Why would you expect that to be acceptable?  If a piece of the spec is
needed for interoperability, it needs to be there during the review.
Why send it to the IESG if there are still questions on how that piece
will be done?  If it is left out, how will anyone know if there is
consensus on the spec as a whole?

It seems to me that:

1. There have been several proposals put forth

2. Issues have been raised on each one

So, it seems prudent (to me) to look at each of the alternatives and
determine which warts everyone concerned is willing to live with.
Running code is a good way to do that.

Making that determination needs to be done before the spec is sent to
the IESG.

Regards,
Brian

> 
> Pascal
> 
> 
>> -----Original Message----- From: Brian Haberman
>> [mailto:[email-masked]] Sent: vendredi 19 décembre 2014
>> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
>>> test in Prague is now in last call, and that document refers to
>>> the NHC draft. The question is what should it refer to, and
>>> whatever it refers to should be stable and implementable by now.
>> 
>> Adrian pointed out, the interop could be a way to work out the
>> tradeoffs of these multiple approaches.  That is, running code
>> leads to an IETF specification rather than the other way around.
>> 
>> Regards, Brian
>> 
>>> 
>>>> [mailto:[email-masked]] On Behalf Of Carsten Bormann
>>>> Sent: vendredi 19 décembre 2014 09:17 To: Routing Over Low
>>>> power and Lossy networks Cc: [email-masked];
>>>> [email-masked] Subject: Re: [Roll] call for consensus
>>>> for the RPL RPI / RH3 compression
>>>> 
>>>>> Decision in Hawaii was that the NHC draft could not be
>>>>> accepted as is, since we should compress also the RH3, and
>>>>> without a clear view of how that would happen, the details of
>>>>> the NHC compression could not be determined. So the NHC
>>>>> approach was abandoned
>>>> 
>>>> The 6553-NHC proposal mainly needs a decision between the
>>>> three variants (flip a coin, if need be). If time is of the
>>>> essence, 6553-NHC is the natural thing to do. We can always do
>>>> an RFC 6554 NHC compression separately.
>>>> 
>>>> The MH proposal is forward-looking and probably the right thing
>>>> for the evolution of 6lo, but probably also not compatible with
>>>> a tight time schedule.
>>>> 
>>>> wether we need to rush 6553-NHC, but if we need to rush
>>>> anything, this one it is.
>>>> 
>>>> Grüße, Carsten
>>>> 
>>>> _______________________________________________ Roll mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 19 Dec 2014 15:54:30 +0000

+1.

It sounds like an interop would be the ideal place to test out the 
various hypotheses on the respective proposals.

Robert

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 19 Dec 2014 18:32:07 +0100

Hi,

I do not think this is an implementation problem. It seems to me an
architectural problem. If we want to compress the HbH routing header we
have to decide for the best approach and do it once. Flow label is an
option that we tested but it is not aligned to the way IPHC headers are
compressed and we discussed this for weeks at 6tisch. We already know most
of the PROS and CONS of the approaches being discussed but the problem I
guess it is not performance or number of bytes saved but the coherence of
the procedure of compressing the header with respect to the IPHC approach.

If going for a NHC or RH3 may take years at 6lo we have the option to stay
with current HbH header approach or push for flow label knowing that due
time constraints we cannot do it better but I do not thing that testing
would solve this coherence problem.

regards,
Xavi

2014-12-19 16:54 GMT+01:00 Robert Cragie <[email-masked]>:
>
>  +1.
>
> It sounds like an interop would be the ideal place to test out the various
> hypotheses on the respective proposals.
>
> Robert
>
>
> [mailto:[email-masked] <[email-masked]>] Sent: vendredi 19 décembre 2014
> Lossy networks Cc: [email-masked];[email-masked]; [email-masked]; 6lo- [email-masked] Subject: Re: [Roll] call for consensus for
> [mailto:[email-masked] <[email-masked]>] On Behalf Of Carsten Bormann
> power and Lossy networks Cc: [email-masked];[email-masked]; [email-masked]; [email-masked] Subject: Re: [Roll] call for consensus
> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) <[email-masked]> <[email-masked]> wrote:
>
> Roll mailing [email-masked]://www.ietf.org/mailman/listinfo/roll
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Dec 2014 22:56:58 +0100

> Running code is a good way to do that.

I agree with Xavi here: This is a good way to gather data for implementation issues (such as the implementation complexity of the “efficient” variant of the NHC approach).  It is not so good for architectural issues (flow label) or housekeeping issues (code point usage of the “greedy” variant; code point re-use in the revised MH proposal).  We should have an agreement on the latter ones before going into a plugfest.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 20 Dec 2014 14:38:38 +0000

Same here,

The only case for which implementation would teach us something is the efficient NHC proposal; but considering that we now have the routing header proposal I doubt that any NHC will ever be implemented...

Cheers,

Pascal

> Le 19 déc. 2014 à 22:57, Carsten Bormann <[email-masked]> a écrit :
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Dec 2014 14:58:14 -0500

someone wrote;

Carsten Bormann <[email-masked]> wrote:
    > I agree with Xavi here: This is a good way to gather data for
    > implementation issues (such as the implementation complexity of the
    > “efficient” variant of the NHC approach).  It is not so good

so, I think that we have consensus that this can not be left to the plugfest.
A number of people have not replied; some ADs and some WG chairs.
(I realize that Gabriel Montenegro is new in this position; maybe he can
bring a fresh viewpoint?)

I am going to put up a doodle poll for the week of Jan. 12.
My goal is not to need it, that we will have a plan for the Jan 9, 6tisch
call.  Please: how do we proceed?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/