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

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Apr 2017 10:54:18 -0400

Pascal Thubert (pthubert) <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Apr 2017 16:03:57 +0000

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:[email-masked]] 
Sent: jeudi 13 avril 2017 16:54
To: [email-masked]; [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>
Subject: on the use of RPL without RPI (was Re: [6lo] Adaption of ROLL for mesh-under)

...

...

    > repairing any damage, which is probably not good for battery operated

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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Apr 2017 12:36:35 -0400

Pascal Thubert (pthubert) <[email-masked]> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Apr 2017 09:31:56 +1200

On 14/04/2017 04:36, Michael Richardson wrote:
...
> insertion of RPI header by the ACP without IPIP encapsulation :-)

I wouldn't bet on that for a few more weeks yet. We do have a couple of
mitigations however:

1) Since the ACP is strictly using ULAs, we can assert that ACP packets
are not intended for the open Internet. It would in fact be tragic for
many reasons if an ACP packet "escaped".

2) Since the ACP will be based on IPsec/ESP, we can assert that breaking
IPsec/AUTH is not an issue.

However, we would also need a story on PMTUD within the ACP.

> I think that this is the case.

Updating the ACP code network-wide, in a large network, might not be so easy.
Ignorant question: what happens if only some RPL nodes support RPI?

   Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Apr 2017 07:28:52 +0000

Hello Brian

This is unspecified since prior to ACP there is always an RPI, thus the need to express it somewhere, which we did in the ANIMA spec; and the problem you raised has 2 sides.

Could be that nodes always expect an RPI and could be that they never do. Either way nodes may drop the packet in some default: case.

I think that what we have now at ANIMA works, and that a more complete specification would be useful for a more general case, explaining pro cons of using RPI and in which case mixed mode could work. Would ANIMA wish that ROLL publishes that doc?

Take care,

Pascal

> Le 13 avr. 2017 à 23:31, Brian E Carpenter <[email-masked]> a écrit :
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Apr 2017 08:26:43 +1200

Hi Pascal,

> Would ANIMA wish that ROLL publishes that doc?

I certainly can't speak for the WG, but to me it seems like an issue that
might arise for other use cases, so an answer from ROLL for the general
case seems to make sense.

   Brian