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