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