[ovs-dev] [PATCH v3] [RFC] ovn: Start work on design documentation.

Gray, Mark D mark.d.gray at intel.com
Fri Feb 27 17:33:53 UTC 2015


> From: Ben Pfaff [mailto:blp at nicira.com]
> Sent: Friday, February 27, 2015 6:54 AM
> On Thu, Feb 26, 2015 at 05:11:54PM +0000, Gray, Mark D wrote:
> > > From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Ben
> > > Pfaff
> > > Sent: Friday, February 20, 2015 7:20 AM
> > > To: dev at openvswitch.org
> > > Cc: Ben Pfaff
> > > Subject: [ovs-dev] [PATCH v3] [RFC] ovn: Start work on design
> > > documentation.
> > >
> >
> > I have some questions below to help my understanding as it's kind of
> > difficult to follow without diagrams, but I think I have the general
> > idea. I look forward to seeing a presentation on this eventually,
> > maybe at the next ovs conf!
> 
> I'd be happy to add some diagrams.  What would it be most helpful to
> illustrate?

I think the thing that is missing for me is the network topology with labels
indicating how various points of the network are associated with table
entries. 

When the OpenStack conference slides get published in May it should
be sufficient.

> 
> Justin and I and Kyle Mestery submitted a presentation proposal for the next
> OpenStack conference, in May.  Our goal is to have a demo-able version of
> OVN ready for that conference.

Cool, I don’t think I will be attending but I'm sure we'll have someone there.
> 
> > > +  <p>
> > > +    OVN, the Open Virtual Network, is a system to support virtual
> network
> > > +    abstraction.  OVN complements the existing capabilities of OVS to add
> > > +    native support for virtual network abstractions, such as virtual L2 and
> L3
> > > +    overlays and security groups.  Just like OVS, OVN's design goal is to
> have
> > > +    a production-quality implementation that can operate at significant
> scale.
> > > +  </p>
> >
> > Will security groups work with the userspace datapath or will
> > something need to be added in userspace?
> 
> We plan to base security groups on the connection-tracking distributed
> firewall support currently in progress for the kernel module.  The same
> support can be added to the userspace version, though it will be more work
> since DPDK doesn't already (as far as I know) have a connection-tracking
> library like the kernel does.
> 
> I seem to recall that I've seen adding userspace support for this on the big to-
> do list on Justin's whiteboard, though I can't swear to it and doubt anything's
> been scheduled yet.
> 
> > > +        A <dfn>Cloud Management System</dfn> (<dfn>CMS</dfn>),
> which is
> > > +        OVN's ultimate client (via its users and administrators).  OVN
> > > +        integration requires installing a CMS-specific plugin and
> > > +        related software (see below).  OVN initially targets OpenStack
> > > +        as CMS.
> > > +      </p>
> >
> > Are you engaging with the OpenStack community on this? Do you have a
> > blueprint?
> 
> Yes, we've quite a bit of discussion (and a number of volunteers) on the
> openstack development list, please do feel free to jump over there if you are
> curious about details.

Thanks for the info
> 
> > > +    <li>
> > > +      <code>ovn-nbd</code>(8) connects to the OVN Northbound
> > > + Database
> > > above it
> > > +      and the OVN Database below it.  It translates the logical network
> > > +      configuration in terms of conventional network concepts, taken from
> the
> > > +      OVN Northbound Database, into logical datapath flows in the
> > > + OVN
> > > Database
> > > +      below it.
> > > +    </li>
> >
> > As both of these databases are common to all instances of
> > ovn-controller, what influenced the design decision to have this
> > double database model? Could you have defined some kind of
> > message-based api northbound that was then translated and inserted
> > into the ovn database or directly into ovsdb? I'm just curious. I
> > presume it was due to ease of implementation?
> 
> ovn-controller, which runs on all the hypervisors, connects only to the OVN
> Database.  The hypervisors don't have any direct connection to the OVN
> Northbound Database.  (Please take a look at the diagram; it's pretty
> helpful.)

I did look. It was helpful. 
> 
> Here's where all this started.  The OVN Database is the center of the system.
> It's what all the hypervisors and gateways interface to directly, and in fact all
> they interface to northbound, OVN-wise at least.  The CMS plugin could
> control OVN by directly talking to it, and that was in fact our initial design.
> That raises an issue, however.
> The OVN database is really low-level and poorly impedance-matched to the
> concepts in a typical CMS, so it seems like by writing a CMS plugin to fill it in,
> one would end up writing a lot of code that you'd want to reuse when you
> added OVN support to a second CMS.  That prompted the idea of
> implementing a library to translate CMS-level concepts to OVN concepts, and
> eventually the library morphed into a database schema.
> There are other alternatives (e.g. a REST API, a command-line tool, a SQL
> database instead of OVSDB, or back to the library idea) and the exact form
> isn't critical, so we're just starting out this way for now.

Make sense. ovsdb is pretty well understood by the community aswell which helps.
> 
> > > +    <li>
> > > +      <code>ovs-nbd</code> receives the OVN Northbound database
> > > update.  In
> > > +      turn, it makes the corresponding updates to the OVN database,
> > > + by
> > > adding
> > > +      rows to the OVN database <code>Pipeline</code> table to
> > > + reflect the
> > > new
> > > +      port, e.g. add a flow to recognize that packets destined to the new
> > > +      port's MAC address should be delivered to it, and update the
> > > + flow that
> >
> > Openstack's neutron uses normal action in both the integration and
> > physical bridge. What kind of flows would get added?
> 
> Flows that implement the logical network topology.  The original architecture
> description has a few sketchy details, toward the bottom of this message:
>         http://openvswitch.org/pipermail/dev/2015-January/050380.html

Good info, I didn't see that thread as I didn’t go back as far as January :)

> 
> > Also, does this mean that the ovn-controller will also be an OpenFlow
> > client to OVS? The diagram doesn’t really indicate that.
> 
> Yes, OpenFlow is the only direct connection between ovs-vswitchd and ovn-
> controller.  That's what the line between them in the diagram is intended to
> show.
> 
> > > +  <p>
> > > +    The amount of PN data is small (O(n) in the number of chassis) and it
> > > +    changes infrequently, so it can be replicated to every chassis.
> >
> > This confuses me, I thought that above it seemed to suggest that there
> > was a single ovn database but you talk about replication here. Is the
> > northbound database central but the ovn database local on each node?
> > Or is the replication due to the clustering that you mention somewhere
> > above?
> 
> Typical OVSDB usage is based on the idea of the client keeping a copy (a
> replica) of the database, or a subset of it.  The client requests a copy of the
> database from the server plus information on changes as they occur.
> 
> > > +    configuration, although that happens indirectly via the OVN
> > > + Northbound
> > > DB
> > > +    and <code>ovn-nvd</code>.
> >
> > ovn-nbd
> 
> Thanks, I fixed that before I pushed this commit earlier today.
> 
> > I hear it's pronounce "oven"? Between that and ovs-*kettle, have you
> > guys got some kind of kitchen theme going on!?
> 
> The theme is only half-baked.

I knew you guys had something cooking

> 
> See also my logo proposal: http://benpfaff.org/~blp/ovn.png


More information about the dev mailing list