18:33:46 #startmeeting Networking FWaaS 18:33:47 hi all 18:33:48 Meeting started Wed Nov 26 18:33:46 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:33:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:33:50 SumitNaiksatam: :-) 18:33:51 The meeting name has been set to 'networking_fwaas' 18:33:53 vishwana_: hi 18:34:06 SridarK_: Hi 18:34:18 #announce SPD: Monday 12-8-2014 SAD: Monday 12-15-2014 18:34:22 just retierating 18:34:28 *reiterating 18:35:07 SumitNaiksatam: yes the pressure :-( 18:35:16 any other announcements anyone wants to share? 18:36:10 ok moving on 18:36:13 #topic Bugs 18:36:16 hi 18:36:35 Swami: hi 18:36:40 hello swami 18:36:48 #link https://bugs.launchpad.net/openstack-manuals/+bug/1346986 18:36:52 thankfully seems like nothing critical/high has showed up 18:36:54 oops sorry 18:37:03 Swami: hi, thanks for joining 18:37:08 SumitNaiksatam: yes nothing new 18:37:17 Swami: we will get to your email on E-W in just a bit 18:37:24 SridarK_: ok cool 18:37:45 we are still delinquent on: https://review.openstack.org/#/c/104132/ 18:37:58 lets review this at the earliest 18:38:36 SumitNaiksatam: no worries 18:38:41 SumitNaiksatam: yes the client one will do that 18:38:54 SridarK_: thanks 18:39:05 badveli: anything else on your radar on the bugs front? 18:39:25 Nothing as i could see 18:40:02 badveli: okay, and you are still tracking the discussion around: https://bugs.launchpad.net/neutron/+bug/1386543 and https://bugs.launchpad.net/neutron/+bug/1335375, right? 18:40:09 yes 18:40:40 badveli: okay 18:40:44 #topic Docs 18:40:53 SridarK_: go ahead 18:41:00 #link https://bugs.launchpad.net/openstack-manuals/+bug/1346986 18:41:22 i noticed your post, thanks! 18:41:34 just in the nick of time ;-P 18:41:47 i think there is one section there - can one post a review for just our section ? 18:42:08 SumitNaiksatam: :-) life seems to be "nick of time" all the time :-) 18:42:18 SridarK_: :-) 18:42:42 SridarK_: i think that should be good, perhaps we can send an email to ann gentle to check with her as to what is the process? 18:42:51 SumitNaiksatam: ok will do 18:42:59 SridarK_: great, thanks 18:43:05 the other one: 18:43:08 #link https://bugs.launchpad.net/openstack-manuals/+bug/1373674 18:43:17 is fixed but someone already 18:43:40 sweet! 18:44:14 documentation seems to be okay on that 18:44:28 it would be good for us to be in the loop on these things 18:44:33 SumitNaiksatam: yes it was a quick clarification 18:44:50 SumitNaiksatam: yes - it seems the only way is to poll for these 18:45:03 SridarK_: yeah :-( 18:45:06 Swami: so on the DVR related documentation, your suggestion is that we wait and watch? 18:46:10 hi 18:46:45 Yes, we will wait till they have the networking guide and we can provide the feedback there to add the services that are supported and how it is supported. 18:46:56 Swami: ok cool 18:47:02 I am working with Edgar, Matt Kassawara and Elke Vorghies 18:47:09 Swami: is there any meeting that we should be attending? 18:47:25 Swami: i recall references during the last neutron meeting 18:47:33 There is a meeting on Friday's from 9.00a.m to 10.a.m. 18:47:50 At this time, I will take care, and if needed I will let you know. 18:47:51 Swami: woudl appreciate if you get SridarK_ and me plugged into that meeting 18:48:04 Ok, it is a google hangout meeting 18:48:09 Swami: okay thanks 18:48:14 I will send you the link. 18:48:19 Swami: thanks 18:48:39 Swami: great! but hangout is wierd for this kind of a thing! 18:48:54 Swami: thanks Swami for that input 18:49:01 anything else on docs? 18:49:06 that's what they do right now 18:49:20 Swami: okay 18:49:28 moving on 18:50:45 #topic FWaaS team mission and charter 18:51:02 https://wiki.openstack.org/wiki/NeutronSubteamCharters#FWaaS_Team 18:51:26 we discussed this over emails 18:51:34 bringing it up here in case anyone missed it 18:51:55 currently this does not mention the DVR E-W 18:52:07 I have mentioned in the DVR charter. 18:52:08 we also need to append to the specs list once we post those 18:52:28 Swami: great, nice to have cross team reinforcement 18:53:02 anything more to discuss here? 18:53:26 we will touch on the topic of services’ split in a bit 18:53:43 ok next topic 18:53:53 #topic Kilo blueprints 18:54:01 related to our charter 18:54:26 Service groups and objects: #link https://review.openstack.org/#/c/131596 18:54:38 badveli: thanks for the updates 18:54:47 thanks sumit 18:54:50 badveli: sorry i havent had a chance to get back to it 18:54:56 is glebo here? 18:54:57 no problem, thanks 18:55:14 looks like not here 18:55:24 thanks giving 18:55:31 week 18:55:44 badveli: i understand, i did expect a light attendance today 18:56:12 i wanted to check if he got any response to the emails he had sent to mestery or markmcclain regarding the service groups 18:56:16 do we need any inputs from him? 18:56:24 badveli: i will go thru once more and put a +1 18:56:35 i did not see a response, but just checking 18:56:42 thanks sridark, on that front, did not receive anything 18:56:51 SridarK_: thanks, i need to read through again as well 18:57:32 SridarK_: any update on the router/port based insertion? 18:57:56 SumitNaiksatam: will put this together real soon 18:58:09 SridarK_: okay thanks 18:58:15 on router_id - we keep this optional 18:58:33 SridarK_: did we get any response from arvind, brian or glebo on the use cases? 18:58:51 SumitNaiksatam: no 18:59:00 SumitNaiksatam: let me send a reminder 18:59:33 SridarK_: okay 18:59:40 SumitNaiksatam: based on what we have in our various discussions - i think ports seems more palatable 19:00:01 SridarK_: okay, what does the rest of the team think about this? 19:00:17 SumitNaiksatam: the other thing is that this will probab need to go as an attribute of the firewall extension 19:00:30 SridarK_: okay 19:00:36 sridark, does it seem odd to ask the user to give the port 19:00:37 SumitNaiksatam: given that extensions are being clamped down 19:00:59 may be we are asking more from user 19:01:09 badveli: the thought was that the port is a representation of the subnet "behind" it 19:01:26 badveli: and we are add a fw for that subnet 19:01:39 badveli: did u have something else in mind ? 19:02:47 currently i do not have much, i need to think more 19:03:07 badveli: ok - do send an email 19:03:20 i am not sure if the customers really would like anything like this 19:03:46 badveli: we need to go away from the all routers all ports model 19:03:48 thanks sridark, will let you know 19:04:01 yes that would be ideal 19:04:13 badveli: based on the feedback from the summit 19:04:46 sridark, my only thaught was when this happens would be a undo the one that we had done 19:04:55 badveli: if we want to fw a particular subnet for ex engineering 19:05:07 from the configuration 19:05:08 badveli: router port provides a good abstraction 19:05:08 19:06:00 badveli: sorry don't understand 19:06:45 SridarK_: we had discussed one option of having router_id and router_ports, both as optional attributes 19:06:46 sridark ideally we do not want to tie up to ports / routers 19:07:15 sumit, so this will be optional parameters 19:07:50 SumitNaiksatam: yes by specifying the router-id and the ports associated 19:07:59 SumitNaiksatam: perhaps a subset or all 19:08:04 badveli: its an option to have these as optional parameters :-) 19:08:14 SridarK_: okay 19:08:22 okay so lets wait for SridarK_’s spec 19:08:36 SumitNaiksatam: :-) yes all are optional 19:08:47 good one 19:09:17 SumitNaiksatam: but what is ur thought on attribute to firewall extension 19:09:30 SumitNaiksatam: i guess that would be okay ? 19:10:07 SridarK_: you mean an extension to the firewall resource, or add an attribute to the current firewall resource? 19:10:21 SumitNaiksatam: attribute to the firewall resource 19:10:42 SridarK_: perhaps that might be the more palatable option 19:10:58 SumitNaiksatam: the extension to firewall resource may have some acceptance issues 19:11:14 SridarK_: the attribute extension mechanism is more flexible in that it does not pollute the base model, but it has its downside 19:11:20 SridarK_: yeah 19:11:34 SumitNaiksatam: perhaps we can put that as an Alternative 19:11:44 SridarK_: perfect 19:12:06 i would also like to hear the opinion of the rest of the team on this 19:12:08 SumitNaiksatam: ok thx 19:12:24 so i think looking at the spec people can provide an informed opinion 19:12:27 ok moving on 19:12:55 we should also be discussing pcm’s patch of the L3 agent refactor 19:13:10 #link https://review.openstack.org/#/c/135392/ 19:13:57 i believe pcm is on vacation, we can probably have this discussion in this meeting if he is around in the next week 19:14:26 SumitNaiksatam: yes pcm is out 19:14:53 SridarK_: ok thanks 19:14:54 #topic FWaaS for E-W traffic scenario with DVR 19:15:19 Swami just sent some detailed ideas, which i have shared with the rest of the team 19:15:30 #link https://docs.google.com/document/d/11Gp62Yfyi1WH6yM6E_308OB4CC9A6xhxKZJ8B5jOwLc/edit 19:15:33 perhaps we can take a quick min to peruse the diagrams 19:15:39 Swami: thanks! 19:16:04 Just to give a brief summary of the two options that we discussed in Paris. 19:16:38 thanks swami, will take a look 19:16:56 Option 1: is to have a bump in the wire scenario. To add a bridge in between the br-int and br-tun and track all the traffic incoming and outgoing. Apply the rules there. 19:17:27 Option 2: Instead of applying firewall rules in multiple places for East-West and north south, let us apply it in the "qr" namespace. 19:18:21 But when the return traffic hits the br-int, if possible we can force the traffic to get into the router, like a loopback interface and apply the rules there. I am not sure if it is viable and has any issues. But it has to be investigated from the flow rules and from the routers perspective. 19:18:53 Swami: does applying in the “qr” namespace introduce a single choke point? 19:19:15 Swami: btw, thanks for the summary (was about to ask)! 19:19:53 It will not be a single choke point, because you are also applying all the compute nodes. But it will be single choke point for that particular host. 19:20:42 Swami: So the point is that the “qr” namespace itself is distributed since it manifests on all the hosts? 19:20:58 Yes. 19:21:08 swami: adding a bridge 19:21:27 badveli: yes 19:21:45 add forcing the traffic towards it 19:21:46 Swami: we will do the "return traffic thru qr" if we have fw configured ? 19:22:03 how do we do that? 19:22:03 19:22:06 adding a bridge will be similar to the security groups where you apply all the rules in a bridge and then attach it with the veth pairs. 19:22:27 Swami: in that case, i believe the advantage with the second method is that from a fwaas perspective we only have to deal with the “qr” namespace, always (regardless of E-W or N-S traffic)? 19:22:41 thanks swami 19:22:56 SridarK_: Yes, if firewall is configured for the tenant we force the traffic to send it back to the "qr" and so all your rules will be applied in a single place. 19:23:41 Swami: okay i think you answered my question as well with that response 19:23:42 Swami: ok that way we will take a sub-optimal path only then 19:24:08 Swami: defn looks like a viable option but need to think some more 19:24:17 good discussion 19:24:27 Yes we don't need to decide today. But give it a thought. 19:24:44 Swami: thanks for the timely interjection with this proposal :-) 19:24:46 I have also asked "Vivek" to check on the flow rules and any impact for option 2. 19:25:08 Whichever option is viable and riskless we can go on that direction. 19:25:19 lets circle back on the email thread, and have a more definitive discussion in the next meeting 19:25:24 Swami: thanks 19:25:33 5 mins left 19:25:36 Sorry I was supposed to send you out this picture after the paris trip, but I was on Jet lag for a week. 19:25:43 yes, thanks sumit 19:25:46 Swami: np 19:25:49 Swami: thanks 19:25:49 #topic Vendor drivers 19:25:59 vishwana_: you posted your spec, right? 19:26:02 link? 19:26:27 yes, I did, thanks to you and SridarK for initial review and comments 19:26:49 vishwana_: np, just procedural nits 19:27:07 https://review.openstack.org/#/c/136953/ 19:27:19 I am yet to address your review comments 19:27:28 vishwana_: thanks for the link 19:27:39 What is the Ipv6 impact requirement? 19:27:39 any other vendor related bps posted or in the pipeline? 19:27:49 SumitNaiksatam: #link https://review.openstack.org/#/c/129836/ 19:27:56 vishwana_: i am not completely sure on this 19:28:08 vishwana_: however there was a thread in the -dev ML on this 19:28:19 vishwana_: perhaps you can post your question there 19:28:22 Any guidance on how to approach that would be valuable 19:28:32 SumitNaiksatam: Thanks 19:28:36 vishwana_: i believe in your case there should not be any IPv6 impact since this is vendor specific 19:28:49 I see 19:28:53 SridarK_: thanks, did not notice that one 19:29:14 vishwana_: again, my comment was more procedural ;-) 19:29:16 SumitNaiksatam: no worries - it has extension written all over it :-) 19:29:25 SridarK_: :-) 19:29:30 #topic Open Discussion 19:29:35 SumitNaiksatam :understaood 19:29:35 we have one minute 19:29:42 one quick one - #link https://review.openstack.org/#/c/136835/ 19:29:48 services’ split ^^^ 19:30:08 this is shaping up in a different way from what we discussed in the paris summit 19:30:18 SumitNaiksatam: +1 :-( 19:30:22 at any rate i have volunteered to help out on the fwaas side of things 19:30:32 SumitNaiksatam: i can also help 19:30:41 others should read this spec carefully and express their opinion as well 19:30:44 SridarK_: great 19:30:52 ok, lets call it a wrap 19:30:59 happy thanksgiving to all! 19:30:59 Ok bye all 19:31:02 will take a look at it. 19:31:03 bye 19:31:05 bye 19:31:06 bye all 19:31:06 Happy Thanks giving 19:31:14 bye, happy thanksgiving 19:31:17 #endmeeting