[ovs-dev] OVN architecture

Ben Pfaff blp at nicira.com
Mon Jan 19 17:58:06 UTC 2015


On Mon, Jan 19, 2015 at 02:32:02PM +0000, Dave Tucker wrote:
> 
> On 19 Jan 2015, at 13:04, Thomas Graf wrote:
> 
> >Agreed. I would expect that OVN might lead to more frequent releases
> >of OVS with a more "stable at all times attitude" as OVN will depend on
> >specific OVS features.
> 
> This is my concern. For OVN to be useful in the context of OpenStack, we
> should bear in mind which OVS versions are out in the wild.
> http://packages.ubuntu.com/search?suite=default&section=all&arch=any&keywords=openvswitch-switch&searchon=names
> 
> Looking at Ubuntu LTS releases for example - as it's hyped as most popular
> for OpenStack - we have:
> 	- OVS 1.4 in Ubuntu 12.04 (supported until 2018)
> 	- OVS 2.01 in Ubuntu 14.04 (supported until 201
> 
> Let's say, for the sake of discussion, that OVN will require ARP Responder
> and Conntrack - therefore OVS requirement is OVS 2.4+

To keep the discussion going, let's talk about each of those features.

These days, OVS allows an ARP responder can be implemented in the
OpenFlow flow table (since all ARP fields are modifiable), but that has
only been true for a few versions.  Before that, an ARP responder could
only be implemented in an OpenFlow controller.  So to support those
older versions, OVN would have to detect support for ARP field
modification and divert packets to ovn-controller.  I think
ovn-controller will probably need a general framework for that kind of
thing, so it's probably feasible.

But maybe by "ARP responder" you don't mean the ability to respond to
ARP requests but the ability to synthesize ARP requests from IP packets,
like a router needs to do.  OVN will have to do this to implement L3
features.  No current version of OVS can do this from the flow table, so
it will have to be implemented by ovn-controller diversion everywhere.
This may be acceptable, because ARP isn't that performance sensitive,
but perhaps we'll find out that there's good reason to build it into
OVS.  Then we'd, again, make OVN probe for support and use one strategy
or the other.

Conntrack, on the other hand, is a feature that doesn't have a
reasonable implementation without datapath support.  Without it, OVN
would have to fall back to simple TCP flags matching on OVS that
supports that, or skip the firewall entirely on OVS that doesn't have
it.

> >Or we provide feature negotiation aside of versioning.
> 
> I'd love to see feature negotiation as backwards compatibility with OVS is
> top of my wishlist for OVN.
> A rudimentary implementation could read the OVS version (if present) and/or
> schema version from OVSDB - we actually did this in OpenDaylight.
>
> I'm biased, but I think the easiest option would be to use the OVS Python
> bindings.
> [...]

That's easy with the OVSDB C bindings too.



More information about the dev mailing list