18:03:32 #startmeeting Networking FWaaS 18:03:33 Meeting started Wed Oct 30 18:03:32 2013 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:36 The meeting name has been set to 'networking_fwaas' 18:03:59 today's meeting is also in preparation for the Icehouse summit discussions/sessions 18:04:07 #info etherpad: https://etherpad.openstack.org/p/icehouse-neutron-fwaas 18:04:22 #topic Icehouse Summit session 18:04:33 #info link: http://icehousedesignsummit.sched.org/event/c8bf224a93d4e689ee91ffd958ae56a8 18:04:42 #info date/time: Tuesday, Nov 5th, 2:50 PM 18:05:01 btw, no FWaaS meeting in the next week or the week after (since we won't be having Neutron team meetings either), but we will start again in the following week 18:05:19 currently we are the first services' session in the Neutron agenda 18:05:32 hope we can set a good stage ;-) 18:06:13 any issues for anyone with the session time? 18:06:35 except for jet lag should be good :-) 18:06:45 SridarK: :-) 18:07:07 SridarK: get a pillow :-P 18:07:12 :-) 18:07:26 ok so on to the next topic 18:07:33 #topic zones 18:07:43 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-zones-api 18:07:54 we had more discussions on this and more input from folks 18:08:00 zones will be initially used in the source and/or destination arguments for a rule (this will 18:08:07 be later extended to firewall-rule-sets when they are defined) 18:08:15 most people seem to be in agreement with the current proposal 18:08:23 note that we do not aim to perform validation on the composition of ports in the zone (if 18:08:41 there are suggestions, please let us know) since different vendors seem to want to interpret differently 18:09:12 I think we are getting to some convergence may not be perfect for all but is a good start 18:09:24 and folks seem to be in general agreement which is good 18:09:40 SridarK: right, i was just going to say you are looking at this feature closely, right? 18:09:46 in terms of driving it 18:09:57 yes will do Sumit 18:10:08 there is a pending item here to converge on the trunk port to constituent sub-interface ports mapping 18:10:28 the discussion beyounn started 18:10:54 i don't believe we are set on this yet, right? 18:11:21 yes i think we can discuss more in HK with some of the proposals on trunk ports 18:11:31 with all folks being there 18:11:38 #action SridarK beyounn SumitNaiksatam to followup with existing blueprint owners and if required, file a new blueprint, if new blueprint, bring it up for discussion during FWaaS slot in the summit 18:11:51 more thoughts on zones? 18:11:56 is Kaiwei here? 18:12:26 SumitNaiksatam: I'm here 18:12:32 hi Kaiwei 18:13:04 Kaiwei: did the email exchange on the mailing list regarding zones satisfy your concerns? 18:13:17 yes, it does 18:13:25 Kaiwei: ok good 18:13:32 I'm fine using port, though I prefer network/subnet uuid :) 18:13:40 Kaiwei: i see your point 18:14:06 Kaiwei: we can brainstorming on this a little more until the summit 18:14:23 i don't think we plan any implementation on it at least until then 18:14:36 sure 18:14:59 SridarK RajeshMohan beyounn: anything else on zones? 18:15:09 I am fine 18:15:38 sorry, I was late 18:15:41 catching up now 18:15:44 seems like others are in silent agreement :-) 18:15:46 we can refine with more discussion at HK 18:15:51 beyounn: np 18:16:56 ok next topic then 18:17:04 #topic Service Insertion for Firewall 18:17:10 ok, so far so good 18:17:12 :-) 18:17:28 beyounn: ok 18:17:30 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-service-insertion 18:17:38 i just created this bp 18:18:15 pretty much depends on the other services' insertion and chaining dicussion 18:18:46 with this bp we can do router level insertion 18:19:35 garyduan: hi, we are discussing service insertion for firewall 18:20:02 Sorry, I am late 18:20:15 garyduan: np 18:20:20 SumitNaiksatam: so the insertion will be at the level of a router and the zone members will be on top of that still as part of the rule 18:20:33 SridarK: yes, thats the current thinking 18:20:40 ok 18:20:54 SridarK: insertion should be able to setup the datapath correctly 18:21:15 SridarK: zones will be used to interpret the rules 18:21:23 yes makes sense 18:21:37 Sumit, how about BIW case? 18:21:52 For that we don't need router right? 18:22:01 beyounn: you mean insertion for BITW? 18:22:05 yes 18:22:10 beyounn: no router for that 18:22:13 ok 18:22:25 beyounn: the insertion context will be different for that (it will be a subnet) 18:22:36 If router does specified, the fwaas driver should understand the insertion context and only load the specified routers 18:22:37 ok 18:22:44 beyounn: i was talking about the reference implementation 18:22:56 garyduan: that is correct 18:23:10 ok. thinking of service framework integration 18:23:43 garyduan: we have different agenda item for service type integration 18:24:02 garyduan: unless you have something to discuss in the insertion context 18:24:26 garyduan: per the latest proposal we don't modify the existing service type framework at all 18:25:31 SumitNaiksatam: "don't modify", can you elaborate? 18:25:55 garyduan: we will use the existing service type/provider framework mostly as is 18:26:01 yes. 18:26:18 garyduan: the proposed insertion context will be a separate entity 18:26:27 SumitNaiksatam: Yes. I was just thinking the behavior of fwaas driver. 18:26:41 SumitNaiksatam: shouldn't have any impact on insertion 18:27:16 garyduan: the plugin will have to interpret the insertion context, and convey the router id to the agent/driver 18:27:48 SumitNaiksatam: yes. 18:27:49 garyduan: so we will have to make changes to the agent and driver as well (reference implementation) to account for this 18:28:05 garyduan: yes, driver will change 18:28:05 SumitNaiksatam: agent need some change 18:28:10 garyduan: yes 18:28:19 garyduan: hopefully changes will not be too much 18:28:37 garyduan: perhaps changes are more for interpreting zone 18:28:40 we will see 18:28:51 SumitNaiksatam: I will think about it 18:28:59 anything more on insertion? 18:29:22 ok moving on 18:29:23 #topic Address Objects 18:29:26 SumitNaiksatam: Should I be able to access the spec for BP link for FWaaS service insertion? (I can't) 18:29:42 * pcm_ VPNaaS team member lurking 18:29:48 #undo 18:29:49 Removing item from minutes: 18:30:03 pcm_: hi, of course everyone is welcome :-) 18:30:16 pcm_: no formal spec document yet 18:30:35 pcm_: however the dependent blueprint captures a lot of details 18:30:47 pcm_: the one regarding insertion and chaining 18:30:48 SumitNaiksatam: Ah. Accounts for access denied :) 18:31:06 pcm_: yes, because there is no spec :-) 18:31:19 SumitNaiksatam: np. Will look at the BP. 18:31:40 pcm_: ok, we can discuss offline if you have followup questions 18:31:51 #topic Address Objects 18:31:58 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-address-objects 18:32:07 we will first target static IP objects 18:32:32 Brian does not seem to be here 18:33:05 #topic Service Objects 18:33:12 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-customized-service 18:33:26 proposal is to capture protocol, port, icml type and code, and timeout 18:33:32 beyounn has the blueprint 18:33:43 Sumit, should I mark the approver to you? 18:33:50 beyounn yes 18:34:06 beyounn: anything more to discuss beyond what we have already? 18:34:22 If no one has question , then let;s move on 18:34:26 I think in last week's meeting we were only talking about what is required 18:34:29 and what is optional 18:34:37 Kaiwei: ok 18:34:44 beyounn: can you elaborate? 18:34:51 yes, 18:35:07 I think we have agreed that timeout is optional 18:35:26 I also think to make protocol/ports to be must to have field 18:35:34 but to provide notion "ANY" 18:35:40 beyounn: ok 18:35:46 I think this can cover most of cases 18:35:52 I think protocol/port should be optional, and we should obsolete "protocol" attribute in current rule model 18:36:16 Kaiwei: that could be one approach 18:36:19 it doesn't make sense to have protocol in service object and in rule level.... 18:36:32 Kaiwei, 18:36:48 we should not force people to only go one way 18:37:00 beyounn: thats right, that was the thinking 18:37:05 User should be able to decide whether to use service object 18:37:06 or not 18:37:18 Kaiwei: we want to let the users be able to define iptables type of rules 18:37:19 Sumit, just joined. Sorry for joining late. 18:37:33 Kaiwei: that will be the basic rule (sort of core definition) 18:37:38 RajeshMohan: hi, np 18:38:06 Kaiwei: the service object will be an extension to the basic rule definition 18:38:25 Sumit:+1 18:38:33 beyounn: sorry did not mean to cut you 18:38:45 no, not at all 18:38:58 Kaiwei: thoughts? 18:39:08 or for that matter, others as well? 18:39:44 we don't have to decide it here 18:40:15 Kaiwei,if you want you can post the idea to BP directly 18:40:27 beyounn: thats a good suggestion 18:40:34 If we have contradicitng values in service object and rule, then we have to report error? 18:40:44 RajeshMohan: good point 18:40:55 I believe we can provide all flexibility to users if we want, but having two ways (or multiple ways) of configuring one field doesn't seems to be a good approach 18:40:56 perhaps that is Kaiwei's concern as well 18:41:20 yes - I was trying to undersand where Kaiwei is coming from as well 18:41:23 yeah, especially they can conflict with each other 18:41:33 My thoughts is, you can not have both service or rule level proto/port defined at the same time 18:41:51 I only thought if you defined a service, you need to have proto/port define 18:41:54 Kaiwei RajeshMohan we will need to set some priority order 18:42:01 otherwise, the serivce object is worng 18:42:18 ok 18:42:30 also keep in mind that the service definition we are talking about is a service "object" 18:42:57 I will try to squze group concept 18:42:58 as a user it seems to be a little cumbersome to me to have to create an object if i just want to create a simple rule 18:43:02 but not sure if I will have time 18:43:34 ok discussion on to the blueprint 18:43:44 typically service definition should contain protocol, tcp:80 defines HTTP, (not considering AppID for now) 18:43:51 I will update the BP 18:44:15 one way to simplify this is to provide "inline" service-object that can be specified in the rule directly, without explicitly creating a service-object.... 18:44:30 Kaiwei: agreed 18:44:43 Kaiwei: cli, for example, can hide the object creation 18:44:58 Kaiwei: I think it's the current way 18:44:59 Kaiwei: however from an api perspective we are still creating a new object 18:45:01 but I also hope we can reuse service object 18:45:09 beyounn: good point 18:45:12 beyounn: yes 18:45:21 beyounn: that would be the goal 18:45:36 lets first tackle as to what goes into the service (mandatory and optional) and then think about if want to change the existing rule 18:45:41 rule defintion 18:45:55 ok 18:45:59 discussion on to the blueprint/mail list 18:46:03 ok 18:46:09 #topic service_type framework 18:46:15 #link https://blueprints.launchpad.net/neutron/+spec/fwaas-service-types-integration 18:46:22 i believe garyduan is on this 18:46:34 garyduan: anything to discuss? 18:47:16 SumitNaiksatam: Will this allow to write a plugin-driver? 18:47:26 Not much, we talked about it in insertion context 18:47:57 RajeshMohan: plugin-driver is what I am thinking 18:47:58 RajeshMohan: you can write that today as well, but this will allow you to create firewalls using different drviers 18:48:22 RajeshMohan: as of today, you can configure exactly one driver and all firewalls are created using that 18:48:24 provider is set that firewall level 18:48:37 'at' firewall level 18:49:03 Thanks Sumit, Gary. 18:49:05 RajeshMohan: with this change, you can decide via the API as to which "provider" you want for a particular firewall 18:49:14 provider maps to a driver 18:49:36 Good. Thanks. 18:49:52 garyduan: okay, i guess nothing new to discuss, we are going to do something similar to LBaaS and VPNaaS 18:49:57 #topic revisit firewall to firewall_policy association 18:50:09 #link https://blueprints.launchpad.net/neutron/+spec/neutron-fwaas-explicit-commit 18:50:17 most vendors seem to think that the current implementation in the patch is good and works for them 18:50:33 SumitNaiksatam: +1 18:50:34 by works i mean, the like the semantics 18:50:40 RajeshMohan: okay 18:50:56 SumitNaiksatam: same here +1 18:51:06 SridarK: okay 18:51:13 however some members in the neutron core team have concerns 18:51:26 so i guess we will bring this up in the summit session 18:51:32 one question 18:51:36 garyduan: please 18:51:55 if admin creates a firewall first 18:52:03 then create rules and policy 18:52:25 at this moment, policy is not associated with firewall yet 18:52:35 now, to apply the policy to firewall 18:52:55 yeah 18:53:13 two step 18:53:18 1.assoicate firewall to the policy, 2. commit 18:53:26 garyduan: yeah 18:53:43 should it be different? 18:53:49 what I should see is, firewall is created with another policy, 18:53:59 to associated with the new policy 18:54:15 admin has to, 1. update firewall, 2. commit 18:54:27 garyduan: when you create firewall without policy, there is default policy to deny all traffic 18:55:05 garyduan: are you suggesting it should be one step? 18:55:35 SumitNaiksatam: just try to confirm, always two steps 18:55:49 garyduan: yeah, thats the current proposal 18:55:58 SumitNaiksatam: create policy, create firewall with policy, commit 18:56:16 okay, i want to have time for open discussion for anything that we may have missed, and that we should bring up at the summit 18:56:21 garyduan: lets take offline 18:56:31 SumitNaiksatam: ok 18:56:36 #topic Open Discussion 18:57:04 so have we missed anything in the past three weeks of discussion that is critical to someone? 18:57:30 at this point we will mostly bring up the items discussed today at the summit 18:57:37 since they have owers 18:58:10 Zones and Commit are critical to us. Is Zones assigned to someone? 18:58:20 I would think it will have more than one BP 18:58:26 RajeshMohan: yes 18:58:44 SumitNaiksatam: Thanks 18:59:02 well by owners i meant, at least some initial interest 18:59:03 RajeshMohan: i will pick up work on zones 18:59:21 we can decide how we can split work based on the interest and needs 18:59:43 please note that, as a team we will also need to do tempest work 18:59:58 SridarK: Thanks Sridar. 19:00:08 of course we all work together 19:00:21 SridarK: yeah, like last time 19:00:27 yes :-) 19:00:28 I think we are more hands now 19:00:41 so hopefully it will be better 19:00:49 +1 19:00:52 alright folks, thanks much for attending this 19:00:59 follow up discussions over emails 19:01:05 thanks and see u all at HK 19:01:10 SumitNaiksatam: Service insertion is obviously important but I did not bring it up as I assumed that is different discussion 19:01:12 we can huddle together after the summit session 19:01:24 RajeshMohan: thanks, yes absolutely 19:01:39 i will let you know date/time about huddle in HK 19:01:48 Huddle in HK, i like that :-P 19:01:48 SumitNaiksatam: Thanks. See you all in HK. 19:01:56 alright, thanks all 19:02:01 bfn! 19:02:07 bye 19:02:10 Bye 19:02:25 #endmeeting