20:07:16 <alagalah> #startmeeting ODL usecases
20:07:16 <odl_meetbot> Meeting started Mon Jul  7 20:07:16 2014 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:07:16 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:07:16 <odl_meetbot> The meeting name has been set to 'odl_usecases'
20:07:48 <alagalah> #topic Enterprise Access Use Cases
20:08:22 <tbachman> #info Sanjay says that he hasn’t received any comments/questions on his presentations
20:08:36 <tbachman> #info Sanjay asks if we can spend 20-30 minutes to provide this now
20:08:37 <alagalah> tbachman: Thanks mate, I was just typing that, keep going
20:09:38 <alagalah> #chair lenrow
20:09:38 <odl_meetbot> Current chairs: alagalah lenrow
20:09:47 <alagalah> #chair tbachman
20:09:47 <odl_meetbot> Current chairs: alagalah lenrow tbachman
20:09:47 <lenrow> #link https://wiki.opendaylight.org/view/File:Policy_Usecases.pptx
20:10:33 <tbachman> lenrow: thx!
20:11:15 <tbachman> #info Enterprise acces control, multi-tier access control are some of the use cases
20:13:36 <tbachman> #info alagalah asks if reputation should be in the operational state repository
20:13:59 <tbachman> #info Sanjay says that how you handle that should be in the policy repository, but what you with it could be in an operational repo
20:14:26 <tbachman> #info Sanjay notes that the endpoint mapping could change
20:17:47 <tbachman> #info readams says that the contract there are targets, which can be used for quality matching
20:18:22 <tbachman> #info the producer and consumer EPGs can have consumer/producer target selectors, which can match on the target  qualities
20:19:50 <tbachman> #info a condition is something that applies to an endpoint, not to the entire endpoint group
20:22:48 <tbachman> #info lenrow asks if a condition is just a boolean (either/or)
20:23:15 <tbachman> #info readams says that right now it’s just a flag, but they could be parameterized, but doing so would affect flow rules
20:23:35 <tbachman> #info (i.e. increase flow rules exponentially)
20:24:44 <tbachman> #info Sanjay thinks that the outside/inside could be treated as a condition, because it changes
20:26:02 <tbachman> #info readams says that you can in general avoid using conditions, as you can change EP groups as easly as you change conditions
20:26:48 <tbachman> #info Sanjay thinks reputation could also be treated as a condition
20:27:33 <tbachman> #info Sanjay asks what a capability is in this example
20:27:45 <tbachman> #info readams says you often don’t need requirements and capabilities
20:27:54 <tbachman> #info and that those are needed for more advanced policy
20:28:12 <tbachman> #info which might be for things like shared services, where you have lots of EPGs mapping to shared services
20:28:29 <tbachman> #info readams says that in the common case, that’s easily done as a named contract selection
20:31:33 <tbachman> #info lenrow asks if the assumption that the state of any given condition is maintained by the EP registry?
20:32:24 <tbachman> #info Sanjay says yes
20:32:56 <tbachman> #info mickey_spiegel says there a question of how dynamic a reputation is
20:34:05 <tbachman> #info lenrow wonders whether the change is infrequent enough to be handled by the renderer — does it change at such a rate so that the control plane can be “pre-configured” to handle this
20:34:46 <tbachman> #info readams says that you have to update the switches on ingress whether changing EP’s EPG membership vs. changing the EP’s condition
20:35:23 <tbachman> #info readams says that in general, the condition is a bit of a workaround to the fact that an EP can only belong to one EPG
20:36:10 <tbachman> #info mickey_spiegel says that the point is you have to touch the EP Registry either way
20:37:11 <tbachman> #info readams says that complexity will be quadratic for the number of EPGs, and exponential with the number of conditions
20:41:59 <tbachman> #info readams points out you can’t withdraw a subject, but you can create another subject who has classifiers with higher priority
20:42:47 <tbachman> #info Sanjay wants the ability to take away the access, without introducing a condition  — just introduce a higher priority rule
20:43:07 <tbachman> #info readams says you can introduce a higher priority rule, as long as it uses the same classifiers
20:44:27 <tbachman> #info lenrow asks what the action associated “withdraw” looks like — is it a drop?
20:44:34 <tbachman> #info Sanjay says yes.
20:45:46 <tbachman> #info readams says that classifiers in general should be applying to layer 4 and up
20:46:43 <tbachman> #info mickey_spiegel asks if subjects have priorities
20:47:01 <tbachman> #info readams says yes - the reason that if you just put them on the rules, then it’s much harder
20:47:44 <tbachman> #info mickey_spiegel asks if he has QoS permit, deny, and redirect — they would be in different subjects?
20:48:10 <tbachman> #info readams says that you get one action-set, and then you’re done
20:49:00 <tbachman> #info Sanjay says that in order to create deny rules — effectively do away with deny, that they came up with the idea of withdrawing subjects… overriding subjects with other subjects
20:49:14 <tbachman> #info readams says that’s not the way the current GBP model works
20:49:32 <tbachman> #info readams says you can have two classifiers that apply to different sets of traffic
20:50:03 <tbachman> #info readams says that in the case where the only action is permit-only, then it’s easy
20:50:22 <tbachman> #info but multiple actions based on different classifiers, then it becomes a multi-stage process
20:50:57 <tbachman> #info readams says that trying to map the semantics of this onto actual systems, then you end up with a large number of rules to be generated
20:52:46 <tbachman> #info Sanjay would like to have follow-on discussions with the “withdraw” concept
20:53:20 <tbachman> #info Sanjay recommends moving this to the arch/model meeting (Friday), and continuing for now
20:54:14 <tbachman> #info mickey_spiegel thinks there are two overlapping things here
20:54:23 <tbachman> #info one is wanting to do different actions in logically different tables
20:54:40 <tbachman> #info the other is whether this construct allows for conflicts, where it looks like two things apply but one has to win
20:55:02 <tbachman> #info readams says that the model documentation does a good job of describing the semantics
20:55:30 <tbachman> #info this only becomes an issue when you want to do things like apply QoS and do allow/deny
20:55:41 <tbachman> #info lenrow asks what if you want to do QoS and NAT?
20:56:01 <tbachman> #info readams says that NAT can be provided by the infrastructure
20:57:10 <tbachman> #info readams says that every EPG has an L3 context associated with it, which affects addressability
20:57:31 <tbachman> #info If they are in different L3 contexts, you could allow them to communicate with a sort of double-NAT
20:58:08 <tbachman> #info readams says this is a forwarding context property
20:58:22 <tbachman> #info readams says that anything L3 or below shouldn’t be in your policy
20:58:50 <tbachman> #info this would be an infrastructure-level configuration item
20:59:39 <tbachman> #info readams says that any kind of labeling action (QoS, add a timestamp, etc.) then it makes sense
21:03:09 <tbachman> #info readams says that multi-table can grow complexity, and needs to be thought through
21:05:18 <tbachman> #info mickey_spiegel says that 2 or 3 lookups based on separate keys is a useful thing to have
21:05:32 <tbachman> #info readams says that this gets complicated when you start looking at different HW vendors
21:06:00 <tbachman> #info lenrow asks about HW that does TTP, where multiple tables are used to do multi-table OF?
21:06:59 <tbachman> #info readams says we can probably define specific sets of things, that might be doable
21:09:26 <tbachman> #info lenrow asks if we want to talk about any more of these use cases today?
21:10:11 <tbachman> #info mickey_spiegel asks if any of these use cases bring out new issues
21:10:37 <tbachman> #info Sanjay says he’s already covered these: service inclusion in the clauses, and priority between static and dynamic rules
21:12:24 <tbachman> #info lenrow asks what language we’re using to express this (e.g. the language that dvorkin introduced in a recent meeting)
21:12:49 <tbachman> #info Sanjay says that the first step would be to make sure that the use case maps to all the constructs
21:13:01 <tbachman> #info and the second step is to write it out in that language
21:13:22 <tbachman> #info uchau1 asks if dvorkinista’s language is reconciled with the current model
21:14:38 <tbachman> #action tbachman to provide the latest UML model
21:16:31 <tbachman> #info uchau1 asks if the yang has been updated with all the latest policy constructs
21:16:45 <tbachman> #info uchau1 asks what the right language is to create this
21:17:52 <tbachman> #info readams says that the language that exists right now is the RESTCONF XML or JSON
21:18:21 <tbachman> #info readams says you can check out the GBP project, run it, and look at the auto-generated API documentation
21:18:43 <tbachman> #info readams says that you get the REST APIs exposed on port 8080
21:19:22 <tbachman> #info uchau1 says that the documentation doesn’t really describe how it’s structured.
21:19:40 <tbachman> #info readams says that the yang model and policy arch documentation should provide a good basis for this
21:20:43 <readams> http://localhost:8080/apidoc/explorer
21:21:18 <tbachman> #info http://localhost:8080/apidoc/explorer is the link to use for looking at the documentation
21:21:58 <tbachman> #info Sanjay asks if anyone wants to help him with the conversion?
21:22:29 <tbachman> #info readams points out that the JSON is an internal API, and not what would be presented to an end-user
21:27:28 <tbachman> #topic Service Function Chaining IETF Use Cases
21:27:45 <tbachman> #info lenrow says that he’s been having 1-on-1 conversations w/Paul Quinn
21:28:39 <tbachman> #action lenrow will post the SFC use case slides to the wiki
21:29:25 <tbachman> #info A tenant identifier has to be carried along with the traffic to be serviced
21:29:45 <tbachman> #infoit is typical of tenant assets to be deployed in an isolated layer2 or layer3 domain such as VLAN, VXLAN, or VRF
21:30:31 <tbachman> IT has to be noted that the SNs themselves may be deployed in different domains to suit the deployment needs of the SP and hence using the domain in whcih the SN is deployed is not an option. Although such a model is feasible it removes the deployment flexibility for the servife providers to the WAN edge.
21:30:42 <tbachman> #info IT has to be noted that the SNs themselves may be deployed in different domains to suit the deployment needs of the SP and hence using the domain in whcih the SN is deployed is not an option. Although such a model is feasible it removes the deployment flexibility for the servife providers to the WAN edge.
21:31:15 <tbachman> #info To support multi-tenant aware service functions or SNs, traffic being serviced by a service function chain has to be identified by a tenant identifier.
21:32:31 <tbachman> #info lenrow thinks the right thing to do is to match SFC behaviors onto EPGs
21:32:44 <tbachman> #info Firewall engines are an EPG, etc.
21:32:56 <tbachman> #info and question becomes how you pick an EPG (e.g. proximity)
21:33:34 <tbachman> #info mickey_spiegel asks what lenrow means by allocating pools of firewalls
21:34:28 <tbachman> #info lenrow says that the policy shouldn’t be boggd down by “which device implements the FW"
21:34:46 <tbachman> #info mickey_spiegel then asks why you’d want that implied by the intent?
21:35:15 <tbachman> #info lenrow says that the physical and virtual middle-boxes are an EPG and it makes sense to model them that way b/c that’s how you think about them.
21:35:30 <tbachman> #info Sanjay says this feels like an intent kind of thing
21:35:44 <tbachman> #info lenrow says that the intent is for the two EPGs to go through a third EPG
21:36:04 <tbachman> #info lenrow says that we’re not turning the renderer into an L4 services platform — it only knows how to steer things.
21:36:35 <tbachman> #info Sanjay says he thought things were specified at a higher level.
21:37:09 <tbachman> #info mickey_spiegel understands that the details of L4-7 don’t need to be in the renderer, but that the renderer doesn’t need to care about which device it is.
21:37:41 <tbachman> #info mickey_spiegel says we can use an indirection to avoid putting this into the intent
21:38:04 <tbachman> #info the indirection allows an expert to define all of this
21:46:02 <tbachman> #info Sanjay says that at the intent level we’d need to define a few more primitives
21:46:48 <tbachman> #info lenrow would like to spend time on Friday’s call on things like “what does a redirect look like”
21:48:11 <tbachman> #info lenrow is also trying to coordinate with the AAA folks
21:51:56 <tbachman> #info lenrow asks if someone would be up for proposing a straw-man for what to talk about on Friday’s meeting
21:53:09 <tbachman> #endmeeting