<div dir="ltr">Speaking on behalf of Tap-as-a-Service members, we would also be very much interested in the following initiative.... :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com" target="_blank">Cathy.H.Zhang@huawei.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think there is no formal spec or anything, just some emails around there.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></span>
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.<br>
<br>
With that in mind, I would split this job into 3 pieces:<br>
* first, adopt l2 agent extension mechanism for SFC functionality (dropping custom agent);<br>
* then, work on semantic flow management support in OVS agent API class [1];<br>
* once the feature emerges, switch SFC l2 agent extension to the new framework to manage SFC flows.<br>
<br>
I would at least prioritize the first point and target it to Newton-1. Other bullet points may take significant time to bake.<br>
<br>
[1] <a href="https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py" rel="noreferrer" target="_blank">https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py</a><div class="HOEnZb"><div class="h5"><br>
<br>
Ihar<br>
<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></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks and Regards,<br>Reedip Banerjee</div><div>IRC: reedip</div><div><br></div><div><br><br><br></div></div></div></div></div>
</div>