Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Haim,

Thanks for taking care of this. I see that Miguel has started working on the 
new L2 extension for Flow management。

https://bugs.launchpad.net/neutron/+bug/1563967
https://review.openstack.org/#/c/320439/

We may need to sync up the change with this new work too.

Thanks,
Cathy

From: Haim Daniel [mailto:hdan...@redhat.com]
Sent: Thursday, May 26, 2016 5:42 AM
To: Ihar Hrachyshka
Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Vikram Choudhary; Sean M. Collins; Mathieu Rohon; Shaughnessy, David; 
Eichberger, German; Henry Fourie; Armando M.
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per Ihar's 
suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto: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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Haim Daniel]

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per
Ihar's suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka 
wrote:

> Cathy Zhang  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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Vikram Choudhary]

+1 for the bi-weekly proposal @17:00 UTC Tuesday.

IMO, let's start with this and then we can check on the feasibility of
having the meeting on a weekly basis.
On May 23, 2016 1:10 PM, "Takashi Yamamoto"  wrote:

> On Wed, May 18, 2016 at 4:57 PM, Miguel Angel Ajo Pelayo
>  wrote:
> > Hey,
> >
> >Finally we took over the channel for 1h. mostly because the time was
> > already agreed between many people on opposed timezones and it was a bit
> > late to cancel it.
> >
> >The first point was finding a suitable timeslot for a biweekly meeting
> > -for some time- and alternatively following up on email. We should not
> take
> > over the neutron channel for these meetings anymore, I'm sorry for the
> > inconvenience.
>
> Tony pointed out that there are bi-weekly slot available.
> https://review.openstack.org/#/c/316830/
> i guess the slot is fine for many of us.
>
> >
> >   Please find the summary here:
> >
> >
> http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html
> >
> > On Tue, May 17, 2016 at 8:10 PM, Kevin Benton  wrote:
> >>
> >> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
> >> discuss development stuff during that hour.
> >>
> >> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo
> >>  wrote:
> >>>
> >>> I agree, let's try to find a timeslot that works.
> >>>
> >>> using #openstack-neutron with the meetbot works, but it's going to
> >>> generate a lot of noise.
> >>>
> >>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka  >
> >>> wrote:
> 
> 
>  > On 16 May 2016, at 15:47, Takashi Yamamoto 
>  > wrote:
>  >
>  > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
>  >  wrote:
>  >> hi,
>  >>
>  >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka
>  >>  wrote:
>  >>> +1 for earlier time. But also, have we booked any channel for the
>  >>> meeting? Hijacking #openstack-neutron may not work fine during
> such a busy
>  >>> (US) time. I suggest we propose a patch for
>  >>> https://github.com/openstack-infra/irc-meetings
>  >>
>  >> i agree and submitted a patch.
>  >> https://review.openstack.org/#/c/316830/
>  >
>  > oops, unfortunately there seems no meeting channel free at the time
>  > slot.
> 
>  This should be solved either by changing the slot, or by getting a new
>  channel registered for meetings. Using unregistered channels,
> especially
>  during busy hours, is not effective, and is prone to overlaps for
> relevant
>  meetings. The meetings will also not get a proper slot at
>  eavesdrop.openstack.org.
> 
>  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
> >>>
> >>>
> >>>
> >>>
> >>>
> __
> >>> 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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

On Wed, May 18, 2016 at 4:57 PM, Miguel Angel Ajo Pelayo
 wrote:
> Hey,
>
>Finally we took over the channel for 1h. mostly because the time was
> already agreed between many people on opposed timezones and it was a bit
> late to cancel it.
>
>The first point was finding a suitable timeslot for a biweekly meeting
> -for some time- and alternatively following up on email. We should not take
> over the neutron channel for these meetings anymore, I'm sorry for the
> inconvenience.

Tony pointed out that there are bi-weekly slot available.
https://review.openstack.org/#/c/316830/
i guess the slot is fine for many of us.

>
>   Please find the summary here:
>
> http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html
>
> On Tue, May 17, 2016 at 8:10 PM, Kevin Benton  wrote:
>>
>> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
>> discuss development stuff during that hour.
>>
>> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo
>>  wrote:
>>>
>>> I agree, let's try to find a timeslot that works.
>>>
>>> using #openstack-neutron with the meetbot works, but it's going to
>>> generate a lot of noise.
>>>
>>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka 
>>> wrote:


 > On 16 May 2016, at 15:47, Takashi Yamamoto 
 > wrote:
 >
 > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
 >  wrote:
 >> hi,
 >>
 >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka
 >>  wrote:
 >>> +1 for earlier time. But also, have we booked any channel for the
 >>> meeting? Hijacking #openstack-neutron may not work fine during such a 
 >>> busy
 >>> (US) time. I suggest we propose a patch for
 >>> https://github.com/openstack-infra/irc-meetings
 >>
 >> i agree and submitted a patch.
 >> https://review.openstack.org/#/c/316830/
 >
 > oops, unfortunately there seems no meeting channel free at the time
 > slot.

 This should be solved either by changing the slot, or by getting a new
 channel registered for meetings. Using unregistered channels, especially
 during busy hours, is not effective, and is prone to overlaps for relevant
 meetings. The meetings will also not get a proper slot at
 eavesdrop.openstack.org.

 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
>>>
>>>
>>>
>>>
>>> __
>>> 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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Kevin Benton]

No worries. If the slot isn't available maybe we can get infra to add
another channel.

On Wed, May 18, 2016 at 12:57 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Hey,
>
>Finally we took over the channel for 1h. mostly because the time was
> already agreed between many people on opposed timezones and it was a bit
> late to cancel it.
>
>The first point was finding a suitable timeslot for a biweekly meeting
> -for some time- and alternatively following up on email. We should not take
> over the neutron channel for these meetings anymore, I'm sorry for the
> inconvenience.
>
>   Please find the summary here:
>
>
> http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html
>
> On Tue, May 17, 2016 at 8:10 PM, Kevin Benton  wrote:
>
>> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
>> discuss development stuff during that hour.
>>
>> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo <
>> majop...@redhat.com> wrote:
>>
>>> I agree, let's try to find a timeslot that works.
>>>
>>> using #openstack-neutron with the meetbot works, but it's going to
>>> generate a lot of noise.
>>>
>>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka 
>>> wrote:
>>>

 > On 16 May 2016, at 15:47, Takashi Yamamoto 
 wrote:
 >
 > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
 >  wrote:
 >> hi,
 >>
 >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <
 ihrac...@redhat.com> wrote:
 >>> +1 for earlier time. But also, have we booked any channel for the
 meeting? Hijacking #openstack-neutron may not work fine during such a busy
 (US) time. I suggest we propose a patch for
 https://github.com/openstack-infra/irc-meetings
 >>
 >> i agree and submitted a patch.
 >> https://review.openstack.org/#/c/316830/
 >
 > oops, unfortunately there seems no meeting channel free at the time
 slot.

 This should be solved either by changing the slot, or by getting a new
 channel registered for meetings. Using unregistered channels, especially
 during busy hours, is not effective, and is prone to overlaps for relevant
 meetings. The meetings will also not get a proper slot at
 eavesdrop.openstack.org.

 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

