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

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

Well, Michael:

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. 

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.

The DIO piece acts as a DV routing protocol that is quite similar to other IGPs like EIGRP and Babel, with the same feasibility condition which avoids transient loops, but with RPL the IGP would care about only one destination, thus providing a DODAG towards the ACP only. Which is how RPL gets autonomic properties, a central point decides parameters for the whole network that nodes in the network will learn and apply as the network forms. 

The DAO piece populates the routes back to the nodes, along the DODAG that leads to the ACP. With a stretch, there could have been cases of transient loops, with a CTI. This is why in the ACP spec we set the RPL stretch to zero. Which means wait for an ensured solution, take no risk of reparenting behind yourself. There will be short dead times till local recovery has fixed the situation, but the chances of packets looping are very remote; we use flood as opposed to diffusion so on paper, so there is still a chance, and RPI would detect it. Since the case comes from multiple loss of flooded poisoning, it's really unlikely on wires, and anyway the local CTI, accelerated by trickle, will detect it, even without RPI.

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?

Take care,

Pascal


-----Original Message-----
From: Michael Richardson [mailto:[e-mail]] 
Sent: jeudi 13 avril 2017 16:54
To: [e-mail]; [e-mail]
Cc: Pascal Thubert (pthubert) <[e-mail]>
Subject: on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)


Pascal Thubert (pthubert) <[e-mail]> wrote:
    > Hello Benjamin:

...

    > The control plane can be adapted, certainly quite easily. But a key
    > question is whether or not the data plane can be adapted to use RPL's
    > RPI or not.

    > The RPI is how RPL signals its instances and manages routing failures.

...

    > RPL can work without it, we do that in ANIMA for wired use cases (see
    > draft-ietf-anima-autonomic-control-plane-06).  But that means quickly
    > repairing any damage, which is probably not good for battery operated
    > devices.

It wasn't clear to me that we were specifying the ACP to operate RPL without RPI.  It was a bug that I was going to try to get fixed.

I also was thinking about how useofrplinfo (and rfc2460bis header
insertion...) applied to the ACP, and what compromises we could make given the apparent new views.


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