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