#opendaylight-nic: nic weekly

Meeting summary

1. agenda bashing (colindixon, 16:03:56)
   1. devond wants to cover the release plan (colindixon, 16:04:24)
   2. dlenrow may cover the SFC use case a bit (colindixon, 16:05:19)
   3. covering jonathan’s slides (colindixon, 16:06:31)
   4. dmentze also wants to cover the sample code and YANG (devond says that this is likley part of the release plan) (colindixon, 16:07:14)
   
   
2. release plan deliverables (colindixon, 16:07:19)
   1. devond points out that the M3 deadline is 3/19 (~3 weeks) and isn’t getting any further away (colindixon, 16:07:44)
   2. we promised to deliver Feature Freeze, YANG Freeze, Use Case Freeze, HIgh Level Design (colindixon, 16:08:06)
   3. colindixon asks whether we seem to be converging on the YANG model or are we headed toward some collision when we need to actually pick a model? (colindixon, 16:09:16)
   4. devond says he’s seeing more converging than conflicts on the horizon (colindixon, 16:09:41)
   5. https://lists.opendaylight.org/pipermail/release/2015-February/001493.html gzhao points out that there is more to the M# release and this is the template (colindixon, 16:10:22)
   6. dbainbri responds to colindixon by saying “I think we have a path forward and it has been the correct approach to see if we can encode the known use cases using the proposed model.” (colindixon, 16:11:56)
   7. the consensus seems to be that we’re moving in the right direction, but we just need to keep moving (colindixon, 16:12:10)
   8. dlenrow said as offset 2 project, if necessary we can ask TSC approve for API update after function freeze. (gzhao, 16:12:19)
   9. dlenrow asks if attendance here is declining because people aren’t interest or if we’re driving them away because we’re not listening (colindixon, 16:13:13)
   10. ACTION: dlenrow to poll people to figure out if we’re losing people for bad reasons? (colindixon, 16:13:29)
   11. Dave is baffled by the new fangled technology known as the scrollbar ;) (dbainbri, 16:13:57)
   
   
3. API (colindixon, 16:14:08)
   1. dmentze says that we’re trying to work out the API and he asked for people get use cases in by 2/20 to be able to have some core set to evaluate the YANG/API (colindixon, 16:14:42)
   2. dmentze wants to be clear that he really doesn’t want to freeze bringing new use cases, just get some key ones so we can talk (colindixon, 16:15:07)
   3. two people took the time to write REST invocations for the use cases to evaluate them (colindixon, 16:15:39)
   4. one came from Shaun and another came from Louis, they were targeting two different YANG models (colindixon, 16:16:44)
   5. https://wiki.opendaylight.org/view/Network_Intent_Composition:Use_Cases use cases on the wiki (colindixon, 16:17:16)
   6. Louis and dmentze talk back and forth about Louis’s use case with respect to looking at endpoint attributes and traffic attributes at the same time (also source and destination attributes) (colindixon, 16:23:41)
   7. dlenrow asks if we’re still thinking we want endpoints to be very flexible, e.g., hosts vs. traffic prefixes vs. L4 flows, etc., and if that can move us away from traffic classification (colindixon, 16:28:11)
   8. colindixon says he’s pretty sure we’re all in agreement that we want endpoints to be more flexible than just hosts (colindixon, 16:28:35)
   9. colindixon says there is some debate if this means we don’t need traffic classification in addition to endpoint details, e.g., trapping all DNS traffic is harder to express using just endpoints than you might like (colindixon, 16:30:24)
   10. we need to be extremely carefull about building our NBI based on anticipating the implementation. When the primary goal is ease of use, and we know theres a risk of making this too complicated to consume, we don't want to pollute the user experience with implementation driven detail. The whole point of intent is to not pollute the user experience with (dlenrow, 16:32:11)
   11. https://lists.opendaylight.org/pipermail/nic-dev/2015-February/000293.html the mailing list thread on DNS and how it can/can’t map to purely EPG-based things (colindixon, 16:33:02)
   12. It seems to me that in wireshark there is a good example of selecting "network" things. I am a fan of leveraging things that exist and are proven in nature. we could then extend that to meet our other needs such as label (tag) searching and mapping of service names to ports and protocols. (dbainbri, 16:33:37)
   13. ACTION: everyone should look over the use cases on the wiki and figure out how they think about them, so we can look at it over the week (colindixon, 16:34:18)
   14. Helen and gzhao say that they’ve been trying to make endpoints work for carrier use cases and they have been having trouble (colindixon, 16:36:15)
   15. we also need to keep in mind IPv6 and not just IPv4 (dbainbri, 16:36:20)
   16. dmentze asks for Helen to document this and bring it to the mailing list and wiki this week so we can have a discussion (colindixon, 16:37:03)
   
   
