[ovs-dev] OVN and OpenStack Provider Networks
Salvatore Orlando
salv.orlando at gmail.com
Sat Jun 13 22:12:11 UTC 2015
Hi Russel,
thanks for sharing these thoughts. I was indeed thinking as well we need to
support this in OVN as the provider networks are a fairly basic neutron
feature - despite being an "extensions".
I have some comments inline. I apologise in advance for their dumbness as
I'm still getting up to speed with OVN architecture & internals.
Salvatore
On 10 June 2015 at 20:13, Russell Bryant <rbryant at redhat.com> wrote:
> I've been doing some thinking about OpenStack Neutron's provider
> networks and how we might be able to support that with OVN as the
> backend for Neutron. Here is a start. I'd love to hear what others think.
>
>
> Provider Networks
> =================
>
> OpenStack Neutron currently has a feature referred to as "provider
> networks". This is used as a way to define existing physical networks
> that you would like to integrate into your environment.
>
> In the simplest case, it can be used in environments where they have no
> interest in tenant networks. Instead, they want all VMs hooked up
> directly to a pre-defined network in their environment. This use case
> is actually popular for private OpenStack deployments.
>
> Neutron's current OVS agent that runs on network nodes and hypervisors
> has this configuration entry:
>
> bridge_mappings = physnet1:br-eth1,physnet2:br-eth2[...]
>
> This is used to name your physical networks and the bridge used to
> access that physical network from the local node.
>
> Defining a provider network via the Neutron API via the neutron
> command looks like this:
>
> $ neutron net-create physnet1 --shared \
> > --provider:physical_network external \
> > --provider:network_type flat
>
> A provider network can also be defined with a VLAN id:
>
> $ neutron net-create physnet1-101 --shared \
> > --provider:physical_network external \
> > --provider:network_type vlan \
> > --provider:segmentation_id 101
>
The only pedant nit I have to add here is that the 'shared' setting has
nothing to do with provider networks, but on the other hand it is also true
that is required for supporting the "can't be bothered by tenant networks"
use case.
>
>
> Provider Networks with OVN
> --------------------------
>
> OVN does not currently support this use case, but it's required for
> Neutron. Some use cases for provider networks are potentially better
> served using OVN gateways. I think the "simple networking without
> tenant networks" case is at least one strong use case worth supporting.
>
the difference between the provider network and the L2 gateway is in my
opinion that the former is a mapping between a logical network and a
concrete physical network (I am considering VLANs as 'physical' here for
simplicity), whereas the L2 gateway is a "service" that inserts in the
logical topology to provide the same functionality. In other words with the
provider network abstraction your traffic goes always on your chosen
physical network, with the l2 gateway abstraction your traffic stays in the
tenant network, likely an overlay, unless packets are directed to an
address not in the tenant network, in which case they cross the gateway.
In my opinion it's just too difficult to state which abstraction is better
for given use cases. I'd rather expose both abstractions (the provider
network for now, and the gateway in the future), and let operators choose
the one that suits them better.
>
> One possible implementation would be to have a Neutron agent
> that runs parallel to ovn-controller that handles this. It would
> perform a subset of what the current Neutron OVS agent does but would
> also duplicate a lot of what OVN does. The other option is to have
> ovn-controller implement it.
> There are significant advantages to implementing this in OVN. First, it
> simplifies the deployment. It saves the added complexity of a parallel
> control plane for the neutron agents running beside ovn-controller.
>
This alonr would convince me to implement the solution with OVN; for
instance the L3 agents should then be aware of the fact that interfaces
might be plugged in multiple bridges, VIF plugging might also differ and
therefore more work might be needed with port bindings, and finally you'd
have provider networks secured in the "neutron way", whereas tenant
networks would be secured in the "OVN way"
Nevertheless, this might be a case where possibly ML2 could be leveraged
(with or without tweaks) to ensure that the OVS driver implements provider
networks, whereas the OVN driver implements tenant networks.
> Second, much of the flows currently programmed by ovn-controller
> would be useful for provider networks. We still want to implement port
> security and ACLs (security groups). The major difference is that
> unless the packet is dropped by egress port security or ACLs, it should
> be sent out the physical network and forwarded by the physical network
> infrastructure.
>
> ovn-controller would need the equivalent of the current OVS agent's
> bridge_mappings configuration option. ovn-controller is
> currently configured by setting values in the local Open_vSwitch
> ovsdb database, so a similar configuration entry could be provided
> there:
>
> $ ovs-vsctl set open .
> external-ids:bridge_mappings=physnet1:br-eth1,physnet2:br-eth2
>
> ovn-controller would expect that the environment was pre-configured
> with these bridges. It would create ports on br-int that connect to
> each bridge.
>
> These networks also need to be reflected in the OVN databases so that an
> OVN logical port can be attached to a provider network. In
> OVN_Northbound, we could add a new table called Physical_Switch
> that a logical port could be attached to instead of Logical_Switch.
>
The provider network is still a logical network. I am not able to see a
reason for having to attach a logical port to a physical switch. Can you
explain?
It seems that you are trying to describe the physical network the logical
network maps to. This makes sense, but since in Neutron then we also have
the "multi-provider" extension, which is a generalization of the provider
network concepts, would it make sense to consider some sort of logical
network bindings? These bindings might express for the time being vlan
mappings, but in the future they could be used to specify, for instance,
VTEPs or the encap type the tenant network implements. I know this might be
nonsense, but at first glance it seems a viable alternative.
> The ``Physical_Switch`` schema could be the same as Logical_Switch
> except for the addition of 'type' (flat or vlan) and 'tag' (the VLAN
> id for type=vlan)::
>
> "Physical_Switch": {
> "columns": {
> "name": {"type": "string"},
> "type": {"type": "string"},
> "tag": {
> "type": {"key": {"type": "integer",
> "minInteger": 0,
> "maxInteger": 4095},
> "router_port": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Router_Port",
> "refType": "strong"},
> "min": 0, "max": 1}},
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited"}}}},
It seems that this structure replaces the LogicalSwitch for provider
networks. While this makes sense from one side, it might not play nicely
with Neutron integration. the provider info for a neutron network can
indeed be updated [1], [2] - thus allowing to make a regular tenant network
a provider network. As usual Neutron is inconsistent in this as well: you
can transform a regular network into a provider network, but you cannot do
the opposite.
>
> Currently, a Logical_Port has a lswitch column. It would also
> need a pswitch column for when the port is attached to a
> Physical_Switch:
>
> "Logical_Port": {
> "columns": {
> "lswitch": {"type": {"key": {"type": "uuid",
> "refTable":
> "Logical_Switch",
> "refType": "strong"}}},
> "pswitch": {"type": {"key": {"type": "uuid",
> "refTable":
> "Physical_Switch",
> "refType": "strong"}}},
> ...
>
If I get your proposal correct, pswtich and lswtich are mutually exclusive,
or can a port be attached to a pswitch and a lswtich at the same time?
>
> This would have an impact on the OVN_Southbound database, as well.
> No schema changes have been identified. Entries in the Bindings
> table would be the same, except that the UUID in the
> logical_datapath column would refer to a Physical_Switch instead
> of a Logical_Switch. The contents of the Pipeline and the
> flows set up by ovn-controller would need to change.
>
Would we need chassis entries also for the bridges implementing the mapping
with physical networks, or do we consider them to be outside of the OVN
realm?
> In the case of a Physical_Switch instead of a Logical_Switch,
> one major difference is that output to a port that is non-local is just
> sent out to the physical network bridge instead of a tunnel.
>
> Another difference is that packets for an unknown destination should
> also be sent out to the physical network bridge instead of dropped.
>
>
> If there is some consensus that supporting something like this makes
> sense, I'm happy to take on the next steps, which would include a more
> detailed proposal that includes Pipeline and flow details, as well as
> the implementation.
>
> Thanks,
>
[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/multiprovidernet.py#n74
[2]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/providernet.py#n32
>
> --
> Russell Bryant
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
More information about the dev
mailing list