3 ms·

>> >> You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper’s forthcoming 1

>> >> You see, physical switch operating systems leave a lot to be desired in terms of supporting modern automation and API interaction (Juniper’s forthcoming 14.2 JUNOS updates offer some refreshing REST API’s!). >> This. Network hardware vendors have no incentive to make their devices more easily automated, and in fact face disincentive not to. There is actually a relatively established roadmap for the solution to this in "bare metal" / "white box" switches that essentially just talk OpenFlow to a controller. Google moved their entire international internal backbone (more traffic than public facing) to this model[1]. The issue at the moment is that there isn't lots of OS options and subsequently very little hardware support. Google developed their own hardware (despite preferring to have bought it[2]) and my understanding is they wrote their own software too. [1] http://www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf http://www.opennetsummit.org/archives/apr12/hoelzle-tue-open... [2] http://youtu.be/VLHJUfgxEO4?t=39m20s http://youtu.be/VLHJUfgxEO4?t=39m20s

donavanm 12y ago
+1, talking about rest endpoints hosted by junos is missing the forest for the trees. Protocols like Openflow, and whatever the contrail version was called, seems o be where network automation is headed. Centralized state & modelling and pushing specific paths/updates out to the edge. With regards to "bare metal" virtualization I'd expect to see a lot more in the next 12-18 months. On the network you need dynamic path configuration and traffic encapsulation/isolation. That should be "openflow" and vxlan/nvgre. On the host hardware youll want io virtualization (sr/mr iov) and possibly hardware encap as well. Substantial progress is being made on both fronts. Edit: although its great to have two encap options I think theyre incomplete at best. All of the hard work has been punted to the centralized controllers and the rfcs have nothing useful to contribute there. Some of the rfc behavior is also insane/laughable; multicast for broadcast and mac/tunnel endpoint discovery ORLY? Ill be very surprised if there are any large vxlan/nvgre deployments which arent bespoke.
- thomseddon 12y ago
  The opportunity extends beyond support for x86 devices in that more traditional hardware switches etc. should also work with openflow. I've found there's lots of OSS around the controller and virtual switches for testing/lab but the only serious openflow agent designed for hardware switches I've found is Big Switch's Indigo[1] it has very limited hardware support. I see experimental support in OpenWRT - this is very interesting as it opens up a shed load of hardware options. [1] http://www.projectfloodlight.org/indigo/ http://www.projectfloodlight.org/indigo/
superbaconman 12y ago
As someone who works with OpenFlow (a lot) I have my doubts if the tech will pan out. Look at what Facebook did to their network using traditional technologies. Look at Cisco's ACI, and Jupier's Contrail. About the only thing OpenFlow has going for it is that it runs on multiple vendor platforms (assuming you ignore all the switch-to-controller interop problems).

donavanm 12y ago

+1, talking about rest endpoints hosted by junos is missing the forest for the trees. Protocols like Openflow, and whatever the contrail version was called, seems o be where network automation is headed. Centralized state & modelling and pushing specific paths/updates out to the edge. With regards to "bare metal" virtualization I'd expect to see a lot more in the next 12-18 months. On the network you need dynamic path configuration and traffic encapsulation/isolation. That should be "openflow" and vxlan/nvgre. On the host hardware youll want io virtualization (sr/mr iov) and possibly hardware encap as well. Substantial progress is being made on both fronts. Edit: although its great to have two encap options I think theyre incomplete at best. All of the hard work has been punted to the centralized controllers and the rfcs have nothing useful to contribute there. Some of the rfc behavior is also insane/laughable; multicast for broadcast and mac/tunnel endpoint discovery ORLY? Ill be very surprised if there are any large vxlan/nvgre deployments which arent bespoke.

thomseddon 12y ago
The opportunity extends beyond support for x86 devices in that more traditional hardware switches etc. should also work with openflow. I've found there's lots of OSS around the controller and virtual switches for testing/lab but the only serious openflow agent designed for hardware switches I've found is Big Switch's Indigo[1] it has very limited hardware support. I see experimental support in OpenWRT - this is very interesting as it opens up a shed load of hardware options. [1] http://www.projectfloodlight.org/indigo/ http://www.projectfloodlight.org/indigo/

superbaconman 12y ago

As someone who works with OpenFlow (a lot) I have my doubts if the tech will pan out. Look at what Facebook did to their network using traditional technologies. Look at Cisco's ACI, and Jupier's Contrail. About the only thing OpenFlow has going for it is that it runs on multiple vendor platforms (assuming you ignore all the switch-to-controller interop problems).