00:01:03 #startmeeting networking_fwaas 00:01:04 hoangcx I gave you sit rights on the drawing 00:01:05 Meeting started Thu Oct 15 00:01:03 2015 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:08 The meeting name has been set to 'networking_fwaas' 00:01:18 Hi 00:01:19 o/ 00:01:30 xgerman: Thanks a lot. I will check it 00:01:33 * sc68cal sighs 00:01:45 sc68cal I forgot to add some topics to the agenda 00:02:01 no worries, I'll try and run through our recap quickly and then let you take over 00:02:18 cool 00:02:25 * sc68cal is banging head against wall for making a neutron_fwaas directory in eavesdrop that he'll have to ignore forever 00:02:39 * xgerman lol 00:02:52 #topic recap actions from last meeting 00:02:57 #chair xgerman SridarK 00:02:57 Current chairs: SridarK sc68cal xgerman 00:03:06 #link http://eavesdrop.openstack.org/meetings/networking_fwaas/2015/networking_fwaas.2015-10-07-18.32.html Minutes from last meeting 00:03:12 xgerman: looks like it's all you 00:03:37 xgerman: the spotlight is on :-) 00:03:58 alreday 00:04:12 so Midccyle 00:04:29 HP can host the mid cycle in Seattle 00:04:52 I am wondering if we should start some eitherpad to vote on time/location 00:05:34 xgerman: +1, if folks want to come to the bay area, i can arrange to host as well 00:06:17 I'm +1 for SEA. Was easy for me from US East Coast 00:06:42 #link https://etherpad.openstack.org/p/fwaas_mitaka_midcyle 00:06:45 SEA is probably good for APAC too, only people who it's tough for is probably Europe 00:07:06 yeah, on that note we have trouble to fund International travel 00:07:55 doh. xgerman you are in europe aren't you? 00:08:05 nope, I am in San Diego 00:08:16 * sc68cal breathes sigh of relief 00:08:31 but Seattle is our base so easy to get to (for me) 00:08:50 given the time of the year, we stay on the west coast :-) 00:09:45 +1 00:09:50 +1 00:10:19 +1 00:10:20 for dates I am gone most of December so I would say we should aim for January/early february 00:10:33 also I think we are supposed to coordinate with armax 00:10:58 xgerman: yes 00:11:10 I talked to mugsie (I don’t recall the irc) 00:11:16 that’s him 00:11:22 Graham in real life 00:11:29 xgerman: I am hoping to get the summit out of the way first 00:11:34 k 00:11:45 but most definitely it makes sense to coordinate 00:11:59 xgerman: if you’re out December 00:12:24 well, I am out beginning 12/15 so the first few weeks might still work ;-) 00:12:25 xgerman: that means we’d need to defer the Neutron mid-cycle meetup and we typically had that in December 00:12:30 xgerman: ok 00:12:48 also I usually skip the Neutron mid cycle... 00:13:04 I've been going to them, so I think we'll have coverage there 00:13:11 cool 00:13:27 so you guys are thinking of Dublin as venue? 00:13:44 that would be LBaaS/DNSaaS joint meeting 00:13:55 FWaaS is different and dougwig said we should keep separate 00:14:21 but right now a lot of stuff is in the air... 00:14:28 so ideally you’d want these to be back-to-back? 00:14:34 or simply not conflict? 00:14:41 and spaced them out 00:14:41 ? 00:14:43 simply not conflict 00:14:55 xgerman: ok fair enough 00:15:30 noted in my list of chores 00:15:38 anything else from me? 00:15:52 nope - otherwise we are pretty self organizing 00:16:11 all hail the PTL! 00:16:16 * xgerman bows 00:16:18 xgerman: excellent 00:16:24 +1 ;-) 00:16:26 * armax blushes 00:16:50 On that note, xgerman how did prioritization go? 00:16:59 done 00:17:40 xgerman: i forget which link is for this 00:18:23 ahhh sorry - dumb thing. The bugs in launchpad 00:18:31 yep, you made a Google link 00:18:54 cool - thanks for doing that :) 00:19:29 If anyone has a bug that they think needs different priority, feel free to reach out 00:19:38 +1 00:19:46 xgerman: how about the google doc, that was the last thing 00:20:19 I complained to the corporate people and it seems I can share with people’s e-mail 00:20:46 #link https://docs.google.com/a/hpe.com/drawings/d/1eFDVOtkwG2Flt54zqZcAFnOY9cww_EgJKuIp9aPqAIs/edit?usp=sharing 00:20:58 might be worth taking and copying into an etherpad or something where we don't have to add people 00:21:11 I think that link allows to edit 00:21:22 those options just showed up today 00:21:42 hmm, I had to request access 00:21:57 xgerman: yes ^^^ same here 00:21:57 nope, then it doesn’t work :-( 00:22:00 I think maybe it's time to move it to etherpad. 00:22:03 * hoangcx just got approved about that :-) 00:22:08 just pushed that button 00:22:30 my main concern is having it publicly accessible 00:22:46 the trello board, yeah you had to get access to edit, but at least accessible publicly 00:23:32 yeah, as I said this is all still in flight of there at HP 00:23:49 should have used a non-HP Google Drawing account 00:24:19 oh. It's the _drawing_ 00:24:48 yep 00:24:55 sorry, beig stupid tonight. Though there was some other google doc 00:25:30 ok, anyway I'll hand it over to xgerman since you had a couple topics you wanted to discuss? 00:25:39 (make sure to use #topic) 00:25:50 #topic Design session 00:26:10 #link https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services 00:26:30 so we have a session on fwaas 00:27:05 lets get the DVR related discussion covered for the broader audience there 00:27:11 ^ ++ 00:27:15 + 00:27:43 But we hope to get some good discussion going before that 00:27:58 yeah 00:28:05 so it will be ideal if we can lay out some options here, perhaps that is a bit optimistic 00:28:11 but we can shoot for that 00:28:23 I chatted with jwarendt and we came up with a few things we think can be achieved in M 00:28:30 We need to know if any of the 2-stage proposals (going through router at both source and destination) will fly. Swami is supposed to write one option up. I am supposed to write another option up. 00:28:36 For DVR 00:28:52 oh, ok 00:29:06 would that work with our new port based idea? 00:29:37 mickeys:, badveli: & I had a quick sync with Swami as well to at least lay out some issues so we have some background set 00:29:40 Does not matter whether it is the router in its entirety or a router port. If it goes through the router and it is asymmetric, it breaks conntrack 00:29:55 If it is not router port, no issue with DVR 00:29:59 we were worried about that 00:30:07 conntrack... 00:30:55 I believe we either need to have a DVR mode that is symmetric, with 2-stage forwarding, or we need to change the semantics of FWaaS so that router stuff is only north-south 00:31:17 I think the later might be ok 00:31:36 mostly east-west will be between vms 00:31:38 xgerman: i am not sure if that will fit all deployments 00:31:50 That is the big question that we need answered coming out of Tokyo 00:31:52 if they are different subnets 00:31:58 yeah, there are always edge-cases :-) 00:32:14 yes that we need to flush those out 00:32:44 mickeys — that would be more an ML question with a follow up in Tokyo or vice versa 00:32:59 xgerman: were u thinking on the router port(s) aspect as a priority (ur discussion with jwarendt ^^^ ) 00:33:19 we just like ports 00:33:26 xgerman: i agree 00:33:48 hence my second bullet “Define clearly what a port is" 00:33:53 The etherpad already laid out a few options. With Swami, SridarK, badveli, trying to come up with enough detail on 2-stage forwarding so that DVR folks can say yes or no 00:34:01 #link https://etherpad.openstack.org/p/mitaka-neutron-next-adv-services 00:35:32 mickeys: if it is conditional of FWaaS being configured - i think what we have is a resonble approach 00:36:00 but we can try to close at the summit 00:36:06 ^ +1 00:36:34 one of my concerns is, define behaviors at the API level - don't let one implementation define behaviors that others can't do 00:37:00 we want it to work with DVR - obviously, but in a way where the API makes sense in all cases and for all implementations 00:37:26 yep, we might just say if you use DVR router ports are only south-west 00:37:42 so all the people who skip DVR can have east-west ;-) 00:38:01 Actually, for DVR, only policies on north/gateway ports on routers 00:38:07 Both directions 00:38:24 If we don't do 2-stage forwarding 00:38:58 ok, but as sc68cal said that shouldn’t stop us in API design... 00:39:46 mickeys: yes that was change to be done so FWaaS was not completely broken with DVR 00:39:54 in Juno 00:40:22 One option is to keep that restriction going forward, but cleaner because it will be explicitly tied to the gateway port 00:41:10 yeah, we can clearly roadmap that - so we have the restriction in M but N we might have 2-stage-forwarding... 00:42:28 getting in basic "tying to port(s)" support should be straightforward, always had that in mind even with Router Insertion 00:43:15 the FW and insertion point association are kept in a separate table, for ease of supporting different insertion models 00:45:04 yeah, so that would mean no changes to the data model 00:45:31 xgerman: yes not for the FW resource 00:45:46 keeps it less messy 00:46:37 I thought the firewall resource is where the association is kept. The policy and rules are separate. 00:46:46 mickeys: yes 00:46:59 the association with FW and Policy 00:47:20 but the association with the FW and insertion point is outside of the FW table 00:47:56 earlier the FW was pushed to all routers on that tenant - so nothing was tracked 00:48:12 the agent managed most of that 00:51:38 time check, only 10 minutes left 00:52:00 anyone have anything to add? hoangcx ? 00:52:17 one more thing 00:52:34 Please review: #link https://review.openstack.org/#/c/231246/ 00:52:44 sc68cal: Yeah. Would love change status from "Confirm" to "Triage" for the Logging API 00:52:53 Just a query to everyone: Would ICMP code based filtering be a part of FWaaS ? 00:53:04 #link https://bugs.launchpad.net/neutron/+bug/1468366 00:53:04 Launchpad bug 1468366 in neutron "RFE - Logging API for security group and firewall rules" [High,Confirmed] - Assigned to Yushiro FURUKAWA (y-furukawa-2) 00:53:23 I think it could be 00:53:23 Thanks xgerman for setting pritority 00:53:39 reedip 00:54:44 xgerman: but I guess it would require a detailed discussion bcz it would impact Usability (Client/Horizon)as well the base code 00:55:13 I see it as part of our DPI aspirations 00:55:24 xgerman +1 00:55:26 which would need those changes anyway 00:55:55 DPI ? 00:56:06 Deep Packet Inspection 00:56:12 Oh , ok... 00:57:49 sc68cal, xgerman, SridarK: We are focusing on the logging design. So it is better if the status change to "Triaged" to get more attention from others to file it, especially for upstair people. 00:58:35 hoangcx got it 00:58:39 done +done 00:58:51 sorry i was another wrong channel from morning 00:59:04 xgerman: Thank you so much :-) 00:59:18 ok, out of time... 00:59:31 #endmeeting