Open Stack

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.

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.
>
> thanks,
> --
> yamahata
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev