[Roll] Alvaro's review on turnon Rfc 8138 07

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

Dear all

Alvaro raised an issue about

  1.  Why intermediate routers that do not support the compression have to be leaves
  2.  the decision to undo compression when delivering a packet to the destination, where the "knowledge" of support comes from
  3.  the relationship between this draft and the capabilities

We need your advice to move forward. Please bear with me and help us with arguments if you see reasons to go / nogo as proposed below:

For 1) I plan to clarify that we want to avoid compressing and decompressing on the way, so when RFC 8138 is turned on, one can be a router if and only if it can forward the compressed form. Without that rule, we'd need to know the support of the next hop before we forward in compressed form and we do not have that signaling (we'll need 3) for that).

With that rule, if the next hop is not the final destination, then it is a router and it supports the compressed format. So if there's an SRH that is not fully consumed when forwarding, the next hop supports the compression. This is a huge simplification, at least in non-storing mode.

Since  RPL does not signal a leaf from a router, when a router passes a packet to a child RAN in storing mode, the router does not know if this RAN owns the destination address so it does not know if it is a router so even with the rule above, it still cannot infer the support of compression.  Argl.

This takes us to 2) The above is why in the current text the leaf that does not support the compression SHOULD act as a RUL, so it is an external target and thus the default for it is to decompress before forwarding. Alvaro and I are talking about MUSTing that, with the argument that a RUL supporting the RPL compression looks like an oxymoron.

If we MUST that the nodes that do not support the compression have to become RULs, then by definition all the RANs left support it. There is no more need to have a special "knowledge" of support about nodes. The parent knows it is delivering to a RUL, so it knows to undo compression if there's something left; usually there's nothing to do: there's a inner packet that is decapsulated and forwarded by the RUL's parent and that is not compressed with RFC 8138.

So with that additional rule:
Parent to child where child is RUL => decompress
Everywhere else => forward compressed

The corollary question to the group is whether we make the rule above specific to a storing mode DODAG, and in non-storing we say that the default is to uncompress once the SRH is fully consumed. Which one works best?

For 3) I think we should remove the discussion on the capabilities work from this draft. Capabilities are a RPLv2 feature (MOP>=7) whereas the turnon flag is only defined for RPLv1 (MOP<7). The capability can help to decide when to turn on, and that is earlier in the flow. The draft covers what happens when the decision is made.

When the capabilities infrastructure is available, if we decide to have a capability for RFC 8138, we can reconsider all the decisions above, whether a RAN can stay a RAL as opposed to a RUL when the compression is on and even whether we accept to decompress / recompress between routers. This would be a new design for RPLv2. But it might also be that we simply MUST the support of RFC 8138 with RPLv2, in which can we will not need a capability. That's a decision for the future, we do not need it now.

So do we agree to remove the reference to capabilities?

Pascal