[ovs-dev] Imperative vs. Declarative abstraction at the SB DB

Liran Schour LIRANS at il.ibm.com
Thu Apr 12 19:50:55 UTC 2018

Ben Pfaff <blp at ovn.org> wrote on 06/04/2018 11:05:24 PM:
> On Fri, Mar 30, 2018 at 05:15:57AM +0200, Liran Schour wrote:
> > I wanted to raise a question that I came a cross. Maybe the community 
> > already dealt with it.
> > 
> > The ovn-northd translates the CMS's commands that resides in the NB DB 

> > into the SB DB.
> > 
> > Specifically it produces the Logical_flow table which represent the L2 
> > topologies specified in the NB DB.
> > However logical flows are very much imperative abstraction. Means that 

> > they are very specific and instruct the hypervisors
> > how to implement those topologies. These logical flows are very much 
> > derived and linked to the physical networking while we are 
> > virtual networking.
> > 
> > The disadvantage that I see for such approach are:
> >         1. Reduce flexibility of implementation at the hypervisor 
> >         2. Increase total number of control messages between SB DB to 
> > hypervisors.
> > 
> > I see the reason why to do that in one centralized place (SB DB) 
> > of on each hypervisor, but the hypervisors anyhow needs to translate 
> > logical flows into actual local flows.
> > Therefore there is no real reduction of computation in the system 
> > 
> > Lower at the stack, the ovn-controller' on each hypervisot, should 
> > implement an imperative abstraction with it's datapath.
> I'm not sure I understand the point yet.  What alternative approach do
> you recommend?

I will try to explain my point better.

Currently, the control plane abstraction OVN uses for interacting with the 
hypervisors (via local ovn-controller) is based on Logical Flows which are 
derived from OpenFlow protocol which is imperative and specific (based on 
specfic match and actions expressions and physical network concepts). This 
abstraction assumes and dictates that the hypervisors datapaths are based 
on some kind of OpenFlow controlled datapath (e.g OpenvSwitch).

However, there is an advantage to move to a more declarative control 
abstraction API, to let hypervisors to be more autonomous and to support 
heterogenous datapaths environments. This approach also has a potential to 
reduce the volume of control traffic between the centralized database 
(SouthBound DB) and the hypervisors (ovn-controllers).

For example, on a creation of a new logical port in the system, only a 
CreatePort(X, Y) (where X is the new port and Y is the Logical Network) 
will be pushed to the hypervisors and each hypervisor will compile this 
message to a specific control command based on it's local datapath 
implementation, e.g. into a set of Logical and then Physical flows in OVS 

More information about the dev mailing list