IT Infrastructure Performance Discussions

• The Data Center LAN Evolution Series
• A Webtorials Thought Leadership Discussion
• Dr. Jim Metzler, Moderator
• Featuring Arista, Avaya, Brocade, Cisco Systems, Extreme Networks and HP

There has been a lot of interest recently in OpenFlow - a communications protocol that enables the separation of the control of packets from the forwarding of packets.  By separation is meant that the forwarding of the packets occurs on an OpenFlow switch and the control of those packets occurs on a separate controller. 

The OpenFlow specification itself is being developed by the Open Networking Foundation (ONF). 

One of the things that is interesting about the ONF is that its founding and board member are Deutsche Telekom, Verizon, facebook, Google, Yahoo and Microsoft.  At first it may seem strange that companies such as Google, facebook and Yahoo are so involved with the development of new communications protocols.  However, given that separating the control and the forwarding of packets onto separate devices is somewhat of a radical idea, one could argue that the initial advocates would have to be non-traditional players.

The definitive paper on OpenFlow is entitled "OpenFlow:  Enabling Innovation in Campus Networks." The paper was written in 2008 by researchers at some of the US's most prestigious universities; i.e., Stanford, Berkeley, Princeton and MIT.

The first sentence of that paper states "This whitepaper proposes OpenFlow:  a way for researchers to run experimental protocols in the networks they use everyday."  That sentence sets up the theme for this month's discussion: Does OpenFlow actually enable the innovation and cost savings that the articles in the press have been talking about or is OpenFlow just a science experiment by some really bright people?

• The Data Center LAN Evolution Series
• A Webtorials Thought Leadership Discussion
• Dr. Jim Metzler, Moderator
• Featuring Arista, Avaya, Brocade, Cisco Systems, Extreme Networks and HP

There is considerable discussion in the trade press about the value of converging the data center LAN and SAN.  The typical argument that is raised is that it is notably more efficient to run one network than it is to run two networks.  That argument sounds very familiar.  That is the same argument that was made as part of the justification for converging voice and data networks.   So, one could conclude that since that argument worked for voice and data networks it will work for the LAN and SAN.  While that may be a valid conclusion, it took several years before a converged voice and data network became mainstream.  Will that be the case with the convergence of the LAN and SAN or is this situation different enough that adoption will occur more rapidly?

This month's discussion will focus on the convergence of the data center LAN and SAN.  We will explore some fundamental issues such as why exactly would an IT organization want to converge their LAN and SAN and if they do, how should they best go about doing it?

• The Data Center LAN Evolution Series
• A Webtorials Thought Leadership Discussion
• Dr. Jim Metzler, Moderator
• Featuring Arista, Avaya, Brocade, Cisco Systems, Extreme Networks and HP
  

Driven largely by the changes brought on by the adoption of virtualization and cloud computing, the majority of IT organizations are currently re-thinking their data center LAN strategy.  To help IT organizations develop effective strategies, we will present a series of six monthly discussions that will involve six of the major data center LAN vendors.  Each discussion will begin with a somewhat high-level question on a topic that is relevant to the evolution of data center LANs.  During each month, we will ask one or two follow-on questions.

During each month, the sponsors will respond to the questions and will comment on the responses of the other sponsors.

Each vendor response and comment will focus on technology and design issues.  The vendors will not, for example, discuss products. We look forward to your participation in the discussions.