This photo of me outside the Interop conference at the Mandalay Bay hotel in Las Vegas in front of a large screen display of my product , the HP 3800 Series switches, was taken by one of my customers.
I was at Interop at the Mandalay Bay hotel in Las Vegas last month to meet some customers when, to my pleasant surprise, I had noticed a large screen display on a wall outside the conference in the hotel dedicated to my product, the HP 3800 Series switches. This was outside the entrance to the conference, so anyone in the hotel could see it. I am very proud to say that I am the Global Product Manager for this product at HP. We recently introduced support on this product for two SDN applications – Network Protector and Network Optimizer for Microsoft Lync. You can find out more about the HP 3800 Series switches here.
It has been a long time since I’ve posted a blog entry. In the meantime I have helped put together a SDN panel discussion for OPEN SV this Saturday, June 8th, 2013 at the Santa Clara Convention Center. I wrote a guest blog piece for OPEN SV here with a perspective on SDN and on the speakers.
It promises to be an exciting discussion. Just today, the moderator of the panel, Craig Matsumoto, who is the Editor of Light Reading covered Big Switch’s decision to pull back from its role in OpenDaylight. The panel discussion will also feature the VP of Engineering at Big Switch, Howie Xu. Rounding up the panel are Luis Robles, (VC at Sequoia), Awais Nemat (CEO of PLUMgrid), and Dominic Wilde (VP of Product Management at HP Networking).
If you’re in the San Francisco Bay Area, I highly recommend attending this panel. It is part of OPEN SV’s 10th annual OPEN Forum. More information on the panel itself is available here.
Literally speaking, 2012 was the hottest year in recorded history, though there will always be climate change deniers. From the perspective of networking as well, it was a very hot year. Dozens of vendors are battling it out to claim their share of the SDN pie, a market, which IDC expects to grow to $3 billion by 2016. With IAAS/Cloud finally living up to the hype it generated five years ago or so, we are truly in a golden age of innovation in networking. Greg Ferro often says that the last time networking saw such excitement was when MPLS was introduced. However, MPLS was always a Service Provider solution and just a direct replacement for Frame Relay and ATM. If you ran a mid-size Enterprise network or an SMB, the chances are that you wouldn’t need to worry about MPLS. Some have argued that MPLS can be run in the Data Center, but the number of implementations is quite few. More importantly, MPLS had no consideration about the type of applications that it was transporting. SDN, on the other hand, with its Northbound API, is completely application-aware. With all the monumental changes happening in networking nowadays, it can be rather overwhelming trying to keep up just by reading blogs and newsletters. In this post I’ll outline three ways of collaborating with the networking community.
Packet Pushers, which the aforementioned Greg Ferro co-hosts along with Ethan Banks, is the premier podcast show for getting the scoop on trends in the networking industry. It features quality professionals, many of whom maintain their own blogs or are active on Twitter. Packet Pushers has a handy forum where you can ask questions on just about anything and can interact with like-minded networking professionals in the virtual meeting room. Greg and Ethan complement each other very well. While Ethan is more in tune with the more day-to-day activities of a network engineer, Greg is generally more active in promoting the discourse for newer technologies, such as the OpenStack Quantum project. The shows generally tend to be more in favor on Data Centers and SDN than, say, VoIP or Wireless, but thanks to the forum, listeners can chime in with their preferences for upcoming shows.
SDNCentral was launched in January 2012 as means for people to educate themselves on the SDN market and it does a wonderful job at that. One of the website’s features is the SDN Trending Index, which measures the most popular SDN companies, based on SDNCentral community activity. This is a clever way to gauge how hot a new SDN vendor is. A more recent feature of SDNCentral is the Demo Friday series in which an SDN vendor demonstrates their product. At the time this post is published was the second in this series – Cloud-enabled Networking–NEC ProgrammableFlow SDN in Action. The first in the series was Plexxi and Boundary. I had written about Plexxi after listening to them in a sponsored Packet Pushers show. I have since softened my stance on them thanks to the demo, which showcased Plexxi’s optically-connected switches built around a closed, controller-based architecture. I was impressed with how it flattens the network and how it can co-exist with legacy network designs. Indeed, it would be difficult to survive nowadays with a rip-and-replace strategy. From SDNCentral: Boundary applies analytics against real-time network flow data to enable Application Performance Management without the need for appliances or tap/span ports. The demo showed how Boundary discovers real-time application topology and monitors application throughput, latency, packet retransmits and other metrics on a per second basis. In other words, it is Software Defined Monitoring. Without SDNCentral, I probably would not have learned about Boundary or appreciate the value Plexxi can offer.
Ben Pfaff speaking at the Bay Area Network Virtualization Meetup at Hacker Dojo on March 20, 2013
Meetups provide an excellent opportunity to learn by interacting with real people in a face-to-face environment. In the San Francisco Bay Area, there are a few meetups that are bringing a sense of community to the networking industry, fueled by the Open Source movement. It wasn’t like this between 2000 and 2010. Hackathons were traditionally associated with only developers, not networking folks. This week, Nicira’s Ben Pfaff spoke at Hacker Dojo of the past, present, and future of Open vSwitch, which he helped create. He showed a live demonstration of how OVSDB, the configuration tool of OVS, works. I met some of my former colleagues and other peers who I normally interact with online. Nowadays, in the SF Bay OpenStack meetups led by Mirantis and Sean Roberts from Yahoo!, attendees bring their laptops and help each other through the OpenStack installation and configuration process with DevStack. Similarly, the Bay Area Network Virtualization meetup offers a fantastic opportunity not only to learn about OpenFlow and Open vSwitch, but also to mingle with fellow practitioners. However, meetups are not limited to the San Francisco Bay Area. In a recent Packet Pushers show, Kyle Mestery, one of the original team members of the Nexus 1000V, mentioned that an OpenStack meetup has also started in Minnesota. Meetups tend to catch on like wild fire. Hopefully we’ll see many more that cater to open networking.
These are healthy signs of a growing industry with plenty of people willing to help out and give back to the community.
Military nations demonstrate their power by testing nuclear weapons. Pure play networking vendors display their power in the SDN ecoystem by releasing Controllers. ~Anonymous
I sat in today on Cisco’s Webcast on OpenFlow and the ONE Controller. Cisco CTO, and Engineering and Chief Architect, David Ward spoke at length of this announcement. Ward is also the Chair of the Technical Advisory Group of the Open Network Foundation (ONF). The webcast featured two use cases – in the Enterprise (Indiana University) and in the Service Provider (NTT Communications) arenas.
OpenFlow Model
A typical OpenFlow Controller, or Switch as defined by the standards, would interface to the Data Plane via OpenFlow Configuration Protocol, OF-Config, (persistent across reboots) and OpenFlow Protocol (mechanism for adding and deleting flows). But OpenFlow is just a part of SDN.
In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats. – ONF Website
Cisco ONE Controller Model
The goal of Cisco’s ONE Software Controller is to enable flexible, application-driven customization of network infrastructure. It includes the onePK toolkit – an SDK for developers to write custom applications to solve their business needs. So, a ONE Controller could speak to other vendor devices via the OpenFlow standard or it could speak to Cisco devices via the onePK southbound API. At least that is what the diagram shows – onePK and OpenFlow are side-by-side. However, during the webcast Q&A, it was stated that onePK is an infrastructure that includes support for multiple abstraction protocol; onePK includes Openflow. This is probably semantic.
One of the features described is network slicing. It is intended to provide more than just L2 or L3 segmentation. It is more like a form of multi-tenancy. The way it was described on the call, instead of making decision based on just ‘shortest path’, network slicing can enable the controller to differentiate based on lowest cost path, highest bandwidth path, and latency. At a demo at Cisco Live in London, latency was tweaked and the Controller was able to compute a different path accordingly.
Another feature presented by Cisco in ONE Controller is of hybrid mode SDN, in which network operators can use SDN for specific flows and traditional integrated CP/DP (i.e. classical routers or switches) for the remaining traffic
What are the ramifications of this release on the SDN ecosystem? Well, although the new open source consortium Daylight supposedly does not include Cisco onePK on Day 1, it is very likely it will be included in about six months. Cisco has announced platform support roadmaps for the Platform APIs (onePK platforms), Controller Agents, and Overlay Networks such as VXLAN Gateway. Some of these won’t be available until Q3 of this year. That sounds just about the right time for a vendor to provide an end-to-end solution for Daylight. If a pure play hardware networking vendor, such as Cisco, can provide a free open source controller, it will be able to kill the competition from many SDN startups. For example, take Floodlight, the open source OpenFlow controller that was developed by Big Switch and is sold on a freemium licensing model. If ONE Controller is given away for free, why would a customer use Floodlight?
In other words, in Daylight there is no need for Floodlights!
I’m writing this post the week after Cisco Live was held in London. I did not attend Cisco Live, but this morning I attended a Cisco event today titled entitled Fabric Innovations for the World of Many Clouds. It was kicked off by Cisco’s Chief Strategy Officer Padmasree Warrior who outlined the Fabric vision of the company at this time, which is summarized in the figure below.
February 4, 2013 Cisco Announcement
The Nexus 6000 is a new product line with a super high 10/40 Gbps port density and hovering at 1.2 microsecond port-to-port latency. Available today, the 4RU Nexus 6004 has 48x40Gbps ports along with 4 expansion modules allowing for a total of up to 96x40Gbps ports. Also announced, but available in Q2, is the Nexus 6001 – a 1RU switch with 48x1Gx10G with 4x10G/40G uplinks. Senior VP of Cisco’s Data Center Business Unit, David Yen, said that even Cisco could avail of merchant silicon, but that they still backed their own custom silicon to deliver lower port-to-port latencies, as seen in their Algo Boost technology. To give you an idea on how low 1.2 microseconds is in the industry, Arista has been boasting low-latency switches as low as 350 nanoseconds port-to-port for several years. But Cisco already has an answer for Arista’s ultra-low latency switches – the Nexus 3548 which boast port-to-port latencies as low as 190 nanoseconds. These are better suited for financial exchanges where low switching latencies are critical for conducting electronic trades.
Cisco claims it can scale the Nexus 6004’s 1.2 microsecond latency for as many as 1,500 10G ports. The number 1500 is attained when the Nexus 6004 is combined with another new product – the Nexus 2248PQ Fabric Extender. The last-named product can support 1500 GE or 10GE server ports through Cisco’s FEX technology. Assuming 50 VMs per server, this means that the 1500 FEX ports can support up to 75,000 VMs. This is an impressive number and shows the scalability of the Nexus 6000 platform.
The Network Analysis Module (NAM) has also now formally made its foray into the Nexus offering. I worked a lot with the first two generations of the NAM in 2004 and was impressed by its robustness (one of the few products at the time to be built on Linux) and ease of use. Of course, that was with the Catalyst 6500 platform, which was defribilliated a couple of years ago with the Supervisor 2T. It seems that Cisco is now finally bringing service modules onto the Nexus platform.
The second major announcement was the Nexus 1000V InterCloud for connecting enterprise clouds to provider clouds in a secure manner. The highlights are making application migrations incredibly simple without having to convert VM formats, create templates, deploy site-to-site tunnels between clouds, or re-configure network policies. The Nexus 1000V IC is intended to automate all these steps and support all hypervisors. It is managed by Virtual Network Management Center (VNMC) InterCloud. The highlight of that (to me) was that it hooks into cloud orchestration systems like Cloupia (Cisco’s recent acquisition) and Cisco’s own Intelligent Automation for Cloud (IAC) via a northbound API. Hybrid cloud deployment solutions are a relatively new area and I will be following how this pans out with great interest.
I was most keen about the third announcement, which was of Cisco’s ONE Controller. Last year Cisco announced onePK, but there was no product. Now finally, there is the Controller. It features northbound APIs, such as REST and OSGI and southbound APIs, such as OpenFlow and Cisco’s own onePK. Cisco also announced a roadmap for the ONE Controller’s compatibility with Cisco’s existing Nexus and Catalyst product line.
More information is available from the following links:
What are the ramifications of this release on the SDN ecosystem? Well, although the 
Umair Hoodbhoy - Multi-Cloud, Networking, and Kubernetes 