Open Stack

Hi,

there are still some differences in terms of features supported by the two
implementations. Those I am aware of are :
-LB can support VLAN transparent networks as mentionned in [2];
-OVS supports MPLS tagging, needed by the bagpipe driver of the bgpvpn
project;
-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].

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.

[2]https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst
[3]https://bugs.launchpad.net/neutron/+bug/1445089

On Tue, Jun 23, 2015 at 9:03 AM, Irena Berezovsky <irenab.dev at gmail.com>
wrote:

>
>
> On Mon, Jun 22, 2015 at 7:48 PM, Sean M. Collins <sean at coreitpro.com>
> wrote:
>
>> On Mon, Jun 22, 2015 at 10:47:39AM EDT, Salvatore Orlando wrote:
>> > I would probably start with something for enabling the L2 agent to
>> process
>> > "features" such as QoS and security groups, working on the OVS agent,
>> and
>> > then in a second step abstract a driver interface for communicating with
>> > the data plane. But I honestly do not know if this will keep the work
>> too
>> > "OVS-centric" and therefore won't play well with the current efforts to
>> put
>> > linux bridge on par with OVS in Neutron. For those question we should
>> seek
>> > an answer from our glorious reference control plane lieutenant, and
>> perhaps
>> > also from Sean Collins, who's coordinating efforts around linux bridge
>> > parity.
>>
>> I think that what Salvatore has suggested is good. If we start creating
>> good API contracts, and well defined interfaces in the reference control
>> plane agents - this is a good first step. Even if we start off by doing
>> this just for the OVS agent, that'll be a good template for what we
>> would need to do for any agent-driven L2 implementation - and it could
>> easily be re-used by others.
>>
>> To be honest, if you squint hard enough there really are very few
>> differences between the OVS agent and the Linux Bridge agent does -
>> the parts that handle control plane communication, processing
>> data updates, and so forth should all be very similar.
>>
>> They only become different at the lower
>> levels where it's brctl/ip2 vs. ovs-vsctl/of-ofctl CLI calls - so why
>> maintain two separate agent implementations when quite a bit of what
>> they do is functionally identical?
>>
>
> 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.
> This work should have minimal impact on Server side, and mostly about code
> reuse by L2 Agents.
>
> [1] https://review.openstack.org/#/c/189723/
>
> BR,
> Irena
>
>> --
>> Sean M. Collins
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150623/42d85381/attachment.html>