On 01/15/15 at 03:36pm, YAMAMOTO Takashi wrote: > > On Thu, Jan 15, 2015 at 10:38:45AM +0900, YAMAMOTO Takashi wrote: > >> > ovn-controller > >> > -------------- > >> > >> neutron "ofagent" agent has a similar design to ovn-controller. > >> you might be able to reuse at least some of code if python+ryu > >> is acceptable. > >> > >> https://github.com/openstack/neutron/tree/stable/juno/neutron/plugins/ofagent > > > > I didn't know that there was an existing local controller. I'll learn > > something about the design. > > similar: > > - it's a local OpenFlow controller running on each nodes > > - it has ARP suppression feature implemented with packet-ins > (called "local arp responder" there) > > different: > > - ofagent doesn't have a layer equivalent to "OVN database". > it obtains the necessary info from its CMS (neutron) directly
Another local controller to look at is the OpFlex OVS agent which runs locally as well and uses libopenvswitch and libofproto to talk OF/OVSDB to OVS. (I think OVN should be built on top of the now exposed shared libraries as well). It is written in C++ for the same reasons as outlined in the OVN architecture document: speed and scale. It currently lives in the ODL git repo: https://git.opendaylight.org/gerrit/gitweb?p=opflex.git;a=tree;hb=HEAD The main difference is that it takes an object tree based group policy model describing intent as input in addition to topology information. (Some will remember my talk at the OVS fall conference on the path from intent to hardware offload.) This information is also stored in a database. In addition, it allows communication among local controllers which is why it speaks OpFlex instead of OVSDB northbound. The network virtualization features are similar with VXLAN overlay based L2/L3, ARP responder, ACLs, ... I would expect OVN and the OpFlex agent to be complementary and compatible in the sense that there is a lot of value for a local controller doing nothing but overlay based network virtualization. At the same time, OVN does not hide any information relevant to constructing a policy model on top of it. They can coexist or be integrated, whatever makes the most sense going forward. I'm very positive and have no doubts that this will result in the best local controller architecture out there, solving both the needs of network virtualization and policy for CMSs. No doubt, it will be awesome to tie OVN to Congress in the long run for example. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
