18:00:35 #startmeeting tws 18:00:36 Meeting started Mon Nov 3 18:00:35 2014 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:36 The meeting name has been set to 'tws' 18:00:43 #topic agenda bashing 18:01:16 #chair alagalah_ 18:01:16 Current chairs: alagalah_ colindixon 18:01:31 #chair alagalah 18:01:31 Current chairs: alagalah alagalah_ colindixon 18:01:39 #topic Agenda Bashing 18:01:41 #link https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas 18:02:30 #info today, Steve Dean is going to cover the device driver framework project proposal 18:06:35 #topic Device Driver Framwork presentation 18:06:38 #topic Device Driver Framwork 18:06:40 #link #link https://wiki.opendaylight.org/view/File:DeviceDriverProposal-v2.pptx slides for today on the wiki 18:06:42 lol beat me to it mate 18:06:45 it all works 18:06:46 Thanks colindixon 18:06:48 #undo 18:06:48 Removing item from minutes: 18:06:52 #link https://wiki.opendaylight.org/view/File:DeviceDriverProposal-v2.pptx slides for today on the wiki 18:08:18 those slides are now put on the wiki from the agenda for today as well 18:09:37 #info the basic problem is that different devices have different capabilities even if they support the same standard, e.g., OpenFlow 18:10:05 #info the device driver framework (originally built in the HP controller) provides a uniform interface to devices despite that via drivers 18:10:24 #info an example is flowmod drivers which adjust the flowmod to be more appropriate for the given device 18:10:34 #info other examples include VLAN/VxLAN config 18:11:13 #info there are five major components: (1) device type registry, (2) device type identification, (3) device managment, (4) security repository, and (4) device drivers 18:14:38 #info 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) 18:16:41 #info abhijitkumbhare asks how this interacts with TTPs 18:19:03 #info 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 18:19:57 #info colindixon asks how this is going to fit in with ODL including OpenFlowPlugin, etc. 18:20:03 #info steve says he has some slides on that later 18:21:06 #info 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” 18:21:12 #info steve dean says, basically, yes 18:23:49 #info dbainbri says that the indentification part looks a lot like the discovery project, how would this interact? 18:24:08 #info steve dean says, yeah, that’s a really good point and we need to talk about it 18:28:19 #info colindixon and edwarnicke try to tease out what they key new funcationality from the parts that look like it’s own SAL 18:30:19 #info the answer seems to be (inserting my interpretation) that the goal is to provide a way to adapt common interfaces to specific southbound devices 18:30:56 #info the rest is basically a way to provide the critical information to do that 18:36:38 alagalah: I need to jump off 18:36:47 if anyone else wants to scribe feel free 18:36:48 colindixon: later 18:38:12 #info edwarnicke asks what functionality changes would be needed to MD-SAL to facilitiate the project 18:38:39 #info uchau says ability to store encrypted keys, but steve skipped to slide13 that highlights Concerns 18:47:50 https://wiki.opendaylight.org/view/Project_Proposals:DeviceDriverFramework 18:50:07 #link https://wiki.opendaylight.org/view/Project_Proposals:DeviceDriverFramework 18:54:51 #info Discussion about the "finer" points of Creation Review etc 19:01:08 #endmeeting