[ovs-dev] OVN and OpenStack Provider Networks

Ben Pfaff blp at nicira.com
Tue Jun 23 22:56:15 UTC 2015


On Tue, Jun 23, 2015 at 11:58:25PM +0200, Salvatore Orlando wrote:
> I'm afraid I have to start bike shedding on this thread too.
> Apparently that's what I do best.

These are important clarifications, not bikeshedding.

More below (with lots of trimming and reflowing for clarity):

> On 06/23/2015 05:10 PM, Ben Pfaff wrote:
> > A "tenant network" is what OVN calls a logical network.  OVN can
> > construct it as an L2-over-L3 overlay with STT or Geneve or
> > whatever.  Tenant networks can be connected to physical networks via
> > OVN gateways.
> >
> > A "provider network" is just a physical L2 network (possibly
> > VLAN-tagged).  In such a network, on the sending side, OVN would
> > rely on normal L2 switching for packets to reach their destinations,
> > and on the receiving side, OVN would not have a reliable way to
> > determine the source of a packet (it would have to infer it from the
> > source MAC).  Is that accurate?
> 
> While this is correct, it is also restrictive - as that would imply that a
> "provider network" is just a physical L2 segment on the data centre.
> Therefore logical ports on a provider networks would be pretty much pass
> through to the physical network. While it is correct that they might be
> mapped to OVS ports on a bridge doings plain L2 forwarding onto a physical
> network, this does not mean that L2 forwarding is the only thing that one
> can do on provider networks.
> 
> A provider network is, from the neutron perspective, exactly like any other
> logical network, including tenant networks. What changes are bindings (or
> mappings, I don't know what's the correct OVN terminology). These bindings
> define three aspects:
> 1 - the transport type (VLAN, GRE, STT, VxLAN, etc)
> 2 - the physical network, if any
> 3 - the segmentation id on the physical network, if any,
> 
> For tenant networks, bindings are implicit and depend on what the control
> plan defaults to. As Ben was suggesting this could STT or Geneve.
> For provider networks, these bindings are explicit, as the admin defines
> them. For instance I want this network to be mapped to VLAN 666 on physical
> network MEH.
> 
> In practical terms with provider networks the control plane must honour the
> specification made in the neutron request concerning transport bindings for
> the logical networks. If it can't honour these mapping - for instance if it
> does not support the select transport type - it must return an error.
> Nevertheless the control plane still treats provider networks like any
> other network. You can have services like DHCP on them (even if often is
> not a great idea), apply security groups to its ports, uplink them to
> logical routers, and so on.

OK, let me take another stab at a recap, then.

For a tenant network, it is outside the scope of Neutron to dictate or
configure how packets are transported among VMs.  Instead, that is
delegated to the plugin itself or to whatever the plugin configures
(e.g. in this case, to OVN).

For a provider network, the administrator (via Neutron) configures use
of a specific transport in a specific way.  A Neutron plugin must
operate over that configured transport in that way, or if cannot then it
must refuse to operate at all.

OK, if that all that is correct, does the following logical extension
also hold?  A provider network implementation is expected to
transparently interoperate with preexisting software that shares a given
transport.  For example, if I set up a provider network with Neutron on
a particular Ethernet network, and I have a bunch of physical machines
attached to the same Ethernet network, then I would expect my Neutron
VMs attached to the physical network to be able to communicate back and
forth with those physical machines.

If that is the case, then I guess one description of the two different
types of network is this: a Neutron plugin may *define* a tenant
network, but a Neutron plugin only *participates* in a provider network.
Is that fair?

(I apologize if all this should be obvious to Neutron veterans.  I'm new
to this!)

Thanks,

Ben.



More information about the dev mailing list