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