19:03:06 <SumitNaiksatam> #startmeeting networking_policy
19:03:07 <openstack> Meeting started Thu Mar 27 19:03:06 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:10 <openstack> The meeting name has been set to 'networking_policy'
19:03:14 <mandeep> Hi SumitNaiksatam
19:03:29 <mandeep> Hi Swami, welcome to policy meeting
19:03:30 <SumitNaiksatam> we are at the OVS hackathon
19:03:42 <s3wong> I am also, in the other roo,
19:03:42 <SumitNaiksatam> Kyle and some others are busy with that
19:03:44 <Swami> mandeep: hi
19:03:44 <s3wong> room
19:04:08 <SumitNaiksatam> most folks are here but in different rooms :-)
19:05:04 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#March_27.2C_2014
19:05:18 <SumitNaiksatam> #topic Action Item Review
19:05:43 <SumitNaiksatam> “Team to flesh out PoC details in doc"
19:05:54 <mandeep> #link https://docs.google.com/a/noironetworks.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit#
19:06:02 <SumitNaiksatam> mandeep: thanks
19:06:10 <mandeep> Updated, please review and comment in the doc
19:06:17 <SumitNaiksatam> mandeep volunteered to add content here
19:06:21 <SumitNaiksatam> its been done
19:06:25 <s3wong> Document is still being edited when I opened it :-)
19:06:35 <banix> lets have a quick look
19:06:45 <SumitNaiksatam> lets get into the details of that as a separate agenda topic
19:06:51 <mandeep> Changes order of (a) and (b) based on review.
19:07:01 <SumitNaiksatam> second action item was “mestery to check if meeting can be moved by an hour"
19:07:14 <s3wong> mandeep: since roles (admin vs tenant) is being emphasized here, is it customary for Neturon API layer to know what APIs to expose to admin vs tenants?
19:07:17 <SumitNaiksatam> i dont think we have changed the item yet (obviously)
19:07:22 <s3wong> or it is just a matter of keystone?
19:07:25 <SumitNaiksatam> s3wong: one sec
19:07:48 <SumitNaiksatam> it does not matter today since there is no follow up ODL meeting
19:08:05 <SumitNaiksatam> we will check if can change the time for next week
19:08:23 <SumitNaiksatam> #action mestery to check if meeting can be moved by an hour
19:08:26 <Swami> s3wong: At the API layer today all API's are exposed.
19:08:41 <SumitNaiksatam> #topic PoC Proposal
19:08:55 <s3wong> SumitNaiksatam: I think the current time is OK. The ODL status meeting itself is becoming a smaller event now we break into sub-groups
19:09:15 <mandeep> s3wong: The use-case is written in terms of roles, the API does not have to be exactly that - it needs to support this use case
19:09:17 <banix> the documen reads: Show automatic orchestration that can respond to changes in policy or infrastructure without requiring human interaction to translate intent to specific actions (like say with HEAT today)
19:09:18 <SumitNaiksatam> s3wong: ok cool, whatever works for you guys
19:09:30 <banix> so there are two things in there
19:09:44 <SumitNaiksatam> banix: yes go ahead
19:10:12 <banix> one the exposure ofpolicy to HEAT and the other dealing wih changes in policy
19:10:37 <SumitNaiksatam> banix: ofpolicy?
19:10:41 <s3wong> of policy
19:10:45 <banix> bth good but may be we separate them; mainly tomake sure we get to the first one even if we dont get to do the second by PoC
19:10:59 <prasadv> as long as api are present, heat plugins should be easy
19:11:03 <banix> s3wong: yes
19:11:09 * SumitNaiksatam distracted by openflow discussion (ofpolicy)!
19:11:23 <banix> prasadv: yes and you guys have done some ork along that line
19:11:28 <s3wong> banix: so your opinion is that you want PoC to be more about Heat and static policy applying
19:11:45 <Swami> sumit: is there are separate thread for the ofpolicy
19:11:51 <s3wong> banix: rather than demo-ing the ability to guard the contract in case of change?
19:11:53 <banix> s3wong: no; I want to call these two things as wo separate things
19:11:55 <SumitNaiksatam> Swami: no
19:12:07 <SumitNaiksatam> banix: yes they are separate itesm
19:12:19 <mandeep> banix: My intent here was more about providing some contrast with HEAT, the HEAT exposure is a separate item.
19:12:27 <SumitNaiksatam> banix: i think the dependency of the Heat work is on the API and resource model being fleshed out
19:12:28 <banix> for the reason i mentioned: first part easier than the second part ...
19:12:30 <mandeep> banix: I will add that
19:13:04 <s3wong> mandeep banix SumitNaiksatam: with these two items, say we can't do both before J-Summit, which one has higher priority?
19:13:11 <SumitNaiksatam> i would also like to reiterate that the value of this group policy model should be apparent regardless of heat
19:13:17 <s3wong> i.e., which one is more preferred to be shown as a demo
19:13:19 <banix> mandeep: make sense;  thanks
19:13:20 <s3wong> or PoC
19:13:56 <banix> s3wong: obviously the dynamic changes to poicy is more interesting ut more difficult
19:14:02 <SumitNaiksatam> s3wong: like i said, Heat work can start as soon as the API/resource model is ready on the Neutron side
19:14:03 <banix> wondering if we may not get there
19:14:38 <SumitNaiksatam> what is being referred to the second part of the PoC here can also proceed in parallel at that point
19:14:40 <banix> the HEAT exposure seems like a low hanging fruit tat can be ore meaningful to some non networking people
19:14:44 <prasadv> sumitNaiksatam; I agree that showing policy above and beyond heat would be important
19:14:53 <banix> SumitNaiksatam: yes agree
19:15:07 <mandeep> banix: I agree
19:15:09 <nbouthors> Is there a way to show what policy is applied to a group in the demo
19:15:21 <SumitNaiksatam> banix: yes, and i think that can proceed in parallel
19:15:57 <s3wong> So we now aim to demo the ability to change policy and contract being guarded
19:16:05 <mandeep> nbouthors: I was not sure as to what Horizon support that we will have at this time. Still looking into that
19:16:59 <s3wong> SumitNaiksatam: this dynamic change of policy thing may lead us to conflict resolution decision earlier than we projected
19:17:07 <SumitNaiksatam> s3wong: ok
19:17:17 <banix> s3wong: sorry i missed your earlie comments on priority; first item should be easy to achieve; the queston is if/when we have the second prt. that's all i was saying
19:17:31 <SumitNaiksatam> s3wong: the dynamic change of policy is the second part of the PoC
19:18:01 <SumitNaiksatam> out first punch line is that this is a easier model for the App Dev to use
19:18:14 <SumitNaiksatam> that is the first thing we will show from the PoC
19:18:27 <banix> by first item i meant having the HEAT exposure which should be doable if the rest is in place. Right prasadv?
19:18:31 <SumitNaiksatam> that is by way of definition of the group policy model
19:18:44 <banix> SumitNaiksatam: agree; exactly
19:18:50 <s3wong> banix: as you said the second part is much more difficult, and therefore we may have to accept that by J-Summit, part 1 is all we can demo
19:19:15 <prasadv> banix:yes
19:19:16 <mandeep> s3wong: Let us see how far we can get ;-)
19:19:26 <SumitNaiksatam> mandeep: yeah
19:19:32 <banix> s3wong: don't understimate mandeep :)
19:19:40 <banix> just kiddig, all of us.
19:19:46 <mandeep> banix: ;-)
19:19:50 <SumitNaiksatam> so other than that do the steps defined look good to all
19:20:00 <s3wong> banix: the only unknown for part 1 is the ovs agent / mech driver - which I never heard back from mestery :-)
19:20:27 <SumitNaiksatam> s3wong: why are there any changes needed for that?
19:20:42 <banix> SumitNaiksatam: yes looks good but will go through it more carefully and make comments if necessary by tomorrow latest
19:20:42 <s3wong> SumitNaiksatam: rendering of policy
19:20:46 <mandeep> s3wong: We will use the mech_driver as is.
19:20:52 <SumitNaiksatam> banix: yes sure
19:21:17 <SumitNaiksatam> s3wong: rendering policy here is the mapping of policy constructs to the existing neutron constructs
19:21:44 <mandeep> banix: I will be updating the use-case with a little more detail on these steps later today/tomorrow. Please review that as well.
19:22:01 <SumitNaiksatam> s3wong: we dont anticipate any changes to the ML2 plugin or drivers at this point
19:22:05 <banix> mandeep: sure will do
19:22:12 <s3wong> SumitNaiksatam: how is 'redirect' done with current Neutron construct? (sorry, I really don't know)
19:22:14 <SumitNaiksatam> we might need to make changes to the adv services
19:22:16 <SumitNaiksatam> maybe
19:22:37 <SumitNaiksatam> s3wong: redirect falls in the realm of the services’ discussion
19:22:48 <SumitNaiksatam> s3wong: redirect to a single service is easier than to a change
19:22:55 <SumitNaiksatam> *chain
19:23:23 <SumitNaiksatam> s3wong: but we might need to some changes to the adv services (my earlier point)
19:23:31 <banix> Yes starting with a single service makes sense
19:23:41 <s3wong> SumitNaiksatam: also for endpoint in endpoint group, I guess we need to completely resolve the Neutron port -> classifier mapping -> actions set
19:23:42 <SumitNaiksatam> s3wong: i might be missing something that you have noticed
19:23:51 <mandeep> Service chain is out of scope for this PoC
19:24:12 <SumitNaiksatam> ok so mandeep put a stake in the ground, i like that :-)
19:24:33 <banix> sounds reasonable
19:24:34 <SumitNaiksatam> s3wong: ok you are getting into the model discussion, that is the next point in the agenda
19:24:49 <s3wong> SumitNaiksatam: I am also guessing if we only support 'allow' / 'deny', then we render {classifer, action} to just security group entry?
19:25:13 <SumitNaiksatam> s3wong: hang on to that question
19:25:20 <s3wong> SumitNaiksatam: sorry, I am just trying to picture how it would work
19:25:30 <SumitNaiksatam> s3wong:  we can talk about that as a part of the model discussion
19:25:33 <SumitNaiksatam> we probably need to spend some more time digesting the PoC proposal
19:25:41 <SumitNaiksatam> but at a high level i think we have agreement
19:25:48 <banix> yes
19:25:51 <SumitNaiksatam> so we will start marching on this
19:25:54 <prasadv> yes
19:26:07 <SumitNaiksatam> unless we have any major objections
19:26:13 <SumitNaiksatam> we can evolve the scope as we progress
19:26:21 <SumitNaiksatam> i mean not increase the scope :-)
19:26:22 <s3wong> SumitNaiksatam: no problem - let's move forward
19:26:32 <SumitNaiksatam> ok good
19:26:44 <SumitNaiksatam> #action team to formally working on the PoC…yay!
19:26:56 <rms_13> :)
19:27:11 <SumitNaiksatam> #topic Group Policy Model
19:27:22 <SumitNaiksatam> so some revisions were made
19:27:22 <s3wong> SumitNaiksatam: is the division of labor the same as before, or we redivide up the work?
19:27:32 <SumitNaiksatam> #undo
19:27:33 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2be7750>
19:28:10 <prasadv> s3wong: I think we need do a little bit of design just like last time
19:28:17 <SumitNaiksatam> prasadv: sure
19:28:20 <prasadv> before we jump to work items
19:29:11 <SumitNaiksatam> but i am thinking the broad division of work can proceed along earlier lines
19:29:53 <SumitNaiksatam> #topic Group Policy Model
19:30:07 <SumitNaiksatam> we have some revisions
19:30:16 <rms_13> link please
19:30:17 <prasadv> sumitnaiksatam: we should list broad work items then at the end
19:30:23 <SumitNaiksatam> not sure how many people had a chance to review
19:30:25 <SumitNaiksatam> sure
19:30:41 <mandeep> #link https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00
19:30:42 <banix> just saw it beore the meeting
19:30:45 <rms_13> thx
19:30:48 <SumitNaiksatam> mandeep: thanks
19:30:57 <SumitNaiksatam> banix: thanks, i havent yet looked at your comments
19:31:11 <SumitNaiksatam> this is trying to make it consistent with what is being discussed in ODL, etc
19:31:13 <banix> SumitNaiksatam: not critical
19:31:18 <Swami> I will take a look at it.
19:31:32 <SumitNaiksatam> also, we tried to walk through the current PoC proposal and validate the model against what is required there
19:31:41 <SumitNaiksatam> Swami: thanks
19:31:42 <banix> so we have added the Contract Scope
19:31:50 <SumitNaiksatam> banix: yes
19:31:53 <s3wong> SumitNaiksatam: I agreed, this looks much more similar to what we had before
19:32:08 <SumitNaiksatam> s3wong: “before”?
19:32:38 <s3wong> SumitNaiksatam: what was writeen in the design doc; except of course action changed a lot :-)
19:32:54 <banix> note page 11 with current Neutron objects
19:33:16 <SumitNaiksatam> s3wong: ok :-)
19:33:19 <rms_13> contracts? seriously?
19:33:32 <rms_13> Whats wrong with Policy (group of policy rule)
19:33:35 <s3wong> banix: which is not much :-)
19:33:38 <SumitNaiksatam> rms_13: yeah seriously :-)
19:33:45 <SumitNaiksatam> rms_13: it makes you accountable :-)
19:33:54 <banix> isnt service flavor expected to be associated with policy_rule?
19:34:03 <banix> rather thatn policy/contract?
19:34:35 <SumitNaiksatam> banix: not sure why it will associated with a rule?
19:34:42 <s3wong> SumitNaiksatam: action is a dict, some it is just {action_type, obj}
19:34:45 <banix> or an action?
19:35:08 <s3wong> SumitNaiksatam: for 'redirect', now you are restricting user to only put at most one Neutron object to redirect to?
19:35:43 <banix> can't a contract be associaed with multiple flavors?
19:35:50 <SumitNaiksatam> banix: one sec, let me respond to s3wong first
19:35:59 <banix> SumitNaiksatam: sre
19:35:59 <prasadv> s3wong: redirect goes to another contract
19:36:01 <banix> sure
19:36:13 <SumitNaiksatam> s3wong: yeah what prasadv said ^^^
19:36:27 <s3wong> prasadv: and contract scope doesn't allow you to get a list of objects anyway?
19:36:51 <prasadv> s3wong: what object? nuetron?
19:36:58 <SumitNaiksatam> s3wong: i think you need to come over to our room :-)
19:37:16 <SumitNaiksatam> s3wong: ok if we address your concern offline?
19:37:18 <s3wong> prasadv: yes - if a tenant redirect it to a contract scope, what does that relaly mean?
19:37:45 <SumitNaiksatam> s3wong: ^^^ ?
19:38:06 <SumitNaiksatam> we can get back to banix
19:38:08 <banix> i see multiple flavors for a contract is there.
19:38:39 <mandeep> s3wong: policy rule redirects to a contract. The visibility of contracts is limited by scope.
19:38:45 <SumitNaiksatam> banix: to your question, what is currently shown is the relationship from contract to a service “type/flavor”
19:39:08 <banix> SumitNaiksatam: yes noticed that. thx
19:39:08 <SumitNaiksatam> banix: i think that is different from a particular instace of a service
19:39:17 <SumitNaiksatam> *instance
19:39:40 <banix> so what does it mean to asociate a contract with a flavor?
19:39:44 <SumitNaiksatam> banix: i believe what you are looking for is the latter?
19:39:46 <s3wong> mandeep: so it is assumed that the provider of such contract will consume the traffic?
19:40:46 <SumitNaiksatam> banix: so if you want to look up contracts to understand which contract you need to consume so as to be able to get a particular service
19:41:06 <SumitNaiksatam> banix: you need to know what service that contract is offering access to
19:41:23 <rms_13> Its a nit, but will it make more sense to call "contract  scope" a "contract handle" ?
19:41:27 <SumitNaiksatam> banix: the contract to flavor relationship provides that
19:41:28 <banix> SumitNaiksatam: hmmm I see
19:41:34 <SumitNaiksatam> rms_13: hang on
19:41:51 <SumitNaiksatam> rms_13: lets not discuss naming conventiong now
19:41:58 <SumitNaiksatam> rms_13: we have beaten that to death
19:42:12 <rms_13> fine
19:42:12 <SumitNaiksatam> rms_13: i am not saying we have to accept this convention
19:42:22 <SumitNaiksatam> rms_13: we can have a separate agenda item for that :-)
19:42:36 <mandeep> rms_13: No, we actually mean a scope that filters to 0 to n entities. A handle (in my view) would be an identity of a specific provider
19:42:47 <SumitNaiksatam> for now i would really like to get closure on the model (at least a first iteration) to make progress for the PoC
19:42:48 <mandeep> SumitNaiksatam: OK
19:42:57 <rms_13> coo
19:42:58 <SumitNaiksatam> this is a dependency for the whole project to progress
19:43:00 <rms_13> *cool
19:43:03 <SumitNaiksatam> rms_13: thanks for understanding
19:43:08 <SumitNaiksatam> banix: sorry go ahead
19:43:21 <prasadv> provided contract scopes, does or will it include keystone user scopes? Probably not right?
19:43:23 <s3wong> SumitNaiksatam: is contract to flavor association one to one or to a list of flavors?
19:43:31 <banix> I had misunderstood why flavors wre in the model
19:43:43 <SumitNaiksatam> s3wong: i thought i made it one to many (at least i intended to)
19:44:01 <banix> it is oneto many
19:44:02 <SumitNaiksatam> s3wong: just confirmed, its 1 to [0..n]
19:44:07 <SumitNaiksatam> banix: yeah
19:44:11 <banix> i missed it the first i lookedat the doc
19:44:15 <SumitNaiksatam> does that make sense?
19:44:21 <banix> yes
19:44:39 <s3wong> SumitNaiksatam: yes 1 to . - so in that diagram it means one to many
19:44:41 <SumitNaiksatam> sorry, font was small
19:44:50 <s3wong> SumitNaiksatam: thanks
19:44:50 <SumitNaiksatam> s3wong: yes, is that okay?
19:45:07 <s3wong> SumitNaiksatam: yes
19:45:08 <SumitNaiksatam> s3wong: ok good
19:45:11 <banix> wrt actions referring to contracs, are we making this mor complicated than it shoud be?
19:45:35 <SumitNaiksatam> banix: ok
19:45:36 <rms_13> +1 banix
19:46:07 <s3wong> banix: I agreed. What is action -> contract? I can't quite picture that (hence the questions above)
19:46:13 <s3wong> sorry for my ignorance...
19:46:18 <mandeep> banix: How would you specify a service chain? The contract solves that problem
19:46:18 <SumitNaiksatam> banix: but this it consistent with the rest of the model and the goal for a level of dynamic binding
19:47:13 <mandeep> s3wong: redirect action needs to consume a service - and that is defined by contract
19:47:14 <banix> mandeep: in the earlie model, we were saying that is defined outside the policy
19:47:30 <thinrichs> How does a contract allow us to represent a service chain?
19:47:58 <mandeep> banix: My understanding was that in the advanced services IRC there was an agreement to use contarcts for chains
19:47:59 <banix> so a contractis essentially a wrapper for the servce chain?
19:48:13 <mandeep> thinrichs: Yes
19:48:34 <s3wong> mandeep: I see, using contract as a way to eventually get to an endpoint group where the service belongs to
19:48:42 <mandeep> banix: exactly
19:49:17 <thinrichs> mandeep: My question was How--not if.  Maybe an example?  I'm thinking of a contract as a pointer to a collection of policy rules.
19:49:18 <mandeep> s3wong: Yes, that is the intent
19:49:26 <s3wong> and use classifer or label to redirect to a particular EPG in case a contract is associated with many EPGs
19:49:47 <rms_13> maybe a naive question but I would still ask :), why cant action be redirect to EPG? Wont we achieve svc-chain like that?
19:50:08 <s3wong> mandeep: starting to get the intent. Need to think through the use cases to make sure it works well
19:50:27 <mandeep> thinrichs: In the advanced services, the discussion was to use the "consumes" relationship to identify the providing entity and the constraints on that service (like available ports)
19:50:45 <prasadv> rms_13: epg is wrapped with contract and redirecting to a contract means redrecting to epg right?
19:50:52 <SumitNaiksatam> btw, the services’ discussion was the next point in the agenda
19:50:58 <mandeep> prasadv: Yes
19:51:16 <SumitNaiksatam> can we keep the redirect action aside for a min?
19:51:17 <banix> mandeep: are you referringto the meeting yesterday?
19:51:31 <banix> SumitNaiksatam: go ahead pls
19:51:31 <mandeep> rms_13: Allows you to restrict say the ports available from that EPG
19:51:48 <thinrichs> Should I be thinking of the policy we're targeting with an action as a big if-then-else block directing what should be done?
19:51:50 <SumitNaiksatam> at this point is everyone comfortable with the other aspects of the model?
19:51:52 <mandeep> banix: I think that was the week before that
19:52:07 <banix> mandeep: thx will go back and read.
19:52:13 <rms_13> mandeep: understood.
19:52:31 <s3wong> prasadv: not necessary, it is great pictorial representation, but in reality a contract can be reused by other EPGs
19:52:41 <mandeep> thinrichs: I would not characterize as that. That would not allow for composition
19:53:30 <banix> SumitNaiksatam: yes the rst looks good
19:53:31 <thinrichs> mandeep: if the thens are actions then those actions can target other contracts, and we get composition.  ???
19:53:32 <SumitNaiksatam> my question to everyone (if you keep the redirect action aside) are you comfortable with the other aspects of the model?
19:53:39 <SumitNaiksatam> banix: good
19:53:48 <rms_13> does that mean we have to have contract -> policy rule as 1->M
19:53:50 <prasadv> s3wong: I guess it means contract+epg
19:54:22 <SumitNaiksatam> rms_13: that is how it is
19:54:36 <mandeep> thinrichs: IRC is probably a difficult way to explain that, let me try and write that in the doc and then send a link to you.
19:54:43 <SumitNaiksatam> rms_13: its acutally *:n
19:54:52 <rms_13> it shows *:n
19:54:55 <rms_13> k
19:55:11 <SumitNaiksatam> yeah, same policy_rule can be reused
19:55:13 <SumitNaiksatam> *reused
19:55:26 <s3wong> SumitNaiksatam: I finally have a grasp of what the model is trying to accomplish, but too early for me to say deifnitively "OK with it"
19:55:28 <thinrichs> mandeep: that'd help.  Maybe an example would suffice--and would likely help others.  Maybe just one of the design docs.
19:55:40 <SumitNaiksatam> s3wong: good
19:56:31 <s3wong> Well 4 more minutes :-)
19:56:44 <SumitNaiksatam> s3wong: thanks for keeping track :-)
19:57:19 <SumitNaiksatam> i want to get preliminary validation from the team if we are comfortable with moving forward with this model at least for the PoC
19:57:32 <SumitNaiksatam> the redirect action is TBD
19:57:51 <SumitNaiksatam> but other than that
19:58:00 <banix> yes i think the rest is mainly what we have had
19:58:01 <SumitNaiksatam> also the specifics of other actions are TBD
19:58:14 <SumitNaiksatam> banix: there are things which have evolved
19:58:23 <mandeep> thinrichs: The basic premise in the contract is that it is white list only. With that we can define multiple subjects (policy rules) in a contract that may be overlapping and the identify all that is allowed. In that context this is not an if then else, but a declartion of intent which could then be realized using if then else or a FOL resolution ...
19:58:31 <SumitNaiksatam> banix: first it was the notion of the contract
19:58:31 <s3wong> SumitNaiksatam: I think it isn't so much about 'redirect' in general, but wrapping our heads around action pointing to another contract
19:58:53 <SumitNaiksatam> s3wong: yes, but that manifests only in the redirect action
19:59:09 <SumitNaiksatam> banix: the second change was the “contract scope"
19:59:13 <s3wong> SumitNaiksatam: well, "log" and "copy" also :-)
19:59:24 <s3wong> SumitNaiksatam: but yes, I get your point :-)
19:59:31 <SumitNaiksatam> banix: third, was the addition of the notion of labels
19:59:43 <SumitNaiksatam> s3wong: yes thats what i meant :-P
19:59:46 <thinrichs> mandeep: That was my understanding of a contract.  Which makes the question why we're using that to describe a service chain.
20:00:18 <SumitNaiksatam> banix: fourth: is the clear separation of the policy model, and its mapping to the legacy neutron model
20:01:08 <SumitNaiksatam> banix, all: are we fine with all of the above in this first iteration (again keeping redirect, log etc actions aside)
20:01:12 <SumitNaiksatam> ?
20:01:30 <banix> How about spending a couple of days and geting back together early next week?
20:01:40 <SumitNaiksatam> banix: yes sure
20:01:45 <mandeep> thinrichs: In GP model, you can consume a contract only when it is provided by an entity, So the act of consuming a contract for a network service identified a "next hop" and we can use that to identify the chain
20:01:46 <SumitNaiksatam> meanwhile we can get started
20:01:48 <banix> by email if nothing else
20:01:53 <prasadv> banix:+1
20:02:18 <SumitNaiksatam> so i will assume that if there any objections, those will be called out
20:02:21 <banix> sounds good
20:02:26 <SumitNaiksatam> else we will start making progress
20:02:30 <SumitNaiksatam> great thanks guys
20:02:31 <mandeep> SumitNaiksatam: +1 to getting started ...
20:02:42 <s3wong> Yes - let's start doing stuff!
20:02:44 <banix> thanks all
20:02:46 <SumitNaiksatam> unfortunately, we could not get to the services part again!
20:03:06 <s3wong> SumitNaiksatam: it is OK - we can use the service meeting for services
20:03:14 <SumitNaiksatam> or rather not continue it
20:03:20 <SumitNaiksatam> s3wong: yes sure
20:03:22 <SumitNaiksatam> we are over time
20:03:26 <s3wong> SumitNaiksatam: probably better to have this meeting about PoC - more urgent
20:03:32 <SumitNaiksatam> any parting comments/issues?
20:03:46 <s3wong> SumitNaiksatam: good job on the model, thanks!
20:03:59 <s3wong> will think through it
20:04:21 <SumitNaiksatam> great, thanks all!
20:04:25 <s3wong> thanks
20:04:26 <SumitNaiksatam> #endmeeting