Subject: Re: iSCSI & iFCP Overlapping (Was iFCP as an IP Storage Work Item)

From: "John Hufferd" <[email-masked]>
Date: Mon, 15 Jan 2001 15:10:28 -0800

With my TC hat on:
Please reframe from speculation about iFCP as an End to End protocal.  iFCP
has not been proposed by its authors to be End to End, and is not up for
discussion without an approprate draft.  The authors and the iFCP Draft
clearly define iFCP as an Gateway to Gateway protocol.  We are currently
having enough problems just working on the Gateway to Gateway issues, and
do not need to explore areas where the Draft did not go.

Please lets limit further iFCP discussions to iFCP as a Gateway to Gateway
protocol.

TC hat off.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: [email-masked]

"Y P Cheng" <[email-masked]>@ece.cmu.edu on 01/15/2001 08:40:41 AM

Sent by:  [email-masked]

To:   <[email-masked]>
cc:
Subject:  iSCSI & iFCP Overlapping (Was iFCP as an IP Storage Work Item)

> iFCP and FCIP have nothing to do with OSPF.  I think your statements
> show that you do not understand iFCP and its objectives.  I would
> have hoped that those critical of iFCP would have at least a minimal
> understanding of it.

Josh,

Had I stayed with the topic of "saving the customers' investment in FCP
stack" I would have done better and not invited the above statement.  :-) I
have no doubt that you are a very good and wonderful network engineer.
But,
I am afraid, iFCP simply is a better mouse trap solving the same problem as
that by iSCSI.

After reading the iFCP draft carefully, I can't help but conclude that by
connecting N-Port to IP directly iFCP usurps the fibre channel Extended
Link
Services and replaces class F traffic by all the wonderful stuff like EGP,
BGP, OSPF, etc., offered by the Big Internet.  I found the iFCP effort
overlaps with iSCSI and it provides no additional benefit.  As you have
indicated that iFCP provides a transition into the iSCSI world of the
future.  We must agree that initially even iSCSI storage devices will have
FCP or SCSI devices "inside the box".  This is because the storage industry
will take some time to change its infrastructure to produce iSCSI drives.
On the other hand, the iSCSI HBAs will be available quickly -- I hope you
do
give me more credit in knowing the HBA world. :-)  Therefore, it is very
easy for the Network Storage Industry to have an iSCSI target adapter
inside
its box to communicate with the iSCSI hosts and clients.  If iFCP is a
viable solution, the HBA industry can produce iFCP target and host adapters
just as quickly as the iSCSI adapters.  Trust me, if we can implement the
Fibre Channel and InfiniBand specifications, we can do iFCP.  I do hope you
see my logic now.

Therefore, while iFCP may be a better mouse trap than FCIP, IMHO, it is
providing the same solution as that of iSCSI.

By the way, lets hear from other folks on this topic, please!

Y.P. Cheng, ConnectCom Solutions.

---

From: "Y P Cheng" <[email-masked]>
Date: Mon, 15 Jan 2001 19:02:50 -0800

> Please reframe from speculation about iFCP as an End to End
> protocal.  iFCP has not been proposed by its authors to be End to End,
> and is not up for discussion without an approprate draft.
> The authors and the iFCP Draft clearly define iFCP as an Gateway to
> Gateway protocol.  We are currently having enough problems just working
> on the Gateway to Gateway issues, and do not need to explore areas where
> the Draft did not go. Please lets limit further iFCP discussions to
> iFCP as a Gateway to Gateway protocol.

John,

Thank you for taking time to write a long essay about iFCP in another
posting.  It is not my intent to compare iFCP to an end-to-end solution like
iSCSI.  Let me respond by staying within the realm of treating iFCP as a
Gateway protocol.  I want to look at the whole issue from another angle.

Most of us would agree the market driver for iSCSI, iFCP and FCIP is the
need to have block-address storage devices on Internet.  The number of new
SSP companies tells the story.  In fact, we can divide the world into two:
clients and SSPs, even when many data centers only serve internal customers.

As a client, if he has made no investment to fibre channel before, iSCSI is
the nature choice provided his SSP supports iSCSI.  If his SSP has FC or the
client has already invested in FC, he needs to add a gateway of iFCP or FCIP
whichever is required by his SSP.  Of course, he can choose iSCSI if it is
supported by his SSP too.  His decision is based on cost, confidence,
availability and performance.  In other words, iSCSI, iFCP, and FCIP are
choices of a client.  Most likely, he is unconcerned whether it is
end-to-end or a gateway until he writes the check.

As an SSP, for some time to come, most will be built around FC and SCSI
devices.  (Some SSP may even wish to build around ATA drives.  Checks with
3ware.)  However, an SSP may choose to "export" its disk drives with iSCSI,
iFCP, or FCIP support.  Notice, what devices an SSP has vs. what it chooses
to export can be unrelated.  It can do so simply with the target HBAs that
support the iSCSI, iFCP or FCIP protocols while the storage devices are
configured as "virtual" drives.  An SSP can invest switches supporting
iSCSI, iFCP and FCIP for export as well, even iFCP is a gateway and iSCSI is
an end-to-end protocol.  You have mentioned more than once that the iFCP
gateway supplier would support iSCSI in the future.  The exporting protocol
of the devices is only important to the clients as long as they don't have
to throw away the old investment or spend a lot of money buying new
equipment.  Most companies making RAID or large storage boxes is quite
familiar with this virtual device game.  For example, you can choose your
own FC or SCSI connection for a RAID box.

It is in this context that I believe iSCSI and iFCP may have overlapping
utilities because they both take full advantage of IP routing.

Y.P. Cheng, CTO, ConnectCom Solutions Corp.