The resilience angle is interesting, but I think the key question is what state survives the reroute.
OpenVPN already has several failover primitives — multiple remote entries, connect-retry, remote-random, float, and persist-tun — but those are still basically reactive failover mechanisms. If the active endpoint becomes unavailable, the client establishes a new path and, in practice, you're usually dealing with a new session and potentially a different tunnel address.
So for a self-healing L4 overlay, the part I'd want to understand is not just how quickly it can choose another path, but what happens to the OpenVPN control and data-channel state when that path changes.
For example:
Does the existing TLS/control session survive the path change?
Can the data channel continue without a full renegotiation?
Does the peer see the change as the same connection, or as a new 5-tuple that has to be authenticated again?
What happens to tunnel-address and server-side session state if the path terminates on a different node?
If the session itself cannot migrate, then a millisecond-scale underlay reroute may still become a normal OpenVPN reconnect at the overlay boundary. That would improve path availability, but not necessarily session continuity.
The closest comparison I can think of is QUIC connection migration: changing the network path is useful because the connection identity is not bound solely to one 5-tuple. I'm curious whether your draft is proposing something similar at the overlay layer, or whether the OpenVPN session above it is expected to restart when the selected path changes.
Also, I would separate this from DCO. DCO can change where packet processing happens and improve the data path, but it does not by itself change OpenVPN's failover/session semantics.
If you have a section in the draft that defines how session identity survives endpoint/path changes, that is probably the part I'd read first.
