Storage Strategies - Thursday, April 08, 2004
Reader Mail: A Response to the FCIA
The author outlines 10 reasons why he disagrees with the FCIA's view of
By Jon William Toigo
A friend of mine, quite a talented artist, just took a marketing role
for the Fibre Channel Industry Association (FCIA). Being a friend, he
set about to smooth relations between that organization and this
columnist, explaining that some of the Storage Strategies columns had
criticized FC SANs, a fact brought to his attention by several FCIA
In his words, "During one of our meetings someone brought up this
article written by you. Some people certainly thought that the writer
did not know FC at all. Well, we know different. So here is my
question: Would you be interested in coming into the lion's den and
present at a FCIA meeting? I believe many of our members would benefit
from an outside view. They might not like it, but maybe it would rattle
them... This would NOT be an adoring crowd so think about it
We deferred on the invitation for several reasons, which are enumerated
1. FCIA pushed FCP into service as the interconnect for a SAN because
it was the fastest interconnect available in the late 1990s. They knew
that it was not a true network and lacked in-band services (for
management, security, etc.) that are part of any real network in
business use today.
FCP was, in fact, an implementation of serialized SCSI over a point-to-
point channel interconnect. The FCP inventors at IBM explicitly noted
that they had not set out to create a network protocol and had
deliberately excluded all "IP stack like functions" from FCP. They
just wanted to replace the fat SCSI cables they kept tripping over
every time they walked around the back of their rack storage!
In 1998 and 1999, the deficiencies of the FC protocol were clearly
understood and documented. In the words of the white paper I helped
write, FCIA was "going to work to add services into the protocol to
make it more network like" over the next few years.
My opinion of FCIA soured when that white paper was shelved "for
marketing reasons." The industry was touting FCP as the ONLY
interconnect for building SANs (oxymorons abound) and wasn't taking
kindly to suggestions that the protocol wasn't quite up to snuff.
2. As iSCSI began to be developed at IETF, it seemed that a credible
contender to FCP -- one based on a true network protocol -- was in the
offing. When I suggested that SANs might eventually be based on IP
rather than FCP, many FCIA member companies responded with hostility.
I remember a senior member of a FC HBA manufacturer at Networld+Interop
a few years back telling me there was no way that IP would ever be a
storage interconnect. When I reminded him of this encounter a year and
a half later, when his company announced the industry's first iSCSI
HBA, he claimed to have forgotten the incident completely.
3. I have followed the development of both iSCSI at IETF and FCP at
ANSI. Both standards-making efforts are imperfect, given the
omnipresence of vendors in the standards process, but the politics
surrounding FC switching standards at ANSI was over the top. Standards
like FC-SW2, for example, were written with sufficient wiggle room for
any vendor to create a switch to the letter of the standard that would
be completely non-interoperable with other standards-compliant switches
from competitors. I agreed with the 10-page critique submitted by
Cisco Systems at the time condemning FC-SW2 and concluded that FC
protocol development had become a microcosm of the industry itself.
4. At conference after conference, FCIA articulated the same themes:
FCP rules, everything else drools. The problem was that FC Fabrics
really weren't delivering on the SAN vision as articulated in the
original ENSA white paper from Compaq.
With an FC SAN, you needed the services of a true network, IP, to
provide all management and control on an out-of-band basis that wasn't
being provided in-band by FCP. So, a SAN was actually a "dual-network"
architecture at a time when many companies were looking to consolidate
voice, video, and data on a single IP network. It made scaling an SAN
an even more problematic undertaking since you had to scale both the IP
and the FC fabric components. The word "kludge" comes to mind.
5. FCIA tried to convince everyone that SANs were the best platform
for all data. Nonsense. The differences between applications and
their data storage requirements make a one-size-fits-all topology a
In point of fact, some apps actually do very well with FC SANs -- and I
have recommended them in certain instances. However, others do best
with NAS or with DAS because of application requirements. All do not
want the same drink of storage from the same SAN pool. There can be no
one-size-fits-all storage topology because applications are all
different. "SAN everywhere" is oversell. (Story continues below)
6. FCIA members have started pitching "FC SANs for the rest of us"
(i.e., the SMB market). Most SMBs don't need SANs. They don't have
high-end tape libraries (what motivated about 70 percent of early SAN
adoptions) to share. Those needing a topology for scaling block
storage behind certain apps (a key motivator for SANs today) will be
better served by much less-expensive Serial Attached SCSI (SAS) or
iSCSI configurations than by dumbed-down FC HBAs and switches -- an
opinion born out by site visits and conversations with IT staff in SMB
7. Claims that "FC SANs are needed for real data protection" are
simply not true. While a stable SAN might provide a platform for
expeditious data replication and failover, I wouldn't trust a SAN-based
data replication scheme unless all of the equipment was from a single
vendor at both the primary and all remote sites. Heterogeneous SANs
create more downtime than they avoid.
8. "FC SAN interoperability has reached a new level": Hundreds of
press releases with this theme came out this past year. Behind the
scenes, technicians painted a different story: "Interoperability
issues are worse now than they were five years ago," I was told by one
test lab guy, while another noted, "We were lucky if we could keep the
fabric alive for longer than 15 minutes at a time." Perhaps I was
talking to the wrong people? Maybe. But, my clients tell a different
9. If there is so much inevitability behind the ascension of FC SANs
as the dominant storage topology, why does FCIA exist? What is its
10. At the end of the day, topology is not the big issue -- provided
it is stable. The challenges of storage have little to do with
topology, but rather with data and its management: how data is
characterized and named, how access frequency is counted, and how
storage platforms are characterized by cost and capability so a policy
engine can migrate data to the right platform and protective process
automatically. SAN standards are tinker toys compared to what will be
required to make this happen.
I will agree that FCIA has been remarkably successful in convincing the
top tier of the market that FCP is all there is. My industry friends
complain they can't sell a port of anything that isn't Fibre Channel.
But most Fortune 500 shops have been wasting money on high priced gear
with poor capacity utilization efficiency for years. Many are already
planning for the replacement of storage gear just as they deploy their
most recent acquisition. I have interviewed IT managers in such shops
who say they are on their third FC SAN deployment -- and quickly add
how little they thought of their first two.
Going forward, I expect FCIA will have a bigger challenge from vendors
in the SMB space. For one thing, they do not have the deep pockets of
their wealthier cousins, and they have a distinctly "show me" attitude.
For another, these folks possess the common sense to realize that the
value products deliver to their organizations is the true measure of
I'm thankful for the invitation to the FCIA meeting, but I'm happier
discussing these issues in a public forum. Why not set up a public
meeting: FCIA on one side of the table, and many disgruntled SAN users
on the other? That would give the FCIA a more comprehensive "outside
view" than anything I could possibly say.
Copyright 2004 101communications LLC.