<div dir="ltr"><div>Hi,</div><br><div class="gmail_extra"><div class="gmail_quote">2013/4/11 Tomasz Paszkowski <span dir="ltr"><<a href="mailto:ss7pro@gmail.com" target="_blank">ss7pro@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><p>Hi,</p></div></blockquote><div>
<div><br></div><div>Hi, </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><div>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>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><div> </div></div></div></div>
</div></blockquote><div>It's a good question which doesn't only concerns proxy-arp feature but also VXLAN support...I suppose the agent could exit as it would be an incoherent configuration, but the plugin should also check if VXLAN is enabled globally in order to prevent provider network allocation if VXLAN is not supported.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><div>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>

<div><br></div></div></div></div></div></blockquote><div style>For now, 3 different alternatives were coming to my mind:</div><div style>-A centralized approach where plugin distributes [mac, IP, VNID, agent_ip] tuples to the agents (rpc distribution of these tuples could be triggered by update_device_up/down) in this case plugin would need an additionnal DB to track port to agents mappings, as well as agent_ips</div>
<div style>-A distributed one where agent fanout_casts [mac, IP, VNID, agent_ip] to other agents when a port becomes up. Agents having ports on the same networks should answer with the properties of the ports they handle. To achieve this agents should maintin a list of their ports.</div>
<div style>-We could also think to use an external control plane: BGP may land in quantum for VPNaaS, it could also be a good candidate to propagate VXLAN neighbors infomations (see <a href="http://tools.ietf.org/html/draft-boutros-l2vpn-vxlan-evpn-01">http://tools.ietf.org/html/draft-boutros-l2vpn-vxlan-evpn-01</a>)</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><div>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>

<span><font color="#888888">

</font></span></div><span><font color="#888888"><div><br></div></font></span></div></div></blockquote><div>Yes, but it'll remain an issue with provider networks: if several <span style="color:rgb(80,0,80)">physicalNetworks a</span>re declared, the same VNI could still be reserved on different <span style="color:rgb(80,0,80)">physicalNetworks...</span></div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><font color="#888888"><div>

</div>-- <br>Tomasz Paszkowski<br>SS7, Asterisk, SAN, Datacenter, Cloud Computing<br><a href="tel:%2B48500166299" value="+48500166299" target="_blank">+48500166299</a>
</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>