SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iscsi: rev 05 - section 2.5.1 is incomplete



    
    Julo,
    
    You raise an interesting perspective on the desire to have an atomic target
    reset and to scope the use of that function to authorized initiators.
    Unfortunately, there isn't any way in either SAM or Access Controls to
    define the "initiators we don't want to allow...based on the authentication
    and/or accessId".  Access controls grant access to a device and a subset of
    logical units.  There is no "level of authority" that allows the target to
    distinguish a management entity from a non-management entity for any SAM
    task management function.   SAM has no such notions.  iSCSI could define
    such notions, but then why must the action be SAM's Target Reset (see
    "approaches" below).
    
    Also, I wasn't aware that a reservation was required to do a logical unit
    reset.
    
    Here's my perspective.
    1) In the multi-initiator environments, the Target Reset type function
    (warm or cold) should be handled through management interfaces, not by any
    host with access to a part of the device.  In fact, ANYTHING that impacts
    non-clustered/non-cooperating initiators in unsuspecting ways ought to have
    this property; this includes anything that smacks of management action.
    2) There are many reasons for such a function (for example, to clear
    networking interfaces for the device, reboot, etc.), but it should NOT be
    just to clear task sets; it should be done with extreme care and by an
    entity that sees the "bigger picture".
    3) The overhead of iterating a set of individual logical unit resets to
    clear task sets is minimal compared to the ill effects more global actions
    might have on other initiators.
    
    In short, I support disallowing Target Reset in iSCSI.
    
    If you want a "managed" form of this action, I see three approaches:
    a) define it as a iSCSI function (not a SAM function) and scope the rules
    on who/what/when/where/why.  That's a big rat hole and is what you suggest
    will be required somewhere.
    b) define it as a SCSI Access Controls service action requiring the
    management key.
    c) leave it to the vendor-specific management interfaces.
    In all cases however, the function is NOT SAM's Target Reset Task
    Management.
    
    Jim Hafner
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03-13-2001 04:27:19 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iscsi: rev 05 - section 2.5.1 is incomplete
    
    
    
    
    
    John,
    
    I respectfully disagree (and I said so in the T10 meeting too).  There are
    better ways to protect against Target Reset
    than to remove it from your command set. The Target Reset allows you to
    clean atomically all your LUs.
    If you are afraid about mistakes by unauthorized initiators we can leave it
    to the target to reject the command
    for unauthorized initiators.  To obtain the same effect without Target
    Reset you will have to do a sequence of operations including a reservation
    for all the units and that might not work out.
    
    I bet that they will end-up having to put the same function back through
    some management interface (SNMP?)
    and then have to deal with the synchronization.
    
    I suggest we leave the commands in and invent a reject-response for
    initiators we don't want to allow them to do it based on the authentication
    and/or accessId.
    
    Regards,
    Julo
    
    John Hufferd@IBMUS
    13/03/2001 12:18
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    From: John Hufferd/San Jose/IBM@IBMUS
    Subject:  Re: iscsi: rev 05 - section 2.5.1 is incomplete  (Document link:
          Julian Satran - Mail)
    
    Julian,
    based on the response that we got from Robert Elliott @ Compaq,  we should
    probably at least change the draft to  remove the Target Reset (Target Warm
    Reset and Target Cold Reset).  This is good news, since these things would
    have been to much of a problem for iSCSI to permit.  I do not really like
    the Logical Unit Resets either, but at least it should only effect the
    device you have a right to use, so the impact is a lot less of a problem
    there, and I think we can live with that.
    
    Rober said:
    Today, T10 approved 01-015r2.  For devices compliant with SAM-2 revision
    16,
    Logical Unit Reset is now mandatory and Target Reset is not.  Protocols are
    allowed to mandate Target Reset, make it optional, or not support it at
    all.
    
    In response, the SCSI RDMA protocol working group (defining SCSI over
    InfiniBand) voted to remove Target Reset support from that protocol.  See
    T10 document 01-108r0 for the (short) proposal.
    
    I recommend you do the same and remove both Target Warm Reset and Target
    Cold Reset task management functions from iSCSI.
    
    Other IP protocols don't offer similar resets - a web browser doesn't have
    a
    way to reset an http server, a NFS client cannot reset an NFS server, a
    telnet user cannot interfere with other telnet users.  iSCSI shouldn't be
    any different.
    
    John's email mentioned 4 task management functions, which included Logical
    Unit Reset, and Clear Task Set.  The Access Controls feature (by Jim
    Hafner;
    going into SPC-3 revision 1) can be used to prevent initiators from logging
    in and issuing Logical Unit Reset and Clear Task Set. ....
    ---
    Robert.Elliott@compaq.com
    Compaq Server Storage
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Internet address: hufferd@us.ibm.com
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 03/12/2001 11:31:08 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iscsi: rev 05 - section 2.5.1 is incomplete
    
    
    
    
    
    Will fix.
    
    It should read:
    
       For the <Clear Task Set>, the target MUST enter a Unit Attention
       Condition for all other attached initiators to inform them that all
       pending tasks are cancelled. After reporting the Unit Attention
       Condition the target MUST enter the ACA state for any initiator for
       which it had pending tasks.
    
       For the <Target Warm Reset> and <Target Cold Reset> functions, the
       target cancels all pending operations and are both equivalent to the
       Target Reset as specified by SAM-2.  The target MUST enter a Unit
       Attention Condition for all attached initiators notifying them that the
       target is being reset.
    
       In addition, for the <Target Warm Reset>, after reporting the Unit
       Attention Condition, the target enters the ACA state on all sessions and
       all LUs on which the condition was reported.
    
       In addition, for the <Target Cold Reset> the target then MUST terminate
       all of its TCP connections to all initiators (all sessions are
       terminated). However, if the target finds that it cannot send the
       required response or AEN, it MUST continue the reset operation and it
       SHOULD log the condition for later retrieval. The logging operation MUST
       be reported through the target MIB.
    
       Further actions on reset functions are specified in the relevant SCSI
       documents for the specific class of devices.
    
    
       Thanks,
       Julo
    
    Ralph Weber <ralphoweber@compuserve.com> on 13/03/2001 06:09:08
    
    Please respond to ENDL_TX@computer.org
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:
    Subject:  iscsi: rev 05 - section 2.5.1 is incomplete
    
    
    
    
    The following statement is only half true:
    
       For the <Clear Task Set>, if the SCSI control mode
       enables AE reporting, the target MUST send an
       Asynchronous Event to all other attached initiators
       to inform them that all pending tasks are cancelled.
    
    If the SCSI control mode [page] does not enable AE
    reporting, then the target MUST establish a unit
    attention condition for all other attached initiators.
    
    In fact, the target must establish a unit attention
    condition regardless of the contents of the SCSI
    control mode page.  At this is specified in SAM-2.
    What the control mode pages does is tell the target
    how to report that unit attention condition; via
    a Check Condition on the next command received, or
    via an asynchronous event report.
    
    Someone might read the iSCSI version 05 text as
    releasing them from the SAM-2 requirement, which
    I doubt will be helpful to the SCSI community
    at large.
    
    The same problem exists in the following 2.5.1
    text:
    
       For the <Target Warm Reset> and <Target Cold Reset>
       functions, the target cancels all pending operations
       and are both equivalent to the Target Reset as
       specified by SAM-2.  Provided that SCSI control mode
       enables AE reporting, the target MUST send an
       Asynchronous Event to all attached initiators
       notifying them that the target is being reset.
    
    FYI
    
    Ralph...
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

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