>>>
>>>
>>>
>>> __
>>> 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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

Hey,

   Finally we took over the channel for 1h. mostly because the time was
already agreed between many people on opposed timezones and it was a bit
late to cancel it.

   The first point was finding a suitable timeslot for a biweekly meeting
-for some time- and alternatively following up on email. We should not take
over the neutron channel for these meetings anymore, I'm sorry for the
inconvenience.

  Please find the summary here:

http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html

On Tue, May 17, 2016 at 8:10 PM, Kevin Benton  wrote:

> Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
> discuss development stuff during that hour.
>
> On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo <
> majop...@redhat.com> wrote:
>
>> I agree, let's try to find a timeslot that works.
>>
>> using #openstack-neutron with the meetbot works, but it's going to
>> generate a lot of noise.
>>
>> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka 
>> wrote:
>>
>>>
>>> > On 16 May 2016, at 15:47, Takashi Yamamoto 
>>> wrote:
>>> >
>>> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
>>> >  wrote:
>>> >> hi,
>>> >>
>>> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 
>>> wrote:
>>> >>> +1 for earlier time. But also, have we booked any channel for the
>>> meeting? Hijacking #openstack-neutron may not work fine during such a busy
>>> (US) time. I suggest we propose a patch for
>>> https://github.com/openstack-infra/irc-meetings
>>> >>
>>> >> i agree and submitted a patch.
>>> >> https://review.openstack.org/#/c/316830/
>>> >
>>> > oops, unfortunately there seems no meeting channel free at the time
>>> slot.
>>>
>>> This should be solved either by changing the slot, or by getting a new
>>> channel registered for meetings. Using unregistered channels, especially
>>> during busy hours, is not effective, and is prone to overlaps for relevant
>>> meetings. The meetings will also not get a proper slot at
>>> eavesdrop.openstack.org.
>>>
>>> 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
>>>
>>
>>
>> __
>> 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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Kevin Benton]

Yeah, no meetings in #openstack-neutron please. It leaves us nowhere to
discuss development stuff during that hour.

On Tue, May 17, 2016 at 2:54 AM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> I agree, let's try to find a timeslot that works.
>
> using #openstack-neutron with the meetbot works, but it's going to
> generate a lot of noise.
>
> On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka 
> wrote:
>
>>
>> > On 16 May 2016, at 15:47, Takashi Yamamoto 
>> wrote:
>> >
>> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
>> >  wrote:
>> >> hi,
>> >>
>> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 
>> wrote:
>> >>> +1 for earlier time. But also, have we booked any channel for the
>> meeting? Hijacking #openstack-neutron may not work fine during such a busy
>> (US) time. I suggest we propose a patch for
>> https://github.com/openstack-infra/irc-meetings
>> >>
>> >> i agree and submitted a patch.
>> >> https://review.openstack.org/#/c/316830/
>> >
>> > oops, unfortunately there seems no meeting channel free at the time
>> slot.
>>
>> This should be solved either by changing the slot, or by getting a new
>> channel registered for meetings. Using unregistered channels, especially
>> during busy hours, is not effective, and is prone to overlaps for relevant
>> meetings. The meetings will also not get a proper slot at
>> eavesdrop.openstack.org.
>>
>> 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
>>
>
>
> __
> 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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

I agree, let's try to find a timeslot that works.

using #openstack-neutron with the meetbot works, but it's going to generate
a lot of noise.

On Tue, May 17, 2016 at 11:47 AM, Ihar Hrachyshka 
wrote:

>
> > On 16 May 2016, at 15:47, Takashi Yamamoto 
> wrote:
> >
> > On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
> >  wrote:
> >> hi,
> >>
> >> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka 
> wrote:
> >>> +1 for earlier time. But also, have we booked any channel for the
> meeting? Hijacking #openstack-neutron may not work fine during such a busy
> (US) time. I suggest we propose a patch for
> https://github.com/openstack-infra/irc-meetings
> >>
> >> i agree and submitted a patch.
> >> https://review.openstack.org/#/c/316830/
> >
> > oops, unfortunately there seems no meeting channel free at the time slot.
>
> This should be solved either by changing the slot, or by getting a new
> channel registered for meetings. Using unregistered channels, especially
> during busy hours, is not effective, and is prone to overlaps for relevant
> meetings. The meetings will also not get a proper slot at
> eavesdrop.openstack.org.
>
> 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
>
__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Ihar Hrachyshka]

> On 16 May 2016, at 15:47, Takashi Yamamoto  wrote:
> 
> On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
>  wrote:
>> hi,
>> 
>> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka  wrote:
>>> +1 for earlier time. But also, have we booked any channel for the meeting? 
>>> Hijacking #openstack-neutron may not work fine during such a busy (US) 
>>> time. I suggest we propose a patch for 
>>> https://github.com/openstack-infra/irc-meetings
>> 
>> i agree and submitted a patch.
>> https://review.openstack.org/#/c/316830/
> 
> oops, unfortunately there seems no meeting channel free at the time slot.

This should be solved either by changing the slot, or by getting a new channel 
registered for meetings. Using unregistered channels, especially during busy 
hours, is not effective, and is prone to overlaps for relevant meetings. The 
meetings will also not get a proper slot at eavesdrop.openstack.org.

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

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension

[Cathy Zhang]

Hi everyone,

We will have the first meeting discussion on Common Flow classifier at 1700 UTC 
on openstack-neutron channel 5/17/2016. 
Based on our etherpad action item in the Austin Summit meeting, Louis and I 
have created a wiki page for this work, describing the work overview and API 
design guideline we have discussed in the summit. I have also uploaded a table 
comparing the FC rules used in security group and networking-sfc. 

https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier

Let's discuss them in tomorrow's meeting. 

Thanks,
Cathy 
__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

On Mon, May 16, 2016 at 10:25 PM, Takashi Yamamoto
<yamam...@midokura.com> wrote:
> hi,
>
> On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>> +1 for earlier time. But also, have we booked any channel for the meeting? 
>> Hijacking #openstack-neutron may not work fine during such a busy (US) time. 
>> I suggest we propose a patch for 
>> https://github.com/openstack-infra/irc-meetings
>
> i agree and submitted a patch.
> https://review.openstack.org/#/c/316830/

oops, unfortunately there seems no meeting channel free at the time slot.

