On Tue, Apr 12, 2016 at 11:02 AM, Russell Bryant <russ...@ovn.org> wrote: > > On Tue, Apr 12, 2016 at 1:35 PM, Mickey Spiegel <emspi...@us.ibm.com> wrote: > > > One comment below. > > > > -----"dev" <dev-boun...@openvswitch.org> wrote: ----- > > > > >To: Ben Pfaff <b...@ovn.org> > > >From: Russell Bryant > > >Sent by: "dev" > > >Date: 04/12/2016 09:37AM > > >Cc: ovs dev <dev@openvswitch.org> > > >Subject: Re: [ovs-dev] [PATCH 3/3] ovn: Add address_set() support for > > >ACLs. > > > > > > > >On Mon, Apr 11, 2016 at 12:08 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > > >> On Tue, Apr 05, 2016 at 05:24:19PM -0400, Russell Bryant wrote: > > >> > This feature was originally proposed here: > > >> > > > >> > http://openvswitch.org/pipermail/dev/2016-March/067440.html > > >> > > > >> > A common use case for OVN ACLs involves needing to match a set of IP > > >> > addresses. > > >> > > > >> > outport == "lp1" && ip4.src == {10.0.0.5, 10.0.0.25, 10.0.0.50} > > >> > > > >> > This example match only has 3 addresses, but it could easily have > > >> > hundreds of addresses. In some cases, the same large set of addresses > > >> > needs to be used in several ACLs. > > >> > > > >> > This patch adds a new Address_Set table to OVN_Northbound so that a > > set > > >> > of addresses can be specified once and then referred to by name in > > ACLs. > > >> > To recreate the above example, you would first create an address set: > > >> > > > >> > $ ovn-nbctl create Address_Set name=set1 > > >> addresses=10.0.0.5,10.0.0.25,10.0.0.50 > > >> > > > >> > Then you can refer to this address set by name in an ACL match: > > >> > > > >> > outport == "lp1" && ip4.src == address_set(set1) > > >> > > > >> > Signed-off-by: Russell Bryant <russ...@ovn.org> > > >> > > >> It might be worth making address sets scoped somehow. Otherwise it > > >> might eventually become a bottleneck if there are many address sets that > > >> a given hypervisor does not need to know about. > > >> > > > > > >Good point. > > > > > >The primary use case I have for this is to use in the match column of OVN > > >ACLs. ACLs are scoped to logical switches, so we could do the same for > > >address sets. Having them scoped equally makes sense to me. > > > > > >The only downside I can think of is that it will cause OpenStack to have > > to > > >duplicate the same address set across multiple logical switches in some > > >cases. I think that's probably OK though. It's still a huge improvement > > >over what it does today. > > > > Thinking of the use of remote_group_id in OpenStack security groups, I > > believe it would be common for the same address set to be used in all > > logical switches that are connected to the same logical router. Since there > > is no notion of project in OVN, it is not so obvious what to scope address > > sets to. > > > > Yes, that's right. I was just assuming that the common case was not having > having that many networks, so that we still got a significant improvement. > > One option would be to skip trying to scope it for now and revisit if it > becomes a bottleneck. >
Agree, it would be better not scope address set to lswitches. > > > Would it be good enough to have controllers check to see if the address > > set is used by any of the local logical switches? > > > > That's not easy to do. That check means scanning all logical flows to see > if the address set is referenced. We need to load all address sets before > processing logical flows so that we can actually make sense of the address > set reference when we hit one. > Since we will know which acls are using an address set, and acls are scoped to lswitches, then we can deduce the lswitches that uses an address set. How about storing this information in a new column of address set table in SB, so that ovn-controller can utilize this information for optimization? (Of course this is not required in the first version). > -- > Russell Bryant > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev -- Best regards, Han _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