4. Jonathan’s slides (presentation from Inocybe/Mathieu) (colindixon, 16:40:20)
   1. the idea is to create an open intent runtime that runs across controllers (colindixon, 16:40:45)
   2. ACTION: jfokkan will post the slides after the call (colindixon, 16:42:19)
   3. dbainbri asks if the deal between ONF and Inocybe has been finalized? dlenrow says not yet. (colindixon, 16:42:59)
   4. the proposal (at least on the slides) shows an open intent engine that compiles down to both ONOS and ODL (colindixon, 16:43:46)
   5. dlenrow and dbainbri ask if this is still relevant given mlemay’s recent statements and the fact that the ODL intent project seems very hesitant to take code from from external sources and more amenable to taking models (colindixon, 16:44:35)
   6. there’s a timeline with a Proof of Concept being delivered by June (colindixon, 16:45:24)
   7. dmentze asks about when the infomodel is coming since he doesn’t even see it in the slides (colindixon, 16:46:06)
   8. the answer is that the “runtime” on the slides is actually an offline translation tool from a common infomodel to controller-specific infomodels (colindixon, 16:46:37)
   9. dbainbri if ODL has an intent model of it’s own, what’s the value proposition of deploying, testing, scaling, etc. a separate intent model layer (colindixon, 16:48:20)
   10. response is that the goal (as dbainbri suggested) is really just a standard model (colindixon, 16:48:37)
   11. dlenrow says ONF does infomodeling in UML and that’s what the ONF standard interface is likely to be while ODL does infomodeling in YANG (colindixon, 16:49:15)
   12. dlenrow, dmentze, and dbainbri seem somewhat skeptical of this approach if it’s anything more complicated than a basic translator from ONF UML operations to ODL YANG/RESTCONF operations (colindixon, 16:50:46)
   13. it sounds like there’s really cool stuff going on, but the exact details seem to be in flux (colindixon, 16:52:09)
   
   
5. intent prototype (colindixon, 16:52:24)
   1. https://git.opendaylight.org/gerrit/#/c/15629/ the prototype git (colindixon, 16:52:52)
   2. colindixon asks if we can break down the patch into smaller chunks that are more understandable (colindixon, 16:55:07)
   3. people ask for a deep dive that is remote-friendly (colindixon, 16:55:22)
   4. ACTION: devond and dmentze will set up that meeting, likely not for next week, but for the next week (colindixon, 16:55:48)
   5. dmentze asks if people have opinions on whether this is just a good example or if it’s good code to accelerate Li development (colindixon, 16:57:41)
   6. colindixon asks if we can do a deep dive next week to make sure we can get something started if we think we might want to use the code for some of our M3 deliverables (colindixon, 16:59:59)
   7. ACTION: dmentze and devond to schedule a deep dive for next week (colindixon, 17:01:36)
   8. ACTION: everyone to work hard on the API (colindixon, 17:01:40)

Action items

1. dlenrow to poll people to figure out if we’re losing people for bad reasons?
2. everyone should look over the use cases on the wiki and figure out how they think about them, so we can look at it over the week
3. jfokkan will post the slides after the call
4. devond and dmentze will set up that meeting, likely not for next week, but for the next week
5. dmentze and devond to schedule a deep dive for next week
6. everyone to work hard on the API

Action items, by person

1. devond
   1. devond and dmentze will set up that meeting, likely not for next week, but for the next week
   2. dmentze and devond to schedule a deep dive for next week
2. dlenrow
   1. dlenrow to poll people to figure out if we’re losing people for bad reasons?
3. UNASSIGNED
   1. everyone should look over the use cases on the wiki and figure out how they think about them, so we can look at it over the week
   2. jfokkan will post the slides after the call
   3. everyone to work hard on the API

People present (lines said)

1. colindixon (75)
2. dbainbri (25)
3. dlenrow (8)
4. gzhao (7)
5. devond (4)
6. odl_meetbot (4)
7. tbachman (1)
8. LouisF (1)