18:55:08 #startmeeting Networking FWaaS 18:55:09 Meeting started Wed Apr 9 18:55:08 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:55:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:55:12 The meeting name has been set to 'networking_fwaas' 18:55:14 Yes 18:55:27 SridarK beyounn garyduan: thanks for joining 18:55:39 I am not sure that Rajesh will join 18:55:54 #topic Service Insertion and Firewall 18:55:55 dont see him online 18:56:11 #link https://review.openstack.org/#/c/62599 18:56:54 Rajesh as updated the patch 18:56:59 *has 18:57:20 and we are trying to chase the reviewers 18:57:32 thanks SridarK for working on the CLI 18:57:39 any further thoughts on that? 18:57:47 SumitNaiksatam: i will also pick up his changes to run a complete end to end test 18:57:53 SridarK: nice 18:58:09 i think the DB migration changes are probably not right in his patch 18:58:15 i mean the changes to the HEAD 18:58:19 need to check 18:58:54 #topic Firewall Zones 18:58:56 Jenkins would have complained then correct ? 18:59:04 SridarK: not sure 18:59:21 I mean i am not sure that we are supposed to modify that file 18:59:23 it seems happy now anyways wil discuss later 18:59:37 it will work but i am not sure that its the right convention 18:59:42 #undo 18:59:43 Removing item from minutes: 18:59:50 : #topic Firewall Zones 19:00:22 SumitNaiksatam: starting to pull things together as a doc 19:00:28 SridarK: ok good 19:00:40 SridarK: do you by any chance have a link? 19:00:41 did have some questions and need to run thru more usecases 19:00:51 For zone, I just brought an idea if it can be covered by service chaining 19:00:53 no not yet still very prelim 19:01:10 garyduan: yes we should discuss that 19:01:12 SridarK: ok 19:01:20 garyduan: okay, is this documented? 19:01:37 The notion of a zone could be a collection of some basic neutron resources indicating src or dest of the traffic of interest. This could beyond just looking at router or ports perhaps networks, subnets too ? 19:01:38 no, just in the email 19:01:52 garyduan: ah ok, the one you had sent a few days back? 19:02:06 so working of that looks a lot like what we are doing for service insertion at least in term of what we are specifying 19:02:13 SumitNaiksatam: yes 19:02:19 garyduan: got it 19:03:07 SridarK garyduan: in general if we can “infer” zones from other existing constructs we should do that 19:03:27 SumitNaiksatam: garyduan it does seem like we can do that 19:03:30 that said, service_context itself is not yet merged/approved 19:03:45 so one could also make a case for zones 19:03:51 that said just want to make sure that there is no ambiguity and no corner cases 19:04:01 to infer the service_context :-) 19:04:29 Let's say we still want to define zone 19:04:42 SridarK listed two options we discussed before 19:05:01 setting the zone on policy or on rules 19:06:01 what is the predominant usage in firewalls? 19:06:02 garyduan: one concern on the second case was being able to reuse the policy for other zone pairs 19:06:13 SridarK: ah, good point 19:06:24 SridarK: but that would apply to the policy as well? 19:06:50 SumitNaiksatam: from the cisco usage it would be outside the rules and more as a policy being applied across a zone pair 19:07:17 SridarK: ok 19:07:26 garyduan beyounn: what do you guys think? 19:07:29 SumitNaiksatam: (1) is not really embedded in the policy but more as FW attribute 19:07:46 SridarK: ok 19:08:38 The concern is we might need a lot of firewall, simply for different zones 19:08:59 garyduan: ok 19:09:09 garyduan: ok because we have a single policy 19:09:30 SridarK: yes 19:09:45 SridarK: or if zone is an attribute of FW 19:10:14 SridarK: do we allow a list of src/dst zones or just one pair 19:10:38 SridarK: to be associated with one firewall instance? 19:10:57 garyduan: rather that was the case in how we view it with a single policy - what i meant was the zone pair assoc is done outside the policy 19:11:25 garyduan: the thought now is to think in terms of a single pair 19:12:09 because the zone is itself a list of n/w entities 19:12:31 SridarK: so we might still need multiple firewalls on one router 19:12:34 garyduan: but i agree on ur point of having multiple fw is not easy 19:13:23 if we supported multiple policies then on each policy we could apply diff zone pairs 19:14:00 SumitNaiksatam: but i think we dont want to think in terms of having multiple policies on a FW ? 19:14:09 or define zone at rule level 19:14:23 I mean associate zone with rules 19:14:34 SridarK: we avoided doing that because composition is not easy 19:14:39 garyduan: yes so we can have co mingling of zones 19:14:48 SumitNaiksatam: yes 19:15:00 SridarK: yes 19:15:37 garyduan: SumitNaiksatam: i think in that case this is a strong case for supporting it in the rules if we cannot have multiple policies 19:16:01 SridarK: ok 19:16:18 i wanted to take a step back though, and think through this 19:16:24 Ofcourse vendor backends can normalize to their implementations 19:16:50 in the sense that, what abstractions should be exposed in any *aaS in Neutron 19:17:25 does a zone need to be a fundamental fwaas abstraction? 19:17:43 or is is a detail that needs to be hidden from the “cloud” user 19:18:25 SumitNaiksatam: Hmm! cant think beyond a network guy :-) 19:18:39 but u raise an important point in terms of the abstraction 19:18:48 from a user perspective 19:19:03 SridarK: i think that applies to all of us :-) 19:19:43 i bring this up, because there was a discussion on more than one occassion, raising the question whether every aspect of every service needs to be represented as an abstraction in neutron/openstack 19:19:44 i see something like "deploy a FW btwn the engineering folks and the marketing folks" 19:19:52 SridarK: true 19:20:09 engineering - could be a collection of some n/w entities 19:20:27 same for mktg and that we think of as a zone 19:20:49 SridarK: correct 19:20:57 agree on ur thought on the abstraction and i am sure this will be raised 19:21:06 SridarK: hence my hesitation 19:21:29 SridarK: as long as we are able to respond and justify, we can go ahead with this 19:21:29 Someone asked in HK summit that can zone be defined by subnet 19:21:37 instead of ports 19:21:48 SridarK: right now i dont have a strong enough justification 19:21:52 garyduan: ok 19:22:05 SumitNaiksatam: also earlier we were thinking of zone as a resource but perhaps how we think of Service context more an attribute 19:22:18 that becomes very similar to service chain 19:22:27 garyduan: yes subnets, networks 19:22:28 so i come back to asking, are there “cloud” use cases that we cannot satisfy without the explicit definition of zones? 19:22:52 garyduan: and this also led me to ur line of thought with relation to service context 19:23:44 I think we need zone concept, either in terms of zone object or service context 19:23:47 SumitNaiksatam: i think we can justify along the lines of the engr mktg type usecases ofcourse with more analysis with something more realistic 19:24:17 or web server subnet and database subnet 19:24:29 garyduan: adding that from and to 19:24:31 subnet => networks 19:25:01 garyduan: ok 19:25:53 SumitNaiksatam: i will work thru more with some usecases 19:26:00 web and db networks served in one l3 router can have different policies 19:26:11 SridarK: okay, great 19:26:16 garyduan: correct 19:26:31 right now this is can be sort of achieved by IP addresses 19:27:03 garyduan beyounn: are you guys still comfortable with the current defintion of service_context? 19:27:34 SumitNaiksatam: beyounn just left 19:27:34 or for that matter it’s need 19:27:45 garyduan: ok, what about you? 19:27:49 SumitNaiksatam: I think it is OK 19:28:06 SumitNaiksatam: but we need more clarification on validation logic 19:28:29 garyduan: ok let me ask in a different way, what is your understanding on service_context? 19:28:53 i am asking since different people are interpreting in different ways 19:29:07 A place to insert the service 19:29:45 so insert to you means, attaching to the network, or being able to steer traffic to it? 19:29:54 but the context only defines the place, but only implies what the service is 19:30:34 SumitNaiksatam: either way 19:31:11 garyduan: hmmm…thats where it gets a little ambiguous 19:31:12 SumitNaiksatam: I think it's up to driver to decide 19:31:25 okay i am not sure if there is another meeting on this channel now 19:31:43 i think we can go on until we are bumped out (since we started a little late) 19:32:00 SumitNaiksatam: i thought steering was out of the scope 19:32:10 SridarK: yeah i was about to ask you 19:32:16 SridarK: so what is your understanding? 19:32:20 of service_context 19:32:43 SumitNaiksatam: to me it seems defining the insert point similar to what garyduan mentioned 19:33:09 SumitNaiksatam: but steering seemed was not out of the scope of this first activity 19:33:24 and will be covered with how the data path stiching happens 19:33:59 we may then need to think in terms of if any encaps are needed etc esp in the chaining case 19:34:24 SridarK: true, but i think others have an opinion that service_context provides the context to steering 19:35:04 SumitNaiksatam: clearly a closely related activity except we were keeping that for step 2 in the discussion 19:35:16 at least from the original BP scope 19:35:36 SridarK: true, not so much from this patch or BP perspective 19:35:48 garyduan: do you agree with what SridarK mentioned? 19:35:58 SumitNaiksatam: yes 19:36:32 garyduan: ok 19:36:42 garyduan: are you travelling or are you local? 19:36:55 SumitNaiksatam: local, I am back :-) 19:37:42 garyduan: ok 19:38:04 lets plan the F2F to discuss more details on the zones, and perhaps touch on service_context 19:38:13 we will circle back in the IRC next week as well 19:38:36 SumitNaiksatam: i will have some travel next week - will sync with u guys on email 19:38:49 SumitNaiksatam: to set a time 19:39:37 SridarK: sure 19:39:44 #topic open discussion 19:39:50 anything more to discuss? 19:40:07 not from me 19:40:09 nothing from me 19:40:26 ok thanks for joining! 19:40:32 until next time, bye! 19:40:35 thanks for the good discussion 19:40:37 bye 19:40:43 #endmeeting