<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 11, 2013 at 11:41 AM, Eleouet Francois <span dir="ltr"><<a href="mailto:f.eleouet@gmail.com" target="_blank">f.eleouet@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p>Hi,</p></div></blockquote><div><br></div><div style>Hi, </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">

<p>Great! It opens new perspectives for Linuxbridge plugin!<br></p>

<p>I was actually also trying to implement a VXLAN
LinuxBridge extension leveraging the integrated proxy-ARP capabilities (this
feature is supported in 3.8 kernel, which should be included in havana's
timeline distributions).</p></div></blockquote><div><br></div><div style>Yes I have already seen this :-) I'm already working on this feature for linuxbridge plugin :-) I'm still wondering what should be the behavior if we detect that feature is not supported by the kernel but</div>

<div style>agent is configured to use it. I don't know if I should just raise an exception and exit agent or just produce error message. Do you have any thoughts on that ?</div><div style> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">

<p>It could be and alternative to dataplane-based learning,
that may raise some scalability issues (see <a href="https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh" target="_blank">https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh</a>
that tries to solve generalized broadcast scalability issue on OVS pluging)</p>

<p>It's pretty hard to figure out how to distribute [mac,
IP, VNID, agent_ip] among agents to populate the proxy-arp, there are lots of
alternatives... I was expecting to discuss about them during the summit (<a href="http://summit.openstack.org/cfp/details/263" target="_blank">http://summit.openstack.org/cfp/details/263</a>
should be a good place for that talk)</p></div></blockquote><div><br></div><div style>As i wrote some time ago on this ml, i believe that for most of the enviroments we could go with non-broadcast,l3-switching-based addressing ethernet networks and just forward all dhcp and arp packets to appropriate nodes (when running with openvswitch module). But as you mentioned it's a very difficult task to distribute appropriate data to the agents and update flow tables. Do you already have some ideas you can share ?</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">

<p>Anyway, if two alternatives could merge peacefully, it
seems to be is a small issue in your proposal: as you explained in
linuxbridge_config.ini, VNIDs are globals in VXLAN module, putting them in
NetworkState DB makes them allocatable on a per-physicalNetwork basis. It could raise (netlink) errors if several
PhysicalNetworks are declared, wouldn't it be better to use a separate DB as
OVS plugin does in TunnelAllocation? Or maybe modular-L2 should be revisited (<a href="https://blueprints.launchpad.net/quantum/+spec/modular-l2" target="_blank">https://blueprints.launchpad.net/quantum/+spec/modular-l2</a>)?</p>

</div></blockquote><div style>I believe it's better to stay with mapping VNI to physical_networks as this allows to bound VNIs range to a specific interface (this is not possible within OVS plugin). The only thing I need to implement is simple check to avoid overlapping VNI between different physical networks (this will be done during quantum-server startup). </div>

</div><br clear="all"><div><br></div>-- <br>Tomasz Paszkowski<br>SS7, Asterisk, SAN, Datacenter, Cloud Computing<br>+48500166299
</div></div>