ZK Research: Home
Google+
Twitter
LinkedIn
Facebook
RSS Feed

Posts Tagged ‘OpenFlow’

This may be hard to believe, but OpenFlow is now about four years old, and late last year version 1.4 of OpenFlow was unveiled. This week, startup Pica8 became the first vendor to support 1.4, which may be the first OpenFlow version that’s ready for prime time. OpenFlow features a number of new features, improvements, and one change.

The new features are:

  • Bundles. The bundles feature of OpenFlow 1.4 enables a group of OpenFlow messages to be “bundled” as a single, which allows for better synchronization of changes across as series of switches. This is similar to a “commit” of multiple configuration changes in traditional layer 2/3 environments.
  • Optical ports. In 1.4, support for Optical ports has been added. OpenFlow can now be used to configure or monitor optical ports, which brings FiberChannel over Ethernet into, play in an SDN. This also allows for higher-speed transmission rates to be used in the SDN.
  • Synchronized tables. Flow tables can now be synchronized uni-directionally or bi-directionally. This has some implications on the way data flows are synchronized to transmissions of data. This effectively doubles the TCAM scalability of the switch.

[keep reading…]

Why do customers pay a premium for Cisco? My research shows that Cisco owns about 75% of switching share but only about 55% of port share, showing Cisco’s obvious revenue per port advantage over everyone else. Why does this discrepancy exist? I know some of you will disagree with this, but in general, customers pay up for Cisco infrastructure because it does more stuff faster than competitive products.

One good example of this is the evolution of power over Ethernet (PoE). Years before the PoE standards were ratified, Cisco rolled out its own version of PoE that gave customers PoE capabilities, while the rest of the industry was arguing in the standards bodies. Cisco got a huge, early-mover advantage by having a solution two years ahead of the field. Then, when the standard was ratified, Cisco supported it.

Cisco has maintained this advantage as remains the only vendor with 60W POE today. There are many, many examples of this. EIGRP is a faster, better protocol than RIP; for years Skinny had more features than SIP; EtherChannel was great for port aggregation, and the list goes on. Some vendors scream “vendor lock in” and “proprietary,” but the fact is that Cisco supports all the standards. But customers prefer the Cisco version since it does more.

[keep reading…]

Last week, Alcatel-Lucent (ALU) held its annual Industry Analyst conference in Annapolis, Maryland. Unified Communications has historically been the primary focus for ALU’s go-to-market strategy, but the company has spent the last few years beefing up its OmniSwitch data networking portfolio as well. In fact, if you recall, ALU was the focal point of this Network World Article where the company beat out Cisco for a network project in its own home state.

Like every other network vendor, ALU has been trying to jump on the market opportunity created by the rise and complexity of server virtualization. I recently did some research that pointed out that a small amount of server virtualization saves both capex and opex. However, highly virtualized environments, meaning those that are more than 50% virtualized, have actually seen operational costs rise by as much as 20%. High amounts of server virtualization create unpredictable traffic flows that can wreak havoc on the network.

[keep reading…]

Despite the hype around software defined networks (SDNs), the industry has yet to find a legitimate “low-hanging fruit” for the network technology. It appears, though, that one might be emerging, as several vendors have announced TAP aggregation as an SDN application. Earlier this year, when Big Switch launched the company it announced its own product called Big TAP. Later, Cisco released TAP aggregation for its Cisco ONE controller.

Well, last week Arista Networks announced its DANZ data analyzer, which is an application based on EOS (Extensible Operating System).

To say the TAP aggregation market is hot is an understatement. This once niche market has become one of the fastest growing markets in the network industry. In the last year, market leader Gigamon started prepping for IPO, VSS was acquired by Danaher Corporation, NetScout bought ONPATH, and Ixia purchased Anue.

[keep reading…]

With the hype around software-defined networks (SDNs) having grown as high as it has, almost every vendor is looking for an angle to capitalize on the opportunity. I’ve noticed recently that many of the vendors, particularly the big-box vendors, are focused on the concept of “network programmability.” While I agree that programmability is a component of SDN, it shouldn’t be the sole focus of the technology. As an example, Cisco has been pushing the Python-based ONE (Open Networking Environment), Juniper has JunosV App Engine and HP has its own programming environments. Like I said, I think these are important parts of the overall SDN solution, but it’s not aligned with where buyers are today.

I recently ran a survey with TechTarget and one of the questions asked was “How do you think SDNs can help your company?” The number one response, at 50% of the respondent base, was “simplify network architecture.” The No. 2 response (46.9%) was “reduce network hardware costs.” The third most popular response (45.4%) was to enable network management. Way down on the list, at 7.7%, was to “provide a more programmable network.”

Programmability could be used to improve network management, but it really doesn’t have any impact on the first two options: simplification of architecture and reduction of hardware costs. Those problems are solved through the use of low-cost, standards-based switching hardware that is simple to deploy and manage. I’m not saying that the big box vendors are trying to slow innovation or aren’t taking SDNs seriously. In fact, it’s quite the opposite. The mainstream vendors do want to offer a credible SDN story, but they do need some level of vertical integration to keep the “end-to-end” value proposition intact.

For most mainstream companies, the limitations of a vertically integrated solution will probably be fine, at least in the near term. In fact, I’m not sure most mainstream companies would even know where to procure low-cost, non-brand-name network hardware. However, for those organizations with hyper-scale data centers where the network is the business, being able to cut the cost of switching through the use of low-cost, simplified network infrastructure can be significant. In a sense, it’s the same market where SeaMicro thrived by offering simpler, lower-cost rack servers.

While much of the industry will focus on the programmability of the network, the companies that want to leverage the cost benefit of SDNs now should think “open” first, and then look to leverage programmability once the architecture has been simplified and the overall network has become more manageable.

As most people who follow the networking industry know, Juniper outlined its vision for software-defined networks (SDN) at last week’s Global Partner Conference in Las Vegas. I’ve had a bit of time to digest the information, answered a number of questions about it, and I thought it was time to share my thoughts on what they announced and the impact to the industry.

First, summarizing what Juniper announced, they began the presentation with a number of myths regarding software-defined networks and then articulated Juniper’s principals of SDNs. I’m not going to repeat these, but if you missed the webcast, Jim Duffy’s article does a good job of highlighting them.

[keep reading…]

ZK Research is proudly powered by WordPress | Entries (RSS) | Comments (RSS) | Custom Theme by The Website Taylor