<div dir="ltr">AFAIK, there is proposal about adding a 'priority' option in the existing flow classifier rule. This can ensure the rule ordering.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro <span dir="ltr"><<a href="mailto:iwamoto@valinux.co.jp" target="_blank">iwamoto@valinux.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At Wed, 20 Apr 2016 14:12:07 +0200,<br>
<span class="">Miguel Angel Ajo Pelayo wrote:<br>
><br>
> I think this is an interesting topic.<br>
><br>
> What do you mean exactly by FC ? (feature chaining?)<br>
><br>
> I believe we have three things to look at:  (sorry for the TL)<br>
><br>
> 1) The generalization of traffic filters / traffic classifiers. Having<br>
> common models, some sort of common API or common API structure<br>
> available, and translators to convert those filters to iptables,<br>
> openflow filters, etc..<br>
><br>
> 2) The enhancement of extensiblity of agents via Extension API.<br>
><br>
> 3) How we chain features in OpenFlow, which current approach of just<br>
> inserting rules, renders into incompatible extensions. This becomes<br>
> specially relevant for the new openvswitch firewall.<br>
><br>
> 2 and 3 are interlinked, and a good mechanism to enhance (3) should be<br>
> provided in (2).<br>
><br>
> We need to resolve:<br>
><br>
>     a) The order of tables, and how openflow actions chain the<br>
> different features in the pipeline.  Some naive thinking brings me<br>
> into the idea that we need to identify different input/output stages<br>
> of packet processing, and every feature/extension declares the point<br>
> where it needs to be. And then when we have all features, every<br>
> feature get's it's own table number, and the "next" action in<br>
> pipeline.<br>
<br>
</span>Can we create an API that allocates flow insertion points and table<br>
numbers?  How can we ensure correct ordering of flows?<br>
IMHO, it might be a time to collect low-level flow operation functions<br>
into a single repository and test interoperability there.<br>
<div class="HOEnZb"><div class="h5"><br>
>     b) We need to have a way to request openflow registers to use in<br>
> extensions, so one extension doesn't overwrite other's registers<br>
><br>
>    c) Those registers need to be given a logical names that other<br>
> extensions can query for (for example "port_number", "local_zone",<br>
> etc..) , and those standard registers should be filled in for all<br>
> extensions at the input stage.<br>
><br>
>    and probably c,d,e,f,g,h.... what I didn't manage to think of.<br>
><br>
> On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>> wrote:<br>
> > Hi Reedip,<br>
> ><br>
> ><br>
> ><br>
> > Sure will include you in the discussion. Let me know if there are other<br>
> > Tap-as-a-Service members who would like to join this initiative.<br>
> ><br>
> ><br>
> ><br>
> > Cathy<br>
> ><br>
> ><br>
> ><br>
> > From: reedip banerjee [mailto:<a href="mailto:reedip14@gmail.com">reedip14@gmail.com</a>]<br>
> > Sent: Thursday, April 14, 2016 7:03 PM<br>
> > To: OpenStack Development Mailing List (not for usage questions)<br>
> > Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and<br>
> > OVS Agent extension for Newton cycle<br>
> ><br>
> ><br>
> ><br>
> > Speaking on behalf of Tap-as-a-Service members, we would also be very much<br>
> > interested in the following initiative.... :)<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>><br>
> > wrote:<br>
> ><br>
> > Cathy Zhang <<a href="mailto:Cathy.H.Zhang@huawei.com">Cathy.H.Zhang@huawei.com</a>> wrote:<br>
> ><br>
> ><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<br>
> > agent extension mechanism. Even today, with SFC maintaining its own agent,<br>
> > there are no clear guarantees for flow priorities that would avoid all<br>
> > possible conflicts.<br>
> ><br>
> > Cathy> There is no requirement for SFC to switch. My understanding is that<br>
> > current L2 agent extension does not solve the conflicting entry issue if two<br>
> > features inject the same priority table entry. I think this new L2 agent<br>
> > effort is try to come up with a mechanism to resolve this issue. Of course<br>
> > if each feature( SFC or Qos) uses its own agent, then there is no<br>
> > coordination and no way to avoid conflicts.<br>
> ><br>
> ><br>
> > Sorry, I probably used misleading wording. I meant, why do we consider the<br>
> > semantic flow management support in l2 agent extension framework a<br>
> > *prerequisite* for SFC to switch to l2 agent extensions? The existing<br>
> > framework should already allow SFC to achieve what you have in the<br>
> > subproject tree implemented as a separate agent (essentially a fork of OVS<br>
> > agent). It will also set SFC to use standard extension mechanisms instead of<br>
> > hacky inheritance from OVS agent classes. So even without the strict<br>
> > 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<br>
> > 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<br>
> > framework to manage SFC flows.<br>
> ><br>
> > I would at least prioritize the first point and target it to Newton-1. Other<br>
> > bullet points may take significant time to bake.<br>
> ><br>
> > [1]<br>
> > <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><br>
> ><br>
> ><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>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > Thanks and Regards,<br>
> > Reedip Banerjee<br>
> ><br>
> > IRC: reedip<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><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>
> ><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>
<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></div>