Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140714/b20a3331/attachment.html>