[RFC] sdn: OVN zone and controller plugins

[RFC] sdn: OVN zone and controller plugins

[Rémi PAETA]

Hi all, 

I work at Comaite, where we run Proxmox VE clusters, and I would like 
to discuss adding OVN (Open Virtual Network) support to the SDN stack 
before sending patches. 

Vision 
====== 

OVN provides a distributed virtual network whose control plane knows 
where every guest port lives. Through the existing SDN objects, it 
could offer: 

Zones 
- an "ovn" zone type tied to an "ovn" controller describing the OVN 
deployment, spanning the nodes of the zone over Geneve (or VXLAN) 
tunnels 
- optional port security per zone: off (default, like a Linux 
bridge), MAC only, or MAC and IPAM addresses 

Vnets 
- each vnet is an OVN logical switch, a distributed L2 segment 
- guests keep their L2 connectivity across live migrations, with the 
port location updated by OVN 

Subnets 
- a distributed logical router per zone, with the subnet gateway as a 
router port, so that traffic between the vnets of a zone is routed 
locally on each node 
- SNAT and external connectivity through a gateway router, or a 
distributed gateway port, hosted on chosen nodes with failover 
between them 
- addresses from the IPAM (PVE, Netbox, phpIPAM) used for the port 
addresses and port security 

DHCP and DNS 
- OVN native DHCPv4/DHCPv6 and router advertisements, answered by 
ovn-controller on the local node from the IPAM mappings, without a 
dnsmasq instance 
- the existing DNS plugin integration (PowerDNS) unchanged 

Firewall 
- the existing guest firewall keeps working 
- later, possibly OVN ACLs, port groups and address sets 

I would propose to deliver this in steps: 

1. controller, zones and vnets: L2 overlay, port security, guest 
firewall, IPAM and DNS integration 
2. subnets: distributed routing, gateway, SNAT and external access 
3. native DHCP and router advertisements 
4. optionally, OVN ACLs for the firewall 

Design principles 
================= 

- The OVN central components (northbound/southbound databases, 
ovn-northd) are deployed by the administrator, outside of PVE, 
ideally as a RAFT cluster, on the PVE nodes or elsewhere. PVE only 
needs their URLs, declared in the "ovn" controller, much like the 
Netbox or phpIPAM plugins use an existing service. 

- PVE manages the logical switches, routers and ports it created, 
tagged in external_ids, so the northbound database can be shared 
with other consumers, and configures ovn-controller on every node 
of the zone. 

- Everything lives in pve-network. pve-manager does not need any 
change; proxmox-ve-rs needs the new zone type to be known so that 
the nftables firewall keeps working. 

I have a working prototype of the first step (controller, zones and 
vnets) on a three node test cluster. We have not signed the CLA yet, 
but will sign the entity CLA before sending any patch. 

Questions 
========= 

1. Are you interested in OVN support upstream? 

2. Is relying on externally deployed OVN central components fine for 
a first version, possibly with a deployment helper later? 

3. Does the mapping of zones, vnets, subnets and DHCP above match how 
you see the SDN model, and is a step by step delivery fine? 

4. Are there plans or constraints in the SDN stack (fabrics, the Rust 
rewrite, the firewall) that this should align with? 

If the direction suits you, I would send the first step as an RFC 
series with the implementation details and test results. 

Regards, 

------------------------------------------------------