19:04:32 <SumitNaiksatam> #startmeeting networking_policy
19:04:33 <openstack> Meeting started Thu Mar 13 19:04:32 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:04:36 <openstack> The meeting name has been set to 'networking_policy'
19:04:54 <SumitNaiksatam> i think the previous meeting was pretty taxing
19:05:16 <SumitNaiksatam> so probably we will keep today's meeting short, give people a chance to catch a breath before the ODL meeting
19:05:16 <banix> but made some progress :) in discussiong important items
19:05:19 <s3wong> SumitNaiksatam: hence not making it back to back with group-policy would be ideal :-)
19:05:32 <SumitNaiksatam> banix s3wong: :-)
19:05:41 <SumitNaiksatam> so action items from last time
19:05:50 <SumitNaiksatam> (it helps that i did not have any :-P)
19:05:59 <SumitNaiksatam> #topic Action Item Review
19:06:15 <cgoncalves> SumitNaiksatam: quick question: ODL meeting focusing on group policy and/or chaining?
19:06:31 <s3wong> cgoncalves: group policy for ODL
19:06:44 <s3wong> independent of Neutron
19:06:51 <SumitNaiksatam> cgoncalves: ^^^
19:07:03 <SumitNaiksatam> so the action item was for the team - Group Policy members to comment on the document here for next week
19:07:05 <mandeep> cgoncalves: (ODL => OpenDayLight)
19:07:07 <cgoncalves> s3wong: I will have to find where the meeting is at and which time. thanks
19:07:18 <SumitNaiksatam> #link https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_00
19:07:28 <SumitNaiksatam> we got a few comments, and i responded to them
19:07:35 <SumitNaiksatam> cgoncalves s3wong: make sense?
19:07:37 <s3wong> I did my part and posted a bunch of comments, in which SumitNaiksatam responded to all
19:07:38 <banix> I think we were waiting for a more complete document first; no?
19:07:57 <SumitNaiksatam> s3wong: yes, you are off the hook ;-P
19:08:07 <SumitNaiksatam> banix: yes sure
19:08:21 <SumitNaiksatam> banix: unfortunately did not make as much progress as expected
19:08:29 <s3wong> SumitNaiksatam: yes, terminology changed, and I would like to see how a composite of actions is represented
19:08:32 <SumitNaiksatam> banix: but you an still comment if you feel comfortable
19:08:32 <mandeep> banix: Yes.
19:08:36 <banix> no problem
19:08:40 <s3wong> but overall, your responses were good
19:08:51 <SumitNaiksatam> s3wong: i am not too worried about the definition of actions
19:09:01 <SumitNaiksatam> s3wong: i think we can collectively enumerate
19:09:12 <SumitNaiksatam> s3wong: ok
19:09:27 <s3wong> SumitNaiksatam: easy for you to say, I was originally tasked to define various types of actions :-)
19:09:41 <SumitNaiksatam> s3wong: ha (i am trying to punt it, as you can tell)
19:09:42 <banix> are we still thinking along the 3 or 4 actions we had looked at?
19:09:51 <banix> security, redirection, qos
19:10:03 <s3wong> banix: I believe so
19:10:11 <s3wong> let's start with those first
19:10:20 <banix> sounds good
19:10:30 <s3wong> though we are only committed to security for the PoC :-)
19:10:34 <mandeep> more like: allow, redirect, add-label, qos-level, etc
19:10:36 <nbouthors> what about a comment from Carlos Gonsalves on missing name attributes. It seems to be gone
19:10:49 <banix> I think in the context of redirect we will need to see how we relate to services, insertion, chaining, etc
19:11:04 <s3wong> mandeep: do we want to introduct label now? or should we focus on what we can achieve for the PoC?
19:11:10 <mandeep> banix: IMO security would not be an action, but a call of actions
19:11:38 <SumitNaiksatam> banix mandeep: i think we have the same semantics in mind, terminlogy
19:11:41 <mandeep> s3wong: We can define those, but implement what we need for PoC
19:11:47 <s3wong> mandeep: security is a fundamental action type - as 'deny' is default, but tenants can set 'allow'
19:11:49 <SumitNaiksatam> mandeep: yeah i agree
19:11:51 <mandeep> (makes understanding the roadmap easier)
19:12:02 <hemanthravi> will contract also address derivation of service_context?
19:12:15 <SumitNaiksatam> s3wong: yes, i think what mandeep is saying is the action name should probably be allow, deny, etc
19:12:18 <hemanthravi> service_context from the adv-services
19:12:40 <SumitNaiksatam> s3wong: the term "security" does not sound like an action
19:12:40 <banix> hemanthravi: that is what we need to discuss
19:13:08 <prasadv> I agree with sumit and mandeep wrt to naming security
19:13:09 <banix> SumitNaiksatam: get on with the old terminology :)
19:13:11 <s3wong> SumitNaiksatam: I am open to other term. But 'allow' needs to be allowed
19:13:37 <SumitNaiksatam> s3wong banix absolutely
19:13:46 <mandeep> hemanthravi: That needs to be represented for"matching"/"providing" service, but not clear in my mind yet as to how we can expose it
19:13:47 <banix> get on board :) just kidding
19:13:55 <SumitNaiksatam> banix: :-)
19:14:06 <banix> Yes we can of course come up with better names but that's not that important
19:14:19 <mandeep> banix: agreed
19:14:26 <banix> As I see it, we need to finalize the model first to get going
19:14:27 <SumitNaiksatam> banix: agreed, agreed don't want to rat hole on the names
19:14:38 <SumitNaiksatam> so hemanth's point
19:14:41 <prasadv> banix: I agree
19:15:21 <SumitNaiksatam> banix: agree
19:15:39 <s3wong> what is hemanthravi 's point?
19:15:44 <s3wong> sorry :-)
19:16:10 <banix> So is the main issue that seems to need more discussion is integration with advanced services? or we are punting on that at the moment?
19:16:10 <SumitNaiksatam> i meant hemanthravi's question
19:16:24 <SumitNaiksatam> banix: good point
19:16:25 <mandeep> s3wong: He was asking how is the service-context exposed in a contarct (or that that is what I understood)
19:16:34 <SumitNaiksatam> banix: i think the model comes first
19:16:44 <SumitNaiksatam> adv services' integration comes next
19:16:45 <mandeep> SumitNaiksatam: Agreed
19:16:57 <SumitNaiksatam> banix: i think thats how you see it, right?
19:17:04 <banix> yes
19:17:07 <s3wong> mandeep: OK
19:17:13 <SumitNaiksatam> i mean stating the obvious
19:17:15 <hemanthravi> mandeep: yes, I thought contract when realized by provider will give the info for the service_context
19:17:23 <banix> just wanted to see what are the things we need to address and then go after them
19:17:32 <banix> SumitNaiksatam: yes
19:17:42 <SumitNaiksatam> i believe hemanthravi's point is that to validate the contract model, we need to consider all aspects
19:17:43 <mandeep> hemanthravi: I agree that is required, just not clear on how to represent it best
19:17:58 <s3wong> hemanthravi: I don't know how service insertion points can be represented here, really. Since our classifier is L4 based
19:18:47 <mandeep> s3wong: We do not need to limit the model to L4 based classifiers. That just may be a limitation of a PoC
19:18:57 <SumitNaiksatam> btw, let me check the topic
19:18:57 <banix> I had earlier suggested that a policy can be the insertion point for a chain but Sumit was suggesting that may not be the case
19:19:06 <SumitNaiksatam> #topic Model review
19:19:21 <hemanthravi> s3wong: agree, not sure how either, but might be the right object to define this
19:19:35 <banix> Shall we have a goal of finalizing the model to the extent that is reasonable by next week?
19:19:40 <SumitNaiksatam> banix: i think what you say makes sense
19:19:56 <SumitNaiksatam> banix: i do not recall what i said earlier :-)
19:20:02 <s3wong> mandeep: I think in earlier days, prasadv wanted to have IP address in classifier; which we collectively rejected (sorry, prasadv)
19:20:15 <prasadv> mandeep: earlier discussion we had, classifier is limited to L4
19:20:34 <SumitNaiksatam> ok guys one sec, banix's question first
19:20:40 <prasadv> i wanted to have IP and we had some discussion around that
19:20:53 <SumitNaiksatam> banix: yes, i agree i think its a good goal for next week,
19:20:56 <s3wong> if we want to extend classifier, it would be above L4, not below. Since we want to hide location addressing scheme from policy
19:21:15 <s3wong> SumitNaiksatam: sorry
19:21:31 <mandeep> We need to create policy in terms of content, not identity. So above L4 is what I was thinking
19:21:33 <SumitNaiksatam> #action Team to finalize the model by next week, SumitNaiksatam to get back with filling any holes
19:21:37 <banix> Let us (looking at myself) have a complete review of the model in the coming days and try to resolve any issues remaining in the meeting next week.
19:21:46 <SumitNaiksatam> #undo
19:21:47 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x2bad990>
19:22:02 <banix> no that was a good action item sumit
19:22:10 <SumitNaiksatam> #action Team to review/finalize the model by next week, SumitNaiksatam to get back with filling any holes
19:22:27 <s3wong> SumitNaiksatam: can we get writable right on the document?
19:22:46 <SumitNaiksatam> s3wong: yeah sure, i thought it was open to anyone with link
19:22:51 <SumitNaiksatam> s3wong:  i can check back
19:23:00 <s3wong> SumitNaiksatam: no, it says comments only
19:23:09 <SumitNaiksatam> banix: you did not like the action item?
19:23:24 <SumitNaiksatam> banix: oh sorry, i misread your statement
19:23:28 <banix> I did; I did not undoing it
19:23:38 <SumitNaiksatam> banix: sorry, rephrasing :-)
19:24:15 <SumitNaiksatam> ok so what else do we want to discuss on the model (after that we will discuss the services' aspect)
19:24:51 <SumitNaiksatam> i discuss based on the extent that you could review the current version
19:24:56 <SumitNaiksatam> *i meant
19:25:08 <s3wong> SumitNaiksatam: mandeep wants us to introduce label into the model, anyone brave enough to take that step :-) ?
19:25:18 <SumitNaiksatam> s3wong: ha
19:25:21 <mandeep> SumitNaiksatam: We just need to get more work done there ... I have been delinquent this week!
19:25:29 <SumitNaiksatam> mandeep: i think mandeep volunteered
19:25:57 <s3wong> SumitNaiksatam: cool, great for mandeep :-)
19:25:58 <mandeep> Yes
19:26:03 <SumitNaiksatam> s3wong: i meant mandeep volunteered :-)
19:26:17 <SumitNaiksatam> ok next topic
19:26:27 <s3wong> don't forget to both subject label and consumption label :-)
19:26:28 <banix> s3wong, man deep: are we talking about labels as they are defined in the ODL group policy?
19:26:30 <banix> sure
19:26:43 <s3wong> banix: that's the only label I know of :-)
19:26:47 <SumitNaiksatam> banix s3wong go ahead
19:26:54 <mandeep> banix: maybe a subset first
19:27:05 <banix> mandeep: makes sense
19:27:22 <nbouthors> There is an n-m relation between Endpoint Group and Contract, does that mean that there should be a way to get back the Endpoint Groups related to a specific Contract? (List a list attribute back)
19:28:28 <banix> I think so
19:28:50 <SumitNaiksatam> nbouthors: yeah, i think so to
19:28:52 <s3wong> nbouthors: in the endpoint group definition page, there are struct to access both provided_contracts and consumed_cotracts
19:29:14 <s3wong> so you should be able to get to contracts via endpoint group
19:29:23 <SumitNaiksatam> s3wong: i think nbouthors is asking can be go back from contracts to EPG
19:29:35 <banix> yes that can be done as well
19:29:55 <banix> I san we can do the db model such that it can be done
19:29:59 <banix> I mean
19:30:02 <SumitNaiksatam> i think what we don't want is the consuming EPG directly referencing the providing EPG
19:30:05 <marun> uh
19:30:38 <marun> so an endpoint group can be 0..1 with a network but endpoint is 1:1 with port
19:30:39 <s3wong> SumitNaiksatam: hmm... at least I guess what contracts the EPG provides should be in the EPG object
19:30:51 <marun> does that imply that an endpoint group has to have a network if it has any endpoints?
19:30:57 <SumitNaiksatam> s3wong: yes
19:31:02 <banix> SumitNaiksatam: agree
19:31:27 <mandeep> marun: no
19:31:35 <marun> or is the relationship between neutron port/network not necessary reflected in the relationship between endpoint and endpoint group?
19:31:38 <SumitNaiksatam> marun: perhaps in the legacy mapping
19:31:49 <mandeep> marun: The relationship on that end is 1..0
19:32:06 <marun> mandeep: maybe i need to rephrase
19:32:27 <mandeep> marun: So for every Neutron network, we will create a corresponding End Point Group, but not vice-versa
19:32:31 <banix> s3wong: not necessarily; we should be able to get that information but that does not require the list of contracts being part of EPG
19:32:34 <marun> mandeep: I get that
19:32:45 <banix> but i see that is part of the model
19:32:47 <s3wong> banix: how so?
19:32:56 <marun> mandeep: I'm asking if, for an endpoint group associated with a network, that all endpoints in the group are associated with ports in that network
19:33:16 <mandeep> marun: Yes
19:33:41 <banix> from having policies associated with EPGs in a separate table; (may be i am referring to something different.)
19:33:43 <mandeep> marun: That is the implied semantics to keep policy consistent with current implemntation of Neutron
19:34:12 <marun> mandeep: so what would come first?  would an endpoint group have to be associated with a network before an endpoint could be created?
19:34:20 <marun> mandeep: the 1:1 between endpoint and port would seem to imply this
19:34:32 <marun> mandeep: or can an endpoint exist without a port?
19:34:54 <s3wong> banix: so I found out about that recently also. Our old policy is now contract :-) but as nbouthors suggested, is there anyway to get from EPG to contract
19:34:56 <mandeep> marun: An end point can not exist without a port.
19:35:15 <s3wong> and we probably don't want to walk through all contracts to get to matching EPG, right?
19:35:40 <marun> mandeep: ok.  and an endpoint group without a network would be useful for defining the policy side of things without a target.  gotcha
19:36:00 <mandeep> marun: (for now, eventually we could allow physical ports to be members of endpointgroups - to allow bare metal integration)
19:36:33 <banix> s3wong: correct wrt not walking through policies. the current model suggests peg has list of associated policies/contracts
19:36:58 <marun> mandeep: ok
19:37:24 <s3wong> banix: right, that was what we talked about. EPG (or peg) has to maintain a list of provided contracts, at the very least
19:38:02 <s3wong> BTW, sorry for branching off to another discussion, guys
19:38:02 <prasadv> can we end this meeting 15 minutes early, some of us are going to ODL group policy meeting
19:38:03 <SumitNaiksatam> ok do we want to switch gears to integration with advanced services?
19:38:12 <SumitNaiksatam> prasadv: ah ok
19:38:25 <s3wong> SumitNaiksatam: should we talk about that in the adv. service meeting?
19:38:37 <banix> s3wong: just referring to the implementation aspects of how to do that.
19:38:45 <SumitNaiksatam> lets discuss for 5mins
19:38:55 <SumitNaiksatam> and we can finish early
19:39:00 <s3wong> SumitNaiksatam: or do you think the adv. srv. meeting is too busy as is :-_
19:39:02 <SumitNaiksatam> #topic Integration with advanced services
19:39:16 <s3wong> banix: OK
19:39:26 <SumitNaiksatam> yeah, i could not bring this up though i had in the agenda in the last meeting
19:39:53 <SumitNaiksatam> so essentially, would like to hear what your thoughts are on this
19:39:58 <prasadv> the integration will come only with redirect action right?
19:40:14 <SumitNaiksatam> prasadv: ah thats the kind of discussion we want to have
19:40:22 <s3wong> SumitNaiksatam: there were suggestions that we can build a linear chain via the 'redirect' list
19:40:28 <banix> prasadv: that's what we have discussed so far
19:40:50 <SumitNaiksatam> there is a pragmatic side to things, as to what we want to achieve for the PoC
19:40:57 <s3wong> and "insert" a service also via 'redirect' action
19:41:07 <SumitNaiksatam> but our model needs to be robust that it can extend beyond that
19:41:13 <prasadv> s3wong: I thought you said that list is a copy list? not a chain
19:41:18 <s3wong> and 'deny' the traffic to the destination EPG initially
19:41:47 <s3wong> prasadv: I think there was never any consensus on whether or not the list should be ordered
19:42:17 <SumitNaiksatam> #action SumitNaiksatam to check with s3wong, prasadv on what was discussed before in the context of service chains
19:42:19 <prasadv> s3wong: if advanced services defines a chain, shoudnt we use that ?
19:42:34 <banix> prasadv: yes
19:42:36 <SumitNaiksatam> prasadv: i would have imagined that would be the case
19:42:38 <s3wong> if the 'redirect' list contains element only for mirroring traffic, then order should not matter
19:42:43 <mandeep> prasadv: agreed
19:42:47 <banix> I think that's a reasonable choice
19:43:10 <SumitNaiksatam> prasadv: since what we are building is the policy framework which should ideally leverage other neutron primitives
19:43:14 <s3wong> prasadv: that was the original case, where service chain is defined outside of policy framework
19:43:22 <SumitNaiksatam> s3wong: ok makes sense
19:43:31 <banix> I think if we know there is a mechanism to define a service chain we should use it
19:43:46 <prasadv> does advanced services include chain definition to have tap type device
19:43:58 <SumitNaiksatam> prasadv: yes that was the proposal
19:44:04 <s3wong> banix: I think Anees was the one who wanted the 'redirect' action to have hook for service chain definition :-)
19:44:06 <SumitNaiksatam> prasadv: separate attribute for tap
19:44:07 <prasadv> since that involves mirroring and forwarding at the same time
19:44:21 <mandeep> s3wong: ideally we have a different actions for tap (mirror) vs. redirect (say to a firewall that can drop the traffic)
19:44:56 <s3wong> prosadv: that can be controlled by 'allow' or 'deny' on a different action-type
19:45:02 <prasadv> mandeep: if the chain has say snort and firewall
19:45:07 <SumitNaiksatam> ok so we did gather some preliminary requirements from this short dicussion
19:45:10 <banix> s3wongL yes, so far we have essentially have punted on how the service chain is defined within our policy framework; assuming we will pick it up from services workk
19:45:16 <SumitNaiksatam> per earlier request, lets stop here for today
19:45:23 <prasadv> sumit: thanks
19:45:28 <s3wong> mandeep: that should be controlled by whether users want to 'deny' traffic or still 'allow' them to the dst EPG
19:45:53 <mandeep> s3wong: Let me read the document again. I think I might just be confused
19:45:58 <SumitNaiksatam> #action advanced services discussion to be continued for next meeting, perhaps with a longer time allocation
19:45:59 <s3wong> SumitNaiksatam: agreed :-) let's plant these seeds for now
19:46:19 <SumitNaiksatam> s3wong: we will end up growing a forest at this rate
19:46:26 <mandeep> ;-)
19:46:34 <SumitNaiksatam> ok thanks guys!
19:46:38 <prasadv> bye
19:46:38 <s3wong> thanks!
19:46:41 <banix> Let's review the model as much as we can this week! Bring up any concerns. on the doc, ML.
19:46:49 <mandeep> Many plants, but no fruits!
19:46:53 <mandeep> (yet)
19:47:02 <SumitNaiksatam> #endmeeting