Re: iSCSI: target reset revisited

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

Thank you for the clarification.  Sorry I got caught up in the section 
on SCSI Task Management Response, and didn't see the reference in Command
section.

Could you please add Target Warm Reset in the < ..> list you have 
in section 2.5 (right after the payload diagram), as a command 
requiring Task Management Response?  This is what tripped me up.

Thanks!
--
Mallikarjun 


Mallikarjun Chadalapaka
M/S 5601			
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com


>
>Mallikarjun,
>
>     1    Abort Task---aborts the task identified by the Referenced
>      Task Tag field.
>      2    Abort Task Set---aborts all Tasks issued by this initiator
>      on the Logical Unit.
>      3    Clear ACA---clears the Auto Contingent Allegiance
>      condition.
>      4    Clear Task Set---Aborts all Tasks (from all initiators)
>      for the Logical Unit.
>      5    Logical Unit Reset
>      6    Target Warm Reset
>      7    Target Cold Reset
>
>
>Satran                Standards-Track, May 2001                    26
>
>                                iSCSI                December 4, 2000
>
>
>   For the functions above a SCSI Task Management Response MUST be
>   returned, using the Initiator Task Tag to identify the operation for
>   which it is responding.
>
>
>"Mallikarjun C." <cbm@rose.hp.com> on 12/12/2000 01:00:56
>
>Please respond to cbm@rose.hp.com
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  iSCSI: target reset revisited
>
>
>
>
>Julian,
>
>To my surprise, I am finding that the latest iSCSI draft still
>does not require a response on a target reset.  We agreed in a
>previous email conversation on this list, that the "warm" version
>of the target reset requires a task management response.  I attach
>the email for reference.  I assume it is a typo and would be
>corrected in the next version.
>
>Thanks.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>M/S 5601
>Networked Storage Architecture
>Network Storage Solutions Organization
>Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>
>From: julian_satran@il.ibm.com
>X-Lotus-FromDomain: IBMIL@IBMDE
>To: ips@ece.cmu.edu
>Message-ID: <C1256951.005EE23C.00@d12mta02.de.ibm.com>
>Date: Tue, 5 Sep 2000 20:14:17 +0300
>Subject: Re: Target Reset handling
>Mime-Version: 1.0
>Content-type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Sender: owner-ips@ece.cmu.edu
>Precedence: bulk
>Status: RO
>X-Status:
>X-Keywords:
>X-UID: 827
>
>
>
>Mallikarjun,
>
>Is the C bit hidden in the CDB? We as a rule avoided examining the CDB
>(iSCSI never has to). If we can make it external then we are in wild
>agreement.
>
>Regards,
>Julo
>
>"Mallikarjun C." <cbm@rose.hp.com> on 05/09/2000 20:03:56
>
>Please respond to cbm@rose.hp.com
>
>To:   ips@ece.cmu.edu
>cc:    (bcc: Julian Satran/Haifa/IBM)
>Subject:  Re: Target Reset handling
>
>
>
>
>Julian,
>
>Thanks for the suggestion.
>
>I am in broad agreement with this kind of definition, if the
>rest of the folks accept it.  I would however suggest a single
>Target Reset task management function (in accordance with SAM-2),
>and provide the choice of a "cold-reset" with a "C" bit in the
>Task Management Command PDU.  Assuming that we do this, let me
>try to summarize our tentative agreement:
>
>o Target Reset task management requires a response, unless the
>  the C-bit is set in which case the sessions would be terminated
>  as well and no response can be expected.
>
>o A Unit Attention AER shall be reported to all currently logged-in
>  initiators, in accordance with the provisions contained in clauses
>  7.9 and 8.3.6 of SPC-2 (basically, to be reported only if agreed
>  in advance between the initiator and the LU).
>
>Regards.
>--
>Mallikarjun
>M/S 5601
>Networked Storage Architecture
>HP Storage Organization
>Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>
>>Mallikarjun,
>>
>>How about having two different function:
>>
>>target warm-reset (connections stay) and target cold-rest (connections get
>>also reset)?
>>
>>Julo
>>
>>"Mallikarjun C." <cbm@rose.hp.com> on 03/09/2000 06:07:07
>>
>>Please respond to cbm@rose.hp.com
>>
>>To:   ips@ece.cmu.edu
>>cc:    (bcc: Julian Satran/Haifa/IBM)
>>Subject:  Re: Target Reset handling
>>
>>
>>
>>
>>Julian,
>>
>>Let me try again, I was arguing that the protocol stack (I assume you
>>mean the state information in various layers by this) and the TCP
>>connections be *not* reset - since I do not see a need for the SCSI
>>transport mechanism to be reset/cleared in the context of "SCSI target
>>reset".  I would again request your attention on the FC precedent, and
>>the software expectations of a confirmed target reset.  Logging in after
>>an arbitrary "long time" and assuming the target reset to be complete is
>>simply unreliable.
>>
>>I do not see a need for a special "iSCSI reset".  I believe that the
>>SCSI target reset task management request is completely adequate to
>>address our requirements.  All I am proposing is a change in its current
>>definition in view of the various reasons I had already stated, and the
>>benefits of making this change (not the least of which is SAM-2
>>compliance).  Addition of a new reset mechanism would also defeat our
>>common goal to keep a fairly lean protocol.
>>
>>The question of security context needs to addressed regardless of the
>>SCSI transport behavior on a target reset.  If security context is being
>>designed as part of the transient operating environment (as opposed to
>>say, creating/modifying mode pages), then my first guess would be that
>>it has to be reset as well to initial values, on a target reset.  I am
>>not sure what you implied, but are you suggesting that the security
>>context cannot be reset with TCP connections living across a SCSI target
>>reset?  Or, did I totally miss something?
>>
>>Regards.
>>
>>Mallikarjun
>>M/S 5601
>>Networked Storage Architecture
>>HP Storage Organization
>>Hewlett-Packard, Roseville.
>>cbm@rose.hp.com
>>
>
>
>
>
>
>
>
>