|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iscsi : OpParmreset
Julian,
Thanks for incorporating the suggestion in 07-99
as the change log indicates.
However, I see that my option (b) for the initiator
is still allowed (empty text command abort)in 3.11.3.
Is there an unrelated reason for that?
Thanks.
--
Mallikarjun
Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com
Julian Satran wrote:
>
> 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: Sat Sep 29 02:17:20 2001 6855 messages in chronological order |