16:00:44 <mestery> #startmeeting networking_policy
16:00:45 <openstack> Meeting started Thu Dec 19 16:00:44 2013 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:48 <openstack> The meeting name has been set to 'networking_policy'
16:00:57 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda
16:01:13 <mestery> Looks like a short agenda today, driven by an email sent to the list by banix last night.
16:01:21 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022677.html
16:01:31 <mestery> Lets first go over action items from last week.
16:01:38 <mestery> alagalah: You around today?
16:02:01 <banix> The taxonomy is already merged.
16:02:09 <mestery> banix: Awesome, thanks for confirming!
16:02:38 <mestery> banix: Do you want to lead the discussion to get consensus on the points you sent out?
16:02:46 <mestery> I think we should focus on that today per your email.
16:02:49 <banix> mestery: yes, sure.
16:02:53 <mestery> banix: thanks
16:03:27 <banix> Following up from the meeting last week and a few email threads, I thought we should close on a few preliminary things:
16:04:01 <banix> Two models namely, source/destination and producer/consumer were discussed
16:04:41 <banix> The proposed solution to merge these models was to modify the model to allow a list of endpoints (rather than single endpoint) in src and dest groups in the policy
16:05:09 <banix> I think we may want to change the name of these two attributes of Policy but other than that would that work for everyone?
16:05:42 <michsmit> In the past, we talked about having a bidirectional flag in the policy
16:06:11 <michsmit> Not sure if source and dest group are the right terms
16:06:29 <banix> michsmith: yes, we have that in the attributes table.
16:06:52 <banix> michsmith: Do you have suggestions for new names?
16:07:04 <michsmit> not yet ;-)
16:07:14 <mestery> Should we use those temporarily then for the names?
16:07:39 <banix> mestery: makes sense
16:07:49 <mestery> michsmit: You ok with that as well?
16:07:52 <michsmit> sure, until we come up with something better
16:07:52 <songole> How about left and right, if that makes sense?
16:07:57 <banix> we can change them when we come up with better names
16:07:59 <s3wong> banix: so if we have directionality in the policy (namely what endpoint groups are associated with what direction), do we still need a flag on policy itself?
16:08:55 <s3wong> I guess if it is for both direction
16:08:58 <ashaikh> banix:  advantage of src/dest naming is clarity in where the policy is applied and directionality
16:09:15 <banix> s3wong: I think by default, there is directionality in one direction. The flag allows to make it bidirectional, if that makes sense for a given policy.
16:09:20 <mestery> ashaikh: Makes sense to me as well.
16:10:44 <mestery> OK, that was an easy one to converge on. Thanks banix!
16:10:52 <banix> great.
16:11:07 <mestery> Next on your list was a minimum set of actions to support, right banix?
16:11:18 <banix> the next issue is the list of actions
16:11:21 <banix> mestery: yes
16:11:21 <prasadv> for bidirectional, what does classifier mean? Will the same classifier apply  in reverse direction?
16:11:44 <banix> prasadv: yes
16:11:55 <s3wong> prasadv: yeah, that would be what it means
16:11:59 <ashaikh> prasadv: if it doesn't, it will be very confusing :-)
16:12:04 <banix> I think for minimum set of actions we have three candidates
16:12:22 <banix> security, redirect and qos
16:12:42 <banix> I think we have a good handle on the first two; do we feel the same about qos?
16:12:51 <prasadv> redirect requires a little bit of clarity too
16:12:56 <s3wong> I guess 'security' is a given - at least 'allow' and 'drop' needs to be supported
16:13:10 <mestery> For qos, we should make sure to loop in sc68cal, as he's doing work in this area and wanted to be involved.
16:13:26 <banix> s3wong: Yes
16:13:27 <prasadv> if there is a group does it mean the traffic is sent to all the ones in the group
16:13:29 <mestery> banix: Lets discuss qos on openstack-dev so sc68cal can chime in there.
16:13:30 <ashaikh> what do folks think about really minimizing the "required" supported policies, e.g., just to security
16:13:38 <michsmit> Does redirect include the service insertion work ?
16:13:48 <mestery> ashaikh: For the POC, it would help with implementation time.
16:13:54 <s3wong> 'redirect' action generated a lot of opinions from the email thread - though the definition now is very generic
16:14:19 <ashaikh> mestery: right, and i would expect a lot more variation on implementations for the other two
16:14:20 <banix> michsmith: potentially, yes.
16:14:26 <s3wong> but prasadv and others want more clarity
16:14:32 * mestery nods in agreement with ashaikh.
16:14:52 <banix> so are we suggesting to have "security" as the only action for now?
16:14:58 <s3wong> I am good with just 'security' as required action for now
16:15:02 <banix> to start with?
16:15:20 <s3wong> sure makes reference implementation simpler
16:15:29 <ashaikh> banix: while we try to sort out a model and api for the other two
16:15:34 <banix> and we can clarify any other action, namely redirect and qos and possibly others
16:15:51 <banix> as we continue this work
16:15:53 <ashaikh> also would give us a chance to solidify connection with things like service chaining/insertion
16:15:55 <banix> ashaikh: yes
16:16:17 <mestery> So is everyone ok with security as the main action for step one then?
16:16:41 <s3wong> banix: let's settle on it then - just 'security': 'allow' | 'drop' as the only required action
16:17:32 <banix> Sounds good, mastery, s3wong
16:17:40 <mestery> #action Initial action supported will be security action.
16:17:44 <s3wong> I will update the document
16:17:46 <ashaikh> s3wong: we could still list the other two as optional action types, right?  (and keep working on their defn)
16:17:52 <mestery> #undo
16:17:52 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x390e850>
16:17:56 <banix> s3wong: You wrote theta part of the doc, would you be willing to convert what we have from the attributes table to
16:17:58 <mestery> #info Initial action supported will be security.
16:18:09 <banix> something that does not suggest these are Neutron objects
16:18:15 <s3wong> ashaikh: of course, and the example are already in the doc, I will update that with more clarity as well
16:18:17 <michsmit> do we need drop or can that be implicit ?
16:18:23 <s3wong> banix: certainly
16:18:34 <banix> s3wong: Thank you.
16:18:49 <s3wong> michsmit: good point, should we make 'drop' be the default?
16:19:24 <mestery> #action s3wong to update attributes table
16:19:58 <banix> mestery: Do you know the status of service chaining? Is it being incorporated as an extension? I didn't see it in the Icehouse list?
16:20:03 <ashaikh> michsmit: i think it makes sense to have drop be the default, i.e., explicitly allow specified traffic
16:20:13 <thinrichs> s3wong, michsmit: I think we're starting to talk about conflict resolution within a policy.
16:20:23 <mestery> banix: Service chaining discussions are mostly on hold due to focus on stability in Icehouse. I expect in "J" for them to come alive again.
16:20:36 <s3wong> OK - 'drop' as default settled - will update the doc accordingly
16:20:36 <banix> mestery: thanks
16:21:01 <thinrichs> If we have both 'allow' and 'drop' and a policy uses both actions, we need to decide which one takes precedence (in some way).
16:21:13 <s3wong> I guess we have 40 minutes for conflict resolution :-)
16:21:24 <thinrichs> If we don't have both 'allow' and 'deny' then we're implicitly assuming conflicts are not allowed within the policy.
16:23:10 <michsmit> thinrichs: it would also allow the policy to be order independent
16:23:23 <banix> Let me try to understand the conflict within the policy issue better
16:23:41 <banix> Would this arise only with overlapping classifiers?
16:23:48 <s3wong> thinrichs: there are several levels of this. Obviously we shouldn't allow two 'security' actions within the list of action in a single policy-rule
16:24:27 <thinrichs> michsmit: we could still be order independent IF we did conflict resolution at the level of the actions themselves, instead of at the level of policy statements, e.g. Allow takes precedence over Deny.
16:24:34 <s3wong> the problem would be when we have multiple policy-rules with conflicting 'security' actions
16:24:53 <thinrichs> So if you write a bunch of allow statements and you write a bunch of deny statements, it could so happen that your policy (sometimes) says to both allow and deny.  When that happens, the conflict resolution scheme deems that 'allow' wins.
16:25:20 <thinrichs> banix: yes--if two classifiers both apply then those rules could dictate different actions.
16:25:43 <s3wong> thinrichs: should the one with more specific classifier match wins?
16:25:44 <thinrichs> banix: it's typically hard to ensure classifiers do not overlap (both for people and for machines)
16:26:34 <thinrichs> s3wong: that's an idea.  I wonder how easy it is, though, to modify a large policy to meet some new demand.
16:26:34 <banix> Two suggested solutions: 1) 'allow; wins 2) more specific classifier wins
16:26:41 <mestery> thinrichs: Seems like your proposal simplifies things a bit, I like resolving this at the higher level.
16:27:01 <s3wong> for example, port 80 match on {min:10, max:100} classifier and {port==80} classifier should take the action of the latter
16:27:16 <thinrichs> How hard is it for someone to figure out what the most-specific classifier is across all rules and then write a rule that is even more specific than it?
16:28:11 <michsmit> thinrichs: depends on the size of the policy, could be difficult
16:28:41 <ashaikh> thinrichs: that's my worry too -- maybe we should try to restrict with an eye toward simplifying the imple in the first version
16:28:41 <thinrichs> And I suppose there's the question of how we define "more specific".  This has to be something that the algorithm decides.  Maybe it's just the number of tests in the classifier?  But then what if there's a tie?
16:28:58 <s3wong> thinrichs: may not be easy if we expect to have many policy-rule within a policy
16:29:27 <ashaikh> e.g., just allow explicit allow actions for now ? i.e., default-off model
16:29:58 <thinrichs> The nice thing about 'allow over deny' is that once we add additional actions (qos, etc.) we can use the same scheme and enable multiple actions to be applied as long as they don't conflict.
16:30:30 <thinrichs> Though perhaps the same could be said for the 'more specific' resolution strategy if we only applied it to groups of actions that are non-conflicting.
16:30:39 <banix> ashaikh: then the first solution (allow over deny) seems simple enough
16:31:04 <s3wong> thinrichs: well there are action types where multiple actions can be defined per classifier match: for example, 'qos'
16:31:06 <thinrichs> ashaikh: we could do that and punt on conflict resolution for now, but I think eventually we'll need a conflict resolution scheme.
16:31:26 <thinrichs> s3wong: absolutely--we've just been talking about qos as a single action today.  I did the same.
16:31:55 <thinrichs> s3wong: sorry--missed your point.
16:31:59 <michsmit> thinrichs: 'allow over deny' makes more sense to me if the only deny is the implicit deny all at the end
16:32:29 <thinrichs> s3wong: What if the actions defined are conflicting?  I don't see that having multiple-actions in a single rule changes things.
16:32:48 <ashaikh> thinrichs: yes, definitely
16:33:23 <s3wong> thinrichs: no, the point is - some action_type is a singleton within an action_list, while others are not (both 'qos' and 'redirect' can have multiple instances in an action list)
16:33:32 <ashaikh> michsmit: i agree, it seems more intuitive to me as well
16:33:33 <banix> OK, are we punting or taking the field goal :)
16:34:03 <thinrichs> michsmit: Or we could have 'deny over allow' and make 'allow' implicit.  I don't think it actually matters that much.  And I think of the default as a 'policy completion' strategy, which is analogous to the conflict resolution strategy except that instead of dealing with a policy that has too much information (conflicts) it deals with the problem of having too little information (where the policy doesn't say anything).
16:34:12 <banix> "allow over deny" for conflict resolution?
16:34:13 <s3wong> banix: let's settle on that for reference implementation purpose
16:34:43 <s3wong> just 'allow' over implicit 'deny' - so a single 'allow' action over overlapping classifiers will win
16:35:01 <songole> banix: Defining exceptions to a generic allow might be an issue
16:35:53 <thinrichs> songole: Conceptually we can suggest writing generic 'deny' statements and then using 'allow' to make exceptions.
16:35:57 <mestery> Are we concluding on the default deny with allow taking precedence, or the reverse?
16:35:59 <banix> songole: Please elaborate? Are you referring to thinrichs's implicit allow?
16:36:03 <s3wong> songole: please elaborate
16:36:35 <songole> Generic allow port 80 and deny a specific source or dest
16:36:39 <michsmit> mestery: I think the default deny makes more sense
16:36:58 <banix> mestery: default deny with allow taking precedence
16:37:10 <mestery> michsmit banix: I agree with both of you.
16:37:32 <thinrichs> songole: I'm sure there will always be cases where we need to do surgery on the existing policy to say what we want (for any conflict resolution strategy).
16:37:37 <banix> songole: src/dest are fixed in the policy
16:38:07 <s3wong> songole: wouldn't that be a different policy for specific endpoint groups?
16:38:20 <banix> I think this is a good first step for conflict resolution
16:39:18 <songole> Does the endpoint define src/dst?
16:39:23 <banix> If we agree on that (default deny, allow taking precedence), should we move on to net topic?
16:39:28 <prasadv> we do need to also talk about classifier
16:39:39 <s3wong> OK - with consensus, I will also update the doc with allow over deny on action section
16:39:55 <banix> prasadv: go ahead please
16:40:05 <prasadv> i think songole meant that classifier can have src/dest fields different from src/dst groups
16:40:29 <s3wong> prasadv: yes, now we are talking about adding the IP address fields in classifier
16:40:38 <songole> prasadv: yes
16:40:44 <s3wong> hence 'next topic' :-)
16:41:13 <mestery> #action s3wong to update document to note "allow over deny" in action section.
16:41:18 <michsmit> s3wong:  I would think we would try to avoid IP addresses in the classifiers
16:41:20 <banix> yeah, I remember you guys talking about this. DO we need to have this in the first cut?
16:41:55 <prasadv> michsmit: how can we avoid them, if some use cases need them
16:42:03 <s3wong> michsmit: I am for that. prasadv and Dimitri both want it - so I am open for discussion
16:42:09 <ashaikh> once we start to add more headers, won't we essentially end up with an openflow match-like list (as thinrichs pointed out in email)
16:43:04 <michsmit> IP addresses for subnets outside of Neutron control makes sense, but for VMs I would think that the group membership is the way to classify IP addresses
16:43:31 <michsmit> By subnets outside of Neutron control, I mean WAN, etc.
16:43:54 <banix> I think for now, we should keep the classifier simple (that is as is).
16:44:06 <thinrichs> We're talking about the *possible* matching fields, right?  So just because some rules match on IP source doesn't mean all rules must.
16:44:13 <songole> what is allowed in a classifier - default?
16:44:29 <s3wong> songole: protocol field + L4 port number
16:44:56 <prasadv> michsmit: for group membership it is ok. but I thought we are talking about traffic passing through them right?
16:45:19 <banix> sonogole: and a type. Please refer to https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.6j822g6556qq
16:45:32 <prasadv> and traffic can be independent of the src/dest group IP
16:46:28 <michsmit> prasadv: I'm not sure I understand what you mean by 'traffic passing through them'
16:47:02 <prasadv> michsmit: currently we are deriving the IP addresses to match that of src and dst group right
16:47:29 <banix> prasadv: I think you may be referring to what we are saying would be in the action, e.g, a service chain
16:47:38 <prasadv> banix:yes
16:48:05 <prasadv> if we were to have L2 firewall inserted,
16:48:11 <banix> prasadv: so that would not affect the classifier as we have it in the current model
16:48:29 <prasadv> it does not depend on the src and dest group IP
16:48:32 <prasadv> banix:yes
16:49:23 <banix> prasadv: I meant that would not require having new fields in the classifier. Do you agree?
16:49:52 <prasadv> or I can say send traffic that matches the following classifier from these set of ports to a VM that is analysing traffic
16:49:59 <s3wong> prasadv: so the use case is if only a selected set of traffic from src group or to dst group should subject to a particular action, how can we do it with the current model?
16:50:52 <prasadv> banix: we cannot define such a classifier with the current model
16:51:12 <prasadv> s3wong:yes
16:51:17 <ashaikh> prasadv: i think michsmit was suggesting to "classify" IP subnets for policy by putting them in  their own group (if i understood correctly) as an alternative
16:51:44 <ashaikh> (them = endpoints belonging to the subnet)
16:51:47 <banix> prasadv: I think Inow I understand what you say. Slow day :)
16:52:07 <michsmit> ashaikh: yes
16:52:21 <banix> so we can have the prts/vms in a group but
16:53:00 <banix> then we are limited if we want to apply a policy rule on a subset of traffic between such groups
16:53:21 <s3wong> banix: yes - I think that's what prasadv was referring to
16:53:25 <banix> I think we can keep this as something we discuss more and leave the model as is for now
16:53:27 <prasadv> ashaikh, michsmit: but it may not be just subnets right? Maybe I donot understand how michsmit is suggesting to do
16:53:35 <michsmit> banix: I would think that is the purpose of the classifier in the policy
16:54:31 <s3wong> sounds like it would be nice to be able to tag endpoints to subject to a set of actions directly (or matching tag) - can get complicated
16:54:39 <banix> michsmit: I think the issue is that if groups are made up of ports for example, then the classifier we have won't be able to classify traffic into different groups properly
16:55:20 <michsmit> banix: by ports, you mean Neutron ports, not L4 ports, correct ?
16:55:28 <banix> michsmith: in other words, port number, etc won't be enough
16:55:39 <banix> michsmith: yes
16:56:14 <s3wong> 5 minutes left - should we move this to ML again?
16:56:19 <banix> As we are approaching the top of hour should we keep the model as is for now but continue the discussion
16:56:30 <mestery> +1 to moving to ML.
16:56:34 <banix> s3wong: agree
16:56:36 <ashaikh> banix: yeah, makes sense
16:56:36 <michsmit> +1
16:56:37 <mestery> We're almost out of time, as s3wong indicates.
16:56:39 <prasadv> +1 ML
16:56:46 <s3wong> I am also guessing we won't have meetings over the next two weeks, right?
16:56:50 <banix> there is one thing i want to ask and that is about the PoC?
16:57:26 <s3wong> banix: yes?
16:57:36 <banix> are we planning to do this within the ML2 framework (which makes sense) and if yes, would this be done by ….
16:57:42 <mestery> banix: Lets converge on the PoC at the next meeting perhaps?
16:57:55 <banix> using a framework similar to how Router extension is done for ML2?
16:57:56 <mestery> Any takers to canceling the next week's meetings?
16:58:04 <mestery> banix: +1 to that idea in general.
16:58:09 <banix> ok
16:58:11 <thinrichs> I won't be here next week.
16:58:13 <banix> +1 for canceling
16:58:13 <s3wong> banix: that would be the plan, I think
16:58:37 <s3wong> mestery: so we will reconvene on Jan 2nd?
16:58:37 <mestery> OK, lets cancel this one, but how about if we meet next on January 2?
16:58:39 <mestery> Woudl that work?
16:58:55 <s3wong> mestery: Jan 2nd works for me
16:58:55 <prasadv> Yes for Jan 2
16:59:05 <banix> mestery: that would work for me
16:59:07 <michsmit> +1 Jan 2
16:59:12 <songole> Yes for jan 2
16:59:22 <mestery> #action mestery to send email canceling next week's meeting and noting we'll reconvene on January 2
16:59:25 <mestery> OK, thanks eveyrone!
16:59:29 <mestery> Lets continue the discussions on the ML.
16:59:31 <banix> Happy holidays :)
16:59:35 <mestery> Happy holidays!
16:59:38 <mestery> #endmeeting