Open Stack

On Mon, Jul 14, 2014 at 4:14 PM, Isaku Yamahata <isaku.yamahata at 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 <loywolfe at 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 <mestery at noironetworks.com
> >
> > wrote:
> >
> > > On Fri, Jul 11, 2014 at 4:41 PM, Brent Eagles <beagles at 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 at lists.openstack.org
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Isaku Yamahata <isaku.yamahata at gmail.com>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140714/efe3959b/attachment.html>