>
>>
>> Ihar
>>
>>> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>>>
>>> It is always hard to find a day and time that is good for everyone around 
>>> the globe:-)
>>> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron 
>>> channel.
>>> In the meeting, we can see if we can reach consensus on a new meeting time.
>>>
>>> Cathy
>>>
>>> -Original Message-
>>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>>> Sent: Tuesday, May 10, 2016 12:40 AM
>>> 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
>>>
>>> On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
>>>> Hi Cathy,
>>>>
>>>> Cathy Zhang:
>>>>>
>>>>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>>>>> Hope this time is good for all people who have interest and like to
>>>>> contribute to this work. We plan to start the first meeting on May 17.
>>>>
>>>>
>>>> I would be happy to participate, but I'm unlikely to be able to attend
>>>> at that time.
>>>> Might 15:00 UTC work for others ?
>>>
>>> +1 for earlier
>>>
>>>> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>>>>
>>>> -Thomas
>>>>
>>>>
>>>>
>>>>
>>>>> -Original Message-
>>>>> From: Cathy Zhang
>>>>> Sent: Thursday, April 21, 2016 11:43 AM
>>>>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage
>>>>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim
>>>>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry
>>>>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>>>>> Cc: Cathy Zhang
>>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>>> and OVS Agent extension for Newton cycle
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We have room 400 at 3:10pm on Thursday available for discussion of
>>>>> the two topics.
>>>>> Another option is to use the common room with roundtables in "Salon C"
>>>>> during Monday or Wednesday lunch time.
>>>>>
>>>>> Room 400 at 3:10pm is a closed room while the Salon C is a big open
>>>>> room which can host 500 people.
>>>>>
>>>>> I am Ok with either option. Let me know if anyone has a strong preference.
>>>>>
>>>>> Thanks,
>>>>> Cathy
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: Cathy Zhang
>>>>> Sent: Thursday, April 14, 2016 1:23 PM
>>>>> To: OpenStack Development Mailing List (not for usage questions);
>>>>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim
>>>>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German';
>>>>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>>> and OVS Agent extension for Newton cycle
>>>>>
>>>>> Thanks for everyone's reply!
>>>>>
>>>>> Here is the summary based on the replies I received:
>>>>>
>>>>> 1.  We should have a meet-up for these two topics. The "to" list are
>>>>> the people who have interest in these topics.
>>>>> I am thinking about around lunch time on Tuesday or Wednesday
>>>>> since some of us will fl

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

hi,

On Mon, May 16, 2016 at 9:00 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> +1 for earlier time. But also, have we booked any channel for the meeting? 
> Hijacking #openstack-neutron may not work fine during such a busy (US) time. 
> I suggest we propose a patch for 
> https://github.com/openstack-infra/irc-meetings

i agree and submitted a patch.
https://review.openstack.org/#/c/316830/

>
> Ihar
>
>> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>>
>> It is always hard to find a day and time that is good for everyone around 
>> the globe:-)
>> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron 
>> channel.
>> In the meeting, we can see if we can reach consensus on a new meeting time.
>>
>> Cathy
>>
>> -Original Message-
>> From: Takashi Yamamoto [mailto:yamam...@midokura.com]
>> Sent: Tuesday, May 10, 2016 12:40 AM
>> 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
>>
>> On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
>>> Hi Cathy,
>>>
>>> Cathy Zhang:
>>>>
>>>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>>>> Hope this time is good for all people who have interest and like to
>>>> contribute to this work. We plan to start the first meeting on May 17.
>>>
>>>
>>> I would be happy to participate, but I'm unlikely to be able to attend
>>> at that time.
>>> Might 15:00 UTC work for others ?
>>
>> +1 for earlier
>>
>>> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>>>
>>> -Thomas
>>>
>>>
>>>
>>>
>>>> -Original Message-
>>>> From: Cathy Zhang
>>>> Sent: Thursday, April 21, 2016 11:43 AM
>>>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage
>>>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim
>>>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry
>>>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>>>> Cc: Cathy Zhang
>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>> and OVS Agent extension for Newton cycle
>>>>
>>>> Hi everyone,
>>>>
>>>> We have room 400 at 3:10pm on Thursday available for discussion of
>>>> the two topics.
>>>> Another option is to use the common room with roundtables in "Salon C"
>>>> during Monday or Wednesday lunch time.
>>>>
>>>> Room 400 at 3:10pm is a closed room while the Salon C is a big open
>>>> room which can host 500 people.
>>>>
>>>> I am Ok with either option. Let me know if anyone has a strong preference.
>>>>
>>>> Thanks,
>>>> Cathy
>>>>
>>>>
>>>> -Original Message-
>>>> From: Cathy Zhang
>>>> Sent: Thursday, April 14, 2016 1:23 PM
>>>> To: OpenStack Development Mailing List (not for usage questions);
>>>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim
>>>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German';
>>>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier
>>>> and OVS Agent extension for Newton cycle
>>>>
>>>> Thanks for everyone's reply!
>>>>
>>>> Here is the summary based on the replies I received:
>>>>
>>>> 1.  We should have a meet-up for these two topics. The "to" list are
>>>> the people who have interest in these topics.
>>>> I am thinking about around lunch time on Tuesday or Wednesday
>>>> since some of us will fly back on Friday morning/noon.
>>>> If this time is OK with everyone, I will find a place and let
>>>> you know where and what time to meet.
>>>>
>>>> 2.  There is a bug opened for the QoS Flow Classifier
>>>> https://bugs.launchpad.net/neutron/+bug/1527671
>>>> We can either change the bug title and modify the bug details or
>>>> start with a new one for the common FC which provides info on all
>>>> requirements needed by all relevant use cases. There is a bug opened

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Ihar Hrachyshka]

+1 for earlier time. But also, have we booked any channel for the meeting? 
Hijacking #openstack-neutron may not work fine during such a busy (US) time. I 
suggest we propose a patch for https://github.com/openstack-infra/irc-meetings

Ihar

> On 10 May 2016, at 20:35, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> 
> It is always hard to find a day and time that is good for everyone around the 
> globe:-)
> The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron 
> channel. 
> In the meeting, we can see if we can reach consensus on a new meeting time. 
> 
> Cathy
> 
> -Original Message-
> From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
> Sent: Tuesday, May 10, 2016 12:40 AM
> 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
> 
> On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
>> Hi Cathy,
>> 
>> Cathy Zhang:
>>> 
>>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>>> Hope this time is good for all people who have interest and like to 
>>> contribute to this work. We plan to start the first meeting on May 17.
>> 
>> 
>> I would be happy to participate, but I'm unlikely to be able to attend 
>> at that time.
>> Might 15:00 UTC work for others ?
> 
> +1 for earlier
> 
>> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>> 
>> -Thomas
>> 
>> 
>> 
>> 
>>> -Original Message-
>>> From: Cathy Zhang
>>> Sent: Thursday, April 21, 2016 11:43 AM
>>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
>>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim 
>>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry 
>>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>>> Cc: Cathy Zhang
>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>>> and OVS Agent extension for Newton cycle
>>> 
>>> Hi everyone,
>>> 
>>> We have room 400 at 3:10pm on Thursday available for discussion of 
>>> the two topics.
>>> Another option is to use the common room with roundtables in "Salon C"
>>> during Monday or Wednesday lunch time.
>>> 
>>> Room 400 at 3:10pm is a closed room while the Salon C is a big open 
>>> room which can host 500 people.
>>> 
>>> I am Ok with either option. Let me know if anyone has a strong preference.
>>> 
>>> Thanks,
>>> Cathy
>>> 
>>> 
>>> -Original Message-
>>> From: Cathy Zhang
>>> Sent: Thursday, April 14, 2016 1:23 PM
>>> To: OpenStack Development Mailing List (not for usage questions); 
>>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim 
>>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; 
>>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>>> and OVS Agent extension for Newton cycle
>>> 
>>> Thanks for everyone's reply!
>>> 
>>> Here is the summary based on the replies I received:
>>> 
>>> 1.  We should have a meet-up for these two topics. The "to" list are 
>>> the people who have interest in these topics.
>>> I am thinking about around lunch time on Tuesday or Wednesday 
>>> since some of us will fly back on Friday morning/noon.
>>> If this time is OK with everyone, I will find a place and let 
>>> you know where and what time to meet.
>>> 
>>> 2.  There is a bug opened for the QoS Flow Classifier
>>> https://bugs.launchpad.net/neutron/+bug/1527671
>>> We can either change the bug title and modify the bug details or 
>>> start with a new one for the common FC which provides info on all 
>>> requirements needed by all relevant use cases. There is a bug opened 
>>> for OVS agent extension 
>>> https://bugs.launchpad.net/neutron/+bug/1517903
>>> 
>>> 3.  There are some very rough, ugly as Sean put it:-), and 
>>> preliminary work on common FC 
>>> https://github.com/openstack/neutron-classifier which we can see how 
>>> to leverage. There is also a SFC API spec which covers the FC API for 
>>> SFC usage 
>>> https://github.com/openstack/networking-sfc/blob/master/doc/source/ap
>>>

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

It is always hard to find a day and time that is good for everyone around the 
globe:-)
The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron channel. 
In the meeting, we can see if we can reach consensus on a new meeting time. 

Cathy

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
Sent: Tuesday, May 10, 2016 12:40 AM
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

On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
> Hi Cathy,
>
> Cathy Zhang:
>>
>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>> Hope this time is good for all people who have interest and like to 
>> contribute to this work. We plan to start the first meeting on May 17.
>
>
> I would be happy to participate, but I'm unlikely to be able to attend 
> at that time.
> Might 15:00 UTC work for others ?

+1 for earlier

> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>
> -Thomas
>
>
>
>
>> -Original Message-
>> From: Cathy Zhang
>> Sent: Thursday, April 21, 2016 11:43 AM
>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim 
>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry 
>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>> Cc: Cathy Zhang
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>> and OVS Agent extension for Newton cycle
>>
>> Hi everyone,
>>
>> We have room 400 at 3:10pm on Thursday available for discussion of 
>> the two topics.
>> Another option is to use the common room with roundtables in "Salon C"
>> during Monday or Wednesday lunch time.
>>
>> Room 400 at 3:10pm is a closed room while the Salon C is a big open 
>> room which can host 500 people.
>>
>> I am Ok with either option. Let me know if anyone has a strong preference.
>>
>> Thanks,
>> Cathy
>>
>>
>> -Original Message-
>> From: Cathy Zhang
>> Sent: Thursday, April 14, 2016 1:23 PM
>> To: OpenStack Development Mailing List (not for usage questions); 
>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim 
>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; 
>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>> and OVS Agent extension for Newton cycle
>>
>> Thanks for everyone's reply!
>>
>> Here is the summary based on the replies I received:
>>
>> 1.  We should have a meet-up for these two topics. The "to" list are 
>> the people who have interest in these topics.
>>  I am thinking about around lunch time on Tuesday or Wednesday 
>> since some of us will fly back on Friday morning/noon.
>>  If this time is OK with everyone, I will find a place and let 
>> you know where and what time to meet.
>>
>> 2.  There is a bug opened for the QoS Flow Classifier
>> https://bugs.launchpad.net/neutron/+bug/1527671
>> We can either change the bug title and modify the bug details or 
>> start with a new one for the common FC which provides info on all 
>> requirements needed by all relevant use cases. There is a bug opened 
>> for OVS agent extension 
>> https://bugs.launchpad.net/neutron/+bug/1517903
>>
>> 3.  There are some very rough, ugly as Sean put it:-), and 
>> preliminary work on common FC 
>> https://github.com/openstack/neutron-classifier which we can see how 
>> to leverage. There is also a SFC API spec which covers the FC API for 
>> SFC usage 
>> https://github.com/openstack/networking-sfc/blob/master/doc/source/ap
>> i.rst, the following is the CLI version of the Flow Classifier for 
>> your
>> reference:
>>
>> neutron flow-classifier-create [-h]
>>  [--description ]
>>  [--protocol ]
>>  [--ethertype ]
>>  [--source-port :> source protocol port>]
>>  [--destination-port > port>:]
>>  [--source-ip-prefix ]
>>  [--destination-ip-prefix ]
>>  [--logical-source-port ]
>>  [--logical-destination-port ]
>>  [--l7-parameters ] FLOW-CLASSIFIER-NAME
>>
>> The corresponding code is here
>> https://github.com/openstack/networking-sfc/tree/master/networking_sf
>> c/extensions
>>
>> 

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Takashi Yamamoto]

On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
> Hi Cathy,
>
> Cathy Zhang:
>>
>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>> Hope this time is good for all people who have interest and like to
>> contribute to this work. We plan to start the first meeting on May 17.
>
>
> I would be happy to participate, but I'm unlikely to be able to attend at
> that time.
> Might 15:00 UTC work for others ?

+1 for earlier

> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>
> -Thomas
>
>
>
>
>> -Original Message-
>> From: Cathy Zhang
>> Sent: Thursday, April 21, 2016 11:43 AM
>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage
>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel;
>> Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry Fourie;
>> arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>> Cc: Cathy Zhang
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and
>> OVS Agent extension for Newton cycle
>>
>> Hi everyone,
>>
>> We have room 400 at 3:10pm on Thursday available for discussion of the two
>> topics.
>> Another option is to use the common room with roundtables in "Salon C"
>> during Monday or Wednesday lunch time.
>>
>> Room 400 at 3:10pm is a closed room while the Salon C is a big open room
>> which can host 500 people.
>>
>> I am Ok with either option. Let me know if anyone has a strong preference.
>>
>> Thanks,
>> Cathy
>>
>>
>> -Original Message-
>> From: Cathy Zhang
>> Sent: Thursday, April 14, 2016 1:23 PM
>> To: OpenStack Development Mailing List (not for usage questions); 'Ihar
>> Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu
>> Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry
>> Fourie; 'arma...@gmail.com'
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and
>> OVS Agent extension for Newton cycle
>>
>> Thanks for everyone's reply!
>>
>> Here is the summary based on the replies I received:
>>
>> 1.  We should have a meet-up for these two topics. The "to" list are the
>> people who have interest in these topics.
>>  I am thinking about around lunch time on Tuesday or Wednesday since
>> some of us will fly back on Friday morning/noon.
>>  If this time is OK with everyone, I will find a place and let you
>> know where and what time to meet.
>>
>> 2.  There is a bug opened for the QoS Flow Classifier
>> https://bugs.launchpad.net/neutron/+bug/1527671
>> We can either change the bug title and modify the bug details or start
>> with a new one for the common FC which provides info on all requirements
>> needed by all relevant use cases. There is a bug opened for OVS agent
>> extension https://bugs.launchpad.net/neutron/+bug/1517903
>>
>> 3.  There are some very rough, ugly as Sean put it:-), and preliminary
>> work on common FC https://github.com/openstack/neutron-classifier which we
>> can see how to leverage. There is also a SFC API spec which covers the FC
>> API for SFC usage
>> https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
>> the following is the CLI version of the Flow Classifier for your
>> reference:
>>
>> neutron flow-classifier-create [-h]
>>  [--description ]
>>  [--protocol ]
>>  [--ethertype ]
>>  [--source-port :> protocol port>]
>>  [--destination-port :> destination protocol port>]
>>  [--source-ip-prefix ]
>>  [--destination-ip-prefix ]
>>  [--logical-source-port ]
>>  [--logical-destination-port ]
>>  [--l7-parameters ] FLOW-CLASSIFIER-NAME
>>
>> The corresponding code is here
>> https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions
>>
>> 4.  We should come up with a formal Neutron spec for FC and another one
>> for OVS Agent extension and get everyone's review and approval. Here is the
>> etherpad catching our previous requirement discussion on OVS agent (Thanks
>> David for the link! I remember we had this discussion before)
>> https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>>
>>
>> More inline.
>>
>> Thanks,
>> Cathy
>>
>>
>> -Original Message-
>> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
>> S

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[thomas.morin]

Hi Cathy,

Cathy Zhang:

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17.


I would be happy to participate, but I'm unlikely to be able to attend 
at that time.

Might 15:00 UTC work for others ?
If not, well, I'll make do with log/emails/pads/gerrit interactions.

-Thomas




-Original Message-
From: Cathy Zhang
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics.
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference.

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply!

Here is the summary based on the replies I received:

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics.
 I am thinking about around lunch time on Tuesday or Wednesday since some 
of us will fly back on Friday morning/noon.
 If this time is OK with everyone, I will find a place and let you know 
where and what time to meet.

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
 [--description ]
 [--protocol ]
 [--ethertype ]
 [--source-port :]
 [--destination-port :]
 [--source-ip-prefix ]
 [--destination-ip-prefix ]
 [--logical-source-port ]
 [--logical-destination-port ]
 [--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline.

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
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

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:


Hi everyone,
Per Armando’s request, Louis and I are looking into the following
features for Newton cycle.
· Neutron Common FC used for SFC, QoS, Tap as a service etc.,
· OVS Agent extension
Some of you might know that we already developed a FC in
networking-sfc project and QoS also has a FC. It makes sense that we
have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
service etc.
features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.


Different features may extend OVS agent and add different new OVS flow
t

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Thank you!

Cathy

-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] 
Sent: Friday, May 06, 2016 12:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Sounds good,

   I started by opening a tiny RFE, that may help in the organization of flows 
inside OVS agent, for inter operability of features (SFC, TaaS, ovs fw, and 
even port trunking with just openflow). [1] [2]


[1] https://bugs.launchpad.net/neutron/+bug/1577791
[2] http://paste.openstack.org/show/495967/


On Fri, May 6, 2016 at 12:35 AM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi everyone,
>
> We had a discussion on the two topics during the summit. Here is the etherpad 
> link for the discussion.
> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
>
> We agreed to continue the discussion on Neutron channel on a weekly basis. It 
> seems UTC 1700 ~ UTC 1800 Tuesday is good for most people.
> Another option is UTC 1700 ~ UTC 1800 Friday.
>
> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
> this time is good for all people who have interest and like to contribute to 
> this work. We plan to start the first meeting on May 17.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 21, 2016 11:43 AM
> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim 
> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry 
> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
> Cc: Cathy Zhang
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
> and OVS Agent extension for Newton cycle
>
> Hi everyone,
>
> We have room 400 at 3:10pm on Thursday available for discussion of the two 
> topics.
> Another option is to use the common room with roundtables in "Salon C" during 
> Monday or Wednesday lunch time.
>
> Room 400 at 3:10pm is a closed room while the Salon C is a big open room 
> which can host 500 people.
>
> I am Ok with either option. Let me know if anyone has a strong preference.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 14, 2016 1:23 PM
> To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
> Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
> Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry 
> Fourie; 'arma...@gmail.com'
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
> and OVS Agent extension for Newton cycle
>
> Thanks for everyone's reply!
>
> Here is the summary based on the replies I received:
>
> 1.  We should have a meet-up for these two topics. The "to" list are the 
> people who have interest in these topics.
> I am thinking about around lunch time on Tuesday or Wednesday since some 
> of us will fly back on Friday morning/noon.
> If this time is OK with everyone, I will find a place and let you know 
> where and what time to meet.
>
> 2.  There is a bug opened for the QoS Flow Classifier 
> https://bugs.launchpad.net/neutron/+bug/1527671
> We can either change the bug title and modify the bug details or start 
> with a new one for the common FC which provides info on all 
> requirements needed by all relevant use cases. There is a bug opened 
> for OVS agent extension 
> https://bugs.launchpad.net/neutron/+bug/1517903
>
> 3.  There are some very rough, ugly as Sean put it:-), and preliminary 
> work on common FC https://github.com/openstack/neutron-classifier 
> which we can see how to leverage. There is also a SFC API spec which 
> covers the FC API for SFC usage 
> https://github.com/openstack/networking-sfc/blob/master/doc/source/api
> .rst, the following is the CLI version of the Flow Classifier for your 
> reference:
>
> neutron flow-classifier-create [-h]
> [--description ]
> [--protocol ]
> [--ethertype ]
> [--source-port : protocol port>]
> [--destination-port : destination protocol port>]
> [--source-ip-prefix ]
> [--destination-ip-prefix ]
> [--logical-source-port ]
> [--logical-destination-port ]
> [--l7-parameters ] FLOW-CLASSIFIER-NAME
>
> The corresponding code is here 
> https://github.com/openstack/networking-sfc/tree/master/networking_sfc
> /extensions
>
> 4.  We should come up with a formal Neutron spec for FC and another 
> one for OVS Agent extension an

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

Sounds good,

   I started by opening a tiny RFE, that may help in the organization
of flows inside OVS agent, for inter operability of features (SFC,
TaaS, ovs fw, and even port trunking with just openflow). [1] [2]


[1] https://bugs.launchpad.net/neutron/+bug/1577791
[2] http://paste.openstack.org/show/495967/


