Hello, Security, My Old Friend

Back before software-defined networking, I spent time promoting a different “SDN”: “Self-Defending Networks”. That was Cisco’s marketing tagline for their Security portfolio. At the time that I joined, they had just brought together security-related products from different BUs as the Security Technology Group, under Jayshree Ullal.

Now, Self-Defending Networks wasn’t something that held up under even the lightest technical scrutiny. All of the products except for NAC were acquired, so each had its own element manager with its own policy schema, and none of them really talked to each other. And it’s kind of hard to run an effective security team if each member speaks a different language and operates from a different rule book, regardless of how individually skilled they may be. That’s why I find the possibilities of having a common layer of abstraction (a la ODL) so compelling: you can’t have reliable security without holistic, end-to-end management (too many gaps), and if you have good holistic, end-to-end management, you can spend less time and energy on security.

I’m joining Skyport Systems because it resolves a lot of these challenges in a very streamlined way. It also manages to simultaneously address many of the reservations people have about entrusting sensitive data to external cloud providers, while also providing a consumable Security-as-a-Service offering that eliminates a lot of those security tool integration challenges. That’s a pretty good trick, in my opinion.

It also doesn’t hurt that I’ve worked with several members of the team before. (Fun fact: I accepted the Skyport offer during Back to the Future week. I think I’ve identified the team’s Doc, too.) It’s an intense, high-energy crew, but importantly, one that is generally pretty strong in the Sense of Humor department as well. The leadership team members each have both startup experience and successful track records in large companies, meaning that they’re not afraid of getting their hands dirty, but also have the mindset and rolodexes to scale the company.

One other consideration I had, as a marketer: technical realities aside, I liked that Self-Defending Networks was a fundamentally positive, hopeful vision to strive for. Too much of security marketing (in IT and in modern politics) is all about instilling fear–which often skews perceptions of and responses to risk in wasteful and even counterproductive ways. I prefer a more positive message: providing a foundation of trust. I think Skyport has the right bones to support that.

More soon.

Meet the New Software-Defined Network. Almost the Same as the Old Network.

Occasionally when I wake up, I have some utterly obscure question percolating in my brain. Once, it was about the color of the original, undomesticated carrots (white and purple, it turns out–like their cousins the turnip and the parsnip). I have to go look it up so I can go on about my day without further mental interference, which is why I can tell you, for example, that there is an online Carrot Museum that will tell you everything you want to know about carrots. Also, in Afghanistan they make a fermented beverage from wild carrots. (Thanks, brain!)

Today, I simply had to know what “palimpsest” means. Here’s what it means:

A palimpsest (/ˈpælɪmpsɛst/) is a manuscript page, either from a scroll or a book, from which the text has been either scraped or washed off so that the page can be reused, for another document.[1] …In colloquial usage, the term palimpsest is also used in architecture, archaeology, and geomorphology, to denote an object made or worked upon for one purpose and later reused for another, for example a monumental brass the reverse blank side of which has been re-engraved. [Wikipedia]

SDN is an excellent example of a palimpsest. Let’s take the SDN origin story as gospel: why, indeed, shouldn’t you be able to program a switch the way you can a non-purpose-built computing platform? The short answer is because the networking industry, and the devices it continues to produce and sell, evolved in a certain way, and the world is filled with such devices and vast numbers of people trained to interact with them via communication protocols vs higher-level constructs.

So now we’re elaborating an assortment of higher-level constructs under the common banner of SDN. This does not, however, eliminate existing network concepts, protocols–or the actual networks themselves. We are using all of these things as the foundations upon which software-defined networks will be operated, much as the “Troy” excavated (with dynamite!) by Heinrich Schliemann was, in fact, as many as nine different cities, each of which built upon the decaying foundations of the previous one. And why not? It all works moderately well, and we have lots of people who know how to make it work.

The thing about “adopting” SDN is that it’s a little bit of new technology, but a lot of mindset and process shifts. This, I think, is why SDN is starting to enter a winter of discontent (or if you’re more of a Gartnerian than a Shakespearean–a trough of disillusionment). Networking salespeople and users alike are trained to buy/sell boxes that you plug in and that largely ends the transaction until the support contract comes up for renewal or there’s an opportunity to add in more boxes. SDN controllers today, by contrast, are all at the some-assembly-required stage of evolution. And if your SDN use case is BetterFasterCheaper manageability, it’s very reasonable to question why you should go through a whole bunch of new gymnastics moves to do more or less what you’re already doing in a different way.

It would be a mistake, though, to imagine that the current state of affairs is the de-facto nature of SDN. As controllers mature, they will of course become more plug-and-play. Now that the industry has begun to consolidate around a few leading platforms, we will start to see more packaged SDN applications to run on said controllers. Meanwhile, the bleeding-edge organizations moving towards active deployments now are investing heavily in training NetDevs to build their own applications for proprietary use cases. At Open Networking Summit this spring, and in subsequent media interviews, AT&T indicated that they’re putting tens of thousands of network engineers through specialized coding classes. Some portion of those engineers will eventually go on to jobs at other companies, spreading their new expertise into new soil.

And as I wrote in 2013,

