Open Stack

Hi everyone,

Thanks YAMAMOTO Takashi for reserving a new meeting channel "openstack-meeting", for the discussion.
We will have biweekly-odd meetings on this channel at UTC 1700 on Tuesday. Due to this long weekend in US and some people taking extra days off, let's start the meeting on this new channel on June 14. 

Thanks,
Cathy

-----Original Message-----
From: Cathy Zhang 
Sent: Thursday, May 05, 2016 3:35 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

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; armamig at 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; 'armamig at 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 <description>]
        [--protocol <protocol>]
        [--ethertype <Ethertype>]
        [--source-port <Minimum source protocol port>:<Maximum source protocol port>]
        [--destination-port <Minimum destination protocol port>:<Maximum destination protocol port>]
        [--source-ip-prefix <Source IP prefix>]
        [--destination-ip-prefix <Destination IP prefix>]
        [--logical-source-port <Neutron source port>]
        [--logical-destination-port <Neutron destination port>]
        [--l7-parameters <L7 parameter>] 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:ihrachys at 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.Zhang at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev