How Cisco Nexus 3000 and Python could change the community
Jason Edelman explores the work he's done with Cisco Nexus 3000 and its built-in Python interpreter on his blog. Edelman limited his testing to two components: the Cisco Nexus 3000 switch and the Ubuntu server. Edelman said his main goal was to allow for more programmability when managing network devices.
In a series of steps, Edelman outlines how he programmed the Nexus 3000 switch, while explaining his reasoning and offering other scenarios he could have used. He talks about the challenges of using Python and issues when working with the Nexus platform. He ends his post by explaining why a traditional network engineer may opt to work with Linux on an open platform by outlining three specific benefits that allow for more openness and programmability.
Check out Edelman's full post, and read about his experience with the Cisco Nexus 3000 switch and Python and how both could offer the community more programmability.
Did AT&T decide on VMware SDN?
Service provider AT&T recently sent SDN vendors a request for information in hopes of finding a vendor to work with their SDN platform, and according to research firm MKM Partners, the winner could be VMware. According to The VAR Guy site, VMware's network functionality aligned well with AT&T's long-term SDN plan, called Domain 2.0, which allows the network to take on a more flexible and open "white box" model.
This white-box approach typically consists of x86 servers that are coupled with SDN controllers, allowing SDN to eliminate the need for high-end networking hardware. The post continues to explore other approaches to SDN and how this will affect the industry come 2015 -- although some companies are shifting away from rip-and-replace methods, the post questions if Cisco could profit from SDN in a number of ways. Only time will tell, however, if AT&T will opt for VMware's NSX platform.
Take a look at The VAR Guy's post detailing AT&T's RFI and why VMWare is looking like a winner.
Where did SDN really start?
Blogger Ivan Pepelnjak writes a short post on the actual origins of the term software defined networking. Although the Open Networking Foundation claims to own the definition of SDN, Pepelnjak says a paper published in the December 2013 issue of ACM Queue attributes the early use of the term to the work of Nick McKeown and his team at Stanford, which focused subtly on OpenFlow and the concept of SDN.
Read Pepelnjak's post on the beginnings of SDN.
The role of network virtualization in 2014
Bruce Davie, principal engineer at VMware, took to the company's Network Virtualization blog to make predictions about the technology in the year to come. Davie outlined a number of predictions, including an uptick in network virtualization adoption and the spread of the technology to other markets. Network functions virtualization is bound to grow, since the telcos have taken interest in it as well, Davie added.
New uses for network virtualization will also drive the increase in its adoption in the year ahead, Davie continued. Another trend that we'll most likely see is a focus on the higher layers of the protocol stack. Davie wrote that higher-layer services will be another area where the potential of network virtualization is discovered, since these higher-layer services leverage information that's available in the hypervisor. Finally, Davie ends with predicting that the network virtualization ecosystem will be solidified in 2014, while new uses for the technology that he hasn't predicted are bound to come to light.
Take a look at Davie's full post on the VMware network virtualization blog, which describes his network virtualization predictions in detail.
Principles, protocols and SDN
On the Plexxi company blog, Mike Bushong takes issue with the concept that SDN is categorized in two ways: an "open" technology that separates the data plane and the control plane; and or the protocols surrounding SDN. Bushong argues that neither standpoint fully encompasses what SDN really is.
Instead, Bushong poses a few questions for thought, including whether a network being open automatically makes it SDN. He also writes that the definition of SDN shouldn't come from the technology itself, but rather the context we find it in. For this to happen, the conversation needs to shift away from technology specifics and to other areas, such as delegation, abstraction and globality. In turn, this will start to frame the SDN discussion differently.
Take a look at Bushong's full post, which looks at the definition of SDN with regard to both capability and context.