The customer wanted to use OVN (TP) for their deployment of OCP 4.4 because they foresee that adopting OVS now on OCP 4.4 and then migrating to OVN once GA is a double whammy of a downtime that they can't afford due to the critical nature of the workload.

Below are Customer's use-case for OVN.

• We want to start deploying OCP 4 based clusters as soon as possible.
• OVN will eventually replace OVS as the default networking option.
• We want to keep our clusters as "vanilla" as possible, which means using the default options going forward.
• The assumption that we can "easily spin up a new OCP cluster" is not true in our environment. We don't have the resources readily available.
• The assumption that we can "easily... migrate workload to [a new cluster]" is also not true in our environment. Development effort to change all the endpoints is prohibitive.
• Taking a full outage to a cluster to enable OVN is not an acceptable solution.
• Looking forward, there is some interest within Spark to explore the use of Windows containers which requires OVN.
• Alternatives such as the VMware based Kubernetes platform are being considered.