16:01:19 <mestery> #startmeeting networking_policy
16:01:20 <openstack> Meeting started Thu Dec 12 16:01:19 2013 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:24 <openstack> The meeting name has been set to 'networking_policy'
16:01:29 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda
16:01:37 <sc68cal> morning
16:01:43 <mestery> #topic Action Items
16:01:49 <SumitNaiksatam> hi
16:01:57 <mestery> banix and alagalah: You guys have the first action items. Any updates?
16:02:06 <mestery> These were from last week.
16:02:33 <alagalah> mestery:  banix yes, I put together a strawman taxonomy and banix has fleshed it out, its available for comment
16:02:37 <banix> Aaalagalah, has prepared a resource diagram
16:02:39 <alagalah> #link https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit
16:02:47 <mestery> alagalah: Thanks for sharing that.
16:02:50 <mestery> Have people reviewed this yet?
16:03:34 <s3wong> mestery: no, just aware of it now
16:03:42 <thinrichs> Me neither--looking now.
16:03:51 * mestery gives everyone a minute, and then we can discuss it.
16:04:07 <alagalah> It was written last night, only shared this morning, so you are still getting "first look" thinrichs s3wong
16:04:24 <s3wong> alagalah: :-)
16:04:33 <mestery> Thanks for writing this up alagalah.
16:04:54 <thinrichs> Not so familiar with these diagrams--why are Security, QoS, Redirect not connected to anything?
16:05:22 <banix> thinrichs: These are not Neutron objects
16:05:36 <ashaikh> my first question is whether we also need a relation (mapping) from group to network -- i.e., are "endpoints" here just things that can be put in groups?  (nested groups may need this though)
16:05:38 <alagalah> thinrichs:  Good observation... yes as to banix's point, the idea is to show linkages to existing neutron objects and net new objects
16:05:51 <s3wong> what is the intended meaning of the Policy -> Group arrow?
16:05:53 <banix> so we were debating whether we put them in the figure tror not
16:06:07 <thinrichs> And did we settle on only having Networks and ports as endpoints?  I thought banix said in the google doc we had other objects.
16:06:27 <alagalah> ashaikh:  Great question, and if that is indeed necessary, we have a problem... imho references to existing neutron objects should really be at the edges (ie pure child nodes) of the taxonomy
16:07:17 <ashaikh> alagalah: it may be ok as is, but it would seem a natural mapping of group to network (as an option)
16:07:19 <alagalah> thinrichs:  I made a comment wrt "networks" and "endpoints" last night...
16:07:33 <michsmit> I assume that a given endpoint only a single network, correct ?
16:07:50 <mestery> michsmit: I would agree with that, and thinrichs had commented on that in the google doc as well.
16:08:42 <banix> michsmit: you mean a group cannot be made of more than one network? or i missed your point?
16:09:21 <michsmit> in the diagram, a group references 1 or more EPs which reference 1+ networks
16:09:30 <alagalah> ashaikh:  My only concern with that is that my understand (as naive as it is) is that group should be a collection of endpoints, and endpoints at this stage, seem to make sense to be ports or networks for ease of integration but I think its short sighted to limit it to that, since the intent is to provide an application centric API
16:09:43 <banix> ashaikh: we don't have nested groups as is; we need to add if we need it.
16:10:14 <alagalah> ashaikh:  Hence I think it makes sense to not have a network/port reference in group
16:11:19 <ashaikh> alagalah: i think that is simpler, but we could also think of groups as only collection of endpoints (i.e., ports) and neutron networks being a way to represent groups initially , with option for other mappings
16:11:19 <mestery> OK, so should we incorporate alagalah's diagram into the document?
16:11:22 <s3wong> alagalah: we do need some primitives as endpoints assigned to groups, if not network/port, what can these be?
16:13:17 <alagalah> ashaikh:  Yes, that makes sense to me, and hence the diagram reflects that imho, s3wong I think we need to eventually be able to identify application by LXC / some container identified by UUID, but thats a bigger topic, I'm just trying to build that idea into this
16:13:21 <ashaikh> alagalah: in short, what i think may be missing in the diag is a way to directly map a group to neutron network (i.e., does this say you have to first put it in an endpoint object)
16:13:45 <banix> ashaikh: Wouldn't a group with one endpoint (which is a network) give you the same?
16:13:48 <alagalah> ashaikh:  yes that is exactly what I'm trying to show here... and to be fair, I'm reflecting the tables but yes it makes sense
16:14:31 <thinrichs> s3wong: I have the same question.  If Neutron doesn't know what an 'app' is, it won't be able to enforce any policy about it.  I don't see how we can ask Neutron to enforce policy about objects it doesn't know about.
16:14:40 <ashaikh> banix: yes, it could, just that having to put a network in an endpoint seems a little superfluous (but i'm ok if it simplifies the imple)
16:15:43 <mestery> thinrichs: I get that point. But won't it focus on the objects it knows about?
16:15:50 <s3wong> thinrichs: yes, exactly
16:16:07 <michsmit> Overall, I like the diagram.  My 2 comments :  I don't like the pink line there, I think it should be removed. 2nd comment:  The reference for network and port should not have +
16:16:39 <banix> michsmith: instead of +, 1?
16:16:50 <michsmit> banix: yes
16:17:00 <thinrichs> mestery: Suppose the entire policy just says UUID1 can't send traffic over port 80 to UUID2.  But Neutron doesn't know what UUID1 or UUID2 are.  It can't enforce the policy.  What's the point of writing that policy?
16:17:20 <s3wong> michsmit: agree there, that pink line is strange; and an endpoint is one object, a group is a collection of endpoints
16:17:38 <ashaikh> michsmit: IMO the pink line explains how a groups and policies are expressed, so is useful
16:17:39 <banix> michsmith, s3wong: pink is a placeholder
16:17:57 <banix> the pink was boack at first :)
16:18:24 <banix> In the doc, we specify the policy between a source group and a destination group
16:18:40 <banix> So the pink line is to represent that relationship
16:18:50 <thinrichs> Do we ever foresee a policy that spans more than 2 groups?  Maybe a policy that talks about the need to waypoint communication between a source and a target e.g. through a proxy?
16:19:05 <thinrichs> If so, maybe we just want a + line from policy to group.
16:19:06 <ashaikh> banix: another way would be to have groups hang off of policy with a "2" annotation
16:19:07 <alagalah> thinrichs:  IDeally that is EXACTLY a valid policy and how it should be expressed... I think we should confuse how we identify endpoints, with the objects that the Action leverages
16:19:28 <banix> ashaikh: yes
16:19:30 <alagalah> thinrichs:  sigh, sorry that wasn't right
16:19:31 <s3wong> ashaikh: a policy is provided by a group A, another group who wants to talk to group A consumes the policy; I don't know if the pink line represents this well
16:19:43 <thinrichs> I guess I imagined that there were 3 groups in that policy: source, destination, and a collection of proxies.
16:19:52 <alagalah> s3wong:  Agreed, hence why it's pink and see the reference in the key
16:20:02 <ashaikh> thinrichs:  that list of waypoints could be expressed in the redirect action in that case
16:20:33 <ashaikh> s3wong: this is more a question then of having a policy attached to a group -- i find the produce/consume relation harder to understand
16:20:35 <thinrichs> ashaikh: but that was just an example off the top of my head.  Pick something that requires 3 groups but which doesn't have a pre-defined action built for handling the case.
16:20:36 <banix> thinrichs: the 3rd collection will be part of the action description
16:20:42 <michsmit> banix: agreed, we need a relationship of some sort there (pink line).  I would think the arrow comes from the group and we can leave out the src/dst group
16:21:15 <banix> So here is the pink question:
16:22:00 <ashaikh> thinrichs: in that case, i would express pairwise to be clear which communication the policy is governing
16:22:26 <banix> whether 1) we express the policy through producer/consumer relationship from groups point of view or 2) define the policy as governing traffic between two groups
16:22:38 <s3wong> ashaikh: that's fair, yet the arrow direction + src/dst reference makes it a bit unclear
16:22:42 <thinrichs> Another example with 3 groups: Suppose we want to prohibit traffic from src to dst from traveling through a specific group; we don't care where the traffic goes as long as it does NOT go through that group.
16:22:43 <alagalah> banix exactly... I made a comment in the BP last night along those lines
16:22:51 <banix> I think these are the two models we have been discussing for sometime
16:23:13 <alagalah> Yes, and making it pink was my hamfisted way of highlighting that the tables etc are kind of dependent on the policy model
16:23:15 <michsmit> banix:  I think those 2 models sum it up correctly
16:23:38 <s3wong> banix: good two models summary
16:23:40 <alagalah> michsmit:  I was under the impression we had to pick one
16:23:56 <ashaikh> thinrichs: you would just create a "security" policy that forbid that communication
16:23:58 <michsmit> We may be able to express both by showing that there can be more than 1 src group and more than 1 dest group
16:24:46 <michsmit> and allow the groups to refer to the policy as a src (provider) or destt (consumer)
16:24:55 <ashaikh> michsmit: if we can give flexibility to use either approach, it would be great
16:24:57 <thinrichs> ashaikh: would that policy be written in our policy language or in another?  I thought the point was to put such policies within our language.
16:25:10 <alagalah> michsmit:  I had that discussion with banix too, which means a table modification but makes sense
16:25:23 <alagalah> I personally like the consumes/produces model
16:25:35 <banix> michsmit: so if we allow possibly multiple source and multiple destination groups the two models become equivalent without needing "allow the groups to refer to the policy as a src (provider) or destt (consumer)" No?
16:25:46 <ashaikh> thinrichs: yes, our security policy, i.e., the one in the diag, which i assume has a deny type rule
16:25:52 <michsmit> banix: i think so
16:26:17 <mestery> OK, so lots of good discussion here around this diagram it appears.
16:26:23 <mestery> But it's almost halfway through the meeting now.
16:26:28 <mestery> And there are other items yet to cover.
16:26:38 <mestery> Any concrete action items we want out of this particular discussion?
16:26:39 <thinrichs> ashaikh: but I'm not saying src can't talk to that specific group (let's call it G); it's just that we don't want to route traffic between src and dst through G.
16:26:54 <mestery> I think we should migrate this taxonomy doc into the main google doc. Thoughts alagalah?
16:27:15 <s3wong> mestery: I guess we should incorporate the diagram into the document, and we can then comment on that diagram directly in the document
16:27:28 <alagalah> That would make sense... before we do, see that edit I made?
16:27:29 <banix> mestery: yes for moving to the main doc. LEt's see if we can reach an agreement in the next couple of minutes :)
16:27:33 <mestery> s3wong: Agreed.
16:27:36 <mestery> alagalah : Yes
16:27:40 <ashaikh> thinrichs:  then you're back to the waypoint example, and we could handle with the redirect/classifer policy
16:27:51 <mestery> #action alagalah to migrate taxonomy diagram into the main document
16:28:24 <ashaikh> i agree about putting this diag in the main doc with the changes suggested by banix and michsmit to accommodate both approaches
16:28:36 <banix> So are we going to allow both models by allowing multiple source and destination groups?
16:28:48 <s3wong> banix: we should
16:28:51 <banix> do we all agree that is the way forward?
16:29:00 <michsmit> banix: I think so
16:29:04 <s3wong> banix: +1
16:29:08 <prasadv> banix: +1
16:29:10 <thinrichs> banix: sure
16:29:31 <banix> Great
16:29:49 <ekarlso> what's network policy btw if anyone cares for after meeting
16:29:53 <mestery> OK, thanks banix.
16:29:57 <prasadv> sorry joined alittle late
16:30:05 <mestery> So, lets move on to the next topic.
16:30:06 <prasadv> where is the taxanomy in the document
16:30:26 <mestery> prasadv: See the link from earlier in the meeting (https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit?usp=sharing)
16:30:32 <s3wong> prasadv: https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit
16:30:35 <alagalah> prasadv:  Its not in yet, I didn't have edit access to the BP
16:30:35 <mestery> #topic Discussion Items
16:30:46 <mestery> alagalah: I just added you with edit writes so you're good.
16:30:56 <mestery> Next item: Endpoints/groups
16:31:07 <mestery> https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy (For the item on the agenda for those who don't have it open)
16:31:26 <mestery> The question in the agenda is: Endpoints belonging to multiple groups.
16:31:37 <mestery> I think thinrichs pointed this out in the gdoc as well.
16:31:42 <mestery> OR rather, asked about it.
16:31:54 <banix> mestery: yes.
16:32:27 <banix> Tried to put the questions on the google doc on the list of things to discuss
16:32:30 <thinrichs> Somebody else brought it up.  But the question is whether we want a classifier to have a broader range of test attributes than what was in the doc.
16:32:42 <Dimit> its powerfull, but can create confusion
16:32:54 <thinrichs> And I guess whether a classifier needs to test all of the possible attributes listed in the doc.
16:33:06 <ashaikh> don't we need to allow this to have different policies apply to the same endpoint?
16:33:11 <prasadv> i brought this up. I think it is needed
16:33:28 <banix> So the question is if we allow an endpoint being in multiple groups? Should we not allow it to start?
16:33:34 <mestery> So, if we allow this, then ordering of policies becomes an issue to solve.
16:33:44 <michsmit> we likely want to start off with very simple assignment.
16:33:45 <mestery> banix: Good point. First whether we allow it or not.
16:33:55 <s3wong> My take is the policy is applied from group to group, rather than pointing to an endpoint, therefore subjected to different policy even with a common endpoint in different groups should be fine, right?
16:34:11 <banix> mestery: yes, and possibly having conflicting policies.
16:34:14 <thinrichs> mestery: but I think the difficulty in implementation will affect whether or not we allow it.
16:34:29 <ashaikh> mestery: wsn't there a suggestion to have  a priority with policy rules to address that
16:34:41 <mestery> thinrichs: Agreed, and as michsmit said, we may want to start with the simplest case, likely not allowing this.
16:34:47 <prasadv> s3wong: how does one resolve conflicts as pointed in the document
16:34:53 <mestery> ashaikh: That is one way to solve it, yes.
16:35:02 <Dimit> priority alone doesnt solve it. needs to be global
16:35:02 <ashaikh> thinrichs: agree, but the impl could check and disallow if it can't support ?
16:35:14 <banix> ashaikh: that would apply in a policy among policy rules which may not be necessary after all.
16:35:18 <alagalah> prasadv:  yes, the priority thing is more complex than it appears on the surface... think ye old Cisco ACLs
16:35:30 <s3wong> ashaikh: priority is for having more than one policy rule classifier to match a traffic flow
16:35:48 <ashaikh> s3wong: yes, a simpler cas then
16:36:02 <banix> s3wong: still problem may show up if we allow one endpoint in multiple groups; I commented on the doc.
16:36:26 <thinrichs> It's pretty common to have a conflict resolution scheme for policy languages, e.g. AD uses hierarchies, firewalls use (implicit) priorities.
16:36:43 <thinrichs> I don't think the need for conflict resolution is a show-stopper.
16:37:00 <alagalah> thinrichs:  Agreed
16:37:05 <prasadv> thinrichs: Yes I think so too
16:37:07 <banix> thinrichs: Question is if we need to deal with it now?
16:37:12 <Dimit> hierarchies driven by users assigning the policy is an option
16:37:13 <thinrichs> I think it's more a question of how hard is it to write the policy you want and get what you expect.
16:37:17 <alagalah> thinrichs:  But needs to be explicitly called out, rather than implied
16:37:18 <michsmit> initially, a EP in a single group will be easiest and then we could introduce attribute-based assignment of EP to group
16:37:24 <alagalah> thinrichs:  bingo
16:38:08 <banix> michsmit: makes sense
16:38:13 <thinrichs> alagalah: definitely needs to be part of the language spec if conflicts are possible.  And I agree that the order that rules were added via API calls is a confusing way to resolve conflicts.  So if we go with priorities, they ought to be set explicitly.
16:38:34 <mestery> thinrichs: Agree with you on that point.
16:38:46 <banix> There are two different questions here:
16:39:13 <alagalah> thinrichs:  Yes, and to my point in the BP about whether this is a promise theory based implementation or...
16:39:33 <banix> 1) establishing order among policy rules in a policy, 2) order among policies
16:40:09 <banix> Let me correct the last statement
16:40:24 <Dimit> banix: agreed
16:40:25 <michsmit> ideally if policy rules can be expressed without ordering, things will be easier to manage
16:40:26 <alagalah> One way would be that if there is conflict to push it back to the app to work out... rather than partial implementation.. ie ask for something else
16:40:39 <alagalah> Like the 413 return code
16:40:58 <thinrichs> banix: agreed those are different.
16:41:05 <ashaikh> michsmit: the explicit priority handles that case i think, right?  i'm less sure about the right way to handle globally
16:41:08 <prasadv> alagalah: we should do that anyway after the priorities right?
16:41:09 <banix> 1) establishing order among actions in a policy rule, 2) order among policy rules 3)  order among policies
16:41:40 <thinrichs> banix: 1 is interesting b/c there may be multiple actions that we can apply simultaneously.
16:42:00 <banix> 1 we know the answer to (ordered list of action) 2, may not be a real issue if we do not allow overlapping classifiers 3) we can leave for later by not allowing an EP being in multiple groups
16:42:10 <thinrichs> It depends on the actions we have of course.  But right we need to resolve conflicts (1) within a policy, (2) across policies.
16:42:24 <michsmit> 1 can often be expressed in an order independent manner
16:42:35 <alagalah> prasadv:  Well, it maybe away of ensuring that ordering is irrelevant, ie a more "functional programming" style approach, policy is implemetnted same regardless of ordering
16:42:46 <Dimit> banix: overlapping classifiers are needed for several expressions
16:42:49 <thinrichs> banix: I fear that disallowing overlapping classifiers won't be practical.
16:43:01 <s3wong> banix: (2) is somewhat difficult to enforce - it implies we have to run through all classifier and reject overlap at API level
16:44:12 <banix> To narrow down the problem we are discussing, is there agreement that EP belongs to one group for now?
16:44:52 <s3wong> banix: also (1) action list may not be ordered as different action_type can be executed simultaneously
16:45:16 <thinrichs> banix: if each EP belongs to a single group, can't we still have multiple policies applied to that group and hence have to deal with conflicts?
16:45:40 <thinrichs> If we're dealing with conflicts anyway, we might as well allow an EP to belong to multiple groups and apply the same conflict resolution to it.
16:45:43 <banix> s3wong: then, there won't be a need to establish order
16:46:00 <alagalah> thinrichs:  #agreed
16:46:59 <s3wong> thinrichs: so in essence you are suggesting that we establish orders across policies?
16:47:24 <Dimit> thinrichs: different implementations will end up resolving conflicts in a different manner. users will be confused
16:47:33 <thinrichs> s3wong: I'm not suggesting a conflict resolution strategy yet (though order is typical).  I'm just trying to understand if there's anyway to avoid conflicts first.
16:47:33 <mestery> s3wong thinrichs: Orders == priorities
16:47:48 <banix> thinrichs: I see your point
16:47:57 <thinrichs> Dimit: The conflict resolution I'm suggesting will be part of the language spec.  So all plugins implement it the same.
16:48:32 <banix> mestery: you think we can use a cross-policy priority to solve the problem?
16:48:34 <prasadv> thinrichs: I agree it should be part of the spec.
16:48:34 <ashaikh> mestery: so you mean that we don't want explicit priorities, rather governed by ordering ?
16:48:55 <Dimit> thinrichs: i cant see a unique answer no matter what. users will not know what happened
16:48:59 <michsmit> between a given pair of groups, do we expect more than 1 policy to be applied ?
16:49:10 <mestery> I think thinrichs had suggested using priorities for policies, which may solve the problem ashaikh, right?
16:49:11 <alagalah> ashaikh:  I think his point was that whether you choose ordering or priority, you still end up at the same place
16:49:27 <mestery> alagalah: ^^^^ That too :)
16:49:43 <thinrichs> Dimit: suppose we require every policy to be assigned a unique number (via the API call).  The language spec says that the policy that applies with the highest priority is the one that applies.  Then the user understands what is happening.
16:49:53 <ashaikh> michsmit: couldn't you have have a redirect + QoS policy, for example between groups?
16:50:19 <ashaikh> alagalah: yes, same place, except not implicit in the ordering
16:50:30 <banix> ashaikh: but those will be policy rules in a single policy
16:50:37 <michsmit> ashaikh:  yes, but couldn't they be combined into a single policy
16:51:03 <michsmit> banix:  your fingers are faster than mine :-)
16:51:04 <ashaikh> michsmit:  yes, as mult policy_rules
16:51:07 <s3wong> michsmit: more than one policy: sure, a policy for app tier, an another policy for Sharepoint application specifically
16:51:08 <thinrichs> mestery: I think priorities are one solution, though an absolute priority like I mentioned in the example above is not the only way.  We could have a partial order of priorities and a mechanism for combining policies of the same priority into one.
16:51:15 <hajay___> openstack-meeting-alt
16:51:40 <prasadv> s3wong: can't you combine that into policy rules if the groups are the same
16:51:45 <Dimit> thinrichs: so two priorities: policy and classifier. i can still see conflict. for ep1, policy A preffered when talking to Ep2 and B preferred when talking to ep3
16:52:08 <mestery> Just a note folks: We have 9 minutes left, there is another meeting in this channel immediately following this one.
16:52:09 <banix> then in a single policy, the order can be established more easily.
16:52:12 <thinrichs> Dimit: we need 2 levels of conflict resolution: within the policy and across policies.
16:52:29 <thinrichs> Dimit: I was giving the cross-policy resolution scheme.
16:52:36 <s3wong> prasadv: I picture that we want policies to be reused, so using it like two separate ones seems to make sense
16:52:51 <michsmit> s3wong: if we limit an EP to a single group, the policy could be combined as well in the case of app tier/Sharepoint
16:53:11 <michsmit> s3wong: at least initially
16:53:13 <thinrichs> Dimit: The resolution scheme within a policy should ensure that we can write a policy that describes both QOs and Security.  So a strict ordering there isn't so good either.
16:53:18 <Dimit> thinrichs: cross policy resolution is different for different end poinds . its possible
16:53:30 <banix> michsmit: I think that is the way to go
16:53:56 <s3wong> michsmit: then policy combination become an item we have to support in the framework
16:54:03 <thinrichs> Dimit: sure--I could see priorities on groups as well.  There are a bunch of variations here.  The important thing is that the language chooses one.
16:54:22 <banix> should we continue this discussion on mailing list?
16:54:43 <thinrichs> I would think we start by figuring out the conflict resolution scheme for an individual policy and then worry about cross-policy conflict resolution.
16:54:51 <s3wong> then going back to thinrichs' point, at time of combining policies, we would need to resolve conflicts
16:54:56 <alagalah> thinrichs:  yes
16:54:58 <mestery> banix: +1 to the mailing list discussion
16:55:03 <s3wong> banix: +1
16:55:07 <alagalah> banix: +1
16:55:07 <prasadv> +1
16:55:08 <mestery> We're almost out of time here.
16:55:12 <alagalah> What mailing list :)
16:55:12 <Dimit> thinrichs: exactly.  it can get arbitrarily complex. thats why i suggest single group for ebd point and simple resolution
16:55:17 <mestery> #topic Open Discussion and Next Steps
16:55:28 <mestery> For the last 5 minutes, lets see what we'd like to accompliush for next week.
16:55:35 <mestery> And then do open discussion for hte last few minutes.
16:55:40 <banix> openstack-dev mark with [Neutron][Policy]
16:55:54 <alagalah> banix:  ty
16:56:00 <s3wong> I did some update on the action_type=='qos' just before the meeting, please take a look
16:56:11 <mestery> #info Emails for Neutron policy should go to openstack-dev marked as "[neutron] [policy]"
16:56:18 <mestery> s3wong: Thank you for that.
16:56:30 <s3wong> Also, I would like the community to converge on the default set of actions we would force all plugins to support
16:56:45 <mestery> s3wong: Can you send an email with that to the list?
16:56:55 <s3wong> mestery: certainly
16:56:55 <prasadv> s3wong:are you going to put more clarity on redirect policy
16:57:09 <banix> Let us finalize the object model (with support for combining two model)
16:57:19 <Izik_Penso> fff
16:57:21 <s3wong> prasadv: yes, will also send out to ML to enlist community suggestions/opinions
16:57:41 <banix> s3wong: yes, we need that
16:57:45 <michsmit> banix: +1 I think there is more thinking we need to do on combining the models
16:57:50 <alagalah> s3wong:  I like it but do we want to mix classification with queueing in the same action ?
16:58:00 <s3wong> prasadv: also, you mentioned you want some redirect dst list mgmt, we should discuss that on ML as well
16:58:14 <prasadv> s3wong: yes we do need to do that
16:58:33 <mestery> OK, so lets wrap things up here.
16:58:40 <mestery> We took a few action items which will appear in the meeting minutes.
16:58:46 <mestery> I'll add them for next week to followup on.
16:58:58 <banix> Thanks.
16:59:01 <mestery> Lets continue discussions on the ML for this week for any items which were not discussed here.
16:59:07 <mestery> And thanks for attending everyone!
16:59:10 <mestery> #endmeeting