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

["Pascal Thubert (pthubert)" <[e-mail]>]

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