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