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