Hi. > 4) with no-port-security option, we should implement ovs-plug instead > ovs-hybird-plug, to totally bypass qbr but not just changing iptable rules. > the performance of later is 50% lower for small size packet even if the > iptable is empty, and 20% lower even if we disable iptable hook on linux > bridge.
Is this only for performance reason? What do you think about disabling and then enabling port-security? portsecurity API allows to dynamically change the setting after port plugging. thanks, On Mon, Jul 14, 2014 at 11:19:05AM +0800, loy wolfe <loywo...@gmail.com> wrote: > port with flexible ip address setting is necessary. I collected several use > cases: > > 1) when creating a port, we need to indicate that, > [A] binding to none of subnet(no ip address); > [B] binding to all subnets; > [C] binding to any subnet; > [D] binding to explicitly list of subnets, and/or list of ip address in > each subnet. > It seems that existing code implement [C] as the default case. > > 2) after created the port, we need to dynamically change it's address > setting: > [A] remove a single ip address > [B] remove all ip address of a subnet > [C] add ip address on specified subnet > it's not the same as "allowed-addr-pair", but it really need to allocate ip > in the subnet. > > 3) we need to allow router add interface by network uuid, not only subnet > uuid > today L3 router add interface by subnet, but it's not the common use case > that a L2 segment connect to different router interface with it's different > subnets. when a network has multiple subnets, we should allow the network > but not the subnet to attach the router. Also, we should allow a network > without any subnet (or a port without ip address) to attach to a router > (some like a brouter), while adding/deleting interface address of different > subnets dynamically later. > > this feature should also be helpful for plug-gable external network BP. > > 4) with no-port-security option, we should implement ovs-plug instead > ovs-hybird-plug, to totally bypass qbr but not just changing iptable rules. > the performance of later is 50% lower for small size packet even if the > iptable is empty, and 20% lower even if we disable iptable hook on linux > bridge. > > > > On Mon, Jul 14, 2014 at 9:56 AM, Kyle Mestery <mest...@noironetworks.com> > wrote: > > > On Fri, Jul 11, 2014 at 4:41 PM, Brent Eagles <beag...@redhat.com> wrote: > > > >> Hi, > >> > >> A bug titled "Creating quantum L2 networks (without subnets) doesn't > >> work as expected" (https://bugs.launchpad.net/nova/+bug/1039665) was > >> reported quite some time ago. Beyond the discussion in the bug report, > >> there have been related bugs reported a few times. > >> > >> * https://bugs.launchpad.net/nova/+bug/1304409 > >> * https://bugs.launchpad.net/nova/+bug/1252410 > >> * https://bugs.launchpad.net/nova/+bug/1237711 > >> * https://bugs.launchpad.net/nova/+bug/1311731 > >> * https://bugs.launchpad.net/nova/+bug/1043827 > >> > >> BZs on this subject seem to have a hard time surviving. The get marked > >> as incomplete or invalid, or in the related issues, the problem NOT > >> related to the feature is addressed and the bug closed. We seem to dance > >> around actually getting around to implementing this. The multiple > >> reports show there *is* interest in this functionality but at the moment > >> we are without an actual implementation. > >> > >> At the moment there are multiple related blueprints: > >> > >> * https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity > >> extension support > >> * https://review.openstack.org/#/c/106222/ Add Port Security > >> Implementation in ML2 Plugin > >> * https://review.openstack.org/#/c/97715 NFV unaddressed interfaces > >> > >> The first two blueprints, besides appearing to be very similar, propose > >> implementing the "port security" extension currently employed by one of > >> the neutron plugins. It is related to this issue as it allows a port to > >> be configured indicating it does not want security groups to apply. This > >> is relevant because without an address, a security group cannot be > >> applied and this is treated as an error. Being able to specify > >> "skipping" the security group criteria gets us a port on the network > >> without an address, which is what happens when there is no subnet. > >> > >> The third approach is, on the face of it, related in that it proposes an > >> interface without an address. However, on review it seems that the > >> intent is not necessarily inline with the some of the BZs mentioned > >> above. Indeed there is text that seems to pretty clearly state that it > >> is not intended to cover the port-without-an-IP situation. As an aside, > >> the title in the commit message in the review could use revising. > >> > >> In order to implement something that finally implements the > >> functionality alluded to in the above BZs in Juno, we need to settle on > >> a blueprint and direction. Barring the happy possiblity of a resolution > >> beforehand, can this be made an agenda item in the next Nova and/or > >> Neutron meetings? > >> > >> I think this is worth discussing. I've added this to the "Team Discussion > > Topics" section of the Neutron meeting [1] on 7-14-2014. I hope you can > > attend Brent! > > > > Thanks, > > Kyle > > > > [1] > > https://wiki.openstack.org/wiki/Network/Meetings#Team_Discussion_Topics > > > > > >> Cheers, > >> > >> Brent > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata <isaku.yamah...@gmail.com> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev