On 07/14/2015 10:59 AM, Ben Pfaff wrote:
> I think that the various issues with trying to treat a provider network
> as a logical network are going to difficult to resolve. I think that
> they reflect a conceptual difference between OVN logical networks and
> provider networks. OVN knows the hosts on a logical network and where
> they reside, but it doesn't know that for a provider network, and can't
> do anything related to specific hosts except in the pathological case
> where they reside on the same hypervisor. Broadcast may be a problem,
> but so is a simple output to any port: it's impossible unless the source
> and destination ports are on the same hypervisor. So my thought is that
> modeling a provider network as an OVN logical network is unlikely to be
> fruitful (unless we change the OVN logical network model significantly).
Yes, that seems to be what I'm hitting as I keep working on this. The
more I've worked on trying to make this work using a single OVN logical
network, the more I feel like it just isn't making sense.
> Here's an a strawman alternative. Instead of representing a provider
> network as a single logical network, represent it as a collection of
> logical networks, one for each connected port. Each of these logical
> networks has only two ports, the VM's port plus a physical port on the
> hypervisor where the VM resides (or more likely a patch port to the
> bridge that contains the physical port; the other end of the patch port
> can be an access port if it's a VLAN provider network). It seems to me
> that this models the situation more naturally.
>
> Thoughts?
That's a really interesting idea. Conceptually it seems to map much
nicer than the previous approach. A logical port with MACs configured
as "unknown" matches the processing needed. I'm going to go down this
road and see what I can come up with.
Some misc implementation thoughts ...
When Neutron creates these ports, it needs to indicate that one of the
ports is special and maps to local connectivity to the provider network.
The ovn-controller-vtep work has similar needs and is doing so with a
special port name that follows a particular pattern.
In the case of ovn-controller-vtep, it's using the pattern:
<physical switch name>_<vtep logical switch name>
For provider networks, I need:
- physical network name, which maps to a local ovs bridge
determined by configuration local to each ovn-controller
- Optionally a VLAN ID
I was previously thinking that special names was fine, but maybe we
should go ahead and add attributes to the logical port in OVN_Northbound
to handle this.
For reference, the current schema is:
> "Logical_Port": {
> "columns": {
> "name": {"type": "string"},
> "parent_name": {"type": {"key": "string", "min": 0, "max":
> 1}},
> "tag": {
> "type": {"key": {"type": "integer",
> "minInteger": 0,
> "maxInteger": 4095},
> "min": 0, "max": 1}},
> "macs": {"type": {"key": "string",
> "min": 0,
> "max": "unlimited"}},
> "port_security": {"type": {"key": "string",
> "min": 0,
> "max": "unlimited"}},
> "up": {"type": {"key": "boolean", "min": 0, "max": 1}},
> "enabled": {"type": {"key": "boolean", "min": 0, "max": 1}},
> "external_ids": {
> "type": {"key": "string", "value": "string",
> "min": 0, "max": "unlimited"}}},
> "indexes": [["name"]],
> "isRoot": false},
We could add a new string column called "type". Possible values could be:
- (blank). The current behavior.
- vtep : This logical port represents a connection to a logical switch
on a VTEP enabled switch
- local : This logical port represents a connection to an OVS bridge
that exists locally to each ovn-controller.
Next we could have an "options" column for key-value pairs of options
specific to the configured "type". For vtep you'd have the physical and
logical switch names. For local you'd have the network name and
optionally a VLAN ID.
--
Russell Bryant
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
