Building OpenStack Icehouse and OpenDaylight
For those looking to build OpenStack Icehouse and OpenDaylight, Brent Salisbury featured an updated Fedora 20 image on his site, NetworkStatic. Salisbury wrote that OpenDaylight has merged into the upcoming OpenStack Icehouse, so you can now install OpenDaylight directly from the OpenStack trunk. Salisbury also touched on OpenDaylight's Helium release, which he said uses more work stemming from the Open vSwitch community that he and his team are integrating into the OpenDaylight OVSDB plug-in.
Check out Salisbury's full post, which links to an updated Fedora 20 image for OpenStack Icehouse and OpenDaylight.
Hardware VXLAN and VTEPs: Why you shouldn't virtualize only part of your network
On his IpSpace blog, network engineer Ivan Pepelnjak recalled a conversation he had with a colleague exploring Virtual Extensible LAN (VXLAN) and VXLAN Tunnel Endpoints (VTEPs). The most common use case for these are physical-to-virtual gateways, Pepelnjak wrote, but when his colleague suggested virtualizing just 80% of the servers in the center, and then wondered how to connect the other 20%, Pepelnjak explained why this is a bad idea.
Instead, Pepelnjak suggested starting with a data center network's "customers": the servers. He said to buy new high-end servers with plenty of RAM and CPU cores, and then, virtualize as much as you can without mixing old and new servers.
Take a look at Pepelnjak's argument explaining why it doesn't make sense to virtualize only part of your network.
Why have more than one SDN controller?
That's the question Francisco Ros, adjunct professor in the Department of Information and Communications Engineering at the University of Murcia, looked to answer on his personal blog site. Ros explained that a typical controller in charge of a network domain must be physically distributed to meet performance, scalability and tolerance constraints. Having one single controller causes scalability issues, as well as security concerns.
Most controller platforms, including Onix and OpenDaylight, take these issues into account. OpenDaylight includes clustering support as a key feature of the platform. However, Ros warned that simple deployment of multiple controllers isn't enough to obtain carrier or enterprise-grade networks -- instead, allocation of controllers and intelligent management of network state are required to get the most out of the SDN paradigm.
Read Ros' post on the need for multiple SDN controllers.
Software-defined networks: Are protocols needed?
On the No Jitter blog site, Terry Slattery, senior network engineer, explained how software-defined network domains must interact and share information with external parts of the legacy network, and must therefore take on some traditional routing/switching protocols. Specifically, he said that each SDN forwarding domain must run its own routing protocol to interface with the external network. This will even be the case if only small parts of the network are software-driven and programmable. These routing protocols can either be run on the controller or as external applications that talk to the controller -- as long as there is an interface.
The protocol could also be implemented in a hybrid SDN system, where each switch in the SDN can be controlled by either the SDN controller or by traditional distributed routing protocols.
Take a look at Slattery's reasoning behind implementing protocols in a software-defined network.