|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iscsi : OpParmreset
Mallikarjun,
What you are suggesting is:
abort for the initiator
reject for the target.
It is feasible but not nice.
Let me think if we can have a better alternative.
07-98 still has OpParmReset.
Julo
"Mallikarjun
C." To: ips <ips@ece.cmu.edu>
<cbm@rose.hp.c cc:
om> Subject: Re: iscsi : OpParmreset
Sent by:
owner-ips@ece.
cmu.edu
27-09-01 19:10
Please respond
to cbm
Julian,
> >From your answer it looks like you agree that we need a way to
reset/abort
> a negotiation
Sure, I agree we need a mechanism.
>but you object to the OpParmReset.
Not specifically. I was only concerned that there seem to be several
ways of aborting/terminating a negotiation. I can count three
mechanisms
for initiator -
a) Abort Task
b) Empty text command with TTT=0xffffffff
c) OpParmReset
And two for the target -
a) Timing out the bookmark state, and Reject ("no bookmark for
this ITT" - 0x09) the TTT.
b) OpParmReset
I suggest that we retain only the option-(a)'s for both, and
drop the rest. For this to happen, the case (b) for initiator
should probably be a Reject("Illegal bookmark") - since as you
say, it does seem ambiguous.
Regards.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com
Julian Satran wrote:
>
> Mallikarjun,
>
> >From your answer it looks like you agree that we need a way to
reset/abort
> a negotiation but you object to the OpParmReset.
> Abort task has the disadvantage that the target can't issue it (so that
> the target has no means to force an abort).
> An empty task request or response is ambiguous.
> We could introduce a binary field meaning goon/abort? Is that better
that
> OpParmReset (by which we can always introduce a richer semantics - like
> rest to default).
>
> Julo
>
>
> "Mallikarjun
> C." To: ips <ips@ece.cmu.edu>
> <cbm@rose.hp.c cc:
> om> Subject: Re: iscsi :
OpParmreset
> Sent by:
> owner-ips@ece.
> cmu.edu
>
>
> 27-09-01 03:26
> Please respond
> to cbm
>
>
>
> Julian,
>
> I assume you mean terminate/end a negotiation by "rest a
> negotiaion". If so, I can see two more ways to do the same -
> - aborting the task (changes from rev06 to rev07),
> - sending an empty text command with TTT=0xffffffff.
>
> Either should undo the results of the partial negotiation
> in FFP, as we described in "Negotiation failures" section.
> During the login, as Matthew pointed out, we don't seem to
> need OpParmReset either.
>
> Can you please confirm if you see the same choices? If so,
> I do not see the need for OpParmReset.
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
> Julian Satran wrote:
> >
> > OpParmReset is the only way we have now to rest a negotiation in FFP
> > (public or vendor specific).
> > The restriction about R2T is related to a deadlock that can result when
> you
> > change from no to yes.
> >
> > Julo
> >
> >
> > "BURBRIDGE,MATTH
> > EW To: Julian
> Satran/Haifa/IBM@IBMIL,
> > (HP-UnitedKingdo ips@ece.cmu.edu
> > m,ex2)" cc:
> > <matthew_burbrid Subject: RE: iscsi :
> OpParmreset
> > ge@hp.com>
> > Sent by:
> > owner-ips@ece.cm
> > u.edu
> >
> >
> > 24-09-01 13:36
> > Please respond
> > to
> > "BURBRIDGE,MATTH
> > EW
> > (HP-UnitedKingdo
> > m,ex2)"
> >
> >
> >
> > Is OpParmReset still needed now that there is no operational parameter
> > negotiation until after the security phase? Why would both sides
> > negoitiate
> > a set of parameters only for one side to reset. Surely if one side
> during
> > login is not happy then it should close the connection. In FFP, as
there
> > is
> > no way to re-negotiate (after the OpParmReset) again if one side is not
> > happy then should it not close the connection and start a new one.
> >
> > Also if in FFP, if OpParmReset is sent then does it just reset those
> > parameters that can be negoiated during FFP and not those restricted to
> the
> > login phase? If so would it be easier to negotiate those parameters
> using
> > the explicit name (e.g. InitialR2T) and remove the restriction of
> (example)
> > "Once set to no, it can not be set back to yes" - as this is what using
> > OpParmReset permits.
> >
> > Matthew
> >
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Friday, September 21, 2001 4:34 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : OpParmreset
> >
> > Santosh,
> >
> > The main purpose of this key was to explicitly cancel the effects of a
> > running negotiation and restart anew.
> > As the draft stands now there is no much difference between the two -
but
> > on basic principles the purposes are different (as you well stated).
We
> > may change the value to be:
> >
> > OpParmReset=<default|current>
> >
> > to accommodate both semantics.
> >
> > Julo
> >
> > Santosh Rao
> >
> > <santoshr@cup. To: IPS Reflector
> > <ips@ece.cmu.edu>
> > hp.com> cc:
> >
> > Sent by: Subject: iscsi :
OpParmreset
> >
> > owner-ips@ece.
> >
> > cmu.edu
> >
> > 20-09-01 22:19
> >
> > Please respond
> >
> > to Santosh Rao
> >
> > All,
> >
> > Please refer the definition of OpParmReset login key.
> >
> > " 30 OpParmReset
> >
> > OpParmReset enables an Initiator or Target to request the operational
> > parameters to be reset to the values they had before the negotiation."
> >
> > I suggest that the definition be re-worded to state that the
OpParmReset
> > enables an initiator or target to reset the operational parameters to
> > their DEFAULT VALUES. [instead of the current definition that states
> > that the parameters are reset to the values they had prior to the
> > current negotiation.]
> >
> > The current definition requires the initiator to maintain 2 sets of
> > operational parameter values, the current and the previous. In the case
> > where initiator is just booting up, if the target sets OpParmReset to
> > "yes", the initiator does not know what to set the op params to, since
> > it has lost its prior state information.
> >
> > Comments ?
> >
> > Thanks,
> > Santosh
> >
> > - santoshr.vcf
Home Last updated: Fri Sep 28 23:17:15 2001 6852 messages in chronological order |