On Mon, Jul 14, 2014 at 4:14 PM, Isaku Yamahata <isaku.yamah...@gmail.com> wrote:
> 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, > > the idea way is that OVS can hook to iptable chain at a per-flow basis, but now we have to do some trade off. Requirement of no filter comes from NFV, VNF VMs should not need dynamically enable/disable filter, and they are IO performance critical apps. However, at API level we may need to distinguish these two cases: for VNF VM we need to totally bypass qbr with ''no-port-filter" setting and ovs-plug, while for some other certain VM we just need something like "default-empty-filter", still with ovs-hybrid-plug. > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
