On Thu, Apr 12, 2018 at 10:50:55PM +0300, Liran Schour wrote:
> Ben Pfaff <b...@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 
> L3 
> > > 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 
> implementing 
> > > virtual networking.
> > > 
> > > The disadvantage that I see for such approach are:
> > >         1. Reduce flexibility of implementation at the hypervisor 
> level.
> > >         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) 
> instead 
> > > of on each hypervisor, but the hypervisors anyhow needs to translate 
> these 
> > > logical flows into actual local flows.
> > > Therefore there is no real reduction of computation in the system 
> overall.
> > > 
> > > 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 
> case.

In OVN terms, this is similar to just pushing the northbound database to
all the hypervisors, instead of the southbound database.  It's certainly
a valid point in the design universe, just not the one that we ended up
at.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to