Subject: iscsi : OpParmreset

From: Santosh Rao <[email-masked]>
Date: Thu, 20 Sep 2001 12:19:04 -0700

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

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 21 Sep 2001 18:34:25 +0300

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 <[email-masked]>        
                    hp.com>              cc:                                            
                    Sent by:             Subject:     iscsi : OpParmreset               
                    owner-ips@ece.                                                      
                    cmu.edu                                                             

                    20-09-01 22:19                                                      
                    Please respond                                                      
                    to Santosh Rao                                                      

All,

" 30 OpParmReset

Comments ?

Thanks,
Santosh

 - santoshr.vcf

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Mon, 24 Sep 2001 12:36:24 +0100

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:[email-masked]]
Sent: Friday, September 21, 2001 4:34 PM
To: [email-masked]
Subject: Re: iscsi : OpParmreset

Santosh,

Julo

                    Santosh Rao

                    <santoshr@cup.       To:     IPS Reflector
<[email-masked]>        
                    hp.com>              cc:

                    owner-ips@ece.

                    cmu.edu

                    20-09-01 22:19

                    Please respond

                    to Santosh Rao

All,

" 30 OpParmReset

Comments ?

Thanks,
Santosh

 - santoshr.vcf

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 29 Sep 2001 08:39:16 +0300

Mallikarjun,

That is not a negotiation or a sequence reset.  It is only a bookmark
reset.  Bookmarks are used by the target if it has more data
than it can send in a single PDU (like on answer to SEndTargets) and
resetting it means only that the initiator does not want more data.

We could generalize it and demand that every negotiation sequence carry a
bookmark but I am afraid this would be confusing.

Julo

                    "Mallikarjun                                                                 
                    C."                  To:     ips <[email-masked]>                           
                    <[email-masked]       cc:                                                     
                    om>                  Subject:     Re: iscsi : OpParmreset                    
                    Sent by:                                                                     
                    owner-ips@ece.                                                               
                    cmu.edu                                                                      

                    29-09-01 05:06                                                               
                    Please respond                                                               
                    to cbm                                                                       

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.
[email-masked]

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 <[email-masked]>
>                     <[email-masked]       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.
> [email-masked]
>
> 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 <[email-masked]>
> >                     <[email-masked]       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.
> > [email-masked]
> >
> > 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        [email-masked]
> > >                     m,ex2)"                cc:
> > >                     <matthew_burbrid       Subject:     RE: iscsi :
> > OpParmreset
> > >                     [email-masked]>
> > >                     Sent by:
> > >                     [email-masked]
> > >                     u.edu
> > >
> > >
> > >                     24-09-01 13:36
> > >                     Please respond
> > >                     to
> > >                     "BURBRIDGE,MATTH
> > >                     EW
> > >                     (HP-UnitedKingdo
> > >                     m,ex2)"
> > >
> > >
> > >
> > > login is not happy then it should close the connection.  In FFP, as
> there
> > > is
> > > parameters that can be negoiated during FFP and not those restricted
to
> > the