<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>there are still some differences in terms of features supported by the two implementations. Those I am aware of are :<br></div>-LB can support VLAN transparent networks as mentionned in [2];<br></div>-OVS supports MPLS tagging, needed by the bagpipe driver of the bgpvpn project;<br></div>-when arp responder is activated (with l2pop), OVS supports the fallback to learning mode if the arp responder is not populated. The Vxlan module used with LB does not support it, which leads to bug like [3].<br><br></div>The framework mentionned by irena in [1] is a good approach to report back to the user what features are supported by the cloud and the underlying technology in use.<br><div><div><br>[2]<a href="https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst" target="_blank">https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst</a><br>[3]<a href="https://bugs.launchpad.net/neutron/+bug/1445089" target="_blank">https://bugs.launchpad.net/neutron/+bug/1445089</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 9:03 AM, Irena Berezovsky <span dir="ltr"><<a href="mailto:irenab.dev@gmail.com" target="_blank">irenab.dev@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Jun 22, 2015 at 7:48 PM, Sean M. Collins <span dir="ltr"><<a href="mailto:sean@coreitpro.com" target="_blank">sean@coreitpro.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"><span>On Mon, Jun 22, 2015 at 10:47:39AM EDT, Salvatore Orlando wrote:<br>
> I would probably start with something for enabling the L2 agent to process<br>
> "features" such as QoS and security groups, working on the OVS agent, and<br>
> then in a second step abstract a driver interface for communicating with<br>
> the data plane. But I honestly do not know if this will keep the work too<br>
> "OVS-centric" and therefore won't play well with the current efforts to put<br>
> linux bridge on par with OVS in Neutron. For those question we should seek<br>
> an answer from our glorious reference control plane lieutenant, and perhaps<br>
> also from Sean Collins, who's coordinating efforts around linux bridge<br>
> parity.<br>
<br>
</span>I think that what Salvatore has suggested is good. If we start creating<br>
good API contracts, and well defined interfaces in the reference control<br>
plane agents - this is a good first step. Even if we start off by doing<br>
this just for the OVS agent, that'll be a good template for what we<br>
would need to do for any agent-driven L2 implementation - and it could<br>
easily be re-used by others.<br>
<br>
To be honest, if you squint hard enough there really are very few<br>
differences between the OVS agent and the Linux Bridge agent does -<br>
the parts that handle control plane communication, processing<br>
data updates, and so forth should all be very similar.<br>
<br>
They only become different at the lower<br>
levels where it's brctl/ip2 vs. ovs-vsctl/of-ofctl CLI calls - so why<br>
maintain two separate agent implementations when quite a bit of what<br>
they do is functionally identical?<br></blockquote><div> </div></div></div><div>As Miguel mentioned, the patch [1] adds support for QoS driver in L2 Agents. Since QoS support is planned to be leveraged by OVS and SR-IOV and maybe later by Linux Bridge, the idea is to make common L2Agent layer to enable generic support for features (extensions) and QoS as the first feature to support. This is not the Modular L2 Agent, but definitely the step into the right direction.  </div><div>This work should have minimal impact on Server side, and mostly about code reuse by L2 Agents.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/189723/" target="_blank">https://review.openstack.org/#/c/189723/</a></div><div><br></div><div>BR,</div><div>Irena</div><span class=""><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"><span><font color="#888888">
--<br>
Sean M. Collins<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>