[ovs-discuss] OVN: availability zones concept

[Han Zhou]

On Wed, Mar 6, 2019 at 9:06 AM Ben Pfaff <blp at ovn.org> wrote:
>
> 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.

Thanks Ben for the pointer. I have to admit I was not aware of these
different ways of using tunnels. The documentation is very clear, and
now I understand what OVN currently uses is "Intermediate models",
i.e. partially flow-based - remote-ips are port based while keys are
flow based.
While purely flow-based tunnel is attractive in terms of flexibility,
it seems not fit very well for OVN use case because we do need BFD
sessions. For the "send-to-controller", i.e. reactively set up flows
when packets arrives, I hope it is not really needed for solving the
tunnel scaling problem, since it introduces data plane latency which
could be a bigger problem. (But I am not sure if reactive mode in
general is a good idea - it might be a reasonable trade-off for
solving the scale problem of each HV pre-installing flows for all
related datapaths in a full-mesh alike scenario. Anyway, not directly
related to current topic).

So I would propose to keep the current partially flow-based tunnel
usage in OVN and optimize the tunnel setup only between peers that are
logically connected, if this satisfies the scaling goal of OVN users.
Even with this optimization, we may need to make it as a configurable
option, since in small scale use cases users may in practice prefer
the original behavior to avoid the latency of tunnel setup.