Let me put it in this way-- this was the real intent, but the implementation was openflow influenced ​:) ​...and this is one of many reason we realize lets move it to openflowplugin project :)​

Thanks for the pointer, I missed both that TWS and the thread. I will follow up on it. I do not believe OFP should be the place -- it is technology specific, after all. NETCONF provides this

Inline. Abhijit>> If I remember right the key idea then was a model for "Flow Capable Devices" - via any protocol capable of providing flow like semantics to the flow capable devices. Of course - it

Right, but that was not really how it got marketed :) In fact it was recognized that they are OpenFlow specific when we were deciding whether to move them. So was the idea to essentially define an

In-line. That's my recollection as well - both the points (if it was only 1.0 & 1.3 the models would have been in the OpenFlow plugin right from the beginning, not in the controller first and then

​I think this is one of the reason as well, but the higher level goal was to use them as a controller wide ​model and that was the reason we added all these models in the controller projects.

I would like to clarify slide 5. The original intent between the two models worlds was *not* support for multiple SB protocols, but rather multiple versions of OpenFlow itself (1.0 and 1.3). Therefore

I added a slide for the impact to the OpenFlow consumers (downstream projects) as well as some clarifications in the reorganization slide that we should keep the backward compatibility. Also added

Hi Abhijit, It's would be helpful to add the impact on downstream project because of individual work items. Some of these work items are going to significantly impact the downstream project and this

Hi folks, I put up a strawman proposal with the help of Anil, Muthu and Shuva. This can serve as a starting point of discussion - here it is attached. I also took the liberty of briefly mentioning

Monday can work for me if it is early Pacific time… But I also trust you (Colin) to represent TTP if the meeting ends up later. Curt

Hi all, The NetIDE project informs you that it is dependent on the following projects: - YANG Tools - OpenflowPlugin - OpenflowJava - MDSAL Please

Monday works for me Colin. Thanks, Aneesha

During recent TSC meetings, we noticed that we have at least 6 OpenFlow-related projects: * openflowplugin * openflowjava * of-config * ofextensions/circuitsw * ofextensions/epc * ttp It might make

Thanks for the notes. I’ll drop another line when I get it all figured out :)

See this - https://wiki.opendaylight.org/images/2/2d/MD-SAL_Clustering_Internals.pptx and https://www.youtube.com/watch?v=A9wAAbvliR0 If there were more operations done on that read write transaction

I know where the TransactionProxy “is” from a file location perspective. It is in the controller repo, under md-sal. I don’t understand from a processing perspective you get from

TransactionProxy is in the Distributed data store (aka Clustered data store). The code for that is in the controller project. Look for module sal-distritributed-datastore. -Moiz From:

Hi, I am just starting out with OpenDaylight and I feel like this: https://img.buzzfeed.com/buzzfeed-static/static/2014-10/26/6/enhanced/webdr08/enhanced-14836-1414320930-8.jpg I have a firm grip on

​Thank you for your votes. Michal