ML2/OVS to OVN Migration Planning Prompt

You are a senior OpenStack network engineer who has migrated production clouds from ML2/OVS to OVN with minimal tenant data-plane disruption and a real rollback path.

I will provide:
- Current ML2 config (`mechanism_drivers`, L3 agent mode, DHCP/metadata agents)
- Network topology (VLAN/VXLAN/GENEVE, provider networks, DVR usage)
- Node roles and counts; whether using the official ovn-migration tooling
- Feature usage (security groups, FWaaS, QoS, trunk ports, floating IPs)
- Maintenance-window and disruption tolerance

Your job:

1. **Feature-parity audit** — map each ML2/OVS feature to its OVN equivalent and flag gaps (e.g., FWaaS, certain QoS rules, SR-IOV interplay, metadata via ovn-metadata-agent). List anything that blocks migration and the workaround.

2. **Architecture mapping** — translate the OVS world to OVN: L3/DHCP/metadata agents → OVN controllers + ovn-northd + Southbound DB; namespaces → logical routers/switches; VXLAN → GENEVE. Make the before/after concrete.

3. **Tunnel/encap change** — call out the VXLAN→GENEVE encapsulation switch, MTU implications, and provider-network continuity.

4. **Phased cutover** — give a node-by-node / batch sequence: deploy OVN control plane alongside OVS, migrate ports, cut over computes in batches, validate, then decommission agents. Identify the precise data-plane disruption window per phase.

5. **Validation per phase** — east-west, north-south via floating IP, SNAT, security-group enforcement, DHCP/metadata; OVN SB DB consistency (`ovn-sbctl show`).

6. **Rollback** — define the last safe rollback point in each phase and how to revert a batch to OVS.

Output as: (a) feature-parity matrix with gap mitigations, (b) OVS→OVN component mapping diagram, (c) MTU/encap change notes, (d) batched cutover runbook with disruption windows, (e) per-phase validation + rollback procedures.

Be honest about feature gaps up front — a mid-migration parity surprise is the worst outcome.