On Fri, May 6, 2016 at 12:35 AM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi everyone,
>
> We had a discussion on the two topics during the summit. Here is the etherpad 
> link for the discussion.
> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
>
> We agreed to continue the discussion on Neutron channel on a weekly basis. It 
> seems UTC 1700 ~ UTC 1800 Tuesday is good for most people.
> Another option is UTC 1700 ~ UTC 1800 Friday.
>
> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
> this time is good for all people who have interest and like to contribute to 
> this work. We plan to start the first meeting on May 17.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 21, 2016 11:43 AM
> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; 
> Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry Fourie; 
> arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
> Cc: Cathy Zhang
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
> Agent extension for Newton cycle
>
> Hi everyone,
>
> We have room 400 at 3:10pm on Thursday available for discussion of the two 
> topics.
> Another option is to use the common room with roundtables in "Salon C" during 
> Monday or Wednesday lunch time.
>
> Room 400 at 3:10pm is a closed room while the Salon C is a big open room 
> which can host 500 people.
>
> I am Ok with either option. Let me know if anyone has a strong preference.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 14, 2016 1:23 PM
> To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
> Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
> Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry 
> Fourie; 'arma...@gmail.com'
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
> Agent extension for Newton cycle
>
> Thanks for everyone's reply!
>
> Here is the summary based on the replies I received:
>
> 1.  We should have a meet-up for these two topics. The "to" list are the 
> people who have interest in these topics.
> I am thinking about around lunch time on Tuesday or Wednesday since some 
> of us will fly back on Friday morning/noon.
> If this time is OK with everyone, I will find a place and let you know 
> where and what time to meet.
>
> 2.  There is a bug opened for the QoS Flow Classifier 
> https://bugs.launchpad.net/neutron/+bug/1527671
> We can either change the bug title and modify the bug details or start with a 
> new one for the common FC which provides info on all requirements needed by 
> all relevant use cases. There is a bug opened for OVS agent extension 
> https://bugs.launchpad.net/neutron/+bug/1517903
>
> 3.  There are some very rough, ugly as Sean put it:-), and preliminary work 
> on common FC https://github.com/openstack/neutron-classifier which we can see 
> how to leverage. There is also a SFC API spec which covers the FC API for SFC 
> usage 
> https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
> the following is the CLI version of the Flow Classifier for your reference:
>
> neutron flow-classifier-create [-h]
> [--description ]
> [--protocol ]
> [--ethertype ]
> [--source-port : protocol port>]
> [--destination-port : destination protocol port>]
> [--source-ip-prefix ]
> [--destination-ip-prefix ]
> [--logical-source-port ]
> [--logical-destination-port ]
> [--l7-parameters ] FLOW-CLASSIFIER-NAME
>
> The corresponding code is here 
> https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions
>
> 4.  We should come up with a formal Neutron spec for FC and another one for 
> OVS Agent extension and get everyone's review and approval. Here is the 
> etherpad catching our previous requirement discussion on OVS agent (Thanks 
> David for the link! I remember we had this discussion before) 
> https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>
>
> More inline.
>
> Thanks,
> Cathy
>
>
> -Origin

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,

We had a discussion on the two topics during the summit. Here is the etherpad 
link for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

We agreed to continue the discussion on Neutron channel on a weekly basis. It 
seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. 
Another option is UTC 1700 ~ UTC 1800 Friday. 

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang 
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
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

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to t

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Miguel,

No worry. Today is just a meeting for lunch to get to know each other although 
we touched some technical points.
We will recap and do the technical discussion at Room 400 at 3:10pm Thursday.

Cathy

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Wednesday, April 27, 2016 10:50 AM
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


Trying to find you folks. I was late
El 27/4/2016 12:04, "Paul Carver" 
<pcar...@paulcarver.us<mailto:pcar...@paulcarver.us>> escribió:
SFC team and anybody else dealing with flow selection/classification (e.g. QoS),

I just wanted to confirm that we're planning to meet in salon C today 
(Wednesday) to get lunch but then possibly move to a quieter location to 
discuss the common flow classifier ideas.

On 4/21/2016 19:42, Cathy Zhang wrote:
I like Malini’s suggestion on meeting for a lunch to get to know each
other, then continue on Thursday.

So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
and then continue the discussion at Room 400 at 3:10pm Thursday.

Since Salon C is a big room, I will put a sign “Common Flow Classifier
and OVS Agent Extension” on the table.

I have created an etherpad for the discussion.
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

Please add me to whatsapp or telegram if you use that : +34636522569
El 27/4/2016 12:50, majop...@redhat.com escribió:

> Trying to find you folks. I was late
> El 27/4/2016 12:04, "Paul Carver"  escribió:
>
>> SFC team and anybody else dealing with flow selection/classification
>> (e.g. QoS),
>>
>> I just wanted to confirm that we're planning to meet in salon C today
>> (Wednesday) to get lunch but then possibly move to a quieter location to
>> discuss the common flow classifier ideas.
>>
>> On 4/21/2016 19:42, Cathy Zhang wrote:
>>
>>> I like Malini’s suggestion on meeting for a lunch to get to know each
>>> other, then continue on Thursday.
>>>
>>> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
>>> and then continue the discussion at Room 400 at 3:10pm Thursday.
>>>
>>> Since Salon C is a big room, I will put a sign “Common Flow Classifier
>>> and OVS Agent Extension” on the table.
>>>
>>> I have created an etherpad for the discussion.
>>> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
>>>
>>>
>>
>> __
>> 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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

Trying to find you folks. I was late
El 27/4/2016 12:04, "Paul Carver"  escribió:

> SFC team and anybody else dealing with flow selection/classification (e.g.
> QoS),
>
> I just wanted to confirm that we're planning to meet in salon C today
> (Wednesday) to get lunch but then possibly move to a quieter location to
> discuss the common flow classifier ideas.
>
> On 4/21/2016 19:42, Cathy Zhang wrote:
>
>> I like Malini’s suggestion on meeting for a lunch to get to know each
>> other, then continue on Thursday.
>>
>> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
>> and then continue the discussion at Room 400 at 3:10pm Thursday.
>>
>> Since Salon C is a big room, I will put a sign “Common Flow Classifier
>> and OVS Agent Extension” on the table.
>>
>> I have created an etherpad for the discussion.
>> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
>>
>>
>
> __
> 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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Paul Carver]

SFC team and anybody else dealing with flow selection/classification 
(e.g. QoS),


I just wanted to confirm that we're planning to meet in salon C today 
(Wednesday) to get lunch but then possibly move to a quieter location to 
discuss the common flow classifier ideas.


On 4/21/2016 19:42, Cathy Zhang wrote:

I like Malini’s suggestion on meeting for a lunch to get to know each
other, then continue on Thursday.

So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
and then continue the discussion at Room 400 at 3:10pm Thursday.

Since Salon C is a big room, I will put a sign “Common Flow Classifier
and OVS Agent Extension” on the table.

I have created an etherpad for the discussion.
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit




__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Rossella Sblendido]

On 04/22/2016 02:42 AM, Cathy Zhang wrote:
> So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
> and then continue the discussion at Room 400 at 3:10pm Thursday.
> 
> Since Salon C is a big room, I will put a sign “Common Flow Classifier
> and OVS Agent Extension” on the table.
> 
I am also interested in joining the conversation. Wednesday for lunch
works for me!

__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

