3 ms·
+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, see
by 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 agoThe 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/