RE: iSCSI: login issue - partial consensus call

["Eddy Quicksall" <eddy_quicksall@ivivity.com>]

Millikarjun,

If, after a crash, the initiator does not have any state information, how
will it know the ISID?

Regarding the TSID, if we design this use for it, that will enforce the need
for the target to make it useful ... see, it would be up to the target as to
if it is unique or if it is unique only within this initiator.

Also, the TSID should be 32 bits. That would allow the target to more easily
provide uniqueness.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Thursday, September 06, 2001 8:53 PM
To: ips@ece.cmu.edu
Subject: Re: iSCSI: login issue - partial consensus call


Eddy,

Two comments -

- In a reboot-after-a-crash scenario (one case where the implicit
session
  logout - aka option A - would be useful), initiator may not have any
  old session state including the TSID.

- Current formulation is that TSIDs are not really guaranteed to be
  unique per initiator, nor even among multiple sessions with the same
  initiator (if each is to a different target portal group).

Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com


Eddy Quicksall wrote:
>
> I got a bit lost here but I think the purpose is to reset a session.
> Wouldn't it make it easier if we use the TSID instead of the ISID.
Since the
> target controls that and can issue a unique TSID to every initiator,
it
> could more easily do its job.
>
> Am I missing something?
>
> Eddy
>