[ovs-dev] OVN architecture

Gurucharan Shetty shettyg at nicira.com
Thu Jan 15 15:04:22 UTC 2015


On Thu, Jan 15, 2015 at 4:06 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
> 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).
A point to be noted while taking a decision is that there is currently
no capability to build shared libraries on Windows platform.

>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 at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list