I like Malini’s suggestion on meeting for a lunch to get to know each other, 
then continue on Thursday.
So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday and then 
continue the discussion at Room 400 at 3:10pm Thursday.
Since Salon C is a big room, I will put a sign “Common Flow Classifier and OVS 
Agent Extension” on the table.

I have created an etherpad for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

Thanks,
Cathy


From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Thursday, April 21, 2016 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Miguel Angel Ajo; Reedip
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

+1 on Wednesday lunch

On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics.
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference.

On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is 
4:40-5:20pm. But lunch time should probably be fine if it leaves time for the 
actual lunch...

Thursday at 3:10pm also works for me.


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Stephen Wong]

+1 on Wednesday lunch

On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka 
wrote:

> Cathy Zhang  wrote:
>
> Hi everyone,
>>
>> We have room 400 at 3:10pm on Thursday available for discussion of the
>> two topics.
>> Another option is to use the common room with roundtables in "Salon C"
>> during Monday or Wednesday lunch time.
>>
>> Room 400 at 3:10pm is a closed room while the Salon C is a big open room
>> which can host 500 people.
>>
>> I am Ok with either option. Let me know if anyone has a strong preference.
>>
>
> On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is
> 4:40-5:20pm. But lunch time should probably be fine if it leaves time for
> the actual lunch...
>
> Thursday at 3:10pm also works for me.
>
>
> 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
>
__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Ihar Hrachyshka]

Cathy Zhang  wrote:


Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the  
two topics.
Another option is to use the common room with roundtables in "Salon C"  
during Monday or Wednesday lunch time.


Room 400 at 3:10pm is a closed room while the Salon C is a big open room  
which can host 500 people.


I am Ok with either option. Let me know if anyone has a strong preference.


On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is  
4:40-5:20pm. But lunch time should probably be fine if it leaves time for  
the actual lunch...


Thursday at 3:10pm also works for me.

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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Bhandaru, Malini K]

I vote for Monday to get the ball rolling, meet the interested parties, and 
Continue on Thursday at 3:10 in a quieter setting ... so we leave with some 
consensus.
Thanks Cathy!
Malini

-Original Message-
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] 
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang <cathy.h.zh...@huawei.com>; OpenStack Development Mailing List 
(not for usage questions) <openstack-dev@lists.openstack.org>; Ihar Hrachyshka 
<ihrac...@redhat.com>; Vikram Choudhary <vikram.choudh...@huawei.com>; Sean M. 
Collins <s...@coreitpro.com>; Haim Daniel <hdan...@redhat.com>; Mathieu Rohon 
<mathieu.ro...@gmail.com>; Shaughnessy, David <david.shaughne...@intel.com>; 
Eichberger, German <german.eichber...@hpe.com>; Henry Fourie 
<louis.fou...@huawei.com>; arma...@gmail.com; Miguel Angel Ajo 
<mangel...@redhat.com>; Reedip <reedip.baner...@nectechnologies.in>; Thierry 
Carrez <thie...@openstack.org>
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
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

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are n

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang 
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
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

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.

> Different features may extend OVS agent and add different new OVS flow 
> tables to support their new functionality. A mechanism is needed to 
> ensure consistent OVS flow table modification when multiple features 
> co-exist. AFAIK, there is some preliminary work on this, but it is not 
> a complete solution yet.

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 reso

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

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.

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Vikram Choudhary]

AFAIK, there is proposal about adding a 'priority' option in the existing
flow classifier rule. This can ensure the rule ordering.


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?
> 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 

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[IWAMOTO Toshihiro]

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 

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

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.

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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Miguel Angel Ajo Pelayo]

Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose
abrev. now ;)

On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo
<majop...@redhat.com> 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.
>
> 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 tar

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

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<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto: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://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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Ihar,

My replies are inline.

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, April 14, 2016 4:45 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Vikram 
Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; Shaughnessy, David; 
Eichberger, German; Henry Fourie; Armando M.
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

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.

Cathy> Yes, the existing extension mechanism with Bridge wrapper and cookie is 
a step forward for subprojects.  

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.

Cathy> Good suggestion. We can do this in steps. Previously we were thinking 
about waiting until strict flow management is supported in the extension. 

Thanks,
Cathy

[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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[reedip banerjee]

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 
wrote:

> Cathy Zhang  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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Ihar Hrachyshka]

Cathy Zhang  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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before)
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, April 14, 2016 3:34 AM
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

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.

> Different features may extend OVS agent and add different new OVS flow 
> tables to support their new functionality. A mechanism is needed to 
> ensure consistent OVS flow table modification when multiple features 
> co-exist. AFAIK, there is some preliminary work on this, but it is not 
> a complete solution yet.

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. 

> We will like to start these effort by collecting requirements and then 
> posting specifications for review. If any of you would like to join 
> this effort, please chime in. We can set up a meet-up session in the 
> Summit to discuss this face-in-face.

Great. Let’s have a meetup for this topic.

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
__
OpenStack Development Mailing List (not for usage questions)
Uns

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Eichberger, German]

Just to echo others: FWaaS would be interested in this as well so please keep 
us in the loop.

Thanks,
German




On 4/14/16, 7:12 AM, "Sean M. Collins"  wrote:

>Vikram Choudhary wrote:
>> Hi Cathy,
>> 
>> A project called "neutron-classifier [1]" is also there addressing the same
>> use case. Let's sync up and avoid work duplicity.
>> 
>> [1] https://github.com/openstack/neutron-classifier
>
>Agree with Vikram - we have a small git repo that we're using to futz
>around with ideas around how to store classifiers in a way that is
>re-usable by other projects, and create a decent object model.
>
>It's very very rough, and the API is ... kind of ugly right now. That's
>what you get when I steal like 4 Red Bulls and do an all-night coding
>session in Tokyo.
>
>So, It'd be great to get other people involved, get an API hashed out
>that doesn't expose all the nitty gritty DB details (like it currently
>is) and move forward.
>
>-- 
>Sean M. Collins
>
>__
>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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Sean M. Collins]

Vikram Choudhary wrote:
> Hi Cathy,
> 
> A project called "neutron-classifier [1]" is also there addressing the same
> use case. Let's sync up and avoid work duplicity.
> 
> [1] https://github.com/openstack/neutron-classifier

Agree with Vikram - we have a small git repo that we're using to futz
around with ideas around how to store classifiers in a way that is
re-usable by other projects, and create a decent object model.

It's very very rough, and the API is ... kind of ugly right now. That's
what you get when I steal like 4 Red Bulls and do an all-night coding
session in Tokyo.

So, It'd be great to get other people involved, get an API hashed out
that doesn't expose all the nitty gritty DB details (like it currently
is) and move forward.

-- 
Sean M. Collins

__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Shaughnessy, David]

Hi Cathy.
I’d be interested in contributing.
I think a meet up at the summit would be a good idea as the people I’ve engaged 
with from the other projects on this topic expressed interest.
There was an etherpad for the l2-agent-extensions-api that was merged in Mitaka 
that listed projects that needed access to the flow table[1].
Hope you find it helpful.
Regards.
David.

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion

