20:00:47 <tbachman> #startmeeting gbp_requirements
20:00:47 <odl_meetbot> Meeting started Mon Jun 30 20:00:47 2014 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
20:00:47 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:47 <odl_meetbot> The meeting name has been set to 'gbp_requirements'
20:00:57 <tbachman> will wait for lenrow to kick things off
20:02:17 <tbachman> #chair lenrow
20:02:17 <odl_meetbot> Current chairs: lenrow tbachman
20:02:29 <tbachman> any others :)?
20:04:56 <tbachman> #info Sanjay brings up other possible use cases (iWAN)
20:08:54 <tbachman> #topic Strawman of intent elements for UCI use case
20:09:26 <tbachman> #info uchau has put together JSON that can be used for this.
20:10:32 <tbachman> #info uchau goes over use case with older version of the model
20:10:46 <tbachman> #info In this scenario, there is a single EPG for Users
20:11:13 <tbachman> With a single contract with subjects for each media (voice, video, app sharing)
20:11:21 <tbachman> #info With a single contract with subjects for each media (voice, video, app sharing)
20:11:37 <tbachman> #info And a single class, with Subject of ALL
20:12:05 <tbachman> #info s/class/clause/
20:12:28 <tbachman> #info All flows go into classififier of 5-tuple for each user
20:12:40 <tbachman> #info the EPG is both the provider and consumer of the contract
20:12:49 <tbachman> #info Using named selectors
20:13:03 <tbachman> #info The default clause allows all subjects to be active
20:14:09 <tbachman> #info note that the new model would allow the 3rd type of selector, so that the EPG can use that selector to both provide and consume the contract
20:14:46 <tbachman> #info uchau describes the json
20:14:52 <tbachman> (too much to type here....)
20:18:16 <tbachman> #info lenrow says that the keyword “voice” would allow the renderer to derive some meaning (e.g. latency) so that the backend can do something with it
20:19:02 <tbachman> #info uchau says that the action hjas a value, which provides a mapping, such as “Interacive Voice”, which can be further  mapped to things like DSCP markings
20:20:19 <tbachman> #info mickey_spiegel says that in previous discussions that we had an additional level of indirection
20:20:50 <tbachman> #info lenrow says that if we call out things that are specific, then we can have duplication of functionality in renderers — is seeking sufficient abstractions
20:21:20 <tbachman> #info uchau feels that there are series of renderers, which can leverage these actions.
20:21:38 <tbachman> #info uchau and that we should at least have a base renderer that meets these needs.
20:21:50 <tbachman> #info mickey_spiegel says we need to distinguish between a couple of things
20:22:24 <tbachman> #info mickey_spiegel asks if we need well-known class names so that it can be supported across different providers
20:22:31 <tbachman> #info uchau asks what providers is here
20:22:38 <tbachman> #info mickey_spiegel meant service providers
20:22:56 <tbachman> #info mickey_spiegel adds that these APIs should be able to be used in multiple environments.
20:23:13 <tbachman> #info the question is whether these keywords have to be remapped in different provider environments
20:24:02 <tbachman> #info uchau says that their goal is to provide something more commonly used (e.g. Interactive Voice), but what it gets mapped to (e.g. DSCP markings) depends on the provider environment.
20:24:15 <tbachman> all — please check my work (you all talk fast!) :)
20:24:37 <uchau> you're doing great ;)
20:24:57 <tbachman> #info mickey_spiegel is worried whether we can satisfy everyone with a single definition
20:25:11 <tbachman> #info mickey_spiegel notes that QoS discussions get ugly pretty fast, with strong opinions
20:25:25 <tbachman> #info lenrow notes that ACL policies might be easier, but QoS is indeed harder
20:25:42 <tbachman> #info uchau says we can start with this as a goal to make it as reusable as possible
20:25:58 <tbachman> #info uchau finishes but doesn’t preclude configurability
20:26:23 <uchau> doesn't preclude others from building what they need
20:26:39 <tbachman> #info ucha finishes “doesn't preclude others from building what they need"
20:26:42 <tbachman> uchau: thx :)
20:27:18 <tbachman> #info Sanjay asks where the actions are represented
20:27:25 <tbachman> #info as an example, policing
20:27:38 <tbachman> #info uchau says that actions are specified as parameters
20:28:09 <tbachman> #info mickey_spiegel says that dvorkinista wanted a layer of indirection, to avoid hard-coding things to an environment
20:28:31 <tbachman> #info mickey_spiegel adds that the value can be treated as a class name and the definition of the class gets defined somewhere else
20:28:52 <tbachman> #info lenrow says that a possible place for this is in operational state
20:29:07 <tbachman> #info mickey_spiegel says that this indirection allows the provider to specify it, not the user
20:29:53 <tbachman> #info mickey_spiegel asks whether we should have default class names so that they can be portable across providers
20:30:53 <tbachman> #info lenrow says that this is what we need to take back to the UCIF folks as a proposal
20:31:34 <tbachman> #info uchau notes that this model is very similar to how the UCIF folks are laying out their requirements
20:31:52 <tbachman> #info uchau says that they do want feedback as part of the request, to understand what was actually assigned
20:32:59 <tbachman> #info lenrow asks what happens if the promise cant’ be met
20:33:12 <tbachman> #info dconde says that this can result in an exception notification
20:34:43 <tbachman> #info uchau asks whether some of the things in the model are optional (e.g. some of the things in the action-ref)
20:35:13 <tbachman> #info Sanjay asks whether this is translatable from yang/
20:35:25 <tbachman> #info uchau says this is translated from the yang model
20:36:30 <tbachman> #topic Sanjay presents dynamic use cases
20:37:37 <tbachman> #info firs tuse case is “Demand Usecase 2.1: IWAN Routing”
20:37:53 <tbachman> #info useful for multiple large enterprises with many branch offices (10-15k)
20:38:31 <tbachman> #info The use case has multiple ISPs, and want to monitor the WAN connection, based on a quality matrix
20:39:13 <tbachman> #info They also may want service chaining, WAN optimization
20:40:06 <tbachman> #info This effectively a netflow-based threshold crossing measurement between branch routers and border routers
20:41:08 <tbachman> #link  https://wiki.opendaylight.org/view/File:Policy_Usecases.pptx <= slides for presentation
20:42:46 <tbachman> #info lenrow asks whether the assumption is whether the SDN controller spreads across all of this, and the infrastructure is under the control of the SDN controller
20:44:55 <tbachman> #info the pieces are measurement (border-router to border-router), testing measurements against policy (i.e. intent)
20:45:05 <tbachman> #info and if rules are satisfied, then no action
20:45:16 <tbachman> #info and if rules aren’t satisfied, new policies need to be deployed
20:45:56 <tbachman> #info This is dynamically changing the membership of the flow from one EPG to another EPG, resulting in traffic taking a different path
20:46:16 <tbachman> #info lenrow asks whether monitoring of border routers as a renderer thing, or an application thing
20:47:05 <tbachman> #info Sanjay says it could be either, but would prefer business logic to handle this
20:47:55 <tbachman> #info So, the application becomes aware that a promise isn’t kept, and asks for a new promise
20:48:56 <tbachman> #info lenrow asks from a requirements perspective, whether Sanjay feels this can be supported with current constructs
20:49:15 <tbachman> #info Sanjay believes it can be supported, and the only thing is that we haven’t gone through the forwarding use cases as we have the policy use cases
20:49:39 <tbachman> #info Sanjay also isn’t sure whether he can do the forwarding modeling himself (may need help here)
20:50:10 <tbachman> #info mickey_spiegel says he isn’t sure how this relates to GBP
20:51:58 <tbachman> #info mickey_spiegel says that policy is all about intent and abstraction, not deep into the data plane
20:52:19 <tbachman> #info dconde adds that this is crossing different domains, of intent and implementation
20:52:32 <tbachman> #info Sanjay says that he believes there’s an intent and rendering dimension here
20:53:26 <tbachman> #info The policy is the business routing is the intent, and the rendering handles the forwarding for certain traffic classes (how traffic classes get mapped)
20:54:38 <tbachman> #info mickey_spiegel says that the traffic forwarding is owned by the network admin, not by the application
20:55:49 <tbachman> #info lenrow thinks the intent is clear — but maybe what’s lacking is a clearer picture of what the details of efficiently using resources in the renderer look like
20:56:34 <tbachman> #info mickey_spiegel says that operational policies and renderer aren’t the same thing
20:59:29 <tbachman> #info lenrow says that a lot of this is details that can be (and should be) managed by the renderer
21:00:08 <tbachman> #info lenrow  says that POCs for comparing/contrasting can help make clearer distinctions on this concepts
21:00:28 <tbachman> #info Sanjay introduces a second use case of security across the WAN
21:00:48 <tbachman> #info where measurements are made
21:01:15 <tbachman> #info and threshold crossings are rerported to an operational application, which can implement things like threat-detection logic
21:02:08 <tbachman> #info lenrow says that this is identical to the Defense4All use case
21:02:35 <tbachman> #info the renderer in Defense4All might look different in WAN vs. LAN, but use case is similar
21:02:53 <tbachman> #info A third use case is a threat-detection use case in the datacenter
21:03:25 <tbachman> #info lenrow thinks that the event rates for DDoS detection are probably less than the UCI use case
21:04:58 <tbachman> #info Sanjay says that he hears that for IWAN routing and perhaps security use cases, intent is expressed at a higher level, rather than an operational level, and operational intent should be expressed/handled in the renderer logic
21:08:28 <tbachman> #info alagalah asks whether we can post these to the email list
21:08:34 <tbachman> #info Sanjay says he will send the link again
21:10:05 <tbachman> #info alagalah suggests that we can give reviews of Sanjay’s (and others’) work in the status meeting.
21:11:13 <tbachman> #topic Enterprise Hierarchical Resource Accessuse case
21:11:34 <tbachman> #info Sanjay believes the policy model covers this well
21:14:26 <tbachman> #info There is an EPG called Users, with an India-Empl Users and US-Empl Users as children EPGs
21:14:45 <tbachman> #info HR and Wiki are EPGs within a Web EPG
21:14:57 <tbachman> #info there is a single Contract A
21:15:11 <tbachman> the Web EPG provides the contract, and the Users EPG consumes the contract
21:15:54 <tbachman> #info the Web EPG provides the contract, and the Users EPG consumes the contract
21:16:18 <tbachman> #info the Contract has two subjects, HTTP_low and HTTP_Hi, for low and high security, respectively
21:17:35 <tbachman> #info There are several rules, mapping thes to HTTP_low or HTTP_hi
21:18:30 <tbachman> #info lenrow asks if there are other agenda items
21:18:41 <tbachman> #endmeeting