14:49:55 <alagalah> #startmeeting PolicyArch Mickey's notes
14:49:55 <odl_meetbot> Meeting started Sat Apr 26 14:49:55 2014 UTC.  The chair is alagalah. Information about MeetBot at http://ci.openstack.org/meetbot.html.
14:49:55 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:49:55 <odl_meetbot> The meeting name has been set to 'policyarch_mickey_s_notes'
14:50:01 <alagalah> 
14:50:01 <alagalah> #info Mike Dvorkin
14:50:01 <alagalah> #info Keith Burns
14:50:03 <alagalah> #info Rob Adams
14:50:04 <alagalah> #info Daljeet Singh
14:50:06 <alagalah> #info HP
14:50:08 <alagalah> #info Dan Conde
14:50:10 <alagalah> #info Jan Medved
14:50:12 <alagalah> #info Abhishek
14:50:14 <alagalah> #info Chris Price
14:50:16 <alagalah> #info Mickey Spiegel
14:50:19 <alagalah> #info Ryan Moats
14:50:20 <alagalah> #info Mickey’s intro
14:50:23 <alagalah> #topic Components, high-level flows
14:50:24 <alagalah> #info Jan requests use cases
14:50:27 <alagalah> #info Mike draws Policy Repo and EP Reg / Mapper and Enforcement Exception Repository and Ops State
14:50:29 <alagalah> #info Renderers below
14:50:30 <alagalah> #info Renderers resolve, checks out policies from
14:50:33 <alagalah> #info Theoretically, this guy can declare endpoints, plus resolve
14:50:34 <alagalah> #info Jan asks under what conditions declare endpoints?
14:50:37 <alagalah> #info Mickey notes discovery of an endpoint
14:50:38 <alagalah> #info Jan mentions EP Registry Mapper, other inputs
14:50:40 <alagalah> #info Chris notes as long as same xxx, good
14:50:42 <alagalah> #info Mike notes can be posting can be part of renderer or not, does not have to be
14:50:46 <alagalah> #info For the sake of discussion, say it has to be
14:50:47 <alagalah> #info Renderer can post enforcement exceptions
14:50:48 <alagalah> #info I could not render something
14:50:51 <alagalah> #info Exception
14:50:53 <alagalah> #info Not rendering to the full gravity of what is defined by the policy
14:50:55 <alagalah> #info Jan asks in database, searchable?
14:50:57 <alagalah> #info Mickey assumes not any object anywhere can have exceptions, but at certain places, this is working or not
14:50:59 <alagalah> #info Jan asks if post exceptions to operator
14:51:00 <alagalah> #info Mike notes talking about how renderer interacts with components
14:51:02 <alagalah> #info Renderer updates state
14:51:04 <alagalah> #info Chris …
14:51:06 <alagalah> #info Mike notes to him enforcement exceptions and op state are related
14:51:09 <alagalah> #info One xxx
14:51:10 <alagalah> #info Other can come up with scores, this is my utilization
14:51:14 <alagalah> #info We have this kind of capacity
14:51:14 <alagalah> #info Measures behavior, not enforcement
14:51:17 <alagalah> #info If I ask to do something, gave you a price
14:51:18 <alagalah> #info How well do I fulfill this price?
14:51:20 <alagalah> #info Different xxx, specify how to count things, express in normalized ways
14:51:22 <alagalah> #info Jan notes exception needs access to policy definitions, need to know when an exception, not rendered properly
14:51:26 <alagalah> #info Mike would much rather not
14:51:28 <alagalah> #info Jan asks how to know exceptions occur?
14:51:28 <alagalah> #info Chris would render network, then put triggers within Ops State that would invoke exceptions
14:51:31 <alagalah> #info Mike notes no way to enforce QoS, exception
14:51:32 <alagalah> #info Chris Price notes lower bound for operational state, defines when exception occurs
14:51:35 <alagalah> #info Would Ops State monitor that, or replicate somewhere?
14:51:36 <alagalah> #info Mike notes fine line, depends on what you mean
14:51:39 <alagalah> #info Ops State is derivative of actual state underneath
14:51:41 <alagalah> #info Might have port that is misbehaving, affects behavior of my endpoint
14:51:42 <alagalah> #info Ops State stuff measures that
14:51:46 <alagalah> #info Jan asks for example, contract definition, what state if not rendered properly, what gets injected into Ops State
14:51:47 <alagalah> #info Mike notes if render contract, you cannot enforce something, have to report to exception repository
14:51:49 <alagalah> #info QoS super duper high priority
14:51:50 <alagalah> #info Cannot do for some reason, raise an exception
14:51:53 <alagalah> #info Say mechanism cannot enforce conditions on endpoints because implemented in ASICs, not enough CAM size
14:51:56 <alagalah> #info Relaxing constraint, have to report an exception
14:51:56 <alagalah> #info Jan asks if data model related to policy?
14:51:58 <alagalah> #info Mike wants to make it generic
14:52:01 <alagalah> #info Jan notes have to have exception, cannot enforce contract
14:52:04 <alagalah> #info Mike notes full discussion dedicated to these two
14:52:05 <alagalah> #info Jan’s reason for the question is to figure out, map out data models, data flows
14:52:06 <alagalah> #info Mike draws URI of the affected policy construct
14:52:09 <alagalah> #info URI of the EP
14:52:10 <alagalah> #info “exception description”
14:52:13 <alagalah> #info “probably cause”
14:52:15 <alagalah> #info “severity”
14:52:16 <alagalah> #info “affect on xxx”
14:52:19 <alagalah> #info Measurement of completion
14:52:20 <alagalah> #info Chris Price asks about interaction with consumer?
14:52:23 <alagalah> #info Mike notes URIs
14:52:25 <alagalah> #info If look at policy, know which exceptions are in scope, based on URI
14:52:27 <alagalah> #info Chris Price claims should not deploy, cannot fulfill
14:52:28 <alagalah> #info Mike wants to avoid order of operation issues, have to delete something before you create something
14:52:31 <alagalah> #info Mike claims problem, what if 15 endpoints, for next one that showed up 15 minutes later, you can’t?
14:52:34 <alagalah> #info Raise an exception
14:52:34 <alagalah> #info Feeds into placement engine
14:52:36 <alagalah> #info Because of that, want to move endpoint somewhere else
14:52:38 <alagalah> #info Oftentimes you don’t control where you place endpoints
14:52:41 <alagalah> #info Scheduler sitting on top
14:52:42 <alagalah> #info Cannot move endpoints ourselves, have to give feedback to system on top that makes placement decisions
14:52:44 <alagalah> #info Exceptions are persistent for as long as conditions exist
14:52:46 <alagalah> #info Move it to history
14:52:48 <alagalah> #info Daljeet asks how policy changes are propagated to renderers?
14:52:51 <alagalah> #info Mike notes you subscribe, linear subscription
14:52:53 <alagalah> #info Whenever policy changes, get updated
14:52:55 <alagalah> #info This is why MD-SAL seems like a very good fit
14:52:56 <alagalah> #info Jan claims same pattern for exceptions
14:52:58 <alagalah> #info Mike notes except data is not trees
14:53:00 <alagalah> #info Jan counters, can put in a tree
14:53:03 <alagalah> #info Mike agrees, though a very shallow tree
14:53:06 <alagalah> #info Mike notes might be some other applications interested in this
14:53:07 <alagalah> #info What they do, how they alter policy, we cannot predict that, have to provide framework for that
14:53:08 <alagalah> #info Jan notes that is pubsub
14:53:10 <alagalah> #info Jan brings up, perhaps don’t address that, identifiers may or may not be URIs
14:53:13 <alagalah> #info Internally if Java to Java components, instance identifiers
14:53:15 <alagalah> #info Have solution for that
14:53:16 <alagalah> #info Mike notes logically everything is a URI
14:53:19 <alagalah> #info Mike loves consistent identifiers, hate duality, causes schizophrenia
14:53:20 <alagalah> #info Talking about behaviors versus implementation
14:53:24 <alagalah> #info Jan notes do not want to be just accessing this through REST APIs
14:53:24 <alagalah> #info Mike counters, you can subscribe to it, already agreed
14:53:27 <alagalah> #info Jan notes APIs you subscribe to, does not matter if came to it from REST or something else
14:53:28 <alagalah> #info Mike notes subscribe to certain sets of data within certain scopes
14:53:30 <alagalah> #info Jan hates duality too
14:53:33 <alagalah> #info When get that event, looks the same to you
14:53:35 <alagalah> #info Mike claims URIs are very important, know all of a sudden in the scope of a certain subtree, all of a sudden subject to notification
14:53:37 <alagalah> #info Jan claimed solved with yang tools
14:53:39 <alagalah> #info Mike claims flat data set, do not want to recreate another tree, cost will be staggering
14:53:40 <alagalah> #info Mike draws Exception Repo with objects underneath, without further structure
14:53:42 <alagalah> #info Treating things as URI, tells you position on the tree
14:53:44 <alagalah> #info Being able to filter on that
14:53:46 <alagalah> #info Question how to model URI, does not have to be string
14:53:48 <alagalah> #info Ryan claims everything has to be a URI rather than string
14:53:50 <alagalah> #info Mike notes URI identifies path on the tree, combination of LRIs
14:53:52 <alagalah> #info Mickey asks if using URI synonymous with Distinguished Name?
14:53:55 <alagalah> #info Yes
14:53:57 <alagalah> #info Daljeet asks when endpoints go away, what is flow?
14:53:58 <alagalah> #info Mike notes whoever posts the endpoint, withdraws the endpoint
14:54:00 <alagalah> #info Believe in REST, only two operations, POST and GET
14:54:03 <alagalah> #info POST can be obliteration
14:54:04 <alagalah> #info Ryan asks if Mike wants to reconsider that?
14:54:07 <alagalah> #info Does not like POST obliterations
14:54:08 <alagalah> #info Mike does not like to distinguish between PUT and DELETE
14:54:10 <alagalah> #info Keith notes one is idempotent, another isn’t
14:54:12 <alagalah> #info Ryan can buy GET and POST on a collection
14:54:14 <alagalah> #info On an element, really want GET, PUT, and DELETE
14:54:16 <alagalah> #info Don’t want to POST an element
14:54:18 <alagalah> #info Implies creating something under the element, not an element anymore, a collection
14:54:21 <alagalah> #info Mike thinks everything is an object, don’t think about collections at all
14:54:22 <alagalah> #info REST as tree of objects, containment
14:54:25 <alagalah> #info Ryan notes as soon as I move off the leaf level of your tree, what do I have?
14:54:27 <alagalah> #info A collection
14:54:28 <alagalah> #info Mike notes to delete subtree, delete subtree node root
14:54:31 <alagalah> #info Everything underneath disappears, by the rules of containment
14:54:33 <alagalah> #info That is how policy management systems work
14:54:34 <alagalah> #info Specify subtrees, remove subtrees
14:54:36 <alagalah> #info Ryan notes if do delete on collection via POST, that is an absolute nightmare in terms of coding
14:54:38 <alagalah> #info Same request operation is create and delete, give coders enough rope to load gun, hand xxx, pull trigger
14:54:40 <alagalah> #info Rob notes already a definition of RESTCONF in MD-SAL, verbs will work
14:54:42 <alagalah> #info If we want to argue how MD-SAL works, can take that into a different conversation
14:54:44 <alagalah> #info Jan notes containment does not really work if a flat database in exceptions, and have got URIs
14:54:46 <alagalah> #info Mike claims responsibility of renderer, if something goes away, knows which exceptions are out of scope, responsibility to remove it
14:54:48 <alagalah> #info Have URI, implies a tree
14:54:50 <alagalah> #info Rob notes flat in the sense of yang list of exceptions
14:54:52 <alagalah> #info Exception indexed by URI
14:54:54 <alagalah> #info Jan notes boils down to slightly different mechanism than deleting node, data store, somebody in infrastructure deleting subnodes
14:54:57 <alagalah> #info Here application has to go apply the filter
14:54:58 <alagalah> #info Mike claims that is one of the requirements we have
14:55:00 <alagalah> #info Filter is on a tree
14:55:02 <alagalah> #info Here your tree is still honored, except don’t have explicit tree, putting in there (exceptions) is overkill
14:55:04 <alagalah> #info Jan claims two mechanisms, one in infrastructure, the other in application where you have to apply filters
14:55:06 <alagalah> #info Jan is OK if want to do it in the application
14:55:08 <alagalah> #info Mike counters, argument whether done in application or not, driven by fact that you have to meet certain scalability
14:55:11 <alagalah> #info EP Registry needs to be superfast
14:55:12 <alagalah> #info Can create trees all we want, if not fast, will not work
14:55:15 <alagalah> #info If takes 20 minutes to create policy for an endpoint, does not work
14:55:17 <alagalah> #info If can avoid creating additional objects, will run faster
14:55:18 <alagalah> #info Avoid creating unnecessary things, in the name of efficiency
14:55:20 <alagalah> #info …
14:55:23 <alagalah> #info Rob notes need fast data store
14:55:24 <alagalah> #info Jan asks what is in Ops State at a high level?
14:55:27 <alagalah> #info Someone says stats
14:55:28 <alagalah> #info Mike does not like that
14:55:31 <alagalah> #info The way he thinks about this, rather than specifying precise statistics, should concentrate on health scores
14:55:33 <alagalah> #info Already have detailed instrumentation of these things
14:55:35 <alagalah> #info Don’t want to replicate, Group-Based Policy replicate everything in the world
14:55:36 <alagalah> #info Health Score
14:55:39 <alagalah> #info Capacity Score
14:55:40 <alagalah> #info Security Score
14:55:42 <alagalah> #info Utilization
14:55:44 <alagalah> #info Whatever else
14:55:46 <alagalah> #info Normalized scores, measured as scalars, 1 to 100
14:55:49 <alagalah> #info Jan asks for policies, rendered objects?
14:55:50 <alagalah> #info Mike notes context scope of URI of affected policy construct, and URI of endpoint
14:55:53 <alagalah> #info Jan summarizes, scores for policy and endpoints?
14:55:55 <alagalah> #info Mike notes intersection of both
14:55:57 <alagalah> #info Might have one general to endpoint, one general to policy only
14:55:59 <alagalah> #info Jan notes who creates this has to understand both policy and endpoints
14:56:01 <alagalah> #info Rob claims generic view into state of renderer
14:56:03 <alagalah> #info Exception repository is compliance score
14:56:04 <alagalah> #info Abstraction of state expressed with a complete lack of detail
14:56:06 <alagalah> #info Idea is later on know how things map to concrete models, which is a separate activity
14:56:08 <alagalah> #info Can retrieve, actually show what is going on
14:56:10 <alagalah> #info Ryan asks, score is abstractional scalar with no detail?
14:56:13 <alagalah> #info Pick a random number between 90 and 100?
14:56:15 <alagalah> #info Mike claims one way to understand health score, if object with 20 faults with certain severity, sum up, come up with a score called health score
14:56:16 <alagalah> #info Look at thermals, those things result in threshold crossing alerts
14:56:19 <alagalah> #info Sum up, environmental score (not saying we need that)
14:56:20 <alagalah> #info Rob suggests health of most severe fault
14:56:22 <alagalah> #info (Sometimes that works, sometimes not)
14:56:24 <alagalah> #info Rob wonders how to click on it, figure out
14:56:26 <alagalah> #info Mike notes have to figure out
14:56:28 <alagalah> #info At this point, concrete models are sparse
14:56:30 <alagalah> #info The idea is if renderer renders down to a concrete substrate, his responsibility to have some kind of map
14:56:34 <alagalah> #info Rob asks how renderer exposes concrete state to somewhere?
14:56:34 <alagalah> #info Mike notes in ACI, set of mapping tables, where you have a policy, know where applied, on whose behalf, also know concrete model on boxes, point to concrete xxx on something, low level stuff
14:56:37 <alagalah> #info How mapped to ASICs
14:56:39 <alagalah> #info We need to decide how far to take this
14:56:40 <alagalah> #info Rob notes could have something where renderer exposes opaque object through operational state, plugin on north side
14:56:44 <alagalah> #info Daljeet asks, tweek back to required state? Feedback loops?
14:56:44 <alagalah> #info Rob claims everything in the system is various feedback loops of different sizes
14:56:46 <alagalah> #info Dan asks how to normalize?
14:56:48 <alagalah> #info Mike notes something we have to decide
14:56:53 <alagalah> #info In more complex scenarios, end up with, if fault leaked to somebody else, have propagation and xxx issues
14:56:53 <alagalah> #info Daljeet asks if thrashing issues, programming TCAM 10 times a second?
14:56:55 <alagalah> #info Keith counters, implementation detail
14:56:57 <alagalah> #info Rob notes if performance of this system is such that we are thrashing, that is awesome
14:56:58 <alagalah> #info Keith notes most important thing is each of those scores does not get calculated in the same way
14:57:00 <alagalah> #info Distribution, weights
14:57:05 <alagalah> #info Key thing is to look at frequency of distribution, xxx, data points that make up scores, sensible formulas
14:57:06 <alagalah> #info Mickey asks if we should say something about northbound, interaction with customers?
14:57:07 <alagalah> #info Keith notes all RESTCONF
14:57:09 <alagalah> #info Mike notes you POST policies, RETR policies
14:57:10 <alagalah> #info Ryan notes RESTCONF is OK except in places where RESTCONF isn’t
14:57:14 <alagalah> #info Mike asks what Ryan would propose using
14:57:14 <alagalah> #info Ryan puts his finger on the Neutron question
14:57:16 <alagalah> #info Unless you are talking about pulling RESTCONF into the Neutron plugin for ODL, that is a whole different setup
14:57:18 <alagalah> #info Mike notes either solve as a mediation problem or a translation problem
14:57:22 <alagalah> #info Mike notes Neutron policy model renders directly, subset of ODL’s group-based policy model, just syntactic transformation, essentially a pass through
14:57:22 <alagalah> #info Jan claims can be totally automated
14:57:24 <alagalah> #info Mike notes trouble when have to start doing semantic transformation
14:57:26 <alagalah> #info GBP in OpenStack follows the same
14:57:29 <alagalah> #info Rob notes when north of us, need to be using model, cannot have northbound interface …
14:57:31 <alagalah> #info Southbound you can translate, northbound you can’t
14:57:32 <alagalah> #info Mike wants to normalize constraints
14:57:35 <alagalah> #info Jan summarizes, southbound is in scope, have renderers
14:57:37 <alagalah> #info northbound, …
14:57:38 <alagalah> #info In other projects, people too bound to JSON, percolating through the whole thing
14:57:40 <alagalah> #info Mike notes just an interface, once have information model, can always generate another
14:57:43 <alagalah> #info Jan notes lots don’t understand, have information model, generate NB/SB, everything
14:57:45 <alagalah> #info Ryan claims JSON is not an interface, it is an encoding
14:57:46 <alagalah> #info Mike agrees, a data format encoding
14:57:49 <alagalah> #info Jan, which is defined by the interface
14:57:50 <alagalah> #info Enforcement exceptions, retrieve and notifications
14:57:52 <alagalah> #info Jan asks what interactions with topology, etc?
14:57:54 <alagalah> #info Mike says up to the renderer, that is the smart guy
14:57:57 <alagalah> #info These guys (above) are idiotic
14:57:58 <alagalah> #info Renderer looks at topology, talks to OpenFlow, etc
14:58:01 <alagalah> #info Jan asks 3 or 4 different renderers?
14:58:02 <alagalah> #info Mickey notes candidate list, have at least 4 or 5
14:58:04 <alagalah> #info Which ones become real, depends who volunteers for what
14:58:06 <alagalah> #action Keith notes current state of renderer, identified 4 key ones to go after
14:58:08 <alagalah> #action Rob and Keith will pick one to do strawman
14:58:11 <alagalah> #action Meetings on hold until something to show
14:58:12 <alagalah> #info Trying to break ground
14:58:14 <alagalah> #info Rob would much rather refactor code than argue endlessly
14:58:16 <alagalah> #info Jan notes will not get everything with OVSDB that you need
14:58:20 <alagalah> #action Keith thinks between OVSDB and OpenFlow
14:58:20 <alagalah> #info Mike wonders if have to have both
14:58:22 <alagalah> #info Mickey notes Dave Lenrow asked about service chaining
14:58:24 <alagalah> #info Mike wants to do that in the model
14:58:26 <alagalah> #info Keep things relatively simple to agree on concepts, then add more concepts
14:58:28 <alagalah> #info Jan notes service chaining project being proposed
14:58:30 <alagalah> #info Should reuse APIs that they propose for that project
14:58:32 <alagalah> #info Mike notes define policies, either done through rendering
14:58:34 <alagalah> #info Chris Price thinks renderer should make decision how much to reuse
14:58:37 <alagalah> #info Jan thinks should be able to use both at the same time
14:58:38 <alagalah> #info Chris Price has concerns about renderer strategy, difficult to leverage other capabilities of the controller if just cut through
14:58:40 <alagalah> #info Mike notes renderers can entangle each other
14:58:42 <alagalah> #info Chris Price worries about how many entities to create
14:58:44 <alagalah> #info Chris Price asks about post to policy, how to select which renderer to use?
14:58:46 <alagalah> #info Mike replies TBD
14:58:48 <alagalah> #info Should not depend on the policy, should depend on the network
14:58:51 <alagalah> #info Mike thinks it depends which endpoint
14:58:52 <alagalah> #info If endpoint, intentionally tried to avoid discussion how endpoint ends up there
14:58:54 <alagalah> #info If know which group endpoint belongs to
14:58:57 <alagalah> #info Based which group maps to, know which enforcement domain you are part of
14:58:58 <alagalah> #info Jan suggests need some sort of locator service
14:59:00 <alagalah> #info Thing is endpoints are connected to switches or nodes that you need to program in the renderer
14:59:03 <alagalah> #info Mike claims renderer has a domain that it belongs to, not just technology, sets of things
14:59:04 <alagalah> #info Jan thinks we need to go into detail, these are part of other projects
14:59:07 <alagalah> #info Needs to be hashed out
14:59:08 <alagalah> #info If do things right, can create reusable components, not just for policy, or reuse something in other projects
14:59:10 <alagalah> #info Keep in mind as well
14:59:13 <alagalah> #info Look also what other guys are doing
14:59:15 <alagalah> #info Locator service
14:59:16 <alagalah> #info Assemblance of endpoint registry
14:59:18 <alagalah> #info Service chaining
14:59:21 <alagalah> #info All being done in different projects
14:59:23 <alagalah> #info Mike understands
14:59:24 <alagalah> #info This will be an extension of what they are doing with LISP, for all purposes, concept borrowed from LISP
14:59:27 <alagalah> #info Jan claims that is how service chaining guys are thinking as well
14:59:28 <alagalah> #info Rob notes no locators in our database
14:59:31 <alagalah> #info Jan claims in LISP there is
14:59:33 <alagalah> #info Mike notes conceptually they are similar
14:59:34 <alagalah> #info Logical constructs
14:59:36 <alagalah> #info We will solve it, keep to rendering discussion
14:59:38 <alagalah> 
14:59:41 <alagalah> 
14:59:43 <alagalah> 
14:59:44 <alagalah> 
14:59:46 <alagalah> 
14:59:48 <alagalah> 
14:59:50 <alagalah> 
14:59:53 <alagalah> 
14:59:54 <alagalah> 
14:59:56 <alagalah> 
14:59:59 <alagalah> 
15:00:01 <alagalah> 
15:00:04 <alagalah> 
15:00:05 <alagalah> 
15:00:07 <alagalah> 
15:00:09 <alagalah> 
15:00:11 <alagalah> 
15:00:13 <alagalah> 
15:00:15 <alagalah> 
15:00:16 <alagalah> 
15:00:19 <alagalah> #endmeeting