From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com]
Sent: Thursday, April 14, 2016 10:05 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi cathy,
at net-bgpvpn, we're very interested in this effort. Please, keep us in the 
loop.
Mathieu

On Thu, Apr 14, 2016 at 8:59 AM, Haim Daniel 
<hdan...@redhat.com<mailto:hdan...@redhat.com>> wrote:
Hi,

I'd +1 Vikram's comment on neutron-classifier , RFE [1] contains the original 
thread about that topic.


[1] https://bugs.launchpad.net/neutron/+bug/1527671

On Thu, Apr 14, 2016 at 5:33 AM, Vikram Choudhary 
<viks...@gmail.com<mailto:viks...@gmail.com>> wrote:

Hi Cathy,

A project called "neutron-classifier [1]" is also there addressing the same use 
case. Let's sync up and avoid work duplicity.

[1] https://github.com/openstack/neutron-classifier

Thanks
Vikram
On Apr 14, 2016 6:40 AM, "Cathy Zhang" 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi everyone,
Per Armando’s request, Louis and I are looking into the following features for 
Newton cycle.

• Neutron Common FC used for SFC, QoS, Tap as a service etc.,
• OVS Agent extension
Some of you might know that we already developed a FC in networking-sfc project 
and QoS also has a FC. It makes sense that we have one common FC in Neutron 
that could be shared by SFC, QoS, Tap as a service etc. features in Neutron.
Different features may extend OVS agent and add different new OVS flow tables 
to support their new functionality. A mechanism is needed to ensure consistent 
OVS flow table modification when multiple features co-exist. AFAIK, there is 
some preliminary work on this, but it is not a complete solution yet.
We will like to start these effort by collecting requirements and then posting 
specifications for review. If any of you would like to join this effort, please 
chime in. We can set up a meet-up session in the Summit to discuss this 
face-in-face.
Thanks,
Cathy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Ihar Hrachyshka]

Cathy Zhang  wrote:


Hi everyone,
Per Armando’s request, Louis and I are looking into the following  
features for Newton cycle.

· Neutron Common FC used for SFC, QoS, Tap as a service etc.,
· OVS Agent extension
Some of you might know that we already developed a FC in networking-sfc  
project and QoS also has a FC. It makes sense that we have one common FC  
in Neutron that could be shared by SFC, QoS, Tap as a service etc.  
features in Neutron.


I don’t actually know of any classifier in QoS. It’s only planned to  
emerge, but there are no specs or anything specific to the feature.


Anyway, I agree that classifier API belongs to core neutron and should be  
reused by all interested subprojects from there.


Different features may extend OVS agent and add different new OVS flow  
tables to support their new functionality. A mechanism is needed to  
ensure consistent OVS flow table modification when multiple features  
co-exist. AFAIK, there is some preliminary work on this, but it is not a  
complete solution yet.


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.


We will like to start these effort by collecting requirements and then  
posting specifications for review. If any of you would like to join this  
effort, please chime in. We can set up a meet-up session in the Summit to  
discuss this face-in-face.


Great. Let’s have a meetup for this topic.

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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Mathieu Rohon]

Hi cathy,

at net-bgpvpn, we're very interested in this effort. Please, keep us in the
loop.

Mathieu

On Thu, Apr 14, 2016 at 8:59 AM, Haim Daniel  wrote:

> Hi,
>
> I'd +1 Vikram's comment on neutron-classifier , RFE [1] contains the
> original thread about that topic.
>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1527671
>
> On Thu, Apr 14, 2016 at 5:33 AM, Vikram Choudhary 
> wrote:
>
>> Hi Cathy,
>>
>> A project called "neutron-classifier [1]" is also there addressing the
>> same use case. Let's sync up and avoid work duplicity.
>>
>> [1] https://github.com/openstack/neutron-classifier
>>
>> Thanks
>> Vikram
>> On Apr 14, 2016 6:40 AM, "Cathy Zhang"  wrote:
>>
>> Hi everyone,
>>
>> Per Armando’s request, Louis and I are looking into the following
>> features for Newton cycle.
>>
>> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
>>
>> · OVS Agent extension
>>
>> Some of you might know that we already developed a FC in networking-sfc
>> project and QoS also has a FC. It makes sense that we have one common FC in
>> Neutron that could be shared by SFC, QoS, Tap as a service etc. features in
>> Neutron.
>>
>> Different features may extend OVS agent and add different new OVS flow
>> tables to support their new functionality. A mechanism is needed to ensure
>> consistent OVS flow table modification when multiple features co-exist.
>> AFAIK, there is some preliminary work on this, but it is not a complete
>> solution yet.
>>
>> We will like to start these effort by collecting requirements and then
>> posting specifications for review. If any of you would like to join this
>> effort, please chime in. We can set up a meet-up session in the Summit to
>> discuss this face-in-face.
>>
>> Thanks,
>>
>> Cathy
>>
>> __
>> 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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Vikram Choudhary]

Hi Cathy,

A project called "neutron-classifier [1]" is also there addressing the same
use case. Let's sync up and avoid work duplicity.

[1] https://github.com/openstack/neutron-classifier

Thanks
Vikram
On Apr 14, 2016 6:40 AM, "Cathy Zhang"  wrote:

Hi everyone,

Per Armando’s request, Louis and I are looking into the following features
for Newton cycle.

· Neutron Common FC used for SFC, QoS, Tap as a service etc.,

· OVS Agent extension

Some of you might know that we already developed a FC in networking-sfc
project and QoS also has a FC. It makes sense that we have one common FC in
Neutron that could be shared by SFC, QoS, Tap as a service etc. features in
Neutron.

Different features may extend OVS agent and add different new OVS flow
tables to support their new functionality. A mechanism is needed to ensure
consistent OVS flow table modification when multiple features co-exist.
AFAIK, there is some preliminary work on this, but it is not a complete
solution yet.

We will like to start these effort by collecting requirements and then
posting specifications for review. If any of you would like to join this
effort, please chime in. We can set up a meet-up session in the Summit to
discuss this face-in-face.

Thanks,

Cathy

__
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-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,
Per Armando's request, Louis and I are looking into the following features for 
Newton cycle.

* Neutron Common FC used for SFC, QoS, Tap as a service etc.,
* OVS Agent extension
Some of you might know that we already developed a FC in networking-sfc project 
and QoS also has a FC. It makes sense that we have one common FC in Neutron 
that could be shared by SFC, QoS, Tap as a service etc. features in Neutron.
Different features may extend OVS agent and add different new OVS flow tables 
to support their new functionality. A mechanism is needed to ensure consistent 
OVS flow table modification when multiple features co-exist. AFAIK, there is 
some preliminary work on this, but it is not a complete solution yet.
We will like to start these effort by collecting requirements and then posting 
specifications for review. If any of you would like to join this effort, please 
chime in. We can set up a meet-up session in the Summit to discuss this 
face-in-face.
Thanks,
Cathy
__
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