On Tue, Apr 12, 2016 at 2:17 PM, Han Zhou <zhou...@gmail.com> wrote: > > > 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). >
That's a clever idea. I'll think about that some more when working on the next revision. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
