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