Re: [Roll] on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> wrote:
    > The RPI is mostly aimed at IOT links (LLNs), where the control overhead
    > must be kept below that of actual traffic in all cases. So we fix
    > routes reactively to traffic. For use on wires such as Ethernet, it is
    > acceptable to react proactively to a breakage and fix the routes before
    > they are used.

yes, I agree that this is doable.

I will note two other things about the ACP that matter:
  1) it runs over IPsec, which includes IKEv2, which has a Dead Peer
     Detection.  As such, we can get good ETX values out of the IKE
     daemon.

  2) we can also detect when links go bad pretty quickly, and can feed
     updated (0) ETX values into RPL quickly.

I'm still concerned that we might want the RPI rank value to do loop
detection.  It seems that the ACP should be extra reliable, and that
repairing loops needs to be done very reliably.
Yeah, we could just let TTL kill the packet, but I feel that

    > In that sense, and as long as we can live with a single topology, we
    > can afford to be pure control plane, leaving the RPI and the data plane
    > out of the story, which is good for the separations of planes, and high
    > speed hardware forwarding / software fast path.

There are perhaps some confusing words here.

I think that you mean, the ACP data plane, vs the production data plane.

I think that the high speed hardware will mostly deal with production data
plane forwarding only, and that ACP data plane forwarding will occur in the
"production" control plane: i.e. in software.  This is why I don't think that
having RPI is a problem.

While there are likely platforms that could do IPsec decapsulation, VRF
forwarding, and IPsec encapsulation inside the fast path,  I think that the
amount of state required to do so is just enough that some SDN or other
offloaded control plane, will screw that state up.  The ACP exists exactly to
work around that kind of shooting oneself in the food.  I think that the
much simpler L2-macvlan mechanism on each port (which is entirely stateless)
will be easier to guarantee.

I also think we could in light of rfc2460bis renegotiation, argue for
insertion of RPI header by the ACP without IPIP encapsulation :-)

    > So all in all, considering the hassle of updating silicon along the
    > forwarding plane, I'd think that living without RPI is fine. Now if you
    > tell me that it is always going through software that is easy to
    > update, then why not?

I think that this is the case.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-