…Today’s discrete controllers will wind up going one of two ways:

  • Down, coupled ever more tightly into existing network operating systems, until eventually they will simply be part of OSes with better northbound APIs than before. This will be especially true of “house” controllers from existing networking vendors.
  • Up, as platforms for emerging ecosystems of network applications. There’s nothing to prevent house controllers from moving in this direction, and for major vendors to develop their own developer ecosystems (well, nothing but mindset and institutional support for such)…

There are those, in fact, who expect that controllers will eventually be packaged with applications such that the (micro)controllers are transparent to the user, as opposed to an independent piece of software to be set up and then integrated with a parade of disparate applications. This scenario will necessitate a truly de facto industry controller platform (we’re far from that yet…) as well as a standardized architecture for peer-to-peer controller communications, and mechanisms for defining order of precedence for operations stemming from different applications.

None of this, however, will change what lies beneath in the foreseeable future. We’ll still have some mix of physical and virtual forwarding devices, managed via some set of protocols–some older, some derivations or extensions of existing ones, some genuinely new ones–because SDN doesn’t necessarily change anything about forwarding architecture, and because of refresh cycles and human operator inertia. It will still be valuable for quite some time to understand how those protocols operate on the devices, even as the preferred method for doing so shifts with controller advances and the general state of administrator skillsets. It’s entirely conceivable that 15-20 years down the road, the idea of monkeying around with networking protocols themselves will seem as arcane to most as being fluent in the inner workings of the systems bus in your PC. But we’ve got a long way to go as an industry before that state of affairs appears on the horizon, and most of that shift will come well after we have some semblance of controller maturity and an SDN application ecosystem in place.

Meanwhile, I’ll apparently be mulling over things like the origins of carrots. Stupid brain.

Why Open SDN – In 6 Words

In Maslowian terms:

Open SDN by Maslow

Maslow’s SDN – by Lisa Caywood

Interoperability of different device types from different vendors.

Optimization of device selection–for price and performance independently of services features.

Continuous visibility of flows from source to destination.

Informed, centralized manageability for all devices.

Programmability to shape network and network tools according to users’ needs.

Automation of and by policy.

Thoughts on SDN Consumability

I’ve been using the phrase “SDN consumability” here and there of late, assuming that there was nothing particularly revolutionary in the idea. The response, however, is typically a cocked head, an interested look, and a question: “What do you mean by that?”

So here’s what I mean by that:

In order for SDN to see mainstream adoption, SDN solutions need to be/have

  • Simple to operate – easy to deploy, low-to-moderate learning curve
  • Safe and reliable – tech is stable, nothing blows up, no one gets fired
  • No blue-sky requirements, limited DIY – tech and process migration support available

Continue reading

The Legend of SDN: One Controller to Rule Them All

I originally posted this just over a year ago (Feb 5, 2013) on my corporate blog. I’m reposting here now because the subject of “master controllers” and federation is coming up again more insistently as users begin to think through how to implement a controller-based architecture. I expect to be writing more on this soon.

As we enter the second(ish) Year of SDN, we’ve gone from irrational exuberance to some semblance of reality, with some first-generation products starting to come to market now. That will inevitably drive more reality, on the user side, but an embrace of reality may take a bit longer on the vendor side. I say that because there are still plenty of “whoever wins the controller wars wins all” notions being promulgated in various forums. Continue reading

Notes from ONS 2014 Day 0: SDN Market Opportunities Tutorial

Yes, I’m crazy enough to get up early on a Sunday to go to an SDN conference. I won’t say that there was a lot of “new news” in this session yesterday, but it certainly validated a number of hypotheses. I wound up taking many pages of notes even so, and I’ll summarize the main themes and highlights here.

Open Source and Standards Bodies

While it shouldn’t be a surprise at the Open Networking Summit to hear attendees and speakers beat the open source drum, it was interesting how completely dismissive of traditional vendor implementations most of the speakers were. Prodip Sen of Verizon, also Chair of the ETSI NFV group, commented matter-of-factly,

“Open source is the new standards body. Equipment manufacturers need to build openness, interoperability and modularity into their products. We’re not interested in vertically integrated stacks—that day is gone.”

I could caveat that by noting that even the “enterprise” speakers (from Ebay/Paypal) were rather Web 2.0-flavored and so not completely representative of the broad mass of non-tech enterprises and their needs, but the general direction is pretty unmistakable.

Continue reading

SDN Needs a Charles De Gaulle

There were a pair of stories in the trades last week in which VMware finally took off the gloves and effectively proclaimed themselves the antithesis of Cisco in their approach to—well, not SDN, since both companies say they have gone beyond it. But to the next generation of networking, in any case.

(That’s rather a mouthful, though, so for the rest of this post I’ll refer to their efforts as SDN just as the rest of the industry does; please forgive the shorthand. I’ll get back to the other current discussion about whether SDN 1.0 is dead in another post.)

Any good journalist knows that a good controversy attracts eyeballs, and the best controversy has two—and only two—diametrically opposed antagonists. More than two would complicate the storyline. So we got stories that suggested not only that VMware is now officially at odds with Cisco, but also that SDN architectural options are themselves both binary and comprehensively represented by Cisco and VMware.

Continue reading