Re: iscsi : OpParmreset

["Julian Satran" <Julian_Satran@il.ibm.com>]

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