SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    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.
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:50 2001
6315 messages in chronological order