iSCSI: Target Resets are Management Functions

["John Hufferd" <hufferd@us.ibm.com>]

Julian,
Target Resets are management functions, that is where they belong, not as
an iSCSI or SCSI action/command.  It is not like this is going to be part
of some automatic error recovery function.  Target Resets need and deserve
this function as part of administration management, it is up the vendors'
products to perform, or not, this function, with information they get (or
not) from an Admin interaction).  I do not think we should support it in
the normal iSCSI Protocols.  And we should not have to specify the problem
avoidance approaches  that the implementer SHOULD/MUST take to support this
function.  You will probably say that it s an implementation decision as to
how they avoid the problems, and that is what I am saying, and it belongs
to the vendors' Admin function to implement or not.

If it is a big enough problem for FC to take it out, with their limited
network domain, we certainly should do that also.

.
.
.
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/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...