RE: Target Reset handling

[Robert Snively <rsnively@Brocade.COM>]

I do not believe that the added complexity of a cold and hot 
reset is appropriate.  SCSI-2 had such a concept, and it was ultimately
determined that there was no benefit to it, and the complexity was
immense.

I strongly feel that the SCSI Target Reset should do exactly
no more and no less than the corresponding function does in all
other SCSI devices.

If a session/connection reset is required, it should be performed
by session/connection control mechanisms already defined by TCP/IP.
Its effect on the SCSI target should be defined, but may or may
not be the same as the SCSI Target Reset. FCP-2 provides some examples
of the kind of things that you may choose to reset in table 4.
 
No "C" bit should be used.

The session/connection reset should not be in the CDB or in the 
task management functions.

Bob

>  -----Original Message-----
>  From: Mallikarjun C. [mailto:cbm@rose.hp.com]
>  Sent: Tuesday, September 05, 2000 11:14 AM
>  To: ips@ece.cmu.edu
>  Subject: Re: Target Reset handling (fwd)
>  
>  
>  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
>  >
>  
>  
>