rfc: client route liveness probing / eventual default-on

Author: snormore

rfcs/rfc7-client-route-liveness-probing.md

@@ -51,7 +51,7 @@ ICMP echo probing was selected for its simplicity, universality, and backward-co
 
 ### Integration Context
 
-The probing subsystem integrates with the existing **BGP plugin** in `doublezerod`. Each service type (IBRL, IBRL with allocated IP, multicast) can declare whether route probing is active. In this proposal, probing is **enabled only for IBRL (without allocated IP)** mode.
+The probing subsystem integrates with the existing BGP plugin in `doublezerod`. Each service type (IBRL, IBRL with allocated IP, multicast) can declare whether route probing is active. In this proposal, probing is enabled only for IBRL (without allocated IP) mode.
 
 <details>
 
@@ -187,9 +187,9 @@ sequenceDiagram
 
     The probing worker periodically sends ICMP echo requests toward each destination.
 
-    - Echo replies are received either by the **user-space ICMP listener** or directly by the kernel’s ICMP stack when the route is already installed.
-    - The **Scheduler** determines when each route is probed, introducing jitter to avoid synchronized bursts.
-    - The **Limiter** bounds the number of concurrent probes to control resource usage.
+    - Echo replies are received either by the user-space ICMP listener or directly by the kernel’s ICMP stack when the route is already installed.
+    - The Scheduler determines when each route is probed, introducing jitter to avoid synchronized bursts.
+    - The Limiter bounds the number of concurrent probes to control resource usage.
     - Each probe runs with a per-probe timeout, and the listener automatically restarts with exponential backoff if it fails.
 - **Liveness Evaluation**
 
@@ -328,7 +328,7 @@ The feature introduces no new externally reachable services or credentials, and
 
 ## Backward Compatibility
 
-Route liveness probing is designed to be **interoperable across mixed client versions**, ensuring that enabling it does not break communication between upgraded and non-upgraded peers.
+Route liveness probing is designed to be interoperable across mixed client versions, ensuring that enabling it does not break communication between upgraded and non-upgraded peers.
 
 ### Compatibility Matrix
 
@@ -347,19 +347,17 @@ Route liveness probing is designed to be **interoperable across mixed client ver
 
 ### Deployment Considerations
 
-Initial testing indicates that **approximately 7% of existing clients do not currently respond to ICMP probes**.
+Route probing will ship as a disabled feature flag in initial releases. Operators can opt in for testing, but it will remain off by default until the subsystem has proven stable and client ICMP responsiveness is broadly consistent.
 
-These clients will appear unreachable to peers performing liveness probing, even though routing and forwarding may still function correctly over the control plane.
+Early testing shows that about 7% of existing clients do not currently respond to ICMP probes. These nodes will appear unreachable to peers performing liveness probing, even though control-plane routes and forwarding may continue to function normally.
 
-To ensure consistent behavior, the **first phase of rollout** should focus on enabling ICMP responsiveness across all clients, regardless of whether route probing itself is enabled.
+The first rollout phase should focus on ensuring ICMP reachability across all clients. During this period, probing should be enabled only in controlled or opt-in deployments, where its behavior can be observed without affecting reachability. Once ICMP handling is consistent and the subsystem demonstrates stable performance, the feature can be gradually enabled for broader use and eventually made default-on in later releases.
 
-Once universal ICMP handling is confirmed, **subsequent upgrades** can enable route probing selectively or by default.
+During the transition:
 
-During this transition:
-
-- **Mixed environments remain compatible**, as unupgraded peers still respond via their kernel-space ICMP stack when their routes are installed.
-- **When overlay ICMP is unavailable on the destination**, replies will return over the public internet rather than `doublezero0`, and are treated as probe failures.
-- **Full overlay-level reachability validation over `doublezero0`** becomes reliable once all clients are ICMP-responsive.
+- Mixed environments remain compatible, as unupgraded peers still respond via their kernel-space ICMP stack when their routes are installed.
+- When overlay ICMP is unavailable on the destination, replies will traverse the public internet instead of `doublezero0` and be treated as probe failures.
+- Full overlay-level reachability validation via `doublezero0` becomes authoritative once all clients handle ICMP properly.
 
 ## Open Questions