Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose abrev. now ;)
On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three things to look at: (sorry for the TL) > > 1) The generalization of traffic filters / traffic classifiers. Having > common models, some sort of common API or common API structure > available, and translators to convert those filters to iptables, > openflow filters, etc.. > > 2) The enhancement of extensiblity of agents via Extension API. > > 3) How we chain features in OpenFlow, which current approach of just > inserting rules, renders into incompatible extensions. This becomes > specially relevant for the new openvswitch firewall. > > 2 and 3 are interlinked, and a good mechanism to enhance (3) should be > provided in (2). > > We need to resolve: > > a) The order of tables, and how openflow actions chain the > different features in the pipeline. Some naive thinking brings me > into the idea that we need to identify different input/output stages > of packet processing, and every feature/extension declares the point > where it needs to be. And then when we have all features, every > feature get's it's own table number, and the "next" action in > pipeline. > > b) We need to have a way to request openflow registers to use in > extensions, so one extension doesn't overwrite other's registers > > c) Those registers need to be given a logical names that other > extensions can query for (for example "port_number", "local_zone", > etc..) , and those standard registers should be filled in for all > extensions at the input stage. > > and probably c,d,e,f,g,h.... what I didn't manage to think of. > > On Fri, Apr 15, 2016 at 11:13 PM, Cathy Zhang <cathy.h.zh...@huawei.com> > wrote: >> Hi Reedip, >> >> >> >> Sure will include you in the discussion. Let me know if there are other >> Tap-as-a-Service members who would like to join this initiative. >> >> >> >> Cathy >> >> >> >> From: reedip banerjee [mailto:reedi...@gmail.com] >> Sent: Thursday, April 14, 2016 7:03 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and >> OVS Agent extension for Newton cycle >> >> >> >> 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 <ihrac...@redhat.com> >> wrote: >> >> Cathy Zhang <cathy.h.zh...@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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> >> -- >> >> Thanks and Regards, >> Reedip Banerjee >> >> IRC: reedip >> >> >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
