Hello HP. I’m RFC 1925 Compliant.

RFC 1925 – The Twelve Networking Truths is one of the less technical RFCs that are cited by the networking community. It is perhaps best known for the pigs statement, Truth #3:

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

My favorite, however, is the one that follows it, Truth #4:

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

I interpret that as what makes for a successful product manager. Within networking I’ve been a Developer, a Support Engineer, a Consultant, a Network Engineer, a Technical Marketing Manager, and, most recently, a Product Manager for a startup. And now I’m very proud to share the news of my appointment as a Product Manager at Hewlett Packard. I’ll be owning the lifecycle of HP’s Campus products portfolio. HP Networking sponsored a recent Packet Pushers show and is one of the pioneers of commercial SDN solutions. In my new role I’ll be focusing on tackling the challenge of BYOD and VDI in the ever-changing Campus networking environment. Exciting times ahead!

Collaborating with the Networking Community in the Age of Information Overload

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.

image

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.

OpenStack Cloud Adoption Picking Up

I was listening to the recent Packet Pushers podcast Show 138. HP, who sponsored the show, spoke about HP Cloud, a public cloud that is built on OpenStack. It was launched in May 2012 and made generally available in December. HP is taking Amazon head on in the cloud provider space (at least when it comes to SLAs) as the GM of HP Cloud Services puts it. HP Cloud comprises multiple availability zones, identity management, account management, block storage (ala AWS S2). Compare that with the Cisco Edition of OpenStack, which is just a validated deployment, tested on Cisco’s UCS servers and Nexus switches only. In other words, Cisco does not offer an Enterprise-grade cloud like HP or Amazon do.

And now you can throw IBM’s name into that hat. This week IBM unveiled a new cloud offering based on open cloud standards, including OpenStack, that significantly speeds and simplifies managing an enterprise-grade cloud. IBM, like HP, is one of the founding members of OpenStack and is launching this OpenStack-based public cloud offering in beta mode about one year after HP did with general availability expected later this year. Amazon is famous for it’s low price structure and it will be a challenge for HP and IBM to compete.

Mirantis, a 13-year old company with a history of strong professional services has immersed itself into OpenStack consulting and training in the last couple of years. They help service providers and enterprises build and deploy OpenStack cloud infrastructure. Some of their customers include NASA, Dell, AT&T, and Cisco. Another customer, Internap, launched its OpenStack-based public cloud service back in October 2011 and was assisted by Mirantis. I installed OpenStack in a personal lab at home and encountered several obstacles along the way. It is not easy to set up. For simple lab installations, DevStack is a good option. However, for production deployments, there is a lot of complexity that needs to be understood and overcome for enterprises to deploy clouds. Companies like Mirantis help bridge that gap.

OpenStack Lab Installation with DevStack

I have been experimenting with OpenStack in a personal lab at home. My motivation has been to get some hands on exposure with Quantum. OpenStack is definitely not a trivial task to set up. I have built it with DevStack, a script that builds complete OpenStack development environments, and have encountered a few bumps along the road. The first one was of package dependencies. I have learned that unlike on our personal laptops running MacOS or Windows, when running a Linux server, such as Ubuntu, patching the kernel to the latest release is not always a good idea. In the case of DevStack, I ran into package dependency errors, which are a nightmare to resolve. There is no general consensus on forums for how to mitigate them.

The only way I was able to get around this was to run the DevStack script with an unaltered kernel from Ubuntu 12.04 LTS. That means no running of ‘apt-get update’ followed by ‘apt-get upgrade’. I was able to get OpenStack successfully running with Kernel 3.2.0-29, which is what Ubuntu 12.04 LTS comes with natively. I’ve attended a few OpenStack meetups and my experience is consistent with those of other attendees who I have interacted with. In hindsight, it is not surprising that DevStack broke because OpenStack has so many constant code changes and moving parts. DevStack, which pulls the latest release from Git Hub, is likely to break if a major variable change, such as kernel upgrade, is introduced.

I got some help from the inimitable Brent Salisbury, whose blog posts have come in handy on several occasions. Next I plan to add customizations to my OpenStack installation, such as adding Quantum plug-ins rather than using nova-network.

Cisco ONE Controller – SDN Startup Killer?

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

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

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!

What is PLUMgrid up to?

PLUMgrid is a Silicon Valley based SDN startup that raised $10.7 million in Series A funding in August 2012. They are still in stealth mode and even SDNCentral hasn’t covered much on them yet. However, things are brewing at this startup, which was mentioned last year in the The Economist and featured in Network World. Details are still thin, but when a company publishes five teaser blog posts in the past two weeks (they started their blog in August 2012), signs point to a larger announcement around the corner.

Their blog posts are unlikely to win a Pulitzer prize. If anything, they have enhanced their mystique by keeping things vague. PLUMgrid shuns the term Network Virtualization as it encompasses legacy technologies, such as VLANs, VRFs, and VPNs. Instead, they like to refer to Virtual Networking Infrastructure (VNI) as the means (i.e. abstraction) to provide a Virtual Network Domain, which they define as an administrative boundary established by the Data Center Operator where the VND operator can: Define, instantiate, and manage its own network needs. PLUMgrid defines SDN as networking technologies that create value in the VNI. Moreover, they wrote of consumption models in a manner that would make unicorns cry. A more concrete set of definitions would have helped.

PLUMgrid wrote of Distributed Virtual Switches:

Datacenter admins are quickly realizing that as appealing as DVS may be, Virtual Broadcast Domains (aka Distributed VLANs) are restrictive when designing proper networking solutions. To overcome the limited capabilities of DVS, multiple vendors are providing solutions pointing towards two different vectors.

I would have liked them to elaborate further on this point. How exactly do data center admins find DVS’ restrictive? Is it the lack of control plane? Is it the presence of Multicast state in the core of the network. I want to know what PLUMgrid’s solution offers that, say, Nicira’s STT doesn’t. They have refrained from describing the problems in their posts.

On point that PLUMgrid made in their blog series that caught my attention was when they wrote this of VNI:

VNI platforms should be open to a rich ecosystems of 3rd party network functions: Prevent vendor lock-in.

To me that sounds like a plug-in to OpenStack. In fact, I wouldn’t be surprised to see PLUMgrid’s name listed as a member the new open source SDN Consortium called Daylight, which will be announced at the ONS summit in April 2013.

Are they the Secret Company that will come out of stealth mode and present at Networking Field Day 5 March 6-8? Only time will tell.

Edit: I listened to the Open Networking User Group (ONUG) Lippis Report Podcast this morning and PLUMgrid’s CEO, Awais Nemat, reiterated the need to define new vocabulary for SDN ecosystem, such as VNI. He said that the concept of Cloud only started making sense to people once SAAS, IAAS, and PAAS were clearly defined. Based on conversations it has held with customers, PLUMgrid has its eyes set on Consumption Models as compared to Build Models, which the rest of the industry has been focusing on (Northbound/Southbound APIs, CP/DP separation, etc).

South Bay OpenStack Meetup – Where are the Networkers?

Just a quick note before the weekend. Yesterday I attended a South Bay OpenStack Meetup organized by Mirantis, a provider of OpenStack services. Over 100 people had RSVP’d for the event, which was held on Yahoo!’s campus. About 50 attended.

The event featured an introductory presentation by Mirantis on the OpenStack architecture and featured excellent coverage on the messaging between the various components and APIs. Co-resenting was Lee Xie, Senior Technical Engagement Manager from Mirantis, who had earlier in the day published a detailed, albeit subjective comparison of OpenStack versus VMware.

What struck me as amazing was the lack of questions and familiarity with Quantum, the networking component of OpenStack that has been out since Folsom was released in September 2012. I had never expected myself to be the only person asking questions about Quantum at an OpenStack event! OpenStack itself has been around since 2010 or so, and it is possible that most of the attendees had server and storage background. JSON, REST, Puppet, and Rabbit were the more fluid topics of discussion. I drew puzzled looks when I broached the subject of Floodlight and OpenFlow.

The meetups are scheduled for every other week with Beginners and Intermediate tracks held at the same time in different rooms. Maybe I’ll attend the Intermediate track next time.