Re: Target Reset handling (fwd)

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

Apologies if this is a second copy, I had not seen my copy of
this posting or on the web archive even after more than an hour....
--
Mallikarjun 


Forwarded message:

Date: Tue, 05 Sep 2000 10:03:56 PDT
To: ips@ece.cmu.edu
Subject: Re: Target Reset handling
In-Reply-To: <C1256950.001C76C2.00@d12mta02.de.ibm.com>; from "julian_satran@il.ibm.com" at Sep 4, 100 8:08 am
Status: RO

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
>