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 <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 > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > > > __________________________________________________________________________ > 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
