Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Hi All, We have started a etherpad link [1] for collecting various use-cases about flow-classifier. Request all to provide their opinion on the same. We will be discussing the same over SFC IRC meeting [2]. Any contribution will be appreciated. [1] Etherpad Link https://etherpad.openstack.org/p/flow-classifier [2] SFC IRC Meeting http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Thanks Vikram From: Vikram Choudhary Sent: 05 June 2015 14:42 To: 'Miguel Angel Ajo' Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Thanks Miguel! From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: 05 June 2015 14:12 To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jpmailto:azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.commailto:arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org; 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 ☹. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Thanks for being on top of this. I made some comments on the etherpad. IMO probably, this is better as a simple extension of the api and it's datamodels. Since we won't need to extend core resources to connect them to flow classifiers, but in the other hand, we will connect other services to those classifiers. This (if I got it right) will be just a common model (fed through a common API) to be consumed by other services. Vikram Choudhary wrote: Hi All, We have started a etherpad link [1] for collecting various use-cases about flow-classifier. Request all to provide their opinion on the same. We will be discussing the same over SFC IRC meeting [2]. Any contribution will be appreciated. [1] Etherpad Link https://etherpad.openstack.org/p/flow-classifier [2] SFC IRC Meeting http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting Thanks Vikram From: Vikram Choudhary Sent: 05 June 2015 14:42 To: 'Miguel Angel Ajo' Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Thanks Miguel! From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: 05 June 2015 14:12 To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jpmailto:azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.commailto:arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org; 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 ☹. 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: 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
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Hi Yuji, This is very similar to the flow classifier which has been proposed in https://review.openstack.org/#/c/177946. Since quite some people have reviewed and given comments on https://review.openstack.org/#/c/177946 and the latest version has incorporated those comments, I would suggest that you incorporate your input to https://review.openstack.org/#/c/177946 and work with LouisF and Vikram on driving and developing a unified flow classifier API and model. Thanks, Cathy -Original Message- From: Yuji Azama [mailto:yuj-az...@rc.jp.nec.com] Sent: Wednesday, June 10, 2015 9:24 PM To: Cathy Zhang; Henry Fourie; mangel...@redhat.com; Vikram Choudhary Cc: arma...@gmail.com; Dongfeng (C); mest...@mestery.com; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Hello everyone, I want to join to IRC meeting. But I cannot join to the meeting because there is time difference. I tried to write my idea in spec of common classifier resource. ( https://review.openstack.org/#/c/190463 ) Thanks, Yuji -Original Message- From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] Sent: Saturday, June 06, 2015 3:36 AM To: Henry Fourie; Miguel Angel Ajo; Vikram Choudhary Cc: Azama Yuji(安座間 勇二); arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Sure. I will add this item to the next IRC meeting agenda. Thanks, Cathy From: Henry Fourie Sent: Friday, June 05, 2015 11:27 AM To: Miguel Angel Ajo; Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Miguel, I agree, we can probably use the service-chaining meeting to discuss this. We can have it as an agenda item for the next meeting: http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting - Louis From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; 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/ 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-fo r-service-chaining.rst https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-f or-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-extens ion.rst https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-exten sion.rst Thanks Vikram __ 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
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Thanks Miguel! From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: 05 June 2015 14:12 To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; 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 ☹. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
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 vikram.choudh...@huawei.com wrote: Thanks Miguel! *From:* Miguel Angel Ajo [mailto:mangel...@redhat.com] *Sent:* 05 June 2015 14:12 *To:* Vikram Choudhary *Cc:* azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; 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: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Hi Vikram, Definitely. We should have one unified and generic flow classifier/filter (whatever name we call it) that can be used by all cases. Thank you for driving this! Thanks, Cathy From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; 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 ☹. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals
Sure. I will add this item to the next IRC meeting agenda. Thanks, Cathy From: Henry Fourie Sent: Friday, June 05, 2015 11:27 AM To: Miguel Angel Ajo; Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject: RE: [neutron] Regarding Flow classifiers existing proposals Miguel, I agree, we can probably use the service-chaining meeting to discuss this. We can have it as an agenda item for the next meeting: http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting - Louis From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; 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 ☹. 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
