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