17:00:36 <cathy_> #startmeeting service_chaining
17:00:36 <openstack> Meeting started Thu Feb  4 17:00:36 2016 UTC and is due to finish in 60 minutes.  The chair is cathy_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:39 <openstack> The meeting name has been set to 'service_chaining'
17:00:50 <cathy_> hi everyone
17:00:51 <LouisF> hi
17:00:52 <vikram> hi
17:00:59 <mohankumar_> hi
17:01:20 <pcarver> hi
17:01:35 <johnsom> o/
17:01:40 <hdaniel> hi
17:01:43 <cathy_> any topic your would like to discuss today?
17:02:10 <vikram> cathy_: I have something
17:02:24 <cathy_> vikram: go ahead
17:02:34 <georgewang> hi
17:02:36 <vikram> cathy_: I was just wondering on making logical source port as mandatory
17:03:22 <vikram> cathy_: If SFC is realized using NSH then is it required to make it mandatory?
17:03:46 <cathy_> vikram: no
17:04:11 <cathy_> but making it mandatory will improve performance
17:04:27 <cathy_> besides solving the loop problem
17:04:45 <vikram> cathy_: The issue is.... defined NBI's will become de-facto and may not be useful
17:04:58 <cathy_> NSH will only solve the loop problem
17:05:23 <cathy_> Let me explain this a little bit more
17:05:41 <vikram> ok
17:08:00 <cathy_> If we do not make the logical source port mandatory, then FC needs to be installed and runs on all the compute nodes since we do not know the entry point of the traffic. Performance will be an issue.
17:08:39 <vikram> okay.. but why to make it mandate in the FC API..
17:08:52 <vikram> because it's no more generic
17:09:20 <vikram> I mean we could have an option defined in the port-chain-create cli?
17:09:35 <vikram> probably sfc-parameter or so?
17:10:22 <cathy_> Let me think about this
17:10:26 <vikram> ok
17:11:46 <s3wong> hello --- sorry, joined late
17:12:04 <cathy_> vikram: If we are thinking about making the FC generic across all Neutron features, not just for SFC, then we can think about this a little more.
17:12:22 <cathy_> Others, thought?
17:12:35 <cathy_> s3wong: hi, it is OK
17:13:02 <cathy_> vikram: will get back to you later
17:13:06 <vikram> cathy_: I was thinking from the controller perspective
17:13:16 <vikram> cathy_: no issues
17:13:17 <LouisF> the FC is going to evolve - i think there is a an idea to add TOS/diffserv
17:14:27 <vikram> To me let's not couple FC and port-chain interfaces
17:15:53 <cathy_> FC is currently developed for port-chain. But yes I agree we should try to decouple them completely for it to evolve to be the generic FC.
17:16:21 <LouisF> i agree there
17:17:10 <cathy_> A quick update on the release
17:17:13 <vikram> ;)
17:18:27 <cathy_> A new branch has been pulled for releasing networking-sfc to be compatible with Liberty code base. We are working on it and will release a version compatible with stable/liberty
17:19:31 <LouisF> https://github.com/openstack/networking-sfc/tree/stable/liberty
17:19:47 <cathy_> So we are going to have two branches, one going with Master, the other going with stable/liberty. User can choose either version to download
17:20:18 <mohankumar_> cathy_ : lgtm
17:20:49 <cathy_> how is ONOS integration with networking-sfc API going?
17:21:10 <vikram> cathy_: it works .. no issues
17:21:30 <LouisF> do you have a demo?
17:21:36 <cathy_> is the ONOS driver plugin merged into the networking-sfc repo?
17:21:39 <vikram> driver changes are merged to networking-onos and sfc changes to onos
17:21:57 <vikram> ONOS driver changes we merged to networking-onos repo
17:23:01 <cathy_> how do you integrate with networking-sfc API, DB, and common driver manager?
17:23:15 <vikram> https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst
17:23:27 <vikram> https://github.com/openstack/networking-onos/blob/master/doc/source/devref/flowclassifier_driver.rst
17:25:04 <cathy_> Ok, thanks
17:25:21 <LouisF> vikram: great work
17:25:40 <cathy_> how are horizon and heat work going?
17:26:33 <vikram> mohankumar_: can you plz update?
17:26:57 <mohankumar_> cathy_ : yes
17:27:18 <mohankumar_> cathy_ for heat i tested  code and posted to  community
17:28:03 <vikram> mohankumar_: do have the review link handy?
17:28:53 <mohankumar_> yes vikram
17:29:11 <vikram> can you please paste so that team can review ;)
17:29:14 <mohankumar_> https://review.openstack.org/#/c/249729/
17:29:36 <vikram> thanks
17:30:18 <mohankumar_> for horizon  code , some integration code yet to check in
17:31:10 <cathy_> mohankumar_: I see some -1 on review and Jenkins. When do you think the heat patch can be ready fro merge?
17:32:30 <mohankumar_> cathy_ : most are minior review coments
17:32:59 <mohankumar_> cathy_ :  wil post new patch tomorrow
17:33:40 <cathy_> mohankumar_: thanks for the work!
17:34:04 <mohankumar_> cathy_/LouisF  :  me facing issue in SFC setup , after installing "q-sfc-plugin"  , shall we disscuss here or through mail ?
17:34:28 <LouisF> mohankumar_: send us email on the detals
17:34:31 <LouisF> details
17:34:38 <mohankumar_> http://paste.openstack.org/show/485928/
17:35:06 <cathy_> mohankumar_: OK, let's discuss via email since it involves a lot of details
17:35:19 <mohankumar_> cathy_: ok .. thanks
17:36:02 <cathy_> Anyone would like to discuss a little bit on new features for next phase?
17:36:47 <vikram> cathy_: I have few...
17:36:50 <cathy_> pcarver: you mentioned adding ODL, contrail plugin to networking-sfc. Still the same plan on your side?
17:36:55 <cathy_> vikram: sure
17:37:08 <LouisF> drivers for odl and opencontrail?
17:37:27 <pcarver> cathy_: I'd like to see that happen but don't have any specific resources to commit at the moment
17:37:36 <cathy_> how about adding integration of networking-sfc with OVN?
17:38:18 <cathy_> pcarver: OK, hope you can get some resource. I am also trying to get resource commitment to help on that. Let's sync up later on that
17:38:28 <cathy_> Swami: hi,
17:38:33 <Swami> hi
17:38:54 <cathy_> Swami: you missed important information:-)
17:39:07 <cathy_> vikram: go ahead
17:39:13 <Swami> cathy_: sorry, I will take a look at the logs.
17:39:23 <vikram> cathy_: We couldn't do much on SFC OAM during Mitaka but would like to take it up for Newton... Moreover, I was thinking of deploying a classifier VM via FC API
17:39:28 <cathy_> Swami: sure, np
17:40:10 <vikram> cathy_: classifier VM can sit in front of the chain by default
17:40:15 <cathy_> vikram: could you calrify what you mean by classifier VM via FC API
17:41:39 <vikram> cathy_: Actually I was thinking of a traffic classification entity which could be deployed independently
17:42:13 <cathy_> vikram: That is a good idea, I think
17:42:35 <LouisF> vikram: so all ingress packets from the source VMs would be first steered to this FC VM?
17:42:46 <vikram> LouisF: +1000
17:43:21 <vikram> LouisF: all the incoming traffic should be steered to this guy first
17:43:22 <cathy_> Yes, that is a good feature to add in our second phase, I think
17:43:40 <LouisF> seems like potential bottleneck?
17:44:00 <vikram> LouisF: We can have pool of such VM's
17:44:02 <cathy_> we can have multiple such FC VMs
17:44:47 <vikram> We can rather generalize this VM to do any functionality
17:44:58 <vikram> like DPI / IPS or etc..
17:45:32 <vikram> sorry if I am sound off-track
17:45:39 <vikram> *sounding
17:46:00 <LouisF> vikram: no its a good idea - distributed FC
17:46:39 <vikram> ok
17:46:43 <hdaniel> cathy_, vikram: IMO to have several of those VM's, an additional classifier should be presented - to spread the traffic :)
17:47:04 <cathy_> Depending on user scenario, a DPI based FC is needed for some scenarios, such as subscriber based SFC which needs classification up to l7
17:47:25 <LouisF> its what we currently do for the OVS FC but it's distributed on every HV
17:47:32 <vikram> hdaniel: ;)
17:48:02 <vikram> LouisF: Yes we can avoid such duplicacy
17:48:21 <LouisF> vikram: a FC VM would certainly be able to do DPI, IPS
17:49:18 <LouisF> vikram: agree, only want to have one type of FC active - VM or HV
17:50:19 <vikram> If the team feels it is interesting then let's start prototyping ;)
17:50:50 <vikram> I  can do some initial write up
17:51:17 <cathy_> vikram: sure. thanks
17:53:12 <cathy_> It seems OVN is the prevailing SDN controller mechanism in OpenStack Neutron. I would like to get everyone's input on networking-sfc integration with OVN. We can discuss this in next meeting
17:54:02 <vikram> IIRC, russel raise few concerns earlier
17:54:18 <LouisF> vikram: what concerns?
17:55:02 <vikram> I saw a mail from him long back about API concerns
17:55:15 <cathy_> There is another project on SDN controller, dragonflow
17:55:20 <vikram> I cannot recollect..
17:55:25 <cathy_> vikram: could you find out that email?
17:55:37 <vikram> I will
17:55:42 <cathy_> vikram: thanks
17:56:27 <cathy_> pcarver: s3wong Swami johnsom could you share your thought on OVN or dragonflow in our next meeting?
17:57:22 <vikram> https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg66796.html
17:57:34 <vikram> this is the mail
17:57:35 <Swami> cathy_: ok will take up the dragonflow, since it is similar to dvr.
17:57:40 <pcarver> cathy_: I haven't had time to read anything on dragonflow and I don't know a whole lot about OVN, but I think in general we want drivers for all the SDN controllers that people are using.
17:57:53 <cathy_> georgewang: hdaniel mohankumar_ could you also share your thought on OVN integration with networking-sfc in our next meeting?
17:57:55 <pcarver> But I don't think we want to write them all.
17:58:03 <mohankumar_> cathy_ : sure
17:58:06 <cathy_> pcarver: agree
17:58:43 <pcarver> Ideally we would want SDN controllers with SFC capabilities to see supporting the networking-sfc driver model as a natural thing, like supporting ML2
17:58:56 <cathy_> Swami: ok, thanks. It seems OVN and dragonflow have very similar architecture and functionality
17:59:13 <cathy_> pcarver: exactly!
17:59:15 <georgewang> I think we can discuss about if we want to support ovn in next release
17:59:31 <LouisF> pcarver: +1
17:59:31 <georgewang> in next meeting
17:59:37 <johnsom> I will ask our folks if there is a comment for next week.  Personally I don't have one at the moment.
17:59:41 <cathy_> georgewang: yes, this is for our next release/phase.
17:59:54 <cathy_> johnsom: please. thanks.
18:00:09 <cathy_> sorry our meeting time is up. let's sync up next meeting.
18:00:12 <cathy_> bye everyone
18:00:26 <mohankumar_> bye
18:00:43 <vikram> bye
18:00:57 <cathy_> #endmeeting