[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

reedip banerjee reedip14 at gmail.com
Fri Apr 15 02:02:42 UTC 2016

Speaking on behalf of Tap-as-a-Service members, we would also be very much
interested in the following initiative.... :)

On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka <ihrachys at redhat.com>

> Cathy Zhang <Cathy.H.Zhang at huawei.com> wrote:
>> I think there is no formal spec or anything, just some emails around
>> there.
>> That said, I don’t follow why it’s a requirement for SFC to switch to l2
>> agent extension mechanism. Even today, with SFC maintaining its own agent,
>> there are no clear guarantees for flow priorities that would avoid all
>> possible conflicts.
>> Cathy> There is no requirement for SFC to switch. My understanding is
>> that current L2 agent extension does not solve the conflicting entry issue
>> if two features inject the same priority table entry. I think this new L2
>> agent effort is try to come up with a mechanism to resolve this issue. Of
>> course if each feature( SFC or Qos) uses its own agent, then there is no
>> coordination and no way to avoid conflicts.
> Sorry, I probably used misleading wording. I meant, why do we consider the
> semantic flow management support in l2 agent extension framework a
> *prerequisite* for SFC to switch to l2 agent extensions? The existing
> framework should already allow SFC to achieve what you have in the
> subproject tree implemented as a separate agent (essentially a fork of OVS
> agent). It will also set SFC to use standard extension mechanisms instead
> of hacky inheritance from OVS agent classes. So even without the strict
> semantic flow management, there is benefit for the subproject.
> With that in mind, I would split this job into 3 pieces:
> * first, adopt l2 agent extension mechanism for SFC functionality
> (dropping custom agent);
> * then, work on semantic flow management support in OVS agent API class
> [1];
> * once the feature emerges, switch SFC l2 agent extension to the new
> framework to manage SFC flows.
> I would at least prioritize the first point and target it to Newton-1.
> Other bullet points may take significant time to bake.
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py
> Ihar
> __________________________________________________________________________
> 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

Thanks and Regards,
Reedip Banerjee
IRC: reedip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/f1578ecb/attachment.html>

More information about the OpenStack-dev mailing list