Open Stack

On Mar 15, 2013, at 8:53 AM, Rohon Mathieu <mathieu.rohon at gmail.com> wrote:

> hi,
> 
> thanks for your interest. Actually, I don't know if broadcast could be
> an issue in a normal behavior. But GRE is CPU consuming and transform
> broadcast traffic in unicast in every tunnel could potentially create
> issue on the hypervisor. also, I think this implementation could limit
> the impact of a flooding ARP attack, and it doesn't seems so hard to
> implement, at a first look.
> 
I also agree, this looks like an optimization and improvement to the existing
OVS plugin. Implementing this would be beneficial not just to GRE, but also
VXLAN and other tunnel protocols.

I should note I have a blueprint opened to add support to the OVS Quantum
plugin for both VXLAN and LISP once a released OVS supports those protocols.
OVS 1.10 will support VXLAN, while 1.11 will support LISP.

https://blueprints.launchpad.net/quantum/+spec/ovs-vxlan-lisp-tunnel

The blueprint is just a skeleton now, I will be adding additional details soon.

More comments below.

> live-migatrion use case has to be studied deeper, but it should use
> the create/delete port mechanism.
> 
> On Fri, Mar 15, 2013 at 7:54 AM, Isaku Yamahata <yamahata at valinux.co.jp> wrote:
>> On Thu, Mar 14, 2013 at 09:59:08AM +0100, Rohon Mathieu wrote:
>>> hi all,
>> 
>> Hi.
>> 
>> 
>>> I just wanted to share about a BP to limit broadcasting in every
>>> tunnel while using OVS and GRE. This could also be used for VXLan
>>> tunneling.
>>> 
>>> https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh
>>> 
>>> the specification show a call flow for the port creation.
>>> 
>>> Does anyone see something wrong in my architecture?
>> 
>> Interesting. What number of physical/virtual nodes do you expect
>> broadcast begins to matter with?
>> 
>> What about live-migration? Quantum currently supports live-migration, though.
>> When live-migration completes, hypervisor sends GARP packet to invalidate
>> stale entry in mac-learning table.
>> 
Wouldn't this method continue to work with this new mesh idea just as it did
with the previous method?

Thanks,
Kyle

>> thanks,
>> --
>> yamahata
>> 
>> _______________________________________________
>> 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