[Roll] p2p RPL connections and ACP/RFC8994

[Michael Richardson <[e-mail]>]

Today I am reloading some switches with a new TCAM partitioning.
It turned out that some new (to us) equipment had zero space allocated for
IPv6 multicast groups, which was really causing us a lot of mysterious stuff
where ND just wouldn't work.
("show sdm prefer" if someone is finding this email later on...)

For one switch, we had an out-of-band access to get to the console/craft so I
could do this remotely.  For a second switch, it turned out that I had no way
to get to the console server that didn't go through that switch.
(There was a goal of having a separate mgmt network, but it was hard to
convince STP that loops weren't involved.  My STP-fu is low)

So of course, I look forward to using ACP/RFC8994 for this.
While RPL ought to be able to route around a failing/restarting switch, and
in theory, if the switch knows it is going down, it can do appropriate DAO
messages to remove itself from the DODAG.

But, I'd want to make sure that I wasn't going through the switch before
starting the maintenance.  Some kind of "protect" marking.

It occured to me that p2p-rpl could perhaps do this if it could express the
right metric being "does not traverse device X".
Or now we think we can replace this with aodv-rpl.

I'm wondering if anyone has any thoughts on about to express this metric?
Is a metric the right thing to do?  I doubt that this has utility in sensor
LLNs, but I think that RFC8994 ACPs would definitely like to have this.


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