SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Canonical Targets



    Mark,
    
    > I also don't think that there will be a lot of single-target devices out
    > there, at least not right away.
    
    Perhaps not right away, but definitely eventually.  Using the LUN
    model is the way to ensure that a target (true target, not bridge)
    implementation can be relatively transport independent.  That's proven
    to be a major survival characteristic for targets.
    
    > Most devices will likely be accessed through iSCSI-FC or iSCSI-SCSI
    > gateways in the near future, before iSCSI interfaces are added to
    > the devices themselves.  Our gateway, for example, provides more
    > than one target; my guess is that others will do the same.
    
    Agreed.  The only SST target in the world is a gateway, and it
    provides multiple target support as well.  Our solution to this
    problem was to constrain the target addressing range so that the
    initiator can do the traditional big crawl.  SST was aimed at a
    different design point, so I'm not saying we should adopt the same
    solution with iSCSI, I'm just agreeing that allowing multiple targets
    behind an endpoint in the protocol design is a good idea.
    
    > In this case, an initiator has to deal with multiple targets
    > anyway.
    
    Absolutely.  However, in the limit, the bridges usually wither away.
    Sometimes they wither away a lot faster than you might expect.  There
    were some early attempts at FC/||SCSI bridging that worked from the
    same set of assumptions.  You probably don't need to know how
    successful those were.  That would never happen to today's modern
    bridge vendor, since they've learned how to apply all their
    accumulated cleverness to building native targets in short order :^)
    
    The bridged scenario shouldn't be at the expense of the unbridged one.
    
    My proposal of allowing:
      1) target discovery login
      2) operational login to a default (Julian's right---the term
         canonical is inappropriate) target
      3) operational login to a specified target
    
    seems to cover all bases.  If your bridge does not want to support a
    default target (I bet it will.... how else will you be able to slap it
    under the skins with a Symmetrix and call it an iSCSI storage array?),
    you can reject the login, with a `no default' reason code (TBS).
    
    I don't mind adding Jim Hafner's multi-layer discovery proposal if you
    guys really think it will help.  Personally, I'm skeptical.  Whatever
    the case, it seems like it can be done in such a way as to still
    permit a single-layer login when given nothing but socket
    coordinates.
    
    Let me beat on this one final time.  I think EVERYBODY on this list is
    aware that the biggest selling point of iSCSI across the entire range
    of applications is that it leverages existing IP management skills.
    As such, using socket coordinates to specify targets is what IP
    managers understand.  That doesn't mean we can't introduce additional
    concepts, but the users should be able to get going without them.
    
    Steph
    


Home

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