Goal

Establish a clear, actionable foundation for designing Virtual Private Cloud (VPC) support in OpenShift Networking by defining what a VPC means in an OpenShift context, mapping customer-expected VPC capabilities to existing networking primitives (UDN, CUDN, ClusterNetworkConnects, EVPN), identifying functional gaps, and recommending viable architectural paths forward.

This Initiative focuses on research, analysis, and alignment, ensuring that any future VPC-related design or implementation is grounded in real customer needs, compatible with Kubernetes and OVN-Kubernetes principles, and avoids introducing premature or overly prescriptive abstractions.

Benefit Hypothesis:

If we invest in structured pre-work to clarify VPC semantics, requirements, and architectural options, then:

• OpenShift Networking can address NSX-T migration and service-provider multi-tenancy use cases with confidence and consistency.
• Future VPC-related features will be intentional, composable, and upstream-friendly, rather than fragmented or reactive.
• We will reduce the risk of rework, community pushback, and misaligned expectations by ensuring that VPC functionality is expressed through well-defined lower-level primitives where appropriate.
• Product, engineering, and field teams will have a shared mental model for how OpenShift enables VPC-like outcomes today and how it should evolve.

Resources

This Initiative will primarily require time and engineering expertise, not new infrastructure.

• OpenShift Architect
• OpenShift Multi-Cluster Networking engineering team (site-to-site VPN, multi-cluster connectivity)
• Product Management (Universal Connectivity roadmap)

Supporting inputs include:

• Select Field / Customer feedback
• EVPN multi-cluster work
• VPC work (and perhaps, AWS VPC and VMware NSX VPC reference models)

Responsibilities

• Initiative Owner
  • Drive scope, timeline, and outcomes for the research effort
  • Ensure alignment across networking, architecture, and product
• Networking Engineering
  • Analyze current capabilities and limitations of UDN, CUDN, BGP, EVPN, routing, and multi-cluster networking
  • Evaluate feasibility of proposed architectural options
• Architecture / Core Networking
  • Validate alignment with Kubernetes and OVN-Kubernetes upstream
  • Assess long-term sustainability and upstream considerations
• Product Management
  • Ensure findings align with customer expectations and roadmap priorities
  • Translate research outputs into future feature candidates and RFEs

Success Criteria

This Initiative will be considered successful when:

1. VPC Definition for OpenShift
   • A clear, documented definition of “VPC” as it applies to OpenShift Networking.
2. Capability Mapping & Gap Analysis
   • Explicit mapping of VPC features (subnets, routing, gateways, VPN, peering, tenancy) to existing OpenShift networking constructs.
   • Clear identification of supported, partially supported, and unsupported capabilities.
3. Customer Use-Case Validation
   • Documented analysis of VMware to OCP Virt customer migration requirements
4. Architectural Options & Trade-offs
   • Evaluated options for addressing gaps (e.g., routing CRDs, VPN CRDs, connecting UDNs, RBAC models).
   • Explicit rationale for what should be implemented, deferred, or intentionally not supported.
5. Clear Next Steps
   • A prioritized list of follow-on spikes and Features required to incrementally enable VPC-like functionality.

Results

Completion of this Initiative will produce:

• VPC Research & Findings Document
  • Summarizing definitions, comparisons (AWS, NSX, OpenShift), and architectural implications.
  • Summarizing the go-forward plan and (approximate) list of Jira Features that will be required. 
• Functional Gap Matrix
  • Highlighting where OpenShift Networking aligns with VPC expectations and where gaps remain.
• Concrete Recommendations
  • Routing and route-table CRDs
  • VPN-only subnets and site-to-site VPN support
  • VPC peering and NAT-based inter-VPC connectivity
  • Multi-tenant namespace and RBAC challenges
  • Multi-cluster VPC-like connectivity (with and without control-plane synchronization)
• Shared Alignment Across Teams
  • A common understanding across engineering, architecture, and product of how OpenShift should approach “VPC” without compromising its Kubernetes-native model.