17:00:30 <cathy_> #startmeeting service_chaining
17:00:31 <openstack> Meeting started Thu Mar  3 17:00:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:34 <openstack> The meeting name has been set to 'service_chaining'
17:00:46 <cathy_> hi everyone
17:01:19 <vikram_> hi
17:01:25 <raofei> hi, everyone
17:01:29 <pcarver> hi
17:01:30 <cathy_> hi vikram_ s3wong
17:01:33 <s3wong> hello
17:01:49 <cathy_> hi raofei pcarver
17:01:53 <fsunaval> hi cathy_
17:02:00 <cathy_> hi fsunaval
17:02:44 <cathy_> any topic you would like to discuss today? I have some topics
17:03:07 <vikram_> using L2 extension for SFC
17:03:26 <cathy_> vikram_: yes, that is the one on my mind too
17:03:46 <cathy_> hi mohankumar_
17:03:55 <mohankumar_> Hi cathy_
17:04:16 <cathy_> #topic use new L2 extension API in SFC
17:04:38 <cathy_> here is the link to this https://review.openstack.org/#/c/267591/
17:04:53 <cathy_> #link https://review.openstack.org/#/c/267591/
17:05:54 <fsunaval> I've had a look at this.  Each app essentially needs to request a cookie from the l2 extension api.  It then needs to call the L2 extension API with the cookie information whenever it needs to install a flow.
17:06:03 <cathy_> This one has been merged into Neutron's master. So we need to change our SFC L2 agent code to use this new one.
17:06:34 <cathy_> fsunaval: great, thanks for sharing the info!
17:07:49 <raofei> it seems this solution doesn't support manager the ovs pipeline.
17:08:27 <vikram_> raofei: we can ask ihar about our req
17:08:29 <cathy_> raofei: could you clarify what you mean by managing the OVS pipeline?
17:08:36 <vikram_> raofei: he promised to support
17:09:13 <cathy_> Shouldn't it support programming the OVS table?
17:10:11 <vikram_> ihrachys: raofei has few doubts
17:10:26 <raofei> if multiple services are integrated, there are maybe pipeline resource conflict.
17:10:28 <vikram_> ihrachys: can you plz clarify
17:10:49 <fsunaval> yes, I already asked the committers.  See patch 30 response.
17:10:55 <raofei> OK, vikaram
17:11:20 <fsunaval> this was not within the scope of their commit is what the response says.
17:11:21 <cathy_> I remember when this was discussed in last Tokyo Summit, there is suggestion to put a service type to distinguish different services's table
17:12:40 <raofei> that's good
17:13:21 <cathy_> fsunaval: raofei would you like to think about how to add this missing pieces, talk with Ihar, and maybe submit a bug for this?
17:13:59 <LouisF> fsunaval: that patch only uses cookie to identify rules installed by different drivers, not the resolution of rule conflicts
17:13:59 <cathy_> I mean submit a bug to Neutron and then upload a patch to fix this
17:14:26 <LouisF> that is a much more challenging problem
17:14:40 <fsunaval> LouisF: correct.  it does not resolve rule conflicts.
17:14:47 <cathy_> fsunaval: raofei I will work with you on this missing piece
17:15:30 <raofei> as fsunaval mentioned, they will consider resolve it.
17:15:56 <fsunaval> cathy_: yes, I can initiate a conversation with them about this... It looks like they are aware of the shortcomings.
17:16:33 <pcarver> fsunaval: I think they are aware. It's a fairly complex problem.
17:16:35 <raofei> this patch scope doesn't contain this problem.
17:16:49 <LouisF> there are two issues: 1. detect rule conflicts, 2. resolve rule conflicts
17:17:05 <LouisF> raofei: the is correct
17:17:50 <cathy_> If different features need different rules, then the OVS table needs to support that and one way is to have different tables for different features for that conflict part of rules
17:18:01 <pcarver> We need a general prioritization mechanism
17:18:42 <raofei> yes, I think so
17:18:43 <pcarver> The API (and GUI/CLI/Heat) need to support a mechanism for assigning priorities across different flow manipulating projects
17:18:44 <fsunaval> pcarver: +1
17:19:14 <LouisF> cathy_: yes, different tables can help but T0 needs priorities
17:19:39 <cathy_> LouisF: OK
17:19:44 <LouisF> or rather the rules in T0 need priority
17:19:51 * ihrachys is late
17:19:51 <raofei> it is service injection.
17:19:52 <pcarver> There needs to be a user visible mechanism to describe, for example, whether they want a tap/mirror (TaaS project) to take effect before or after traffic is directed by an SFC rule
17:20:16 <ihrachys> but generally, yes. it's not covered yet, we are aware of shortcomings, and I am glad to see someone driving that in Newton.
17:20:23 <pcarver> Or an OvS based security group rule as another example
17:20:30 <cathy_> If the traffic for different features can be distinguished, then even they desire conflicting rules, OVS can still support both with different forwarding tables
17:21:51 <cathy_> ihrachys: we will help drive that since SFC needs to use it
17:22:11 <LouisF> need analysis of how different features use the ovs tables/rules
17:22:33 <vikram_> LouisF: +1
17:22:45 <cathy_> ihrachys: Is there already a bug for this? If not, we can submit a bug for this enhancement and then work on this, sounds good with you?
17:22:58 <ihrachys> cathy_: RFE, yes, please report
17:23:19 <ihrachys> cathy_: as long as someone will drive the feature apart from me, I am open to support it with reviews and suggestions
17:23:34 <LouisF> this is really more than a bug - itg affects all features the install ovs rules
17:23:38 <vikram_> iharchys: ;)
17:23:53 <cathy_> LouisF: yes:-) It is not a small change
17:23:56 <ihrachys> it's too much for me to take on my own, and honestly I am not directly interested in it to invest too much time
17:24:42 <vikram_> ihrachys: I was thinking what if networking-sfc doesn't uses L2 extension
17:24:46 <vikram_> any issues?
17:25:10 <ihrachys> vikram_: ovs agent does not provide you any guarantees of API
17:25:17 <vikram_> I don't know what is the priority of the current project
17:25:20 <ihrachys> vikram_: also ovs agent is free to reset your flows
17:25:21 <LouisF> vikram_: can you elaborate on 'does not use l2 extension'?
17:25:44 <ihrachys> if you are ok with both of that, well... not that I think it's sane assumption, but if it works for you now...
17:26:25 <vikram_> LouisF: I mean, if networking-sfc doesn't fallback to the new L2 extension support
17:26:30 <cathy_> LouisF: I think what vikram means is that if we keep our existing mechanism and does not use the new L2 extension API
17:26:51 <LouisF> vikram_: got it thanks
17:27:15 <cathy_> ihrachys: If we keep our existing mechanism and do not use the new L2 extension API, it should be fine, right?
17:27:26 <vikram_> My concern is if the effort is huge then if the team is okay to take this up and it is inline with our next project plan?
17:27:38 <cathy_> vikram_: good point
17:28:42 <ihrachys> cathy_: whatever works for you. just don't expect ovs agent will not break you any time.
17:29:01 <cathy_> ihrachys: OK, thanks.
17:29:06 <fsunaval> vikram_: it should be fine.  we will not pass the cookie information and simply call the ovs-ofctl directly.  In that case, the cookie inside the flow will be the UUID timestamp.
17:29:10 <vikram_> ihrachys: agreed
17:29:13 <ihrachys> if you are still in PoC stage, it may be premature for you to spend time on it
17:29:33 <vikram_> fsunaval: ok
17:29:42 <ihrachys> fsunaval: since the cookie is not coordinated with ovs agent, ovs agent restart will reset your flows
17:29:46 <vikram_> fsunaval: sorry, i haven't seen the spec yet
17:30:36 <LouisF> fsunaval: we referring to https://bugs.launchpad.net/networking-sfc/+bug/1538332 right?
17:30:37 <openstack> Launchpad bug 1538332 in networking-sfc "Port Pair Create fails for Provider Network" [Undecided,New]
17:31:07 <LouisF> sorry ignore
17:31:49 <LouisF> i meant https://review.openstack.org/#/c/267591/
17:32:16 <fsunaval> ihrachys:  we do coordinate the cookie with the OVS agent right now.  my point was we should be fine if we do not call the L2 extension agent.
17:32:39 <raofei> once again, even if the SDN controller instead of L2 agent, servic injection mechanism is useful too. Neutron need to provide a north APIs to define sevice priority for injection.
17:33:02 <ihrachys> fsunaval: I suspect not in Mitaka anymore
17:33:21 <fsunaval> ihrachys: I see, ok.  I will need to look into that.
17:34:44 <cathy_> ihrachys: what do you mean not in Mitaka any more. Even we coordinate cookie with OVS agent, it will not work?
17:35:32 <cathy_> ihrachys: could you clarify?
17:35:37 <LouisF> ihrachys: https://review.openstack.org/#/c/267591/ is merged
17:35:53 <ihrachys> cathy_: I think we made some changes with the patch for l2 agent extensions that could break you. you need to check
17:36:02 <ihrachys> depending on how you sync with ovs agent right now
17:36:07 <cathy_> ihrachys: OK, I see,
17:37:20 <cathy_> raofei: since you have worked on the OVS agent part of code, would you like to take an action item and check this?
17:37:38 <cathy_> fsunaval: would you lie to help check this too?
17:37:50 <cathy_> I mean "like", my bad:-)
17:38:04 <fsunaval> cathy_: yes, I can look into it. If needed, I can ask Raofei
17:38:13 <raofei> OK, I'd like to do it
17:38:22 <cathy_> fsunaval: raofei cool, Thanks!
17:39:09 <cathy_> Now next topic
17:39:13 <LouisF> pcarver: are you aware of any work going on the resolve ovs rule conflicts?
17:39:51 <pcarver> LouisF: No. The general need was discussed briefly at the summit but I think it's a fairly big task that hasn't really been tackled.
17:40:14 <cathy_> #action raofei fsunaval check whether existing SFC L2 agent code still work with the new L2 agent extension being added.
17:40:24 <LouisF> definitely bug task - maybe topic for neutron desiggn session?
17:40:27 <LouisF> big
17:40:55 <cathy_> LouisF: good suggestion
17:41:09 <cathy_> #topic service insertion
17:41:36 <cathy_> raofei: would you like to describe the service insertion you have in mind?
17:41:55 <cathy_> you just mentioned that before
17:42:38 <raofei> we can do more extension for L2 agent extension
17:43:52 <mohankumar> raofei:  could you explain bit more :)
17:43:53 <cathy_> you mentioned API, do you mean API extension at networking-sfc API layer or extension at L2 agent layer?
17:44:05 <raofei> we can define new API which provide the sevice process order
17:45:10 <cathy_> at SFC API layer, the API already provides mechanism for service function order
17:45:17 <raofei> and manage all the network resource, such as flow table
17:45:20 <LouisF> cathy_: +1
17:45:41 <vikram_> I think we are make use of port pair group?
17:45:43 <LouisF> its implicit in the order of the PPGs in the PC
17:45:57 <cathy_> raofei: it will be helpful if you can first clarify which API layer are you talking about?
17:46:40 <cathy_> vikram_: yes, the order of port pair group as Louis said
17:46:53 <vikram_> cathy_: ok
17:47:21 <raofei> it's different from sevice chain.
17:47:55 <cathy_> raofei: OK, are you talking about adding an extension at the Neutron API layer?
17:48:08 <LouisF> raofei: can you explain?
17:48:15 <cathy_> or the backend L2 agent layer?
17:49:11 <raofei> both. I will share a link to you
17:49:37 <LouisF> raofei: thanks
17:49:42 <cathy_> raofei: great.
17:51:41 <cathy_> raofei: are you going to send us the link after the meeting?
17:51:57 <raofei> please go on, I have to search.
17:52:01 <raofei> yes
17:52:02 <s3wong> raofei: can you share the link in this meeting (so it is on record)?
17:52:27 <cathy_> raofei Ok, if you can get it, post it, otherwise you can send it to us via email
17:52:37 <cathy_> let's take a look at the link and then discuss in next meeting
17:52:49 <raofei> ok, will do
17:53:25 <cathy_> #action raofei will send out a link on service insertion
17:54:00 <cathy_> #topic SFC features for next phase
17:54:28 <cathy_> we discussed a lot of features desired for next phase.
17:54:57 <cathy_> You can refer to last meeting log for the new features.
17:56:00 <mohankumar> http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-02-25-17.00.log.html
17:56:28 <LouisF> cathy_: can we poll for the level of interest/priority of these items?
17:56:36 <cathy_> Next step is that the feature design tasks need to be assigned.
17:56:53 <cathy_> LouisF: good suggestion.
17:58:27 <raofei> yes, I want to know the plan
17:58:38 <cathy_> SO I would suggest that each of us think about the list and volunteer to take the design work and start working on the design spec.
17:58:58 <cathy_> raofei: great! Thanks!
18:00:27 <cathy_> time is up. BTW, I will be on business trip and can not host next two meetings. Louis, can you host them for me?
18:01:01 <LouisF> cathy_: yes i will
18:01:30 <cathy_> Ok, Thanks. bye everyone. I will talk with you in two weeks
18:01:41 <cathy_> #endmeeting