Re: iSCSI: multiple sessions b/n a pair of WWUIs.

["Jim Hafner" <hafner@almaden.ibm.com>]

Santosh,

Comments in line <JLH> ... </JLH>

Jim Hafner


Santosh Rao <santoshr@cup.hp.com>@cup.hp.com on 05-09-2001 08:54:54 AM

Sent by:  santoshr@cup.hp.com


To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.



Jim,

I agree that the only requirement is uniqueness of ISID among all the
sessions to a given target node. Maintaining uniqueness across all
targets only extends compliance to this requirement a step further and
does not violate it.

<JLH> Correct, it does not violate it and that's all that matters.  Do this
if you want, it's your implementation :-{) </JLH>

All we are debating is David's suggestion that a note could be added to
indicate that implementations may choose to apply this uniqueness across
all target nodes so as to use the ISID as a target lookup mechanism.

<JLH> I'm beginning to believe strongly that such a note is NOT a good
thing as it implies a preferred implementation and (a) that's not the job
of the spec and (b) we haven't hashed out all the possible issues to be
sure we would be recommending a "best" implementation (and such hashing is
NOT the job of this reflector). </JLH>

If there is strong resistance against adding such a note, then, let us
omit it. [as long as the spec does'nt preclude usage of ISID as unique
across all targets].

<JLH> As I said, I'm moving rapidly to "strong" against.   I think the spec
(and any related document or note) currently does not say (and agreeably
shouldn't say) that the ISIDs must be reused in any particular way.  That
option would be simply falling on the other side of the implementation
fence.  The spec might make a note that says that multiple sessions
handlers within a given iSCSI Node sharing a common iSCSI Name should
coordinate their use of ISIDs (carve the name space between them) to avoid
rejected login by one session handler because it reused an ISID already in
use by another session handler.  But that's about all it should say.</JLH>

Regards,
Santosh


Jim Hafner wrote:
>
> Santosh,
>
> As I've said, I agree with the sentiment, but that is not the only
> implementation option.  For example, why can't the database index on the
> pointer to the data structure that has the names, etc, or hash on the
names
> or a million other things.  We shouldn't spec implementations, only
> interoperability requirements.
>
> Jim Hafner
>
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 05-08-2001 11:03:27 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.
>
> Douglas Otis wrote:
>
> >  The usefulness of ISID is also
> > diminished if the client is not expected to maintain this value as
unique
> > across all Targets.
>
> I agree with the above and have stated to similar effect in my response
> to Matt. A practical usage of ISID within an initiator node name space
> is to assign it as unique across all targets, allowing the same ISID to
> be used as a lookup key of the session for any given target port/node.
>
> Not applying uniqueness in ISID assignment across all targets would then
> require initiators to implement a second key mechanism for target
> lookup.
>
> - Santosh