RE: iSCSI: login issue - partial consensus call

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

> In particular this enables independent agents within the same initiator to
> attempt a login without knowing all ISIDs in use by other agents.  Each
> agent would know the ISID of sessions it had successfully  established,
but
> not the ISIDs for sessions established by others.  It can use the ISIDs it
> knows to recover sessions it owns.  If an agent gets a  failure attempting
to
> establish a new session, it would pick a different ISID and 
> retry (or just quit), rather than disrupting a session of another agent.

The intent of the presentation on SCSI/iSCSI modeling, and the text in the
draft, is to illustrate how this example is not a recommended implementation
choice due to the probability of violating the SCSI/iSCSI rules pointed out.
If the "independant agents" had partitioned the ISID space, there would be
no collision on login and no time wasted.  Your illustrated implementation
could spend significant time "trying" ISID's in use by the "other agents".

However, I'm starting to have more sympathy with Julian's concerns due to
the apparent risks of different vendors' initiator implementations not
following the rules.

I just imagined having vendor A's HBA installed and happily servicing
applications, installing vendor B's "plug-n-play" implementation, and having
all A's sessions aborted cause B doesn't know how to play right :-(

Marj