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

["John Hufferd" <hufferd@us.ibm.com>]

YP,
Please refrain from discussing iFCP in any context except what the Draft
supports.
We need to reach consensus on real proposals.
If you want to author another draft we can perhaps discuss that.
The authors of the current draft believe your comments are removing the
focus they need on their iFCP Draft.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com


"Y P Cheng" <ycheng@advansys.com>@ece.cmu.edu on 01/15/2001 07:02:50 PM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  RE: iSCSI & iFCP Overlapping (Was iFCP as an IP Storage Work
      Item)



> 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.