17:33:07 #startmeeting Networking Advanced Services 17:33:08 Meeting started Wed Aug 20 17:33:07 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:33:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:33:11 The meeting name has been set to 'networking_advanced_services' 17:33:28 #chairs s3wong Kanzhe_ songole dougwig 17:33:40 in case i get dropped 17:33:48 o/ 17:34:09 hi 17:34:10 #announcements Juno feature proposal freeze deadline is aug 21st 17:34:44 or that was more of an info! 17:34:50 we already know it 17:35:17 i tried to check mestery last couple of weeks in this IRC meeting about priorities, etc 17:35:22 i -> we 17:35:23 SumitNaiksatam: I am here. 17:35:30 Kanzhe_: welcome back! :-) 17:35:42 i dont think mestery is around today either 17:35:44 SumitNaiksatam: thanks. 17:35:55 lets get started 17:36:07 #topic Flavors 17:36:23 enikanorov_ markmcclain there? 17:36:35 hi 17:36:38 i'm here 17:36:48 enikanorov_: any updates on the spec? 17:37:10 #link https://review.openstack.org/#/c/102723 17:37:23 no 17:37:31 unfortunately... 17:37:36 enikanorov_: ok 17:37:56 enikanorov_: we are still pursuing the implementation patch #link https://review.openstack.org/#/c/105982? 17:38:16 i see that dougwig and pcm_ reviewed, thats great, thanks! 17:38:19 enikanorov_: is there going to a merge of the two specs? 17:38:40 enikanorov_: perhaps just needs a rebase 17:38:45 LouisF: that's a question. I feel we're deffering whole thing to K 17:39:04 i asked about flavors during the neutron meeting, and got an answer that it'd make J. 17:39:31 dougwig: ok 17:40:16 dougwig: well, I'd be glad if someone help me pinging Mark :) 17:40:28 i will. :) 17:41:06 enikanorov_: any else to add? :-) 17:41:15 the impl patch just needs a rebase bacause of migrations went ahead 17:41:22 not really. 17:41:24 enikanorov_: yeah, i guessed as much 17:41:35 any questions for enikanorov_ apart from the ones already asked? 17:41:54 which BP will be the one for flavor or it will be a merged one? 17:41:54 perhaps reviewing #link https://review.openstack.org/#/c/105982 17:41:57 might help 17:42:16 cathy_: #link https://review.openstack.org/#/c/102723 17:42:26 or some variant of it based on reviewer’s comments 17:42:28 SumitNaiksatam: ok, tahnsk 17:42:33 enikanorov_: correct? 17:42:58 SumitNaiksatam: yes 17:43:13 enikanorov_: thanks 17:43:34 #topic Service base and insertion implementation update 17:43:42 Kanzhe_: s3wong marios: hi 17:43:49 SumitNaiksatam: hello 17:43:53 SumitNaiksatam: hi 17:44:22 any updates? 17:44:23 We are making progress in implementation. 17:44:28 Kanzhe_: good 17:44:45 So I had a meeting with blogan and dougwig last Thurs - and concluded that we won't migrate LBaaS v1 to service insertion framework 17:44:53 s3wong: okay 17:45:03 and I met with Kanzhe_ and kevinbenton last Friday to divide up work 17:45:18 the conclusion is that we will only do an experimental migration on vpnaas only 17:45:26 will fwaas use service base? 17:45:42 s3wong: yeah, my question too ^^^? 17:45:45 LouisF: Not before Thursday deadline 17:46:00 is SridarK here? 17:46:17 (technically once the change to ServicePluginBase is in, all services will be "using" it) 17:46:33 s3wong: so you guys narrowed down on vpnaas because its easier? 17:46:33 but of course, none of them will do anything w.r.t. service interfaces 17:46:39 or rather limited in scope? 17:46:40 SumitNaiksatam: yes :-) 17:47:04 in my opinion, fwaas was the one which would have benefited the most 17:47:20 so on vpnaas, is marios here 17:47:22 ? 17:47:23 SumitNaiksatam: certainly - but also the most work on the service (FWaaS) itself 17:47:50 s3wong: i believe SridarK had prepped for this, but we need to check with him 17:48:00 SumitNaiksatam, agree, based on the schedule, it is more realistic to do VPN at first. 17:48:06 at this point, I think it is a stretch to expect SridarK to have it ready by tomorrow 17:48:36 (also, we still don't have neutron python-client...) 17:48:41 s3wong: i meant my understanding was that there was some prep already done on this front, but anyway we can check offline 17:48:51 SumitNaiksatam: sure 17:49:05 s3wong: the client is not bound by milestone constrains 17:49:27 SumitNaiksatam: good to know! :-) 17:49:30 so there should be a little more flexibility there 17:49:47 yeah, client code is released independently 17:49:56 anyway, on the technical aspects 17:50:16 Kanzhe_ s3wong: any blockers? 17:50:37 SumitNaiksatam: we will meet later today for initial integration. 17:50:37 anything we need to discuss in this meeting, or any course corrections we had to make? 17:50:44 we will know then. :-) 17:50:44 Kanzhe_: ok good to know 17:50:52 SumitNaiksatam: my patch will depend on Kanzhe_ 's, so technically that is a blocker :-) 17:51:15 s3wong: :-) 17:51:43 marios had the vpnaas patch in place 17:52:08 so i am assuming you are coordinating with him? 17:52:37 SumitNaiksatam: marios: yes, we will 17:53:01 s3wong: you have the link to your WIP patch? 17:53:24 #link https://review.openstack.org/#/c/113975/ 17:53:29 and it would be helpful if you can update the wiki page: #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:53:38 SumitNaiksatam: sure 17:53:52 s3wong: Kanzhe_: thanks 17:54:03 any questions for s3wong, Kanzhe_ ? 17:55:12 #topic Service Chaining 17:55:19 songole: hi 17:55:27 SumitNaiksatam: hello 17:55:35 songole: updates? 17:55:43 i believe you have the CLI patch as well 17:55:44 We are making progress on the implementation 17:56:09 SumitNaiksatam: i had that question on direction at last meeting 17:56:11 songole: links to the patches? 17:56:13 I will be uploading patches 17:56:29 https://review.openstack.org/#/c/113737/ 17:56:41 https://review.openstack.org/#/c/113738/ 17:56:58 2nd link is CLI patch 17:57:11 songole: thanks! 17:57:24 can you update the wiki page: #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:57:32 ok 17:57:38 LouisF: sorry go ahead 17:58:36 there is a list of services but the order is not ambiguous 17:58:50 remove not^ 17:59:10 LouisF: you mean the order is ambigous? 17:59:17 SumitNaiksatam: yes 17:59:35 LouisF: is this in the context of the return traffic? 17:59:51 SumitNaiksatam: yes 18:00:24 my comment in the most recent patch describes a solution 18:00:25 LouisF: for Juno we are keeping it simple 18:00:39 LouisF: the order will be reversed for return traffic 18:00:44 LouisF: my understanding from the reading the spec and the comments was that there is only one order 18:01:19 the order is specified but with respect to what? 18:01:31 #link https://review.openstack.org/#/c/93524 18:01:42 SumitNaiksatam: I have given similar comments before and raise this in a previous meeting and there is an action item for this. 18:02:00 cathy_: i thought that comment was responded to in the spec 18:02:07 The order of the services application is specified explicitly in the spec. 18:02:12 no AFAIK 18:02:27 cathy_: ok so i might be confusing the responses 18:02:29 SumitNaiksatam, i forgot to do that 18:02:36 Let me descirbe the problem here again 18:02:41 hemanthravi: ah the action item was for hemanthravi :-) 18:03:02 the order of the services is the reverse order for outgoing traffic 18:03:12 songole: can you point to the line in the spec which mentions order clarification (just for the benefit of everyone here)? 18:03:24 hemanthravi: line number in spec? 18:03:44 SumitNaiksatam: line 207 208 mention ingress / egress traffic but they are undefined 18:04:05 162 18:04:06 LouisF: correct :) 18:04:07 LouisF: ah yes, the example 18:04:33 The service chain API specifies sequence of the service functions, eg. FW and IPS, Then it specifies a neutorn port for it. The neutron port is between a subnet and a router, so the quesiton is 18:04:34 hemanthravi: thanks, yeah 161 and 162 18:04:35 LouisF: The example states the exact order. 18:04:37 SumitNaiksatam: yes 18:05:14 mandeep: yes there is an order but ingress/egress is undefined 18:05:17 LouisF: Lines 181-184 18:05:27 is the sequnce "subnet, fw, ips, router" or "router, fw, ips, subnet" 18:05:30 ? 18:06:06 cathy_: What is subnet in this context? A service? 18:06:39 cathy_: See lines 181-184 18:06:40 That is the example in your spec, a neutorn port between a subnet and a router 18:06:47 hmm 18:06:49 the subnet is a sub network 18:06:59 Why is that in the service chain? 18:07:12 It is not a service 18:07:20 so I see the spec and it is very clear 18:07:30 regXboi: Thanks 18:07:41 but I'm not really happy about a service chain *requiring* mirror image on return traffic 18:07:52 mandeep: could you refer to the example in your spec about the neutron port? 18:07:57 I would have preferred that to be a parameter of the chain itself 18:08:08 regXboi: This was for first stage of implementation (Juno) 18:08:25 mandeep: is there a blue print on loosening that up? 18:08:37 regXboi: In future, we canallow different orders, but I wanted to harmonize that with traffic steering and hence avoided gerring into that now 18:08:48 'getting' 18:08:59 mandeep: I liked gerriting :) 18:09:09 regXboi: :-) 18:09:38 cathy_: I did not understand your question. 18:09:47 regXboi: ;-) 18:09:57 mandeep: no really. Ok, let me try again 18:10:08 we have an underlying implementation that already allows different orders - hence my question 18:10:14 the neutorn port is between an externale network and a router 18:10:16 or not question - comment 18:10:31 cathy_: i believe the port is on a network 18:10:47 i mean all “ports” are on a network 18:10:51 mandeep: the direction traffic is not defined - the example imples the N1 - > E1 is egress - right? 18:10:51 what is the sequence: "extenral network, FW, IPS, router" or "router, FW, IPS, external network"? 18:11:00 regXboi: I agree that it is a nice feature to have, particularly for interoperation with NFV 18:11:09 port is scoped by network, but if you look at the "device_owner" it's the router 18:11:34 regXboi: true 18:11:34 regXboi: But I was worried that if we added it now, it might need to get updated when we have TS integrated 18:11:34 regXboi: I already gave such comments twice before in the spec and raised it in a previous meeting 18:11:47 LouisF, that's correct 18:11:53 mandeep: point taken 18:12:11 regXboi: So I created a simpler spec for Juno, which can always evolve later if we need more control. 18:12:59 ok, so I think LouisF and cathy_ are asking the same thing, just in different ways 18:13:02 cathy_: I will try to address that in an email 18:13:10 hemanthravi: so between any two networks the direction is undefined - right? 18:13:29 mandeep, on lines 207/28 for the chain [FW, LB] is the sequence correct or should it be reversed 18:13:40 that should be 208 18:13:42 so is the difference in understanding with respect to the implicit convention (currently) versus explicit for specifying directions? 18:13:55 SumitNaiksatam: it looks like it 18:14:05 mandeep: Could you just provide an answer to my simple example? That will help calrify my simple question:-) 18:14:35 regXboi: okay, when we reviewed the spec it seemed that those concerns were addressed in the spec and was made explicit, but perhaps not as clear 18:14:52 cathy_: I believe the problem is in the question, so the example will probably not address it. 18:15:04 I'd say the implicit convention is that ingress is from network through port and egress is through port to network (based on the example) 18:15:21 mandeep: just for my example, could you let us know what is the sequence? 18:15:28 hemanthravi: it is correct 18:15:42 I think existing API is ambigous about that 18:15:43 SumitNaiksatam: so convention internal network to external net = egress direction? 18:16:04 cathy_: The error is that subnet is not a service and you are confusing data-path with service order 18:16:13 LouisF: how did you get to that? 18:16:31 regXboi: based on the example 18:16:40 I am not saying a subnet is a service. 18:16:44 It is never a service 18:16:48 I don't see where internal network shows up in the example 18:16:57 I see external network, router and port 18:17:12 cathy_: i believe what you are saying is the traffic originating on the internal network/subnet? 18:17:16 LouisF: See lines 204-209 18:17:17 let me restate that :) 18:17:44 regXboi: 177 - 179 18:17:45 yes, I see that the example talks about internal networks, but they are only window dressing and don't really matter 18:17:48 SumitNaiksatam: Let me tyr again. I am using the example given in the service chain spec. 18:18:11 cathy_: sure 18:18:23 cathy_: Line numbers? 18:18:32 in this eg, the chain [FW, LB] is between ext-net and N1/N2 18:19:11 How about this? I am going to send an email to the alias 18:19:13 cathy_: And the order there is specified on lines 204-209 exactly 18:19:28 cathy_: OK 18:19:46 * regXboi wonders if he's helping or not 18:20:11 * mandeep is wondering the same thing 18:20:31 * regXboi wonders if mandeep is wondering about self or about regXboi :) 18:20:56 * mandeep about myself ;-) 18:21:17 * regXboi quotes "join the club, we've got jackets" 18:22:03 ok lets park this for now 18:22:35 cathy_: it helps if you explain your implementation briefly as well in the mail. 18:22:37 i think mandeep songole hemanthravi feel that this is clarified in the spec, but its not clear to cathy_ and LouisF 18:22:44 regXboi: I see your reply "I'd say the implicit convention is that ingress is from network through port and egress is through port to network (based on the example)" 18:22:50 mandeep: it would help if there was text stating the convention for traffic direction 18:22:53 so lets follow up to clarify that 18:22:56 That is my question 18:23:27 #action SumitNaiksatam to reach out to cathy_ LouisF mandeep songole hemanthravi to clarify on the spec 18:23:32 I think it is better to make it explict instead of guessing the "implicit" 18:23:36 The spec says - On port P1: FW->LB->R1 for ingress traffic 18:23:52 R1->LB->FW for egress traffic. 18:24:12 mandeep: yes, and that makes the implicit convention that I stated above 18:24:13 The Port, the direction, the order are all exactly specified 18:24:28 hence my confusion on what is ambigious? 18:24:45 that is why I am not able to parse the question 18:24:49 mandeep: okay lets circle back on that 18:24:55 Today Louis and I have the question on the "implicit", tomorrow other people might have same questions or needs to guess the "implicit". That is my whole purpose of raining this quesiton. Could we make it "explicit"? 18:25:18 cathy_: LouisF: lets circle back today itself, sounds okay? 18:25:24 would it be less confusing to say P1->FW->LB and LB->FW->P1 18:25:38 hemanthravi: I disagree 18:26:05 okay, i think we have to yield to a couple of other sub-topics 18:26:10 mandeep: +1 18:26:16 #topic Traffic Steering 18:26:16 mandeep: that is in the example, would better if added to line 125, 146 18:26:18 SumitNaiksatam: +2 :) 18:26:19 cgoncalves: hi 18:26:26 i know we are not pursuing this for Juno 18:26:44 but any quick updates? 18:26:54 or any feedback you need from the team? 18:28:19 perhaps cgoncalves is not around 18:28:26 #topic Tap 18:28:34 anil_rao: vinay_yadhav: here? 18:28:34 Hi 18:28:42 Hi 18:28:53 We will put up an updated version of the spec this week 18:28:57 vinay_yadhav anil_rao hi, sorry for making you wait for two meetings for this ;-( 18:29:04 vinay_yadhav: ok great 18:29:23 with some changes clarifiing some question 18:29:49 vinay_yadhav: thats good, and perhaps an email to the -dev mailing list will draw attention to this topic 18:30:06 we are also checking up on implementation parts of the spec 18:30:13 sumit: sure 18:30:20 vinay_yadhav: oh good 18:30:27 vinay_yadhav: we still have the WIP patch? 18:30:45 of the code u mean 18:30:50 vinay_yadhav: yeah 18:30:59 sumit: we have not put it up 18:31:06 but would like to do it 18:31:13 vinay_yadhav: okay whenever you are ready 18:31:19 vinay_yadhav: anil_rao: thanks for the update 18:31:28 #topic Open Discussion 18:31:31 we have hit the hour 18:32:14 so last week some of the cores mentioned in this meeting that we should reconsider the work here, based on priorities, and in the context of the “incubator” proposal 18:33:10 given that the direction came pretty late in the cycle, my understanding here is that the team at least wants to get a shot at the patches in J3, and hence we will try to meet the FPF deadline 18:33:10 SumitNaiksatam: do you know which BP under this umbrella will go to J release? 18:33:26 if we dont meet that we are obviously out 18:33:31 cathy_: good question :-) 18:33:33 SumitNaiksatam: any more discussion on this (within the cores)? service insertion got a lot of heat last week 18:33:56 cathy_: that said once we have a working implementation, we can decide where to go with it 18:34:09 cathy_: so as a team, we just got to keep working together 18:34:21 SumitNaiksatam: sure 18:34:26 IMHO it does not matter whether its the main repo or not 18:34:34 SumitNaiksatam: +1 18:34:41 as long as we can get the right implementation in, and have some users use it 18:35:40 in general i think it was already suggested in the past that adv services should be a separate service/project 18:35:51 so this might evolve in that direction, who knows 18:36:24 i believe our mission in this team was to have clean interfaces defined in neutron to be able to facilitate the integration of services 18:36:41 most of what we have discussed today is towards that end 18:36:50 i dont think any that has changed, right? 18:37:15 SumitNaiksatam: +1 18:37:43 SumitNaiksatam: +1 without that not sure how things can be even moved out 18:37:47 SridarK: +1 18:37:58 ok we are well over 18:37:59 SumitNaiksatam: +1 18:38:03 any other parting thoughts? 18:38:48 i am having a bad connection again 18:38:58 thanks all for joining 18:39:11 #endmeeting