RE: iSCSI: reusing ISID for recovery

["John Hufferd" <hufferd@us.ibm.com>]

Folks,
Following your notes, I think  that if an initiator does not know what it
is doing, rather then having a new semantic on Login, why not just Logout,
then re-Login.
Since this should only happen like "Never", if you have coded things well,
and the infrequency should mean that the extra hand shake is not a problem.

However,  if you do not know what your session's TSID is, you probably are
two screwed up to make even the above Logout work, so I think this is what
you are all trying to address.  That is,  we  need to have a method to blow
everything away and start again when the initiator has lost the TSID of its
Session.  This is why we have option A, and Option B.

So I think the issue here is do we add additional responses at boot up
time, or not.  (Quit frankly I do not think this is an important issue,
either way.) However, it is a consideration.  If mode B is used, the clean
up bit is available, and initiators that use it all the time, will usually
cause the Extra interaction to occur at boot, because the normal case would
be that things come up clean.  (Since I think we said that if things are
clean, an error response would be issued. Therefore, most of the time, the
extra response is going to happen).  If, as some have suggested, the right
way to code this is to use  the Clean up bit only when there is a rejection
of the Login, because of existing sessions, and require that the initiator
should come back with the Login again but this time with the Clean up bit
set. The argument is made that there will not normally  be any extra
interaction.  Just extra interactions when clean-up is needed. (This
approach has been called Option B.)  The other approach is known as Option
A.  It will implicitly start the Login and clear out any existing session
when the Login is issued.   There will never be extra responses with Option
A, and there will only be extra responses in option B when the Target
rejects the Login because of a existing session. The Option B clean-up
action will not happen often, and the code is not hard, but there is more
code, perhaps 100 lines.

Now the folks that support option A say that they will not have to do
anything special since they want the Login to always succeed and blow away
any other thing that might be going on.  It is clear that this has less
code and interaction at boot/Startup. (However 100 lines of code is not a
big deal anyway.)
It also seem to me that there is probably less code on the target since
they do not have to do inspection of whether or not sessions are active or
not, etc. They just blow them away if they exist.

So all this flapping has to do with whether we need to add (on either side)
some (perhaps small) amount of code so that we use to protect from a buggy
Initiator.

I think this is a Nit in the Draft and is needlessly divisive, over a small
amount of code.

There has also been stated the opinion that option B is needed when their
is more then one OS sharing the Link.  I do not think this applies since
there should be another iSCSI Initiator Name for each OS, and therefore it
is a different session and has nothing to do with the discussion at hand.

Therefore, since the simplification (less code) is on the side of option A,
and since this is really not important anyway, I suggest that all the B
folks roll over since you will not be able to convince the A folks anyway,
and since they do have a valid (small) argument that Option B requires more
complexity and lines of code.

So I recommend Option A, and lets move on.  This does not deserver the list
space, or the emotion  it has been given.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: hufferd@us.ibm.com