Re: [Roll] [6lo] call for consensus for the RPL RPI / RH3 compression

[Robert Cragie <[e-mail]>]

My views on what I think are the salient points in the discussion so far:

1) Use of interop to validate a way forward

I don't agree that a specification has to be set in stone for an 
interop. The whole point of an interop sometimes is to test the 
specification and expect it to change afterwards. If there are a number 
of proposals, then it doesn't seem unreasonable to clearly specify each 
proposal and implement all proposals. This in itself will give an idea 
of complexity; the interop will give an idea of issues arising and 
therefore it should help in deciding which one is the best as clearly 
there doesn't seem to be consensus based solely on the drafts.

2) Choice of proposals

Assuming elimination isn't going to occur via the mailing list, the 
three options are:

a. draft-thubert-roll-flow-label-02 (RPI only)
b. draft-thubert-6lo-rpl-nhc-02 but pick one of the three (greedy, 
conservative, efficient) first (RPI only)
c. draft-thubert-6lo-routing-dispatch-01 (RPI and RH3)

This implies the current method would be used for RH3 in cases (a) and (b).

3) Compression of RH3 using NHC

This could be developed as an alternative. I don't recall the NHC 
approach being abandoned.

4) Time schedule

Carsten gave a good summary earlier. I can't see why 
draft-thubert-6lo-routing-dispatch-01 would take any longer to finalise 
than draft-thubert-6lo-rpl-nhc-02, especially if the latter would 
include RH3 as well.

5) Sub-IP protocol

The mesh header as it stands is not significantly different to what is 
being proposed for 6LoRH as it too could be used to carry IPv6 addresses 
in a compressed format on the basis that link layer addresses are 
already used with autoconfigured IPv6 addresses. I would therefore see 
6LoRH as a general more flexible replacement for the mesh header and 
therefore 6LoRH used in conjunction with RPI/RH3 would not be a sub-ip 
protocol.

In essence, the difference is really this:

RFC4944:
mesh[0..a] | FRAG1 | IPHC | {IPHC[0..b] | NHC[0..c]}[0..d] | Payload
mesh[0..a] | FRAGN | Payload

draft-thubert-6lo-routing-dispatch-01:
6LoRH[0..a] | FRAG1 | 6LoRH[0..b] | IPHC | {IPHC[0..c] | 
NHC[0..d]}[0..e} | Payload
6LoRH[0..a] | FRAGN | Payload

All the above really shows is that 6LoRH can be used in place of a mesh 
header for sub-ip purposes simply as a "less greedy" way or it can be 
used to replace an IPHC header as used currently in conjunction with a 
more efficient header extension. If I have one issue, it is calling them 
all "6LoRH" - the RPI can sit a "6LoRH-style" header extension alongside 
an IPHC header if there is no encapsulation, I believe?

This is where I have some sympathy with James Woodyatt's e-mail - the 
options start to look a little hairy and it becomes significantly more 
complex to figure out what goes where.

6) Bump-in-the-stack

I have seen both bump-in-the-stack and full decompression/recompression. 
In addition to what Pascal points out, there are some other subtle 
considerations which need to be applied for BITS, especially with regard 
to eliding what look like padding fields - I have seen one issue where a 
value of 0 was considered to be padding and not included correctly.

On 07/01/2015 16:43, Carsten Bormann wrote:
> On 2015-01-06 18:03, Michael Richardson wrote:
>> An experiment which I have yet to do is to see what happens if one 
>> applies
>> GHC (https://tools.ietf.org/html/rfc7400) to 6553 and 6554.
>
> Little point -- there is very little inherent redundancy on the byte 
> sequence level.
>
> Gruesse, Carsten
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>