1. Proposed title of this feature request
In-place Pod Network (clusterNetwork) renumbering for OVN-Kubernetes on OpenShift 4.17+ (without SDN bridge/migration)

2. What is the nature and description of the request?
Enable a supported, automated workflow to change a cluster’s clusterNetwork (pod CIDR[s])—and optionally serviceNetwork—post-install on OVN-Kubernetes, starting with OpenShift 4.17+ where OpenShiftSDN is deprecated and the previous SDN↔OVN migration path is no longer available.

3. Why does the customer need this? (List the business requirements here)
1. Eliminate costly rebuilds. Post-install pod-CIDR collisions with enterprise/VPC networks (common after mergers, peering, or on-prem/cloud expansions) currently force new cluster builds & workload migrations. That consumes weeks of planning, change windows, and risk.

2. Regulatory & availability constraints. Many regulated/24×7 environments cannot accept long outages or bulk replatforming just to change an overlay CIDR. A supported in-place renumber minimizes downtime and reduces operational risk.

3. Feature parity with pre-4.17 paths. From 4.13–4.16, some customers leveraged SDN↔OVN migrations to effectively re-CIDR during transition. With SDN deprecated in 4.17+, there is no supported alternative for OVN-only clusters.

4. List any affected packages or components.
Cluster Network Operator (CNO) – new controller/flow to orchestrate the renumbering, validations, and status.

OVN-Kubernetes – creation of parallel logical networks, temporary inter-CIDR connectivity, re-creation of mgmt ports, switches, LRP/LSP updates, garbage collection of old objects.

Kubernetes control plane components:

kube-controller-manager – node CIDR allocation reconciliation with new clusterNetwork.

kube-apiserver – (if serviceNetwork renumbering is selected) safe reconfiguration and downtime controls.

Machine Config Operator (MCO) – any host-level networking adjustments/reloads needed during phased node re-IP of pods.

Multus CNI – compatibility validation; ensure secondary networks (SR-IOV/macvlan/etc.) remain unaffected.

Windows Machine Config Operator (WMCO)/Hybrid Overlay – ensure Windows nodes and hybridOverlayConfig ranges migrate cleanly.

EgressIP/EgressFirewall controllers – preserve intent and rebind to new node subnets/IPAM.

Observability & Support – must-gather additions, clear events/metrics for migration phases, trouble-shooting hooks.

Documentation – admin guide for planning, preflight, execution, rollback, and known limitations.