RE: iSCSI: reusing ISID for recovery

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

It would help to get your message thru if you could answer our requests for
an explanation of your thinking.  We have tried several times to explain our
logic (w/examples) but I haven't seen an example from you supporting a
scenario in which you see a problem.

If an initiator reboots, and has no context information, how can it know
whether or not a target has a pre-existing session?  Since there is no nice
way to know that, I would probably code my initiator to request a login with
the X bit set (but as Mallikarjun said, I don't like this overloading of the
X bit, it's a special case and makes the coding extra convoluted).  In your
preferred scenario, this would cause the target to reject the login "cause
there is no pre-existing session", and the initiator would re-issues the
login without the X bit set.  What have you saved anyone from here?  You've
just added latency to the login process.  And either way the initiator codes
it's login after reboot, there's a presumably equal probability of
encountering this extra exchange.

I still haven't seen a plausable example where it does harm to have a login
w/ ISID=n, TSID=0 close an existing session with this initiator.  I can see
no case where this would be the wrong decision.  If "this isn't what the
initiator intended", this is a defective initiator implementation and
closing the other session at least does no harm.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 29, 2001 10:46 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> Thanks - I started feeling bad. I could not get a message 
> through. Julo
> 
> "Dev" <deva@stargateip.com> on 29-08-2001 19:03:40
> 
> Please respond to <deva@stargateip.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Julian,
> 
> >But - as this is bound to bring
> >many an initiator writer to set always
> >the bit to "just cover for the case" I propose that the 
> command fails if
> >the X bit was on but there was no need for it to be on.
> 
> The only need to set the X-bit (when ISID, TSID=0) could be 
> to forcibly
> close a pre-existing session, if any in the target right?
> 
> I agree with this proposal, as this forces the initiator to issue the
> command
> with an X-bit only when there is an error (a session already exists).
> I also like that returning an error when there is no need to 
> set an X-bit,
> as it discourages the initiators to set the X-bit by default, 
> for opening
> a session.
> 
> Thanks
> 
> Deva
> Platys Communications.
> 
>