[ovs-dev] OVN architecture

[Thomas Graf]

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.