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