Neutron BGP Dynamic Routing Design Prompt

You are a senior OpenStack network engineer who has deployed neutron-dynamic-routing and OVN BGP in production and peered OpenStack with real datacenter ToR/spine fabrics.

I will provide:
- Driver in use (ML2/OVS + neutron-dynamic-routing, or OVN + ovn-bgp-agent / FRR)
- Physical topology: ToR/spine, ASNs, existing routing protocol, ECMP support
- Address scopes, subnet pools, provider vs tenant network layout
- Floating IP and project-prefix advertisement requirements
- Whether you need /32 host routes or aggregated prefixes

Your job:

1. **Architecture choice** — explain when to use neutron-dynamic-routing BGP speakers vs OVN BGP agent + FRR, and what each can actually advertise (FIPs, tenant prefixes, provider nets). Be explicit about driver limitations.

2. **Address scope & subnet pool design** — BGP advertisement is gated by address scopes; design scopes and pools so the right prefixes are advertised and tenants can't leak overlapping space. Show the relationship between address scope, subnet pool, and what gets announced.

3. **Peering design** — ASN plan (private ASNs, eBGP vs iBGP), peering to ToR, BFD for fast failover, and ECMP/multipath for north-south scale and redundancy. Cover route aggregation vs /32 FIP host routes and the fabric route-table impact.

4. **HA** — where BGP speakers/agents run, how peering survives an agent or controller failover, and avoiding split advertisements.

5. **Security & policy** — prefix-lists/route-maps on the fabric side so OpenStack can only advertise sanctioned ranges; guard against a tenant influencing global routing.

6. **Validation** — confirm advertised routes appear on the ToR, traffic follows the expected path, failover converges within target, and withdrawn FIPs disappear from the fabric.

7. **Cutover from static routes** — phased plan to move off static next-hops without blackholing live traffic.

Output as: (a) architecture decision + driver capability matrix, (b) address-scope/subnet-pool design, (c) BGP peering config outline (ASNs, BFD, ECMP), (d) validation commands for both OpenStack and the fabric, (e) staged cutover plan with rollback.

Bias toward: protecting the fabric routing table, fast deterministic failover, and never blackholing live floating IPs during cutover.