[ovs-dev] [RFC] OVN northbound address sets

Ryan Moats rmoats at us.ibm.com
Wed Mar 9 21:32:22 UTC 2016



"dev" <dev-bounces at openvswitch.org> wrote on 03/09/2016 03:12:07 PM:

> From: Russell Bryant <russell at ovn.org>
> To: ovs dev <dev at openvswitch.org>
> Date: 03/09/2016 03:12 PM
> Subject: [ovs-dev] [RFC] OVN northbound address sets
> Sent by: "dev" <dev-bounces at openvswitch.org>
>
> I'd like to propose a new feature for the OVN northbound database.  If we
> reach some consensus, I will implement it.
>
> Overview:
>
> One use case for OVN ACLs includes matching on a set of IP addresses.  A
> simple example:
>
>     inport == "lport1" && ip.src == {10.0.0.1, 10.0.0.3, 10.0.7}
>
> This is only 3 addresses, but it could easily be hundreds of addresses.
>
> I'd like to add a new table to OVN_Northbound called something like
> "Address_Set".
>
> +        "Address_Set": {
> +            "columns": {
> +                "name": {"type": "string"},
> +                "addresses": {"type": {"key": "string",
> +                                       "min": 0,
> +                                       "max": "unlimited"}}},
> +            "indexes": [["name"]],
> +            "isRoot": false},
>
> I'd also like to be able to refer to an address set by name in an ACL
> match.  I'm not sure about the syntax, but as an example:
>
>     inport == "lport1" && ip.src == address_set("my-set")
>
>
> More context:
>
> OpenStack Neutron (the networking API for OpenStack) has a feature called
> "security groups", which were inspired by security groups for EC2.  The
> default security group policy is:
>
> +--------------------------------------+---------
> +----------------------------------------------------------------------+
> | id                                   | name    | security_group_rules
>                                             |
> +--------------------------------------+---------
> +----------------------------------------------------------------------+
> | 8db9f44c-fa02-4184-b77f-e59a6fb94acd | default | egress, IPv4
>                                             |
> |                                      |         | egress, IPv6
>                                             |
> |                                      |         | ingress, IPv4,
> remote_group_id: 8db9f44c-fa02-4184-b77f-e59a6fb94acd |
> |                                      |         | ingress, IPv6,
> remote_group_id: 8db9f44c-fa02-4184-b77f-e59a6fb94acd |
> +--------------------------------------+---------
> +----------------------------------------------------------------------+
>
> This translates to:
>
> * Allow all outbound IPv4 and IPv6 traffic from the VM.
> * Allow all inbound IPv4 and IPv6 traffic that originated from other
ports
> that have this same security group assigned to them.
> * Otherwise, drop traffic by default.
>
> Implementation of "remote_group_id" requires matching on the set of IP
> addresses for all ports using this security group.
>
> There is a lot of flexibility with OVN ACLs.  The approach currently used
> by the Neutron plugin is to create an OVN ACL for each security group
rule
> on a port.  The ACLs for a given port with this "default" policy might be
> something like:
>
> from-lport  1002 (inport == "5155d5f6-4f1d-4ce2-81a5-60320f412040" &&
ip4)
> allow-related
> from-lport  1002 (inport == "5155d5f6-4f1d-4ce2-81a5-60320f412040" &&
ip6)
> allow-related
>   to-lport  1002 (outport == "5155d5f6-4f1d-4ce2-81a5-60320f412040" &&
ip4
> && (ip4.src == 10.0.0.10 || ip4.src == 10.0.0.9)) allow-related
>   to-lport  1002 (outport == "5155d5f6-4f1d-4ce2-81a5-60320f412040" &&
ip6
> && (ip6.src == fd73:4054:de17:0:f816:3eff:fe5b:5a77 || ip6.src ==
> fd73:4054:de17:0:f816:3eff:fe68:53d4)) allow-related
>
> This becomes much more painful as the number of ports increases.  Given
500
> ports that have both IPv4 and IPv6 addresses, we'll have 1000 ACLs, each
> with 999 IP addresses listed in them.  Adding the last address would be
> harmless, though.  When port 501 gets created, we have to go update the
set
> of IP addresses in the 1000 existing ACL rows.
>
> We could cut this down somewhat by having a single ACL row for this rule
on
> each logical switch.  There are some downsides to this.  First, we still
> have to maintain that large set of IP addresses in multiple places (one
per
> logical switch).  Second, the current ACL-per-port+rule breakdown is
fairly
> convenient.  It may also be beneficial if we want to trace a conntrack
> entry back to the OVN ACL, and then back to the exact port+rule that
> allowed it to be created.
>
> If we had this address set functionality, we could maintain address sets
> for security groups that use the "remote_group_id" functionality.  As
ports
> get added/removed, we would only update the address set and we could
leave
> all of the existing ACLs alone.  This would help greatly with one of the
> bottlenecks we currently have in the OpenStack Neutron plugin.
>
> As for implementation, one way to do this is leave it entirely as a
> northbound DB thing and have ovn-northd translate it into the full set of
> addresses in logical flows.
>
> An additional step could be to add the same "address set" functionality
to
> logical flows to reduce the amount of data expressed in logical flows.
In
> that case, I suppose the "Address_Set" table would be identical to the
one
> in OVN_Northbound.
>
> Thoughts?

IMHO, the scaling arguments for having address sets in the NB db apply
equally to the SB db, so it makes sense to me to carry this all the way
through and expand it to the full set of addresses in ovn-controller.

Ryan (regXboi)





More information about the dev mailing list