We would like to understand if the OpenFlow protocol is still in the use for the network operators and if there are lot of use-cases where is it widely used and if there would be benefits that we could upgrade the OpenFlow implementation in RouterOS from v1.0 to v1.3?
Or we need to look for newer version implementation?

OpenFlow is still very much in use! ISPs, Internet Exchanges and Data Centers all have use cases for OpenFlow. There is a fantastic open source controller called Faucet that is easy to get up and running.

https://faucet.nz/

We have been working on a project to use OpenFlow to manage traffic engineering in Wireless ISPs and went to Google's HQ last fall for FaucetCon to present that work. Video is here:

https://www.youtube.com/watch?v=HyFXpEJ ... 1z&index=4

Unfortunately we couldn't use MIkroTik equipment because it wasn't at least ver 1.3

Please implement this!!

Seconded. Faucet is unquestionably the de facto standard for doing openflow correctly in a production-ready and scalable way. They have a test suite that validates the vendor implementation making sure it's successful and supports all of the right components - the keys being multi-table and next-table. Please implement this, I'm willing to help test, and I will all but guarantee that the Faucet developers will aid as they have done with many other vendors (HPe, Arista, Cisco, ATI, NoviFlow, etc..)

An example of a very successful deployment at massive scale can be heard about here:
https://blog.ipspace.net/2019/04/using- ... -with.html

It would be boon to many to have a Faucet compliant OpenFlow implementation within RouterOS. It would bring reasonably priced gear within reach of many that are interested in OpenFlow.

Including such a feature will surely increase the demand for RouterOS products.

I look forward to implementing a Faucet-controlled OpenFlow network, per the work Sajan, Kevin, Nick, and Adair have been doing.

When I was building a Brocade/Cisco SDN in 2015 for an ILEC telco using opendaylight, I wanted to incorporate Mikrotik to the SDN at the access and customer edge portions of the network - however due to lack of support for current openflow standards to match frames/packets for my flows and direct/rewrite across a service provider network, I abandoned Mikrotik as a contender on this platform.

We built a programmable network where customers could self service and adjust the particulars of their broadband, VPN, VOIP and IPTV service delivery from a portal that auto-provisions these changes without need for waiting on human service order fulfillment, so long as facilities were already available, taking order delivery from days (or weeks, sometimes) down to near instantly applied.

1.3 would've been sufficient for this use case (and stuff I've been working on since then).

It would be fantastic if Mikrotik gave OpenFlow some focus and updated it to OpenFlow 1.3

Yes ! would love an upgrade to v1.3 ^_^

Agree : +1

Hello MikroTik folks, thank you for asking. Let me try to answer your question.

I have been working with network protocols for many years. When OpenFlow switches started to become generally available about 2012-2013, I took an OF 1.0 controller and tried to make assorted OF switches work with it to implement a few applications, with varying success. Also I tried to test stability, capacity, performance, spec conformance and feature set of each OF switch.

When the applications, the controller or the switches crashed for no apparent reason, it was important to understand what is going on on the wire. At that time packet analysers had no support for OF out of the box so I had implemented OF 1.0 decoding in tcpdump. With the decoded protocol exchange I typically either fixed a bug in the controller, or filed a bug report with the switch vendor.

In total I had closely studied hardware OF switches of 7 vendors (mostly brand name) in a lab with actual cables and servers, with 2 more vendors I had only a brief brush. The MikroTik implementation had the most faults and yielded the most bug reports. AFAIR, at least half of these bug reports quietly died somewhere on the MikroTik tech support side of the fence. This is not to offend anyone, but to convey essential facts in support of my point below.

On the upside, RouterBoard was undoubdetly the cheapest, also I found ways to work around the implementation faults in one specific application that required only 4 dataplane ports per OF switch and tolerated low bandwidth (MikroTik OF 1.0 was software-only at the time). So I bought a bag of RouterBoards and worked on that application for a while until much more important things kicked in.

Fast-forward to 2020, if MikroTik adds support for OF 1.3 anytime soon, I still have that bag of RouterBoards and it could be fun to rig something up using the aforementioned Faucet, as a possible example. But please mind that it would likely result in new faults and new bug reports, and if MikroTik just disregards these as before, it will work against the success of the product.

We would like to understand if the OpenFlow protocol is still in the use for the network operators and if there are lot of use-cases where is it widely used and if there would be benefits that we could upgrade the OpenFlow implementation in RouterOS from v1.0 to v1.3?
Or we need to look for newer version implementation?

Uldis,
I think it's obvious from this thread that there's still an interest in OpenFlow. One of the things, I think, that is holding back some adoption is that Mikrotik's implementation doesn't support OpenFlow 1.3 with multiple tables. In the time since Mikrotik released an OpenFlow package for RouterOS, controller software has continued to mature and, I think, Faucet is a good candidate for being the de-facto standard here. I would very much LOVE to see this happen. Even if it's just on the CRS-3xx series, that would be fine. IIRC, the chipset for the CRS-3xx series has OpenFlow support, so it doesn't seem to be a HUGE investment to make that happen.

What's your thoughts on this, Uldis? Should we have hope Mikrotik will do this?

Seconded!!! I would love to see Mikrotik support openflow 1.3 and Faucet!!

+1 I interested too

+1! Please add this to RouterOS

From MikroTiks Openflow manual:
https://wiki.mikrotik.com/wiki/Manual:OpenFlow

Currently RouterOS implements OpenFlow version 1.0.0 required features. Support for newer versions, optional features and switching hardware acceleration are to be added. Current implementation should be considered experimental - NOT production ready and is available for evaluation purposes.

So maybe there will be an upgrade in the future. Accounting that I do use in Splunk for Mikrotik are removed from v7.x, so they need to get Openflow out of beta state.

But I do not have high hope, since this was written for more than 5 years ago and page last updated in 2018

Other as written this:

Well, anything that doesn't touch the CPU can't be collected, so anything where you leverage switch chips will have definite limitations; there's only so much bandwidth between a given switch chip and the host CPU

Nothing much has changed since this video in 2014.....
https://www.youtube.com/watch?v=qGGV-MDZ3UE

maybe someone knows how is it with openflow upgrade in routeros?
it is very demanded functionality

We would like to understand if the OpenFlow protocol is still in the use for the network operators and if there are lot of use-cases where is it widely used and if there would be benefits that we could upgrade the OpenFlow implementation in RouterOS from v1.0 to v1.3?
Or we need to look for newer version implementation?

Would like to see OpenFlow v1.3 support at minumum; but if you're going to be putting in the time to upgrade it, why not v1.5?

I think it was generous of Mikrotik to make an OpenFlow 1.0 package for v6.x, however, its usefulness was very limited because it only supported v1.0. v1.3 is where all the fun stuff starts.

Is this still alive or in the pipeline?, please I hope someone from MT can confirm thanks

PERHAPS P4 INSTEAD?

The OpenFlow protocol is a southbound API used for communication between the controller and the data plane devices. It defines a series of messages in which the controller can enforce a desired policy to the network. The main limitation of OpenFlow is the fixed set of header fields supported. Each new version of the protocol should first be approved by the Open Networking Foundation (ONF) and then be implemented by hardware manufactures. Although more flexibility is available to the network operator in contrast to traditional networking, it is still limited by a fixed set of features of the OpenFlow protocol. Lately progress regarding OpenFlow has stopped in favor of the P4 project.

I personally want this in but I already loose hope if simple DAI "Dynamic Arp Inspection" L2 feature is not in the roadmap how much more on this, We don't really know what market segment they want to position themselves if they want to route/switch/IoT/NAS/storge the world who knows?