#opendaylight-group-policy: PolicyArch Mickey's notes

Meeting summary

1. 1. Mike Dvorkin (alagalah, 14:50:01)
   2. Keith Burns (alagalah, 14:50:01)
   3. Rob Adams (alagalah, 14:50:03)
   4. Daljeet Singh (alagalah, 14:50:04)
   5. HP (alagalah, 14:50:06)
   6. Dan Conde (alagalah, 14:50:08)
   7. Jan Medved (alagalah, 14:50:10)
   8. Abhishek (alagalah, 14:50:12)
   9. Chris Price (alagalah, 14:50:14)
   10. Mickey Spiegel (alagalah, 14:50:16)
   11. Ryan Moats (alagalah, 14:50:19)
   12. Mickey’s intro (alagalah, 14:50:20)
   
   
2. Components, high-level flows (alagalah, 14:50:23)
   1. Jan requests use cases (alagalah, 14:50:24)
   2. Mike draws Policy Repo and EP Reg / Mapper and Enforcement Exception Repository and Ops State (alagalah, 14:50:27)
   3. Renderers below (alagalah, 14:50:29)
   4. Renderers resolve, checks out policies from (alagalah, 14:50:30)
   5. Theoretically, this guy can declare endpoints, plus resolve (alagalah, 14:50:33)
   6. Jan asks under what conditions declare endpoints? (alagalah, 14:50:34)
   7. Mickey notes discovery of an endpoint (alagalah, 14:50:37)
   8. Jan mentions EP Registry Mapper, other inputs (alagalah, 14:50:38)
   9. Chris notes as long as same xxx, good (alagalah, 14:50:40)
   10. Mike notes can be posting can be part of renderer or not, does not have to be (alagalah, 14:50:42)
   11. For the sake of discussion, say it has to be (alagalah, 14:50:46)
   12. Renderer can post enforcement exceptions (alagalah, 14:50:47)
   13. I could not render something (alagalah, 14:50:48)
   14. Exception (alagalah, 14:50:51)
   15. Not rendering to the full gravity of what is defined by the policy (alagalah, 14:50:53)
   16. Jan asks in database, searchable? (alagalah, 14:50:55)
   17. Mickey assumes not any object anywhere can have exceptions, but at certain places, this is working or not (alagalah, 14:50:57)
   18. Jan asks if post exceptions to operator (alagalah, 14:50:59)
   19. Mike notes talking about how renderer interacts with components (alagalah, 14:51:00)
   20. Renderer updates state (alagalah, 14:51:02)
   21. Chris … (alagalah, 14:51:04)
   22. Mike notes to him enforcement exceptions and op state are related (alagalah, 14:51:06)
   23. One xxx (alagalah, 14:51:09)
   24. Other can come up with scores, this is my utilization (alagalah, 14:51:10)
   25. We have this kind of capacity (alagalah, 14:51:14)
   26. Measures behavior, not enforcement (alagalah, 14:51:14)
   27. If I ask to do something, gave you a price (alagalah, 14:51:17)
   28. How well do I fulfill this price? (alagalah, 14:51:18)
   29. Different xxx, specify how to count things, express in normalized ways (alagalah, 14:51:20)
   30. Jan notes exception needs access to policy definitions, need to know when an exception, not rendered properly (alagalah, 14:51:22)
   31. Mike would much rather not (alagalah, 14:51:26)
   32. Jan asks how to know exceptions occur? (alagalah, 14:51:28)
   33. Chris would render network, then put triggers within Ops State that would invoke exceptions (alagalah, 14:51:28)
   34. Mike notes no way to enforce QoS, exception (alagalah, 14:51:31)
   35. Chris Price notes lower bound for operational state, defines when exception occurs (alagalah, 14:51:32)
   36. Would Ops State monitor that, or replicate somewhere? (alagalah, 14:51:35)
   37. Mike notes fine line, depends on what you mean (alagalah, 14:51:36)
   38. Ops State is derivative of actual state underneath (alagalah, 14:51:39)
   39. Might have port that is misbehaving, affects behavior of my endpoint (alagalah, 14:51:41)
   40. Ops State stuff measures that (alagalah, 14:51:42)
   41. Jan asks for example, contract definition, what state if not rendered properly, what gets injected into Ops State (alagalah, 14:51:46)
   42. Mike notes if render contract, you cannot enforce something, have to report to exception repository (alagalah, 14:51:47)
   43. QoS super duper high priority (alagalah, 14:51:49)
   44. Cannot do for some reason, raise an exception (alagalah, 14:51:50)
   45. Say mechanism cannot enforce conditions on endpoints because implemented in ASICs, not enough CAM size (alagalah, 14:51:53)
   46. Relaxing constraint, have to report an exception (alagalah, 14:51:56)
   47. Jan asks if data model related to policy? (alagalah, 14:51:56)
   48. Mike wants to make it generic (alagalah, 14:51:58)
   49. Jan notes have to have exception, cannot enforce contract (alagalah, 14:52:01)
   50. Mike notes full discussion dedicated to these two (alagalah, 14:52:04)
   51. Jan’s reason for the question is to figure out, map out data models, data flows (alagalah, 14:52:05)
   52. Mike draws URI of the affected policy construct (alagalah, 14:52:06)
   53. URI of the EP (alagalah, 14:52:09)
   54. “exception description” (alagalah, 14:52:10)
   55. “probably cause” (alagalah, 14:52:13)
   56. “severity” (alagalah, 14:52:15)
   57. “affect on xxx” (alagalah, 14:52:16)
   58. Measurement of completion (alagalah, 14:52:19)
   59. Chris Price asks about interaction with consumer? (alagalah, 14:52:20)
   60. Mike notes URIs (alagalah, 14:52:23)
   61. If look at policy, know which exceptions are in scope, based on URI (alagalah, 14:52:25)
   62. Chris Price claims should not deploy, cannot fulfill (alagalah, 14:52:27)
   63. Mike wants to avoid order of operation issues, have to delete something before you create something (alagalah, 14:52:28)
   64. Mike claims problem, what if 15 endpoints, for next one that showed up 15 minutes later, you can’t? (alagalah, 14:52:31)
   65. Raise an exception (alagalah, 14:52:34)
   66. Feeds into placement engine (alagalah, 14:52:34)
   67. Because of that, want to move endpoint somewhere else (alagalah, 14:52:36)
   68. Oftentimes you don’t control where you place endpoints (alagalah, 14:52:38)
   69. Scheduler sitting on top (alagalah, 14:52:41)
   70. Cannot move endpoints ourselves, have to give feedback to system on top that makes placement decisions (alagalah, 14:52:42)
   71. Exceptions are persistent for as long as conditions exist (alagalah, 14:52:44)
   72. Move it to history (alagalah, 14:52:46)
   73. Daljeet asks how policy changes are propagated to renderers? (alagalah, 14:52:48)
   74. Mike notes you subscribe, linear subscription (alagalah, 14:52:51)
   75. Whenever policy changes, get updated (alagalah, 14:52:53)
   76. This is why MD-SAL seems like a very good fit (alagalah, 14:52:55)
   77. Jan claims same pattern for exceptions (alagalah, 14:52:56)
   78. Mike notes except data is not trees (alagalah, 14:52:58)
   79. Jan counters, can put in a tree (alagalah, 14:53:00)
   80. Mike agrees, though a very shallow tree (alagalah, 14:53:03)
   81. Mike notes might be some other applications interested in this (alagalah, 14:53:06)
   82. What they do, how they alter policy, we cannot predict that, have to provide framework for that (alagalah, 14:53:07)
   83. Jan notes that is pubsub (alagalah, 14:53:08)
   84. Jan brings up, perhaps don’t address that, identifiers may or may not be URIs (alagalah, 14:53:10)
   85. Internally if Java to Java components, instance identifiers (alagalah, 14:53:13)
   86. Have solution for that (alagalah, 14:53:15)
   87. Mike notes logically everything is a URI (alagalah, 14:53:16)
   88. Mike loves consistent identifiers, hate duality, causes schizophrenia (alagalah, 14:53:19)
   89. Talking about behaviors versus implementation (alagalah, 14:53:20)
   90. Jan notes do not want to be just accessing this through REST APIs (alagalah, 14:53:24)
   91. Mike counters, you can subscribe to it, already agreed (alagalah, 14:53:24)
   92. Jan notes APIs you subscribe to, does not matter if came to it from REST or something else (alagalah, 14:53:27)
   93. Mike notes subscribe to certain sets of data within certain scopes (alagalah, 14:53:28)
   94. Jan hates duality too (alagalah, 14:53:30)
   95. When get that event, looks the same to you (alagalah, 14:53:33)
   96. 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)
   97. Jan claimed solved with yang tools (alagalah, 14:53:37)
   98. Mike claims flat data set, do not want to recreate another tree, cost will be staggering (alagalah, 14:53:39)
   99. Mike draws Exception Repo with objects underneath, without further structure (alagalah, 14:53:40)
   100. Treating things as URI, tells you position on the tree (alagalah, 14:53:42)
   101. Being able to filter on that (alagalah, 14:53:44)
   102. Question how to model URI, does not have to be string (alagalah, 14:53:46)
   103. Ryan claims everything has to be a URI rather than string (alagalah, 14:53:48)
   104. Mike notes URI identifies path on the tree, combination of LRIs (alagalah, 14:53:50)
   105. Mickey asks if using URI synonymous with Distinguished Name? (alagalah, 14:53:52)
   106. Yes (alagalah, 14:53:55)
   107. Daljeet asks when endpoints go away, what is flow? (alagalah, 14:53:57)
   108. Mike notes whoever posts the endpoint, withdraws the endpoint (alagalah, 14:53:58)
   109. Believe in REST, only two operations, POST and GET (alagalah, 14:54:00)
   110. POST can be obliteration (alagalah, 14:54:03)
   111. Ryan asks if Mike wants to reconsider that? (alagalah, 14:54:04)
   112. Does not like POST obliterations (alagalah, 14:54:07)
   113. Mike does not like to distinguish between PUT and DELETE (alagalah, 14:54:08)
   114. Keith notes one is idempotent, another isn’t (alagalah, 14:54:10)
   115. Ryan can buy GET and POST on a collection (alagalah, 14:54:12)
   116. On an element, really want GET, PUT, and DELETE (alagalah, 14:54:14)
   117. Don’t want to POST an element (alagalah, 14:54:16)
   118. Implies creating something under the element, not an element anymore, a collection (alagalah, 14:54:18)
   119. Mike thinks everything is an object, don’t think about collections at all (alagalah, 14:54:21)
   120. REST as tree of objects, containment (alagalah, 14:54:22)
   121. Ryan notes as soon as I move off the leaf level of your tree, what do I have? (alagalah, 14:54:25)
   122. A collection (alagalah, 14:54:27)
   123. Mike notes to delete subtree, delete subtree node root (alagalah, 14:54:28)
   124. Everything underneath disappears, by the rules of containment (alagalah, 14:54:31)
   125. That is how policy management systems work (alagalah, 14:54:33)
   126. Specify subtrees, remove subtrees (alagalah, 14:54:34)
   127. Ryan notes if do delete on collection via POST, that is an absolute nightmare in terms of coding (alagalah, 14:54:36)
   128. Same request operation is create and delete, give coders enough rope to load gun, hand xxx, pull trigger (alagalah, 14:54:38)
   129. Rob notes already a definition of RESTCONF in MD-SAL, verbs will work (alagalah, 14:54:40)
   130. If we want to argue how MD-SAL works, can take that into a different conversation (alagalah, 14:54:42)
   131. Jan notes containment does not really work if a flat database in exceptions, and have got URIs (alagalah, 14:54:44)
   132. Mike claims responsibility of renderer, if something goes away, knows which exceptions are out of scope, responsibility to remove it (alagalah, 14:54:46)
   133. Have URI, implies a tree (alagalah, 14:54:48)
   134. Rob notes flat in the sense of yang list of exceptions (alagalah, 14:54:50)
   135. Exception indexed by URI (alagalah, 14:54:52)
   136. Jan notes boils down to slightly different mechanism than deleting node, data store, somebody in infrastructure deleting subnodes (alagalah, 14:54:54)
   137. Here application has to go apply the filter (alagalah, 14:54:57)
   138. Mike claims that is one of the requirements we have (alagalah, 14:54:58)
   139. Filter is on a tree (alagalah, 14:55:00)
   140. Here your tree is still honored, except don’t have explicit tree, putting in there (exceptions) is overkill (alagalah, 14:55:02)
   141. Jan claims two mechanisms, one in infrastructure, the other in application where you have to apply filters (alagalah, 14:55:04)
   142. Jan is OK if want to do it in the application (alagalah, 14:55:06)
   143. Mike counters, argument whether done in application or not, driven by fact that you have to meet certain scalability (alagalah, 14:55:08)
   144. EP Registry needs to be superfast (alagalah, 14:55:11)
   145. Can create trees all we want, if not fast, will not work (alagalah, 14:55:12)
   146. If takes 20 minutes to create policy for an endpoint, does not work (alagalah, 14:55:15)
   147. If can avoid creating additional objects, will run faster (alagalah, 14:55:17)
   148. Avoid creating unnecessary things, in the name of efficiency (alagalah, 14:55:18)
   149. … (alagalah, 14:55:20)
   150. Rob notes need fast data store (alagalah, 14:55:23)
   151. Jan asks what is in Ops State at a high level? (alagalah, 14:55:24)
   152. Someone says stats (alagalah, 14:55:27)
   153. Mike does not like that (alagalah, 14:55:28)
   154. The way he thinks about this, rather than specifying precise statistics, should concentrate on health scores (alagalah, 14:55:31)
   155. Already have detailed instrumentation of these things (alagalah, 14:55:33)
   156. Don’t want to replicate, Group-Based Policy replicate everything in the world (alagalah, 14:55:35)
   157. Health Score (alagalah, 14:55:36)
   158. Capacity Score (alagalah, 14:55:39)
   159. Security Score (alagalah, 14:55:40)
   160. Utilization (alagalah, 14:55:42)
   161. Whatever else (alagalah, 14:55:44)
   162. Normalized scores, measured as scalars, 1 to 100 (alagalah, 14:55:46)
   163. Jan asks for policies, rendered objects? (alagalah, 14:55:49)
   164. Mike notes context scope of URI of affected policy construct, and URI of endpoint (alagalah, 14:55:50)
   165. Jan summarizes, scores for policy and endpoints? (alagalah, 14:55:53)
   166. Mike notes intersection of both (alagalah, 14:55:55)
   167. Might have one general to endpoint, one general to policy only (alagalah, 14:55:57)
   168. Jan notes who creates this has to understand both policy and endpoints (alagalah, 14:55:59)
   169. Rob claims generic view into state of renderer (alagalah, 14:56:01)
   170. Exception repository is compliance score (alagalah, 14:56:03)
   171. Abstraction of state expressed with a complete lack of detail (alagalah, 14:56:04)
   172. Idea is later on know how things map to concrete models, which is a separate activity (alagalah, 14:56:06)
   173. Can retrieve, actually show what is going on (alagalah, 14:56:08)
   174. Ryan asks, score is abstractional scalar with no detail? (alagalah, 14:56:10)
   175. Pick a random number between 90 and 100? (alagalah, 14:56:13)
   176. 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)
   177. Look at thermals, those things result in threshold crossing alerts (alagalah, 14:56:16)
   178. Sum up, environmental score (not saying we need that) (alagalah, 14:56:19)
   179. Rob suggests health of most severe fault (alagalah, 14:56:20)
   180. (Sometimes that works, sometimes not) (alagalah, 14:56:22)
   181. Rob wonders how to click on it, figure out (alagalah, 14:56:24)
   182. Mike notes have to figure out (alagalah, 14:56:26)
   183. At this point, concrete models are sparse (alagalah, 14:56:28)
   184. The idea is if renderer renders down to a concrete substrate, his responsibility to have some kind of map (alagalah, 14:56:30)
   185. Rob asks how renderer exposes concrete state to somewhere? (alagalah, 14:56:34)
   186. 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)
   187. How mapped to ASICs (alagalah, 14:56:37)
   188. We need to decide how far to take this (alagalah, 14:56:39)
   189. Rob notes could have something where renderer exposes opaque object through operational state, plugin on north side (alagalah, 14:56:40)
   190. Daljeet asks, tweek back to required state? Feedback loops? (alagalah, 14:56:44)
   191. Rob claims everything in the system is various feedback loops of different sizes (alagalah, 14:56:44)
   192. Dan asks how to normalize? (alagalah, 14:56:46)
   193. Mike notes something we have to decide (alagalah, 14:56:48)
   194. In more complex scenarios, end up with, if fault leaked to somebody else, have propagation and xxx issues (alagalah, 14:56:53)
   195. Daljeet asks if thrashing issues, programming TCAM 10 times a second? (alagalah, 14:56:53)
   196. Keith counters, implementation detail (alagalah, 14:56:55)
   197. Rob notes if performance of this system is such that we are thrashing, that is awesome (alagalah, 14:56:57)
   198. Keith notes most important thing is each of those scores does not get calculated in the same way (alagalah, 14:56:58)
   199. Distribution, weights (alagalah, 14:57:00)
   200. Key thing is to look at frequency of distribution, xxx, data points that make up scores, sensible formulas (alagalah, 14:57:05)
   201. Mickey asks if we should say something about northbound, interaction with customers? (alagalah, 14:57:06)
   202. Keith notes all RESTCONF (alagalah, 14:57:07)
   203. Mike notes you POST policies, RETR policies (alagalah, 14:57:09)
   204. Ryan notes RESTCONF is OK except in places where RESTCONF isn’t (alagalah, 14:57:10)
   205. Mike asks what Ryan would propose using (alagalah, 14:57:14)
   206. Ryan puts his finger on the Neutron question (alagalah, 14:57:14)
   207. Unless you are talking about pulling RESTCONF into the Neutron plugin for ODL, that is a whole different setup (alagalah, 14:57:16)
   208. Mike notes either solve as a mediation problem or a translation problem (alagalah, 14:57:18)
   209. 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)
   210. Jan claims can be totally automated (alagalah, 14:57:22)
   211. Mike notes trouble when have to start doing semantic transformation (alagalah, 14:57:24)
   212. GBP in OpenStack follows the same (alagalah, 14:57:26)
   213. Rob notes when north of us, need to be using model, cannot have northbound interface … (alagalah, 14:57:29)
   214. Southbound you can translate, northbound you can’t (alagalah, 14:57:31)
   215. Mike wants to normalize constraints (alagalah, 14:57:32)
   216. Jan summarizes, southbound is in scope, have renderers (alagalah, 14:57:35)
   217. northbound, … (alagalah, 14:57:37)
   218. In other projects, people too bound to JSON, percolating through the whole thing (alagalah, 14:57:38)
   219. Mike notes just an interface, once have information model, can always generate another (alagalah, 14:57:40)
   220. Jan notes lots don’t understand, have information model, generate NB/SB, everything (alagalah, 14:57:43)
   221. Ryan claims JSON is not an interface, it is an encoding (alagalah, 14:57:45)
   222. Mike agrees, a data format encoding (alagalah, 14:57:46)
   223. Jan, which is defined by the interface (alagalah, 14:57:49)
   224. Enforcement exceptions, retrieve and notifications (alagalah, 14:57:50)
   225. Jan asks what interactions with topology, etc? (alagalah, 14:57:52)
   226. Mike says up to the renderer, that is the smart guy (alagalah, 14:57:54)
   227. These guys (above) are idiotic (alagalah, 14:57:57)
   228. Renderer looks at topology, talks to OpenFlow, etc (alagalah, 14:57:58)
   229. Jan asks 3 or 4 different renderers? (alagalah, 14:58:01)
   230. Mickey notes candidate list, have at least 4 or 5 (alagalah, 14:58:02)
   231. Which ones become real, depends who volunteers for what (alagalah, 14:58:04)
   232. ACTION: Keith notes current state of renderer, identified 4 key ones to go after (alagalah, 14:58:06)
   233. ACTION: Rob and Keith will pick one to do strawman (alagalah, 14:58:08)
   234. ACTION: Meetings on hold until something to show (alagalah, 14:58:11)
   235. Trying to break ground (alagalah, 14:58:12)
   236. Rob would much rather refactor code than argue endlessly (alagalah, 14:58:14)
   237. Jan notes will not get everything with OVSDB that you need (alagalah, 14:58:16)
   238. ACTION: Keith thinks between OVSDB and OpenFlow (alagalah, 14:58:20)
   239. Mike wonders if have to have both (alagalah, 14:58:20)
   240. Mickey notes Dave Lenrow asked about service chaining (alagalah, 14:58:22)
   241. Mike wants to do that in the model (alagalah, 14:58:24)
   242. Keep things relatively simple to agree on concepts, then add more concepts (alagalah, 14:58:26)
   243. Jan notes service chaining project being proposed (alagalah, 14:58:28)
   244. Should reuse APIs that they propose for that project (alagalah, 14:58:30)
   245. Mike notes define policies, either done through rendering (alagalah, 14:58:32)
   246. Chris Price thinks renderer should make decision how much to reuse (alagalah, 14:58:34)
   247. Jan thinks should be able to use both at the same time (alagalah, 14:58:37)
   248. Chris Price has concerns about renderer strategy, difficult to leverage other capabilities of the controller if just cut through (alagalah, 14:58:38)
   249. Mike notes renderers can entangle each other (alagalah, 14:58:40)
   250. Chris Price worries about how many entities to create (alagalah, 14:58:42)
   251. Chris Price asks about post to policy, how to select which renderer to use? (alagalah, 14:58:44)
   252. Mike replies TBD (alagalah, 14:58:46)
   253. Should not depend on the policy, should depend on the network (alagalah, 14:58:48)
   254. Mike thinks it depends which endpoint (alagalah, 14:58:51)
   255. If endpoint, intentionally tried to avoid discussion how endpoint ends up there (alagalah, 14:58:52)
   256. If know which group endpoint belongs to (alagalah, 14:58:54)
   257. Based which group maps to, know which enforcement domain you are part of (alagalah, 14:58:57)
   258. Jan suggests need some sort of locator service (alagalah, 14:58:58)
   259. Thing is endpoints are connected to switches or nodes that you need to program in the renderer (alagalah, 14:59:00)
   260. Mike claims renderer has a domain that it belongs to, not just technology, sets of things (alagalah, 14:59:03)
   261. Jan thinks we need to go into detail, these are part of other projects (alagalah, 14:59:04)
   262. Needs to be hashed out (alagalah, 14:59:07)
   263. If do things right, can create reusable components, not just for policy, or reuse something in other projects (alagalah, 14:59:08)
   264. Keep in mind as well (alagalah, 14:59:10)
   265. Look also what other guys are doing (alagalah, 14:59:13)
   266. Locator service (alagalah, 14:59:15)
   267. Assemblance of endpoint registry (alagalah, 14:59:16)
   268. Service chaining (alagalah, 14:59:18)
   269. All being done in different projects (alagalah, 14:59:21)
   270. Mike understands (alagalah, 14:59:23)
   271. This will be an extension of what they are doing with LISP, for all purposes, concept borrowed from LISP (alagalah, 14:59:24)
   272. Jan claims that is how service chaining guys are thinking as well (alagalah, 14:59:27)
   273. Rob notes no locators in our database (alagalah, 14:59:28)
   274. Jan claims in LISP there is (alagalah, 14:59:31)
   275. Mike notes conceptually they are similar (alagalah, 14:59:33)
   276. Logical constructs (alagalah, 14:59:34)
   277. We will solve it, keep to rendering discussion (alagalah, 14:59:36)

Action items

1. Keith notes current state of renderer, identified 4 key ones to go after
2. Rob and Keith will pick one to do strawman
3. Meetings on hold until something to show
4. Keith thinks between OVSDB and OpenFlow

People present (lines said)

1. alagalah (313)
2. odl_meetbot (3)