On Tue, Jul 14, 2015 at 11:59:30AM -0400, Russell Bryant wrote:
> On 07/14/2015 10:59 AM, Ben Pfaff wrote:
> > 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.
These all seem like reasonable ideas to me.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
