<div dir="ltr"><div><div><div>hi henry,<br><br></div>thanks for this interesting idea. It would be interesting to think about how external gateway could leverage the l2pop framework.<br><br></div>Currently l2pop sends its fdb messages once the status of the port is modified. AFAIK, this status is only modified by agents which send update_devce_up/down().<br></div><div>This issue has also to be addressed if we want agent less equipments to be announced through l2pop.<br><br></div><div>Another way to do it is to introduce some bgp speakers with e-vpn capabilities at the control plane of ML2 (as a MD for instance). Bagpipe [1] is an opensource bgp speaker which is able to do that. <br></div><div>BGP is standardized so equipments might already have it embedded.<br></div><div><br></div><div>last summit, we talked about this kind of idea [2]. We were going further by introducing the bgp speaker on each compute node, in use case B of [2]. <br><br>[1]<a href="https://github.com/Orange-OpenSource/bagpipe-bgp">https://github.com/Orange-OpenSource/bagpipe-bgp</a><br>[2]<a href="http://www.slideshare.net/ThomasMorin1/neutron-and-bgp-vpns-with-bagpipe">http://www.slideshare.net/ThomasMorin1/neutron-and-bgp-vpns-with-bagpipe</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 26, 2015 at 7:21 AM, henry hly <span dir="ltr"><<a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi ML2er,<br>
<br>
Today we use agent_ip in L2pop to store endpoints for ports on a<br>
tunnel type network, such as vxlan or gre. However this has some<br>
drawbacks:<br>
<br>
1) It can only work with backends with agents;<br>
2) Only one fixed ip is supported per-each agent;<br>
3) Difficult to interact with other backend and world outside of Openstack.<br>
<br>
L2pop is already widely accepted and deployed in host based overlay,<br>
however because it use agent_ip to populate tunnel endpoint, it's very<br>
hard to co-exist and inter-operating with other vxlan backend,<br>
especially agentless MD.<br>
<br>
A small change is suggested that the tunnel endpoint should not be the<br>
attribute of *agent*, but be the attribute of *port*, so if we store<br>
it in something like *binding:tun_ip*, it is much easier for different<br>
backend to co-exists. Existing ovs agent and bridge need a small<br>
patch, to put the local agent_ip into the port context binding fields<br>
when doing port_up rpc.<br>
<br>
Several extra benefits may also be obtained by this way:<br>
<br>
1) we can easily and naturally create *external vxlan/gre port* which<br>
is not attached by an Nova booted VM, with the binding:tun_ip set when<br>
creating;<br>
2) we can develop some *proxy agent* which manage a bunch of remote<br>
external backend, without restriction of its agent_ip.<br>
<br>
Best Regards,<br>
Henry<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</blockquote></div><br></div>