SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI CONNECT message



    
    Douglan Otis,
    I have no idea what point you are trying to make, I don't even know if I
    disagree with what you intend to say.  I know there is no such thing as a
    SCSI address space.  I know that we need a boot process, that needs to
    depend on establishing a connection to the target Storage Controller, and
    in the iSCSI space this means using the normal IP connection processes.
    Some of those include DHCP, and DNS etc.  So I do not even know what you
    are arguing against.
    
    Many folks are saying that we need additional techniques to get through
    (to) various type of "private" networks, and they are suggesting ways to do
    this (such as the "Target:" string on the Login or a separate "Connect"
    iSCSI command).
    
    However, given the above, I do not even know what you are arguing for or
    against.
    
    Perhaps, if you want to discuss this further off the reflector, we can
    reach an understanding.  I hate to keep punishing every else with these
    notes.
    
    
    .
    .
    .
    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
    
    
    "Douglas Otis" <dotis@sanlight.net> on 10/09/2000 11:42:22 AM
    
    To:   John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
    cc:
    Subject:  RE: iSCSI CONNECT message
    
    
    
    John,
    
    You are still stuck with the chicken and the egg problem.  Unless this
    login
    process can expose extensive amounts of information with selectors to allow
    a user to prune this information, you are left with a scheme that will not
    scale.  Stop designing a database server within the SCSI transport.  It is
    counter intuitive to use transport to inform the system as how to use
    transport.  Bootstrapping must still be defined.  Should there be a tunnel
    that needs to be navigated, leave that operation to the gateway already on
    the network.  The transport should not need to define every aspect of a
    path
    taken between point two points.  Let gateways and routers make those
    decisions.
    
    There have been years of work at allowing this level of separation between
    a
    connection and routing.  Do not mix routing with what should be a simple
    transport.  Keep SCSI addressing free of embedded IPs.  If there is an IP
    domain that must be transversed beyond the portal, it should be configured
    outside the transport.  It is a mistake to try to mix SCSI address space
    with IP address space.  A SCSI target is not a IP:Port combination.  Once
    within a SCSI domain, only SCSI targets using the real addressing such as
    S_ID or D_ID with a link should be used.  To introduce two levels of
    addressing makes it impossible to provide security.  Each domain would have
    a different translation to the eventual target.  Allowing such levels of
    proxy will never scale due to an inability to authenticate or to provide
    meaningful restrictions prior to access.
    
    Doug
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:45 2001
6315 messages in chronological order