Hi Gal, It's really nice that you are also interested. Myself and Miguel was also talking about this over the summit ;) Let's take care of this together ;)
Thanks Vikram On Fri, Jun 5, 2015 at 3:45 PM, Gal Sagie <[email protected]> wrote: > Another use case is for security/firewall classifiers. > > I agree with this and i think me and Miguel talked about it in the summit, > but in order for this to go > forward someone need to start creating a spec and managing this effort. > > Since you proposed it first Vikram, will you do it? > If not i will gladly take this on myself. > > Gal. > > > On Fri, Jun 5, 2015 at 12:11 PM, Vikram Choudhary < > [email protected]> wrote: > >> Thanks Miguel! >> >> >> >> *From:* Miguel Angel Ajo [mailto:[email protected]] >> *Sent:* 05 June 2015 14:12 >> *To:* Vikram Choudhary >> *Cc:* [email protected]; Henry Fourie; Cathy Zhang; >> [email protected]; Dongfeng (C); Kyle Mestery; >> [email protected]; Dhruv Dhody; Kalyankumar Asangi >> *Subject:* [neutron] Regarding Flow classifiers existing proposals >> >> >> >> >> >> >> >> Added openstack-dev, where I believe this conversation must live. >> >> >> >> I totally agree on this, thank you for bringing up this conversation. >> This is not something we want to do for QoS this cycle, but probably next >> cycle. >> >> >> >> Anyway, an unified data model and API to create/update classifiers will >> not only be beneficial from the code duplication point of view, but will >> also provide a better user experience. >> >> >> >> I’m all for it. >> >> >> >> Best regards, >> >> Miguel Ángel Ajo >> >> >> >> On Friday 5 June 2015 at 09:57, Vikram Choudhary wrote: >> >> Dear All, >> >> >> >> There are multiple proposal floating around flow classifier rules for >> Liberty [1], [2] and [3]. >> >> I feel we all should work together and try to address all our use case >> having a unified framework rather than working separately achieving the >> same goal. >> >> >> >> Moreover, I can find the proposal for flow classifier as defined by the >> existing SFC [2] proposal is too generic and could address all the use >> cases by minor extension’s. >> >> >> >> In this regard, I would like all to come forward, exchange their >> thoughts, work together and make it happen good the first go rather doing >> the same effort separately and end up in duplicating code & effort L. >> >> I always feel less code will make our life happy in the long run ;) >> >> >> >> Please let me know about your views. >> >> >> >> [1] Add Neutron API extensions for packet forwarding >> >> https://review.openstack.org/#/c/186663/ >> >> >> >> [2] Neutron API for Service Chaining [Flow Filter resource] >> >> >> https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-for-service-chaining.rst >> >> >> >> [3] QoS API Extension [Defines classifier rule in QoSRule. Classifier >> rule can really grow big in the long run]: >> >> >> https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extension.rst >> >> >> >> Thanks >> >> Vikram >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Best Regards , > > The G. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
