18:02:36 <SumitNaiksatam> #startmeeting Networking FWaaS
18:02:37 <openstack> Meeting started Wed Oct 23 18:02:36 2013 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:41 <openstack> The meeting name has been set to 'networking_fwaas'
18:03:06 <SumitNaiksatam> Welcome to the Firewall as a Service (FWaaS) meeting!
18:03:13 <SumitNaiksatam> today's meeting is also in preparation for the Icehouse summit discussions/sessions
18:03:24 <SumitNaiksatam> #info etherpad: https://etherpad.openstack.org/p/icehouse-neutron-fwaas
18:03:51 <SumitNaiksatam> #topic tempest
18:04:01 <SumitNaiksatam> I have created a place holder blueprint
18:04:15 <SumitNaiksatam> #link https://blueprints.launchpad.net/tempest/+spec/fwaas-api-tempest
18:04:24 <SumitNaiksatam> I also had an action item last week to check with Salvatore, but I did not get a chance to catch him and he is on vacation this week
18:04:40 <SumitNaiksatam> have pinged him though
18:04:56 <SumitNaiksatam> if anyone has any input/thoughts on this, happy to spend a few minutes on this topic here
18:05:27 <SumitNaiksatam> seems like folks are still joining
18:05:52 <SumitNaiksatam> for folks just joining in, we are discussing tempest tests for FWaaS
18:06:05 <SumitNaiksatam> i have posted a placeholder blueprint
18:06:23 <SumitNaiksatam> the idea is to at least test the basic API for the fwaas resources
18:06:34 <SumitNaiksatam> anyone has more thoughts/input on this?
18:07:21 <SumitNaiksatam> okay, so will try to prioritize this at least with the ideas we have
18:07:32 <SumitNaiksatam> moving to the next topic
18:07:33 <SumitNaiksatam> #topic zones
18:07:51 <SumitNaiksatam> everyone's favorite topic :-)
18:07:55 <SridarK> :-)
18:08:03 <SumitNaiksatam> this was another action item for me
18:08:05 <garyduan> Right
18:08:15 <SumitNaiksatam> I was supposed to send a email to the mailer with a proposal
18:08:24 <SumitNaiksatam> we had discussions with some team members on this, and based on that I sent out the proposal
18:08:34 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/fwaas-zones-api
18:08:43 <SumitNaiksatam> currently this is pretty simplistic, hoping to get some input
18:08:50 <SumitNaiksatam> folks had a chance to think about this?
18:09:05 <SridarK> I think this captures it at a high level
18:09:15 <SumitNaiksatam> SridarK: okay
18:09:22 <SridarK> we can work thru some of the specifics over next week
18:09:26 <SumitNaiksatam> one thing we realized is that we cant use zones for all scenarios
18:09:31 <SumitNaiksatam> SridarK: right
18:09:38 <SridarK> so we have something more tangible b4 summit
18:09:45 <garyduan> SumitNaiksatam: we'd like to help or on other FW objects
18:09:51 <SumitNaiksatam> for instance, the zones don't work for bump in the wire scenarios
18:10:02 <SridarK> yes true that was  a good discussion
18:10:06 <SumitNaiksatam> garyduan: sure, that is coming up in the agenda
18:10:33 <SumitNaiksatam> garyduan: you mean pitch in for zones as well?
18:10:41 <SridarK> i think if we cover some of the basic common cases and have it generic so works for all
18:10:52 <SumitNaiksatam> SridarK: makes sense
18:11:20 <SumitNaiksatam> more thoughts on the definition of zones?
18:11:21 <garyduan> SumitNaiksatam: We can share workload.
18:11:39 <SumitNaiksatam> garyduan: definitely, we can decide how to split up
18:11:45 <SridarK> sounds good to me too
18:11:45 <SumitNaiksatam> lets first firm up on the proposal
18:12:15 <SridarK> how abt we target that for the next IRC
18:12:30 <SridarK> to have some more details added to the BP
18:12:30 <SumitNaiksatam> we will add source/destination arguments to the rule to be able to specify zones
18:12:36 <SumitNaiksatam> SridarK: yeah we can do that
18:12:54 <SumitNaiksatam> SridarK: lets also factor in the summit dynamics
18:13:20 <SridarK> SumitNaiksatam: agreed
18:13:25 <SumitNaiksatam> okay seems like everyone is happy with the current state of discussion on zones
18:13:30 <SumitNaiksatam> we will keep working on it
18:13:35 <SumitNaiksatam> next topic
18:13:41 <beyounn> wait
18:13:43 <beyounn> :-)
18:13:48 <SumitNaiksatam> beyounn: sure go ahead
18:13:53 <beyounn> the vlan support is still up in the air
18:14:00 <SumitNaiksatam> ah ok
18:14:01 <beyounn> and there is another bp about this
18:14:03 <beyounn> https://docs.google.com/document/d/1WEGmMJ4Vn21trgwa2_mpQ7U_a1BV2rKxlRzHqc49-9Y/edit
18:14:17 <SridarK> beyounn: i am also talking to Kyle today evening
18:14:18 <SumitNaiksatam> i was kind of thinking of that as implementation detail
18:14:22 <SumitNaiksatam> but good to point out
18:14:25 <SumitNaiksatam> SridarK: thanks
18:14:32 <beyounn> ok
18:14:41 <beyounn> just want to put all the info together
18:14:54 <beyounn> now, I'm done
18:14:54 <SumitNaiksatam> #action SridarK and beyounn to continue following up on trunk port blueprint, and any additional blueprints that need to be created
18:15:03 <SridarK> ok sounds good
18:15:07 <beyounn> ok
18:15:18 <SumitNaiksatam> beyounn: do you want to discuss it here?
18:15:26 <SumitNaiksatam> not sure if kyle is around
18:15:31 <SumitNaiksatam> mestery: there?
18:15:45 <beyounn> ok, let's do it offline then
18:15:53 <SridarK> We are all in a mtg now
18:15:54 <SumitNaiksatam> ok lets do it offline
18:15:58 <SumitNaiksatam> SridarK: got it
18:16:00 <mestery> SumitNaiksatam: Barely. :) In a meeting
18:16:05 <SridarK> so we can pick it up offline
18:16:11 <beyounn> right
18:16:12 <SumitNaiksatam> mestery: okay np, we discuss offline
18:16:20 <SumitNaiksatam> next topic
18:16:22 <SumitNaiksatam> #topic Address Objects
18:16:32 <SumitNaiksatam> we were earlier planning an IP Object resource to model static and dynamic IP objects
18:16:43 <SumitNaiksatam> the proposal is to evolve this to generic "address" objects
18:16:51 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/fwaas-address-objects
18:17:02 <SumitNaiksatam> we will first target static IP objects
18:17:14 <Kaiwei> sorry, I just checked the blueprint for the zones and I'm not sure if using ports as zones actually capture the idea of "zones"
18:17:40 <SumitNaiksatam> Kaiwei: can you hold that thought, we just moved past that topic
18:17:47 <SumitNaiksatam> we can circle back to zones
18:17:51 <Kaiwei> sure
18:18:17 <SumitNaiksatam> #action SumitNaiksatam to followup on Kaiwei regarding zones if we don't get it to it by the end of the meeting
18:18:32 <SumitNaiksatam> coming back to address objects
18:19:27 <SumitNaiksatam> everyone fine with IP address object being a subnet or list/range of ip addresses?
18:19:45 <SumitNaiksatam> this is the "static" ip address object
18:19:46 <beyounn> right
18:19:54 <Kaiwei> how about CIDR?
18:20:07 <Kaiwei> oh, that's a subnet
18:20:13 <SumitNaiksatam> Kaiwei: okay, i was thinking CIDR when i meant subnet
18:20:15 <Kaiwei> miss that part
18:20:19 <SumitNaiksatam> Kaiwei: yeah :-)
18:20:34 <SumitNaiksatam> Kaiwei: but that is a good point
18:20:42 <Kaiwei> I guess that includes a list of subnets as well
18:20:54 <SumitNaiksatam> when i was thinking subnets i was thinking neutron subnets
18:21:05 <SumitNaiksatam> maybe there is a case for a super net or something like that
18:21:32 <Kaiwei> so the subnet is actually a subnet UUID?
18:21:43 <SumitNaiksatam> Kaiwei: that was my initial thought
18:21:49 <SumitNaiksatam> it helps in validation
18:22:00 <SumitNaiksatam> UUID or name
18:22:06 <Kaiwei> I'm fine with that...but having CIDR is more flexible
18:22:12 <SumitNaiksatam> also easier for the user to specify
18:22:23 <SumitNaiksatam> Kaiwei: i guess we can have both
18:22:39 <Kaiwei> that will be great
18:22:42 <SumitNaiksatam> either you can specify the actual CIDR, or the subnet UUID/name
18:22:48 <SumitNaiksatam> perhaps more usable that way
18:23:12 <BrianTorres-Gil> Agreed, both would be helpful.
18:23:13 <SridarK> SumitNaiksatam: Since CIDR can cover all cases - should we support both ?
18:23:22 <SumitNaiksatam> #action SumitNaiksatam to update address object blueprint, add CIDR
18:23:34 <SumitNaiksatam> SridarK: CIDR would cover
18:23:56 <SridarK> just a thought to make it simpler
18:23:58 <SumitNaiksatam> but providing a reference to neutron resource (subnet) in this case makes a little easier for users
18:24:10 <SumitNaiksatam> SridarK: we can discuss as follow up
18:24:18 <SumitNaiksatam> next topic
18:24:21 <SridarK> ok sounds good - i agree
18:24:42 <SumitNaiksatam> Kaiwei: btw, anything more on address objects?
18:24:48 <SumitNaiksatam> before i move on ;-)
18:25:10 <Kaiwei> nope, just want to make sure a list of subnets/CIDR is supported as well
18:25:20 <SumitNaiksatam> okay great
18:25:22 <SumitNaiksatam> #topic Counters
18:25:26 <SumitNaiksatam> couple of blueprints have been proposed
18:25:33 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/fwaas-counters-api
18:25:41 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/firewall-hitcounts
18:25:49 <SumitNaiksatam> the proposal is to pull the counters from the driver, FWaaS DB will not persist any of these
18:25:50 <SumitNaiksatam> this will be a separate API from the firewall_rules API (each rule will be identified based on rule_id and firewall_id)
18:27:24 <SumitNaiksatam> we still need to define what to report
18:27:41 <SumitNaiksatam> i guess the set of what IP tables reports is a must
18:27:46 <SumitNaiksatam> accept, deny
18:28:14 <Kaiwei> I think Salvatore mentioned in last week's meeting that pull the counters directly from driver every time a query is issued can put a lot stress on backend....
18:28:48 <SumitNaiksatam> Kaiwei: I don't think that was what he was suggesting
18:29:16 <SumitNaiksatam> i believe what he was suggesting is that we should not continuously update counters in the FWaaS DB
18:29:30 <garyduan> Kaiwei: My understanding is updating database is too costy
18:29:37 <SumitNaiksatam> garyduan: right
18:30:13 <SumitNaiksatam> Kaiwei: also, periodic update of counters will get give stale values, not of much use
18:30:42 <BrianTorres-Gil> Perhaps this is too implementation specific, but what if there are multiple firewalls with the rule.  Is the counter the sum of the counts on each firewall?
18:31:13 <Kaiwei> ok, probably my misunderstanding
18:31:16 <SumitNaiksatam> BrianTorres-Gil: we want to pull the counters based on rule_id and firewall_is
18:31:26 <SumitNaiksatam> firewall_id
18:31:56 <SumitNaiksatam> i would prefer to leave the aggregation to another extension
18:32:04 <SumitNaiksatam> thoughts?
18:32:09 <BrianTorres-Gil> ok, so counter is per rule and per firewall.
18:32:21 <SumitNaiksatam> BrianTorres-Gil: that is the current proposal
18:32:50 <SumitNaiksatam> we would like to enable the "elemental" API
18:33:12 <SumitNaiksatam> BrianTorres-Gil: perhaps we can make firewall_id optional
18:33:39 <SumitNaiksatam> so if firewall_id is not present, then its an aggregation
18:34:00 <SumitNaiksatam> that said I am worried about supporting this aggregation in the reference implementation
18:34:08 <SridarK> and this is completely driven by the vendor implementation
18:34:51 <SumitNaiksatam> SridarK: that is true, but if we say firewall_id is optional, the reference implementation will have to support aggregation across firewalls
18:35:10 <SridarK> SumitNaiksatam: supporting on the reference would be a stretch
18:35:20 <SridarK> we can keep it simple
18:35:28 <SumitNaiksatam> SridarK: yeah, thats my concern :-)
18:36:03 <SumitNaiksatam> ok lets think a little more how we can handle both scenarios (and not have to support in the reference impl)
18:36:30 <SumitNaiksatam> #action BrianTorres-Gil SumitNaiksatam SridarK to sync up on aggregate counters
18:36:41 <SumitNaiksatam> any other thoughts?
18:36:47 <Kaiwei> one question
18:36:55 <SumitNaiksatam> Kaiwei: go ahead
18:36:56 <SridarK> could whether it is optional or not be vendor specific ?
18:37:07 <Kaiwei> will a rule be shared by multiple firewall policies in icehouse?
18:37:21 <SumitNaiksatam> Kaiwei: not in multiple policies
18:37:36 <SumitNaiksatam> but the policy can be shared in multiple firewalls
18:37:52 <SumitNaiksatam> Kaiwei: this is also a part of the commit operation discussion
18:37:58 <SumitNaiksatam> i have it on the agenda if we have time
18:38:16 <Kaiwei> ok, so the aggregation is on one rule applied to multiple firewall?
18:38:33 <SumitNaiksatam> Kaiwei: yeah, that's what BrianTorres-Gil is referring to
18:38:48 <Kaiwei> got it
18:39:11 <SumitNaiksatam> SridarK: yeah, to your question, yeah lets think more on this
18:39:16 <SumitNaiksatam> next topic
18:39:18 <SumitNaiksatam> #topic Service Objects
18:39:19 <SridarK> ok
18:39:28 <SumitNaiksatam> proposal is to capture protocol, port, and timeout
18:39:39 <SumitNaiksatam> this can be used for source, and destination in a firewall_rule
18:39:54 <beyounn> the port can be a range
18:39:58 <Kaiwei> what timeout is about?
18:40:01 <SumitNaiksatam> beyounn: ok
18:40:06 <SumitNaiksatam> beyounn: over to you :-)
18:40:17 <SumitNaiksatam> Kaiwei's question
18:40:28 <beyounn> The service timeout is used to control a session the life time
18:40:56 <beyounn> you can define a service witha timeout and bind the service to a policy
18:41:10 <beyounn> when a session hits on the policy, session inherit the timeout value from service def
18:42:13 <SumitNaiksatam> beyounn: so you mentioned you wanted to put a blueprint for this?
18:42:23 <Kaiwei> got it,,,,just wondering how many venders have this kind of support....
18:42:25 <beyounn> Sure
18:42:37 <beyounn> or, if you want to create it, I can filling detail later
18:42:57 <SumitNaiksatam> Kaiwei: it seems some vendors are supporting this
18:43:00 <beyounn> Kaiwei: juniper and us
18:43:10 <SumitNaiksatam> Kaiwei: but we don't have to make this a required field
18:43:15 <SumitNaiksatam> it should be optional
18:43:20 <Kaiwei> sure
18:43:21 <SumitNaiksatam> beyounn: agree?
18:43:28 <beyounn> Iyes
18:43:36 <SumitNaiksatam> ok
18:43:56 <SumitNaiksatam> #action beyounn to file service objects blueprint
18:44:11 <SumitNaiksatam> BrianTorres-Gil: you have thoughts on this?
18:44:21 <Kaiwei> Also, I think we should we have one service per rule, instead of two per rule
18:44:41 <SumitNaiksatam> Kaiwei: can you explain?
18:45:07 <Kaiwei> you mentioned we need to have service objects for source and destination
18:45:11 <SumitNaiksatam> ah ok
18:45:20 <Kaiwei> but the protocol/timeout...etc will be same, only port will be different
18:45:28 <SumitNaiksatam> Kaiwei: ok
18:45:46 <Kaiwei> so I think one service object which include src port and dst port should be sufficient
18:45:53 <beyounn> yes
18:46:08 <BrianTorres-Gil> In the service objects seems a strange place to put a timeout, I would connect a timeout more with a rule.  But this is implemented differently in each vendor so hard to say what works best for everyone.
18:46:14 <SumitNaiksatam> Kaiwei: so you are saying rather than use source/destination for this, we have a new attribute for service
18:46:35 <Kaiwei> yes
18:46:37 <beyounn> let me give a short list
18:46:46 <beyounn> in a service object, we can have:
18:47:12 <beyounn> name, proto, port (or port range), timeout
18:47:37 <beyounn> the ports are source and dest
18:47:53 <SumitNaiksatam> proto and port are mandatory?
18:47:59 <SumitNaiksatam> i would assume they are
18:48:26 <Kaiwei> I think proto/port are optional....
18:48:44 <beyounn> kaiwei:yes
18:48:53 <SumitNaiksatam> Kaiwei: if they are optional, then the service object is meaningless
18:49:08 <SumitNaiksatam> you can just use the basic firewall rule attributes
18:49:28 <Kaiwei> I mean, you can have a service object with only dst port, or service object with only protocol but no ports
18:49:33 <SumitNaiksatam> i would imagine that the service is characterized by the protocol and source/dest ports
18:49:45 <garyduan> SumitNaiksatam: an empty service object means match all
18:49:56 <SumitNaiksatam> garyduan: why would you need that
18:50:05 <SumitNaiksatam> garyduan: its match all anyway
18:50:31 <SumitNaiksatam> Kaiwei: i would still argue that at least source or dest port is required since that characterizes the service
18:50:37 <garyduan> Is current protocol in fw rule optional?
18:50:50 <BrianTorres-Gil> It makes sense to me to have proto, srcport, dstport.  And srcport is optional.
18:50:54 <BrianTorres-Gil> Then one service object per rule.
18:51:11 <SumitNaiksatam> garyduan: protocol is optional in the API
18:51:18 <SumitNaiksatam> garyduan: the CLI requires you to use it
18:51:23 <SumitNaiksatam> BrianTorres-Gil: agree
18:51:29 <SumitNaiksatam> okay we are running short on time
18:51:30 <garyduan> SumitNaiksatam: ok
18:51:31 <beyounn> if you have protocol, then port has to be there
18:51:31 <Kaiwei> SumitNaiksatam: Then how to createa rule says: allow all tcp traffic?
18:51:48 <SumitNaiksatam> Kaiwei: that is already supported in the rules today
18:52:06 <SumitNaiksatam> okay let beyounn create the blueprint and we can pick this discussion up again next week
18:52:18 <SumitNaiksatam> #topic service_type framework and insertion
18:52:24 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/fwaas-service-types-integration
18:52:39 <SumitNaiksatam> seems like gardyduan has already implemented something
18:53:08 <SumitNaiksatam> this part is more mechanical though
18:53:17 <SumitNaiksatam> #topic revisit firewall to firewall_policy association
18:53:33 <SumitNaiksatam> i don't think we have enough time for this discussion
18:53:54 <SumitNaiksatam> let's circle back on this next week but i want to bring this up to plant the seed
18:54:15 <SumitNaiksatam> #topic Zones part deux
18:54:38 <SumitNaiksatam> Kaiwei: go ahead, trying to make sure we get back to your question
18:54:57 <Kaiwei> ok
18:55:02 <SumitNaiksatam> so you think group of neutron ports does not represent a zone?
18:55:27 <Kaiwei> if we use ports as zones, what if we have two ports connected to same network (or subnet), each is in different zones?
18:55:50 <Kaiwei> it looks odd that two ports in same network (or subnet) are in different zones...
18:56:01 <SumitNaiksatam> Kaiwei: yes
18:56:17 <SumitNaiksatam> Kaiwei: however, i doubt it will be used that way
18:56:41 <BrianTorres-Gil> I think it would be unusual to have two FW ports on same network/subnet unless you're doing link aggregation.
18:57:20 <Kaiwei> some FW doesn't allow two interfaces on same subnet
18:57:52 <Kaiwei> but I think most can have multiple interfaces on same networks but different subnets
18:58:11 <Kaiwei> also, what if this is for two ports are for two different FWs?
18:58:45 <Kaiwei> it it shouldn't be used this way, why not define zones as networks (or subnets)?
18:58:48 <SumitNaiksatam> Kaiwei: the problem is that we don't have an alternative to using neutron ports
18:58:51 <Kaiwei> if it shouldn't
18:59:41 <SumitNaiksatam> does subnet work for the other firewall vendors?
18:59:56 <beyounn> no
18:59:56 <SumitNaiksatam> lets continue this discussion over emails and in the next meeting
18:59:58 <beyounn> it does not
19:00:04 <SumitNaiksatam> we have to yield to the next meeting
19:00:07 <SumitNaiksatam> thanks all
19:00:13 <SumitNaiksatam> #endmeeting