I had every intention of producing several long posts about ONS 2013, but events in my hometown coupled with a busy meeting schedule at ONS resulted in not finding a lot of time to focus on writing. I think my colleague Mike Bushong summed up much of my thoughts here and I would like to add a few other thoughts I have about SDN after ONS 2013.
Continue reading
Category Archives: Start-Ups
Demonstrating AWESOME in the Pursuit of the Optical Data Center
This week at OFC, Plexxi and Calient are showing the power of SDN and optics. The idea to use some sort of optical or hybrid optical architecture for the data center has been pursued for years. Here is a link to a 2010 paper called, Helios: A Hybrid Electrical/Optical Switch Architecture for Modular Data Centers, written by a number of people, but the most notable author is Amin Vahdat.
Continue reading
How Does Change Occur?
I was having a DM conversation (140 characters at a time) the other day with network architect. We were discussing the reluctance of networking people, especially at the CxO or leadership level to do something different. Personally, I have heard from ~50 people at the leadership level over the past 18 months that state they want to do something different with their network infrastructure. The network has not changed in twenty years and now the time has come to change the network. What is the result of all the pent up desire to do something different? More network incrementalism; at least in the near term. The DM conversation I was having was around the subject of getting network people to do something different. Why do people say they want to make big changes and fail to seize the day? That is the subject of this post.
Continue reading
It is all about Doctrine (I am talking about Networking and that SDN thing)
Last year, I wrote a long post on doctrine. I was reminded of that post three times this week. The first was from a Plexxi sales team who was telling me about a potential customer who was going to build a traditional switched hieracrhical network as test bed for SDN. When I asked why they were going to do that, they said the customer stated because it was the only method (i.e. doctrine) his people had knowledge of and it was just easier to do what they have always done. The second occurrence was in a Twitter dialog with a group of industry colleagues across multiple companies (some competitors!) and one of the participants referenced doctrine as a means for incumbents to lock out competitors from markets. The third instance occurred at the at the Credit Suisse Next-Generation Datacenter Conference when I was asked what will cause people to build networks differently. Here are my thoughts on SDN, networking, doctrine, OPEX and building better networks.
Continue reading
On the Road the Next few Weeks…
I will be on the road a lot the next few weeks for Plexxi. Plexxi will also be engaging in a host of events as well. Here is a list of events:
- March 5: Credit Suisse Datacenter Conference in SF. I will be on an SDN panel with two friends from Big Switch.
- March 7: Plexxi presents at Network Field Day #5. I will be in NYC/NJ that day presenting to customers.
- March 13: I am on the Cloud & Software-Defined Panel at the Pacific Crest Technology Forum event in Boston.
- March 15: Plexxi and Boundary at SDN Central Demo Fridays.
Working Thoughts on SDN #3
Yesterday HP announced some SDN products to include a controller. If you had read my SDN Working Thoughts #3 post, then you already knew this data point. I have many questions about this announcement, starting with why would they announce an OpenFlow based controller when you can get one from Big Switch Networks (BSN)? I am sure there is a smart answer, but that is not my point. In addition to HPQ, IBM announced a controller using the NEC controller. My point is there is has been and continues to be a lot of development and design of controllers going on. My hypothesis is that the controller architecture will play a role as to where the battle of SDN market share will be won and lost in the coming years and simplification of the market into “separating the data plane from the control plane” is not specific enough and does not encompass a broad enough data set. I have written several times before SDN is more than APIs and reinventing the past thirty years of networking in OpenFlowease.
I think a person’s perspective of the controller is directly related to how you see the network evolving and how your company wants to run their business. There is no stand alone controller market. If I was to summarize the various views of the controller I would say that incumbent vendors view a third party controller as a threat and need to provide a controller as hedge in their portfolio in case it becomes a strategic point of emphasis. Incumbents really do not know what to do with a controller in terms of their legacy business, which is why they market a controller as some sort of auto-provisioning, stat collecting NMS on steroids. It will enable you to buy more of their legacy stuff, which for HPQ after today’s guidance cut may not be the case. The emerging SDN companies view the controller as point of contention for network control. All the companies in the market share labeled “other” or “non-Cisco” view the controller as a means to access the locked-in market share of Cisco. In the past, I would have told you that control planes have enormous monetary value if you can commercialize them inside customers. Cisco did this with IGRP, IOS, Cisco IOS and NX-OS. Ciena did this with the CoreDirector. Sonus failed to do this. Ipsilon failed to do this. Does anyone remember the 56k modem standard battle between US Robotics and the rest of the world who were working on the 56k standard and who won that market battle? The question becomes over the next year or two is how many controllers become commercialized in the market place and what are these controllers doing? I think there is a difference between controllers doing network services and controllers providing network orchestration based on application needs.
The following quote is from Jim Duffy’s article in Network World on HP’s controller announcement:
“HP’s Virtual Application Networks SDN Controller is an x86-based appliance or software that runs on an x86-based server. It supports OpenFlow, and is designed to create a centralized view of the network and automate network configuration of devices by eliminating thousands of manual CLI entries. It also provides APIs to third-party developers to integrate custom enterprise applications. The controller can govern OpenFlow-enabled switches like the nine 3800 series rolled out this week, and the 16 unveiled earlier this year. Its southbound interface relays configuration instructions to switches with OpenFlow agents, while it’s northbound representational state transfer interfaces — developed by HP as the industry mulls standardization of these interfaces — relays state information back to the controller and up to the SDN orchestration systems.”
Reading Duffy’s description I think the SDN orchestration system (is that application orchestration?) is more valuable than the controller he describes, but that is a side discussion. I also took the time to read this blog post from HP. Much of this controller architecture discussion has been on my mind for months as well as in my day to day work conversations for the past few months. It seems a day cannot go by without a conversation on this matter. I have no conclusions to offer in this post, so if you are looking for one please stop reading. The point of this post is that controller architecture, controller design and how SDN will evolve is in process and I think it is little early to be declaring the availability of solutions that offer marginal incremental value at best. The evolution of the controller thought process can be summarized at a high level by the following:
- Wired Article from Apr. 2012
- Urs Hoezle’s presentation from ONS in 2012
- Google A Software Defined WAN Architecture (81 Slides) from ONS 2012
- Martin’s Blog
From the Martin’s blog in the section on General SDN Controllers:
“The platform we’ve been working on over the last couple of years (Onix) is of this latter category. It supports controller clustering (distribution), multiple controller/switch protocols (including OpenFlow) and provides a number of API design concessions to allow it to scale to very large deployments (tens or hundreds of thousands of ports under control). Since Onix is the controller we’re most familiar with, we’ll focus on it. So, what does the Onix API look like? It’s extremely simple. In brief, it presents the network to applications as an eventually consistent graph that is shared among the nodes in the controller cluster. In addition, it provides applications with distributed coordination primitives for coordinating nodes’ access to that graph.”
Regarding, ONIX here’s a brief summary of the architecture but you can read a paper on it here and note who the author’s are and where they work:
- Centralized approach. Central controller configures switches using either OpenFlow along with some lower-level extensions for more fine grained control.
- Default topology is computed using legacy protocols (e.g. OSPF, STP, etc.), or static configuration.
- Collects and presents a unified topology picture (they call it a network information base – NIB) to Apps that run on top of it.
- Multiple controllers (residing in Apps) are allowed to modify the NIB by requesting a lock to the data structure in question.
- Scalability and Reliability:
- Cluster + Hierarchy of Onix instances, but NIB is synchronized across all instances (e.g. via a distributed database). For the hierarchical design, there is further discussion on partitioning the scope and responsibilities of each Onix instance.
- Transactional database for configuration (e.g. setting a forwarding table entry), DHT for volatile info (e.g. stats). Lot of focus on database synchronization and design.
- Example of “apps” mentioned in the paper:
- Security policy controller
- Distributed Virtual Switch controller
- Multi-tenant virtualized datacenter (i.e. NVP)
- Scale out BGP router
- Flexible DC architectures like Portland, VL2 and SEATTLE for large DCs
Combining the info from multiple sources, Google uses ONIX for a network OS (see the link to the ONIX paper above). ONIX appears to be Nicira’s closed source version of NOX, and both Nicira and Google use it. NEC has something called Helios that involves OpenFlow, which noted above was OEMed by IBM. I not sure about HPQ and their recent controller announcement, but I think it serves us well to understand the history of the ONIX architecture.
- ONIX users think that fast failover at the switch level while maintaining application requirements is a hard problem to solve. They think it is better to focus on centralized reconfiguration in response to network failures.
- ONIX synchronizes state only at the ONIX controller
- ONIX wants to use multiple controllers writing to the network information base interface and probably to any table in any switch
Is ONIX a direction for some OpenFlow evolution or a design point? I think one of the early visions for OpenFlow and ONIX was for it to become a cloud OS, which it has yet to become, but others are trying. The evolution of OF/ONIX vision looks something like this:
- Build a fabric solutions company with software and hardware, which is largely about controlling physical switches with OpenFlow (Read NOX paper here)
- Build a commercial controller (ONIX) and sell it as a platform product to a community of applications developers
- Build a network virtualization (multi-tenancy through overlays…this is the part where Nicira renames ONIX to NVP?) application that happens to embed their controller (formerly ONIX). Control the forwarding table with OpenFlow and every other aspect of overlay implementation using OVSDB protocol talking to OVS (it is largely about controlling virtual switches with only a pinch of OpenFlow).
- Nicira purchased by VMWare for their general expertise in SDN and for future applications of the technology assets (VMWare today ships a virtualization/overlay solution using VXLAN that does not include any Nicira IP).
It will be interesting over the next year or so to see how the architecture of the controller evolves. I wrote about some of this in the SDN Working Thoughts #3 post. I think we are coming to an understanding that there are variations to just running a controller in band with the data flows. I think we will conclude that having a controller act as session border control device translating between the legacy protocol world and the OpenFlow world is also a non-starter, but this is the current hedge strategy of most incumbent vendors. As the world of SDN evolves, we will look back and see the path to what SDN has become by looking at the failures as proofs along the way. The industry will solve the scaling and large state questions, but I think the solutions will be shown to exist closer to the hardware (i.e. network) than most envision in the pure software only view.
In a prior post I had made a reference to an article that was partially inspired by a post by Pascale Vicat-Blanc on the Lyattis blog. The Lyatiss team has been working on a cloud language for virtual infrastructure modeling. In particular, it generalizes the Flowvisor concept of virtualizing the physical network infrastructure to include application concepts. I am not sure of the extent of their orchestration goals. Do they expect Cloudweaver to spin up the VMs and storage, place them on specific servers, configure the network to satisfy specific traffic engineering constraints, and finally tear down the VMs? I am not sure. With Nicira now part of VMWare what is the future for NOX/ONIX and will other companies be innovators or implementors?
There is another potential market evolution to consider when we think about the controller. The silicon developers are looking to develop chips that disaggregate servers into individual components. The objective is to make the components of the server, especially the CPU upgradable. Some people have envisioned this type of compute cluster to be controlled by OpenFlow, but I think that is unlikely. Network protocols will be around for a very long time, but putting that aside, the question is what does this type of compute clustering do for the network? How much server to server traffic stays in the rack / cluster / pod / DC? I am not sure how much of this evolution will have to do with OpenFlow, but what I do know is that this type of compute evolution will have a lot to do with SDN, if you believe that SDN is about defining network topologies based the needs of the applications that use the network.
In a true representation of the title, this post is just some working thoughts on SDN with hypotheses to be proven. Comments and insights welcome…
/wrk
Quick Thoughts Post VMworld
From my perspective, I thought the show was great. We had a lot traffic in our booth, but the traffic was mixed. A good number of clients we have been talking to came by and we had a number of new engagements. All very positive. On the downside we had a lot of visits from incumbent networking companies. I did not know there were so many PLM and technical marketing people assigned to attend VMworld.
I had one interaction with a VP (Bus. Dev / Strategy / Strategic ) from one of the big incumbents. We both said hello. He asked me what Plexxi did. I said we are an SDN startup. He laughed and said we are all SDN now (apparently the Nicira acquisition by VMWare was some sort of conversion event for the networking industry), but what does Plexxi do he asked. I said we are focused on the data center. Okay, but what do you do he asked again. I said we were competitors and I was not going to provide details. He said okay and walked away.
Kind of interesting he did not know what we did when I think you can figure it out in about 15 mins of reading on the web. We were also showing the product in the picture in our booth, which attracted a lot of attention and we had a demo of Affinity networking if you cared enough to take the time. My take away was if someone wanted to know about a company on the show floor like Plexxi, they should do some research before the show and know exactly what to look for and ask about in the Plexxi booth. Having worked in three public companies, two of which we are large tech companies, it reminded me how inward focused many incumbent companies can be; it is as if the outside world does not exist. By the way, the last point about doing the research before the show, goes for candidates interviewing for a position too. If you do not care enough to do the research, how can I believe you will care enough to be on the team.
One final note to a reader of my blog. I was very humbled by a potential client who visited our booth and promptly told our CEO that he reads my blog and recently sent my Some Working Thoughts on SDN post to the IT team at his firm.
/wrk
What does…
Six sales calls of which two were multi-hour product demonstrations as well as side meetings, dinners, and driving between SFO and SJC four times equal? Tired. Now I have the hardest one hour wait, which is the hour I have to wait till the flight home departs. It is not the redeye that is especially difficult, it is time waiting for the boarding process to start that seems to make time slow. I had an amazing couple of days in SJC/SFO talking data center architecture and SDN with prospective clients, industry luminaries as well as colleagues in fellow SDN startups. The last few days will be time we all look back on as the most fun in the life of a startup. I was with a great team rushing from appointment to appointment, lugging a SDN network in a 200 pound from location to location. At one customer, they even came out to the parking lot to look at the equipment in the back of van to see if it was real before we lugged it to a lab twenty miles up the road.
Now it is time to change coasts and check in with team at headquarters.
/wrk
Not Fooled, Staying Grounded in Reality
My employer Plexxi had some funding news today. I am sitting at my desk in Cambridge letting the tweets, the blog postings, the news articles and the emails wash over me. Truth be told the attention feels pretty good. I know how hard my co-workers have been working and some recognition makes the day before the weekend feel good. I enjoyed it for about fifteen minutes, but now it is back to reality. All the funding coverage has resulted in a number of inquires from people looking to join Plexxi and recruiters seeking to help us expand the team.
I am bit humbled by the inquires because what we have to offer is not for the faint of heart. I posted that a few months back. We do not have teams of people to send on sales calls. We do not have admins and support teams. Selling Plexxi is really cool, but it is not for the faint of heart. What we sell is the new f’ing network for the next twenty years of networking. We fly on red eyes. We are away from home. We do not have fancy marketing presentations and we do not fly in product specialists from headquarters. We are scrappy as our CEO says. We make the sales calls in person. Most of sales calls are on the white board. We get to the point. What we sell is cool, but it has never been done before. It is hard. It is really hard. It is very interesting to clients, but it not easy. Some mornings I have to listen to The Fighter by GCH to get amped up for the day.
I am very aware of our competition. They are far bigger, they have billions in capital and every account we sell into is already occupied by their teams and equipment. We have to be better, cheaper, faster and innovative. We play in the big league under the lights, in prime time. We are not selling miscellaneous things. We sell technology into the core function of our customer’s business. Yes, we are looking for players on the team, but you better know what you are getting into. It is not easy. I am not fooled by the immensity of the challenge. I am also not daunted by the challenge. Game on.
/wrk
D’où Venons Nous / Que Sommes Nous / Où Allons Nous
Why do we seek?
When do you feel most alive?
What causes you to be up at 4am and feel invigorated?
When I first thought about writing this post, I was trying to come up with something pithy to write in parallel to Brad’s post. I failed. I do not have something pithy. What I have is a feeling that I have not had in a long time in tech. It is the feeling of being most alive. I have this feeling because I am meeting people who are seeking. Let me describe a scene:
You are an experienced IT/technology executive. You are told in a few days that some company you have never heard of will be in town and they might have something of interest you should see. You do not really have an accurate description of what you should see; yet you make appointment to go see it. You are given an address. You find the building. It is difficult to gain access, as you need to be on the list at the desk. Once you have arrived at the correct floor, you find another set of doors and then a reception area where you name is checked again. You state your business and are led down hallway past nice offices and well-apportioned conference rooms. A few turns later, down a narrowing hallway you arrive at the smallest, windowless conference room that is next to the storeroom. Inside your conference room you find a few people, some IT equipment. It is hot. There is a tabletop fan swirling the warm air. You sit down. There are no PowerPoint slides – just the white board, a flat panel, a rack of gear and some people. The conversation begins. You can leave at anytime; yet you stay. It is hot; yet you stay. Sleeves are rolled up, your brow fills with sweat and still you stay. The white board is filled many times over. Time goes by and the conversation goes on. When it is done you leave hot, tired, exhausted and alive.
What would you call that? I call that a meeting of the revolutionaries. “It is not the critic who counts, not the man who points out how the strong man stumbled, or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena; whose face is marred by the dust and sweat and blood; who strives valiantly; who errs and comes short again and again; who knows the great enthusiasms, the great devotions and spends himself in a worthy cause; who at the best, knows in the end the triumph of high achievement, and who, at worst, if he fails, at least fails while daring greatly; so that his place shall never be with those cold and timid souls who know neither victory nor defeat.”
/wrk
* It is all about the network stupid, because it is all about compute. *
** Comments are always welcome in the comments section or in private. **