On Thu, Apr 21, 2016 at 9:54 AM, Vikram Choudhary <viks...@gmail.com> wrote: > AFAIK, there is proposal about adding a 'priority' option in the existing > flow classifier rule. This can ensure the rule ordering. > >
It's more complicated than that, there you're only considering Flow Classifiers, while we need to make the full pipeline of features (externally pluggable) work together. > On Thu, Apr 21, 2016 at 12:58 PM, IWAMOTO Toshihiro <iwam...@valinux.co.jp> > wrote: >> >> 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? I believe that just an API to allocate flow insertion points and table numbers wouldn't work, because, you need to get the "next" hop in the table, and the next hop would not be still resolved when you ask for it (may be yes, if we return a mutable object). The idea, is than when all features are declared and inspected, we have the next hops, and table numbers for all features. Also another API for requesting openflow registers would be necessary, as extensions consume registers for different purposes. >> IMHO, it might be a time to collect low-level flow operation functions >> into a single repository and test interoperability there. >> That's may be something we must consider, I don't completely disagree, but if we can find a way to solve the issue dynamically, that would lead to quicker evolution, and easy interoperability with out-of-our-trees solutions, and cross version compatibility. >> > 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 > > > > __________________________________________________________________________ > 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
