[ovs-discuss] OVN: availability zones concept

[Ben Pfaff]

On Tue, Mar 05, 2019 at 09:39:37PM -0800, Han Zhou wrote:
> On Tue, Mar 5, 2019 at 7:24 PM Ben Pfaff <blp at ovn.org> wrote:
> > What's the effective difference between an OVN deployment with 3 zones,
> > and a collection of 3 OVN deployments?  Is it simply that the 3-zone
> > deployment shares databases?  Is that a significant advantage?
> 
> Hi Ben, based on the discussions there are two cases:
> 
> For completely separated zones (no overlapping) v.s. separate OVN
> deployments, the difference is that separate OVN deployments requires
> some sort of federation at a higher layer, so that a single CMS can
> operate multiple OVN deployments. Of course separate zones in same OVN
> still requires changes in CMS to operate but the change may be smaller
> in some cases.
> 
> For overlapping zones v.s. separate OVN deployments, the difference is
> more obvious. Separate OVN deployments doesn't allow overlapping.
> Overlapping zones allows sharing gateways between different groups of
> hypervisors.

OK.  The difference is obvious in the case where there is overlap.

> If the purpose is only reducing tunnel mesh size, I think it may be
> better to avoid the zone concept but instead create tunnels (and bfd
> sessions) on-demand, as discussed here:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2019-March/048281.html

Except in cases where we have BFD sessions, it is possible to entirely
avoid having explicitly defined tunnels, since the tunnels can be
defined in the flow table.  The ovs-fields(7) manpage describes these
under "flow-based tunnels" in the TUNNEL FIELDS section.  Naively, doing
it this way would require, on each hypervisor, a few OpenFlow flows per
remote chassis, as opposed to one port per remote chassis.  That
probably scales better.  If necessary, it could be made to scale better
than that by using send-to-controller actions to add flows for tunnels
as packets arrive for them or as packets need to go through them.