#opendaylight-meeting: tws

Meeting summary

1. agenda bashing (colindixon, 18:00:43)
   
2. Agenda Bashing (alagalah, 18:01:39)
   1. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas (alagalah, 18:01:41)
   2. today, Steve Dean is going to cover the device driver framework project proposal (colindixon, 18:02:30)
   
   
3. Device Driver Framwork presentation (colindixon, 18:06:35)
   
4. Device Driver Framwork (alagalah, 18:06:38)
   1. https://wiki.opendaylight.org/view/File:DeviceDriverProposal-v2.pptx slides for today on the wiki (colindixon, 18:06:52)
   2. the basic problem is that different devices have different capabilities even if they support the same standard, e.g., OpenFlow (colindixon, 18:09:37)
   3. the device driver framework (originally built in the HP controller) provides a uniform interface to devices despite that via drivers (colindixon, 18:10:05)
   4. an example is flowmod drivers which adjust the flowmod to be more appropriate for the given device (colindixon, 18:10:24)
   5. other examples include VLAN/VxLAN config (colindixon, 18:10:34)
   6. there are five major components: (1) device type registry, (2) device type identification, (3) device managment, (4) security repository, and (4) device drivers (colindixon, 18:11:13)
   7. slide 6 in the presentation shows a diagram of how the 5 components interact and a list of the events about how a device interacts with the controller (via the device drirver framework) (colindixon, 18:14:38)
   8. abhijitkumbhare asks how this interacts with TTPs (colindixon, 18:16:41)
   9. steve dean responds saying that right now, they use a combination of table properties messages during OF negotiation and proprietary knowledge of the hardware, but if there are better ways to do this in the future, e.g., TTPs, they’d love to use them (colindixon, 18:19:03)
   10. colindixon asks how this is going to fit in with ODL including OpenFlowPlugin, etc. (colindixon, 18:19:57)
   11. steve says he has some slides on that later (colindixon, 18:20:03)
   12. edwarnicke says “as far as I can tell this is basically a way to have a shim layer that validates and possibly adjusts application interactions with SB protocols and h/w to make things easier” (colindixon, 18:21:06)
   13. steve dean says, basically, yes (colindixon, 18:21:12)
   14. dbainbri says that the indentification part looks a lot like the discovery project, how would this interact? (colindixon, 18:23:49)
   15. steve dean says, yeah, that’s a really good point and we need to talk about it (colindixon, 18:24:08)
   16. colindixon and edwarnicke try to tease out what they key new funcationality from the parts that look like it’s own SAL (colindixon, 18:28:19)
   17. the answer seems to be (inserting my interpretation) that the goal is to provide a way to adapt common interfaces to specific southbound devices (colindixon, 18:30:19)
   18. the rest is basically a way to provide the critical information to do that (colindixon, 18:30:56)
   19. edwarnicke asks what functionality changes would be needed to MD-SAL to facilitiate the project (alagalah, 18:38:12)
   20. uchau says ability to store encrypted keys, but steve skipped to slide13 that highlights Concerns (alagalah, 18:38:39)
   21. https://wiki.opendaylight.org/view/Project_Proposals:DeviceDriverFramework (alagalah, 18:47:50)
   22. https://wiki.opendaylight.org/view/Project_Proposals:DeviceDriverFramework (alagalah, 18:50:07)
   23. Discussion about the "finer" points of Creation Review etc (alagalah, 18:54:51)

Action items

1. (none)

People present (lines said)

1. colindixon (30)
2. alagalah (12)
3. odl_meetbot (6)
4. alagalah_ (0)