Hi Aleksandra, thanks a lot for the review! I considered a northd-side enabled flag but I would prefer to keep SM-health evaluation and eviction logic in the controller. That way, it is local to the place where a dynamic agent will run. In case of control plane connectivity issues, it would be good for ovn-controller to make local decisions regardless of the lack of connectivity to the OVN SB and make the dynamic routing agent evict routes (to prevent the traffic from being sent into a black hole by the fabric).
https://mail.openvswitch.org/pipermail/ovs-dev/2026-July/433781.html v5-v6 still address the concerns you raised I think: - Observability: the controller writes its decision to external_ids:status (advertised, withdrawn-admin, withdrawn-monitor). - Admin control: external_ids:enabled lets an out-of-band writer (e.g. an L7 health agent) withdraw a route independently of SM health. - Fewer DB records: listeners sharing the same VIP IP and the same backend pod use a single row, so a pod backing multiple Services on the same VIP IP produces one row instead of one per listener. - No SB schema changes: the service selector is derived at runtime from existing LB.vips and Service_Monitor tables. The per-backend split is kept intentionally. dynamic-routing-redistribute-local-only needs tracked_port to be the backend LSP, not the peer LRP, so that only chassis hosting a backend install the kernel route. A system test covering this will be in v7. Thanks a lot for the good ideas! Best Regards, Dmitrii Shcherbakov _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
