At Wed, 20 Apr 2016 14:12:07 +0200, Miguel Angel Ajo Pelayo 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.
Can we create an API that allocates flow insertion points and table numbers? How can we ensure correct ordering of flows? IMHO, it might be a time to collect low-level flow operation functions into a single repository and test interoperability there. > 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 __________________________________________________________________________ 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