Brian E Carpenter <[email protected]> wrote: >> Michael H. Behringer <[email protected]> wrote: >> > The configuration of the device is outside scope, I think! If a config >> > change removes the last ACP tunnel (for example), then it's that >> > removal that changes the state in the AN machine. >> >> I like this way of writing it. >> As long as we have working ACP tunnels, then we can fix the configuration. >> >> What happens when the last ACP tunnel dies?
> Two things that I know about should happen, IMHO:
> 1. The ACP "ASA" (the thing that builds and maintains the ACP) will
> just revert to its initial mode where it's listening for neighbors and
> periodically trying to discover neighbors.
> 2. A Boolean somewhere will flip to False so that users of the ACP
> (including GRASP) know that they are on their own.
Yes. I think that this goes into the ACP draft. The above is the minimum...
BUT:
I think that we need additional text though... it seems to me that one might
need to do additional things specific to the device itself, but that these
things might be risky.
Specifically, I think that it the device should consider if there have been
connectivity changes provisioned (such as changing PVIDs at layer-2,
admin enabling/disabling interfaces, or firewall changes) since the last time
the ACP was working. It should consider if it ought to revert to last known
to be working configuration, but that that is in fact the risky part.
I suspect that perhaps there is a lot of vendor-secret-sauce possibilities
here; so I don't want to be prescriptive, but rather to say that when the
last ACP connection goes down, that the device has essentially become
unmanaged, and that it needs to do something (autonomic) to return to managed
state.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
