Open Stack

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 <gal.sagie at gmail.com> 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 <
> vikram.choudhary at huawei.com> wrote:
>
>>  Thanks Miguel!
>>
>>
>>
>> *From:* Miguel Angel Ajo [mailto:mangelajo at redhat.com]
>> *Sent:* 05 June 2015 14:12
>> *To:* Vikram Choudhary
>> *Cc:* azama-yuji at mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang;
>> armamig at gmail.com; Dongfeng (C); Kyle Mestery;
>> openstack-dev at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150605/e809a3bd/attachment.html>