18:01:15 #startmeeting Networking FWaaS 18:01:16 Meeting started Wed Oct 16 18:01:15 2013 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:19 The meeting name has been set to 'networking_fwaas' 18:01:22 SumitNaiksatam: Hi 18:01:32 Welcome to the first IRC Firewall as a Service meeting! :-) 18:01:50 if you are here for the FWaaS meeting say Hi! 18:02:02 just want to get a feel for who is here 18:02:26 hi 18:02:43 lets give it a couple of more minutes 18:02:47 Kanzhe: hi! 18:02:49 ok 18:03:46 Hi 18:03:52 garyduan: hi 18:04:00 just waiting for any more folks to join 18:04:14 is this the first meeting of a regular series? 18:04:37 salv-orlando: probably regular before the summit 18:04:46 ok, thanks 18:04:49 salv-orlando: after that we can decide the frequency 18:05:05 salv-orlando: try to avoid too many meetings :-) 18:05:26 ok so, we are 5 mins past 18:05:30 lets get started 18:05:39 we have had several face-to-face meetings in the bay area before, and its nice to reach out to even more people now 18:05:52 today's meeting is to prep for the Icehouse summit discussions/sessions 18:06:02 we have some activity going on the etherpad: 18:06:09 https://etherpad.openstack.org/p/icehouse-neutron-fwaas 18:06:23 will be back online in couple of mins 18:06:42 i propose using these pre-summit meetings to gather requirements and prioritize them 18:07:20 #topic tempest 18:07:43 since we as a Neutron team want to emphasize on testing lets talk about this a bit first 18:07:43 this is an open area 18:07:54 (a) we need to decide what tests to add 18:08:00 (b) who/how will do it? 18:08:18 not sure if any folks from tempest/testing are here 18:08:45 right now we don't have tempest coverage for FWaaS 18:09:24 ok seems like an obvious thing to do :-) 18:09:42 any volunteers? 18:10:20 looks like we will have to talk to the neutron/tempest gurus on this 18:10:44 i believe there is going to be a common session for Neutron/tempest 18:10:59 moving on 18:11:23 #topic service_type framework and insertion 18:11:55 I have been talking with tempest people, but I reckon we need also somebody from the team who contributed fw code 18:12:06 salv-orlando: agree 18:12:26 once we can decide what is the minimal set of steps to start with, we can get on it 18:12:27 load balancing and vpn contributors also pushed API tests into tempest, which is a good start 18:12:38 the API tests are the minimal set of tests 18:12:42 ok, we can follow that lead 18:13:00 and then you can implement scenario tests which also validate the agent correctly enforces the rule 18:13:02 salv-orlando: can we sync up offline to exchange how the team can go about this? 18:13:12 sure 18:13:19 salv-orlando: thanks 18:13:33 #action SumitNaiksatam to sync with salv-orlando on tempest 18:13:41 For service type framework, currently in havana, we only have one plugin per service with multiple driver mode, right? 18:13:59 garyduan: yes 18:14:13 like LBaaS (and VPNaaS currently in review) we should be extending support for FWaaS for service_type framework 18:14:29 for FWaaS, is this the path we plan to do? 18:14:32 i have a place holder bp for this: 18:14:32 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-service-types-in 18:14:56 there is a parallel discussion going on about insertion 18:15:15 as the discussion converges we can add support for the router level insertion 18:15:34 so that we don't have to apply the reference implementation firewall to all the routres 18:15:49 like we are currently doing 18:15:52 Do we plan to support multi-service, multi-plugin mode? 18:16:25 garyduan: i think that is a question for the "advance service common requirements" dicussion 18:16:41 garyduan: we will have follow up meetings for that, we can bring this up during that time 18:16:49 Sure 18:17:05 garyduan: as for fwaas, it will be expressed as a an independent service in the service_provider configuration 18:17:26 We would also want to be able deploy a FW as L3 or L2 so again a usecase for the service insertion discussion 18:17:51 SridarK: +1. good point. 18:18:16 SridarK Kanzhe : agree, hence having the insertion/chaining discussion in parallel 18:18:26 and also with the VPN and LBaaS team 18:18:33 hoping to converge :-) 18:18:50 ok next topic 18:18:56 #topic revisit firewall to firewall_policy association 18:19:14 this was being discussed as the "commit operation" patch before 18:19:23 it did not make it into H 18:19:39 you can check out the bp: 18:19:49 #link https://blueprints.launchpad.net/neutron/+spec/neutron-fwaas-explicit-commit 18:20:05 and the referenced patch to see the discussion on this 18:20:40 garyduan: i believe you were referring to startup and running config 18:20:41 should we really allow policy sharing? 18:20:59 beyounn: we can discuss this 18:21:25 beyounn: do you mean more than one firewall to use the same firewall_policy? 18:21:32 I think here "sharing" might be intended as reuse, If I'm not wrong 18:21:34 yes 18:21:40 I also think if there is no policy sharing, there would be no confusion 18:21:40 and inside the same tenant 18:21:41 salv-orlando: yes 18:22:41 User has the choice to share or not. Sumit's proposal is to enable both. 18:22:55 there is a use case with a provider enforcing some set of rules to be used by tenants 18:23:16 and the tenants can add to that with tenant specific rules 18:23:19 beyounn garyduan: so the suggestion is to make the firewall to firewall_policy association 1:1? 18:23:33 this couples with zone and other fw objects 18:23:45 if we add them into fw rules 18:23:52 For the use cases where policy sharing makes sense, it would have to be cloned and then somehow synchronize multiple policies. 18:24:13 garyduan: zone is a separate topic (also on the agenda :-) lets hold a little bit) 18:24:21 in most cases, the rule/policy is unlikely shareable 18:24:38 garyduan: that is not always the case 18:25:30 garyduan: if we have support for dynamic objects, that will make it less specific and more shareable 18:25:41 I agree there are cases sharing is prefered 18:26:17 the use cases, for example that we heard from the paypal guys, they said that they create policy once 18:26:25 and then apply it in several places 18:26:48 so sharing was felt necessary, both within tenant, and across tenants 18:27:04 Sumit, that maybe for the chaining case 18:27:29 in general, it was felt that have to create a new policy for every firewall is very cumbersome and unwieldy 18:27:43 note that the policy can have several thousands of rules 18:27:57 beyounn: sorry, i did not get the context of the chain 18:28:59 Sumit, can paypal guy give some detail? 18:29:21 its actually documented in the first fwaas specification 18:29:59 #link https://docs.google.com/document/d/1PJaKvsX2MzMRlLGfR0fBkrMraHYF0flvl0sqyZ704tA/edit?usp=drive_web 18:30:49 beyounn: Due to Audit and compliance reasons too, our customer inputs have also been along the same lines - regarding making any changes to policies 18:31:15 ok 18:32:11 i think Kanzhe pointed out somewhere earlier in this thread - the team felt that it was important to be able to support one firewall policy to many firewalls association 18:32:29 it still allows 1:1 association if required 18:32:57 at any rate, beyounn, garyduan do you want to take a look at the blueprint and the patch, and provide your suggestions? 18:33:09 we tried to find some middle ground 18:33:29 there are some concerns around that solution and we need to resolve those 18:33:42 Sumit, sure 18:33:49 beyounn: thanks 18:33:51 next topic 18:34:02 #topic zones 18:34:04 I read the patch, the commit action is effectively like a clone in the database 18:34:25 garyduan: not a clone, its more like running config 18:34:31 garyduan: we can discuss as follow up 18:34:46 so zones 18:34:49 SumitNaiksatam: Zones is of definite interest for us as well 18:34:49 SumitNaiksatam: thanks 18:35:08 SridarK garyduan: yes this is of interest to lots of people 18:35:31 We definitely want to get the support in 18:35:38 the problem is that everyone defines it in a different way (well not everyone, but there are different opinions on this) 18:35:46 yes as u had mentioned 18:35:54 so our first task will be to find out a crisp definition 18:36:00 SridarK: agree 18:36:04 we could work towards finding common ground 18:36:24 something generic enough so vendor plugins can add minimal tweaks 18:36:36 most firewall vendors seem to define these in terms of "interfaces" 18:36:46 these are interfaces on their network devices 18:36:48 we will probab also have dependencies on Service insertions work 18:37:07 SridarK: good point 18:37:09 yes interfaces seem to be fairly common ground 18:37:10 agree 18:37:35 SridarK: true, but we don't model switch interfaces in neutron 18:37:49 we have the virtual port absrtaction 18:38:38 SumitNaiksatam: we will need to see how we can map that to some notion of a logical i/f inside the vendor service instance 18:38:57 is that something to think about 18:39:26 ok, so in neutron speak are these virtual ports for a tenant? 18:39:50 SumitNaiksatam: Sorry, I didn't get the virtual port part? 18:40:06 garyduan: i was referring to the neutron port resource 18:40:21 SumitNaiksatam: ok 18:40:30 garyduan SridarK: i am not making a proposal here, just thinking aloud 18:40:37 same here 18:40:57 unfortunately we always go in circles on this 18:41:02 :-) 18:41:10 zone is a group of interfaces 18:41:18 agree 18:41:26 and VR is a group of zones 18:41:38 garyduan, beyounn: ok 18:41:47 will there always be a 1:1 mapping between neutron logic port and FW interfaces? 18:41:48 ok 18:41:51 but are those physical interfaces? 18:42:05 Kanzhe: good point 18:42:05 Kanzhe, with vlan, it could be different 18:42:57 FW normally map logic interfaces, and multple logic interfaces can anchr on same VNIC 18:43:20 From the insertion perspective, I would say yes, but not quite sure with physical devices. Like SridarK mentioned, it depends on the insertion proposal. 18:44:32 Kanzhe, what about L3 firewall? 18:44:47 beyounn: I would think a logical port corresponds to a vlan+vnic. 18:45:05 let's start a thread on ML to brainstorm 18:45:05 Kanzhe: right, then it is not1:1 18:45:28 #action SumitNaiksatam send message to openstack-dev to brainstorm on zones 18:46:00 beyounn Kanzhe SridarK garyduan: sound okay? 18:46:18 OK. 18:46:20 beyounn: are u local bay area ? 18:46:25 sure 18:46:32 I have to understand more about service insertion vs. zone 18:46:32 sridark:yes 18:46:52 Sumit, it would be great if we can have another face to face 18:46:54 we could even atleast get some basic thrashing btwn some of us in a face 2 face 18:47:08 Sridark, agree 18:47:18 beyounn: yes sure 18:47:19 hopefully we can come to a common model 18:47:40 we can then ofcourse get some broader consensus 18:47:47 ok so (lots) more discussion needed :-) 18:47:52 next topic 18:47:54 #topic hit counts/counters 18:48:23 this is very important from an operations perspectice 18:48:35 also, helps debugging 18:48:40 lots of people have suggested this 18:49:08 SumitNaiksatam: agree 18:49:12 we should be able to provide a hit counts for the rules 18:50:02 this also another place where having the running_config for the rules might make sense 18:50:19 so the hit counts will be for the rules which are currently in the running_config 18:50:54 running config - Sumit u give away where u worked b4 :-) 18:51:01 hahaha 18:51:13 for metrics, consider whether you want to retrieve them in the same API call as the rule, or with a different cole 18:51:20 cole/call 18:51:21 salv-orlando: good point 18:51:30 salv-orlando: whats your recommendation? 18:51:39 they can put quite a lot of strain on the backend, so I'd go with a different URI 18:51:56 salv-orlando: ok 18:51:58 unless you mandate drivers to always update the server-side counters, which might be bad too 18:52:23 salv-orlando: agree that should not be mandated 18:52:42 salv-orlando: perhaps a periodic sync - less accurate at the instant but will be ok overall 18:52:46 however, i do envision a UI where you see the rules and the counts next to those 18:53:03 maybe something as basic as what you see with iptables 18:53:49 also, history of hits are useful too. 18:54:05 I agree different API might be more flexible. 18:54:07 garyduan: ok, you want to drive this? :-) 18:54:34 kidding, we can decide all that later 18:55:04 ok so this seems useful in the list of priorities 18:55:19 we can revisit this, anything more to add now? 18:55:40 we are running short on time 18:55:42 next topic 18:55:43 #topic vendor drivers 18:55:58 I can currently see this: 18:56:00 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-cisco 18:56:13 Also know that vArmour has a few patches currently in review, anything else planned? 18:56:43 i am asking from the perspective of any specific requirements that vendors might have to support their drivers 18:56:59 SumitNaiksatam: yes just added - again some dependency on the services insertion discussion 18:57:10 SridarK: ok good to know 18:57:17 I believe Sonicwall is working on its driver. 18:57:30 SridarK: hopefully you will be able to convey that in the discussion 18:57:43 Kanzhe: thanks, i did not see blueprint 18:57:46 also some of the discussion on how we get the driver in - perhaps some the L3 Agent refactoring that Nachi was talking abt may play into this as well 18:57:54 #topic Summit sessions 18:58:05 We will most likely have a super session 18:58:16 so we can try to collect our thoughts in this forum 18:58:32 so far FWaaS team has worked great as a team (many thanks!!!) 18:58:40 +1 18:58:50 so i think we can try and continue this collaboration into the summit 18:59:07 2 mins left 18:59:11 #topic other topics of interest 18:59:48 we can meet the next week, same time 19:00:04 hopefully those who missed out today can also chime in 19:00:23 ok thanks much everyone for participating 19:00:29 #endmeeting