SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: ISID issue



    
    David,
    
    Comments in line.
    
    Jim Hafner
    
    
    Black_David@emc.com on 10/04/2001 06:56:46 PM
    
    To:   Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com
    cc:
    Subject:  RE: iSCSI: ISID issue
    
    
    
    Jim,
    
    > As I said in my last note, I'm willing to abandon use of the ISID for the
    > purposes of naming SCSI Initiator Ports and replace that with some text
    key
    > (so that ISIDs are removed from the dual role of identifying sessions AND
    > SCSI initiator ports).  But I haven't seen any specific proposal to that
    > effect and that addresses all the issues involved (as outlined also in my
    > last note).
    
    Ok, I think this is the key piece of your last note:
    
    > My point general point is
    > that I believe we need to have an unambiguous identifier of the SCSI
    > initiator port.  This is for reasons of
    > (a) persistent reserverations (as defined today) as well as for future
    >    extensions
    > (b) there is an obligation today (I think) for the transport layer to
    >    present to the OS layers above a "picture" of the SCSI Initiator
    Ports
    >    (isn't that what you keep saying goes in /dev stuff?).   Wedge
    drivers rely
    >    on this stuff too.
    > (c) some access control stuff (as defined by T10) but this is not a hard
    >    requirement
    
    I would do the following:
    
    (a) Set aside all notion of "future extensions" thereby removing a need
         for an externally visible iSCSI Initiator Port Name for this
    purpose.
    (b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID
         for this purpose.
    (c) Do nothing in the absence of a "hard requirement", and try to use
         the Initiator Node Name for this purpose rather than a Port Name.
    
    <JLH>
    If we do (b), then we're effectively having hte target "name/identify" SCSI
    Initiator Port.  OK, now, suppose the initiator has two sessions active to
    given target portal group.  On one (say with TSID=5) he sends persistent
    reserve registration and on another (say with TSID=7) he sends persistent
    reserve registration + reservation.  Now the target resets and the
    initiator cleans up context and starts up one new session.  What does the
    target do?  Does it assign TSID=5 or 7 or 9?  What logic does it use?  The
    order in which they were originally established?  Does it decide to use 7
    cause that had more 'stuff' associated with it?  Does it decide to use 9 so
    that it can forget/discard all the persistent reservation information?  The
    point here is that the target doesn't have any basis on which to bind the
    persistence property based on initiator port identifier.
    
    I just don't see how that works even in today's model.
    
    I don't know what you mean by (c).  What "purpose" are you talking about?
    </JLH>
    
    
    I would plan to deal with "future extensions" via a possible "future text
    key"
    to be specified after the "future extensions" are so that we have a
    concrete
    set of requirements and objectives to work to.  In the Interim, we can
    advise T10 that iSCSI strongly prefers reservations to be associated with
    Initiators, rather than Initiator Ports.
    
    > In fact, if we do find an alternative to the ISID for naming SCSI
    Initiator
    > Ports, then the ISID would be  irrelevant to the SCSI model (as the TSID
    is
    > now) and we won't need the ISID rule anymore (we'd need another rule for
    > port names, however).
    
    This includes one more reason:
    
    (d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to.
    
    As we discussed, and I think agreed, earlier, it is sufficient to assert
    the existence of such an entity in an iSCSI implementation (some sort of
    session data structure) for the purpose of mapping, but not provide an
    externally visible name that is independently useful outside the bounds of
    the specific iSCSI implementation.
    
    <JLH>
    But I also argued that existing OS's like to see some consistency (you've
    even said they put stuff in /dev) on their initiator ports.  If these are
    all driven by the target (in the sense of identification), then where can
    the iSCSI layer provide such consistency?
    </JLH>
    
    I think this leads to removing ISIDs and the ISID RULE without substituting
    a port name rule.  What goes wrong if this is done?
    <JLH>
    I hope my discussion above touches on what I see as going wrong.
    </JLH>
    
    > We can then ask if there is any value in the iSCSI
    > protocol for either the ISID or the TSID (as I did many many
    > months ago prior to this dicussion).
    
    I'm not seeing any.  We might be better off using that field to hold
    the Target Portal Group number; TSIDs would then only need to be unique
    to an Initiator within a Target Portal Group, and hence could be
    independently managed on a per-Portal Group basis, as opposed to the
    current TSID RULE that spans the entire Target (instead of configuring
    TSID ranges, one configures the Portal Group Number, which probably
    needs to be configured anyway).  This also makes any attempt to span
    Target Portal Groups or recover a session across Target Portal Groups
    immediately obvious to the Target (the first is forbidden, the
    second might work, but probably requires special handling at the Target,
    and may need some more protocol support).  One consequence of
    this field change would be to add Target Portal Group to (b) above, and
    that may actually be a good thing  as it forces exposure of this
    fundamental level of structure.
    
    <JLH>
    You're proposal to include the target portal group number in the TSID is an
    *implementation of configuring TSID ranges* for each target portal group,
    isn't it?  In fact, that would be how I would implement it my target (if I
    was building one, whether the spec said that it had this form or not -- and
    I'm implement my host driver pretty much the same way, via enumeration of
    drivers/devices  (which pretty much constitute initiator portal groups) as
    they are discovered/loaded by the OS).  Such an implementation guarantees
    compliance with the TSID RULE (and would do the same for the ISID RULE as
    well).  So, you haven't avoided it, you've simply spec'ed an implementation
    that meets the requirements.
    
    The proposal to include the target portal group tag in the message header
    (either within or separate from the TSID) is an independent issue from the
    ISID one.
    </JLH>
    
    
    
    John had previously had a bad reaction to my additional suggestion to
    change the TSID field size to 24 bits and the Portal Group field size to
    8 bits if the ISID to Target Portal Group change is made, but that's a
    second order issue at best (and one that I don't care that strongly about).
    
    
    Are we getting anywhere?
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    


Home

Last updated: Thu Oct 04 19:17:45 2001
7047 messages in chronological order