Subject: [storm] FW: SPC-2 reserve/release: Proposed text - version 4

From: "Black, David" <[email-masked]>
Date: Tue, 25 Sep 2012 17:38:44 -0400

version 4 changes:

More changes for Mallikarjun's comments, mostly a rewrite of the first
additional caveat bullet.  I've chosen not to reference Annex B of
SPC-4 as that seems a bit far afield for a SCSI transport standard
like iSCSI.

version 3 changes:

Responding to Mallikarjun's comments (plus some more edits) -

> 1) IMHO, opening sentence of "I_T nexus state includes reservation state"
> is a little too broad,

I removed that sentence, removed I_T Nexus from new section title and tweaked
the persistent reservation text to talk about state in general as opposed to
I_T Nexus state in particular.

> 2) Hard reset is not an LU reset - it is either an iSCSI Target Warm Reset,
> or (more likely) an iSCSI Target Cold Reset. In either case, any of the
> three resets should clear the reserve/release state.

I removed the word "hard" - as you noted, an LU reset is sufficient to remove
a reserve/release reservation.

> 3) Should use Time2Retain+Time2Wait, not Default Time2Wait

Brilliant minds think alike - I got to that one in version 2 ;-).

> 4) Session recovery does not necessarily preserve the I_T nexus state
> (recovery may not occur within Time2Wait+Time2Retain, and may not use
> the same ISID when it occurs), but session reinstatement and session
> continuation certainly should. 

I changed "session recovery" to "session reinstatement".

> 5) Should articulate the underlying linkage between Time2Retain
> (an iSCSI concept), and the reserve/release state (a SCSI state).

I believe I also got to that one in version 2.

version 2 changes:

I moved a paragraph break in response to Ralph's comments, and rewrote
the first additional consideration to reference the connection timeout
values in general.  I also found some minor problems that need correction
in Section 4.6.3.3 (see end of this message).

--- version 4 follows ---

<WG chair hat off>

Here's an initial attempt to propose text to deal with the reserve/
release topic in the consolidated iSCSI draft.  Please comment,
correct, suggest edits, etc.

The new text would be a new section 4.4.3.2 that would follow 4.4.3.1:

4.4.3.1. I_T Nexus State

  Certain nexus relationships contain an explicit state (e.g.,
  initiator-specific mode pages) that may need to be preserved by
  the device server [SAM2] in a logical unit through changes or
  failures in the iSCSI layer (e.g., session failures). In order for
  that state to be restored, the iSCSI initiator should reestablish
  its session (re-login) to the same Target Portal Group using the
  previous ISID. That is, it should perform session recovery as
  described in Chapter 6. This is because the SCSI initiator port
  identifier and the SCSI target port identifier (or relative target
  port) form the datum that the SCSI logical unit device server uses
  to identify the I_T nexus.

-------------------------------

First, for clarity, the following change should be made in the
above 4.4.3.1 text to better identify the recovery mechanism:

OLD
  That is, it should perform session recovery as
  described in Chapter 6.
NEW
  That is, it should recover the session via connection
  reinstatement as described in Section 6.3.4.
END

I believe that a lower-case "should" remains appropriate for this text.

-----------------------------------

NEW TEXT (second draft):

4.4.3.2. Reservations

  There are two reservation management methods defined in the SCSI
  standards, reserve/release reservations, based on the RESERVE and
  RELEASE commands [SPC2], and persistent reservations, based on the
  PERSISTENT RESERVE IN and PERSISTENT RESERVE OUT commands [SPC3].
  Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be
  used; persistent reservations SHOULD be used instead.

  State for persistent reservations is required to persist
  through changes and failures at the iSCSI layer that result in
  I_T Nexus failures, see [SPC3] for details and specific requirements.

  In contrast, [SPC2] does not specify detailed persistence
  requirements for reserve/release reservation state after an I_T
  Nexus failure.  Nonetheless, when reserve/release reservations are
  supported by an iSCSI target, the preferred implementation approach
  is to preserve reserve/release reservation state as part of the
  I_T Nexus state for iSCSI session reinstatement (see Section 6.3.5)
  or session continuation (see Section 6.3.6).

  Two additional caveats apply to reserve/release reservations:

  - When connection failure causes the iSCSI session to fail, and
      the session is not reinstated or continued, target retention
      of that session's reserve/release reservation state for an
      extended period of time may require the initiator to issue a
      reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order
      to remove that reservation state.  The Time2Wait and Time2Retain
      timeout values (see Section 7.55) apply to retention of reserve/release
      reservation state after iSCSI session failure because that state
      is part of the I_T Nexus state.  The need for resets in this
      scenario may be reduced by suitable selection of values for
      these two timeouts.

  - Reserve/release reservations may not behave as expected when
      persistent reservations are also used on the same logical unit;
      see the discussion of "Exceptions to SPC-2 RESERVE and RELEASE
      behavior" in [SPC4].

-----------------------

Reference impacts: both [SPC2] and [SPC3] need to be normative
references, but [SPC4] can be an informative reference.

-------------------------

I deliberately used "the preferred iSCSI implementation approach"
wording for reserve/release reservation state preservation requirements,
as SPC-2 is vague on this topic and I'm rather uncomfortable with placing
a requirement as strong as a "SHOULD" on an obsolete mechanism that
"SHOULD NOT" be used.

---------------

New problem in Section 4.6.3.3 - in this text:

   The Logout response indicates that the connection or session
   cleanup is completed and no other responses will arrive on the
   connection (if received on the logging out connection). In
   addition, the Logout Response indicates how long the target will
   continue to hold resources for recovery (e.g., command execution
   that continues on a new connection) in the text key Time2Retain
   and how long the initiator must wait before proceeding with
   recovery in the text key Time2Wait.

Time2Wait and Time2Retain are not text keys - they're binary fields
in the Logout Response PDU.  Two changes are in order:
	- "text key Time2Retain" -> "Time2Retain field"
	- "text key Time2Wait" -> "Time2Wait field"

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953              FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

---

From: Mallikarjun Chadalapaka <[email-masked]>
Date: Wed, 26 Sep 2012 01:39:00 +0000

Looks good to me overall. Two minor comments:

1) For 4.4.3.1, I have replaced the current sentence with the following one (instead of the proposed):

That is, it should reinstate the session via iSCSI session reinstatement (Section 6.3.5) or continue via session continuation (Section 6.3.6).

2) For proposed new text, I have tweaked the version 4 sentence below, keeping the existing implementations in view:

VERSION 4:
The Time2Wait and Time2Retain
      timeout values (see Section 7.55) apply to retention of reserve/release
      reservation state after iSCSI session failure because that state
      is part of the I_T Nexus state.

VERSION 5:
Instead, implementations are strongly encouraged to apply the 
      Time2Wait and Time2Retain timeout values (see Section 7.5) 
      to manage retention of reserve/release reservation state after 
     iSCSI session failure because that state is part of the I_T nexus state.

Thanks.

Mallikarjun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Tuesday, September 25, 2012 2:39 PM
To: [email-masked]
Subject: [storm] FW: SPC-2 reserve/release: Proposed text - version 4

version 4 changes:

More changes for Mallikarjun's comments, mostly a rewrite of the first additional caveat bullet.  I've chosen not to reference Annex B of
SPC-4 as that seems a bit far afield for a SCSI transport standard like iSCSI.

version 3 changes:

> 1) IMHO, opening sentence of "I_T nexus state includes reservation state"

I removed that sentence, removed I_T Nexus from new section title and tweaked the persistent reservation text to talk about state in general as opposed to I_T Nexus state in particular.

> 2) Hard reset is not an LU reset - it is either an iSCSI Target Warm 
> Reset, or (more likely) an iSCSI Target Cold Reset. In either case, 
> any of the three resets should clear the reserve/release state.

I removed the word "hard" - as you noted, an LU reset is sufficient to remove a reserve/release reservation.

> 5) Should articulate the underlying linkage between Time2Retain (an 
> iSCSI concept), and the reserve/release state (a SCSI state).

version 2 changes:

I moved a paragraph break in response to Ralph's comments, and rewrote the first additional consideration to reference the connection timeout values in general.  I also found some minor problems that need correction in Section 4.6.3.3 (see end of this message).

--- version 4 follows ---

<WG chair hat off>

Here's an initial attempt to propose text to deal with the reserve/ release topic in the consolidated iSCSI draft.  Please comment, correct, suggest edits, etc.

4.4.3.1. I_T Nexus State

First, for clarity, the following change should be made in the above 4.4.3.1 text to better identify the recovery mechanism:

OLD

NEW TEXT (second draft):

4.4.3.2. Reservations

-----------------------

Reference impacts: both [SPC2] and [SPC3] need to be normative references, but [SPC4] can be an informative reference.

I deliberately used "the preferred iSCSI implementation approach"
wording for reserve/release reservation state preservation requirements, as SPC-2 is vague on this topic and I'm rather uncomfortable with placing a requirement as strong as a "SHOULD" on an obsolete mechanism that "SHOULD NOT" be used.

---------------

Time2Wait and Time2Retain are not text keys - they're binary fields in the Logout Response PDU.  Two changes are in order:
	- "text key Time2Retain" -> "Time2Retain field"
	- "text key Time2Wait" -> "Time2Wait field"

Thanks,
--David

---

From: "Knight, Frederick" <[email-masked]>
Date: Wed, 26 Sep 2012 12:39:15 +0000

I'm concerned about this new link between Time2Wait and RESERVE state.  Such a link has not previously existed.  I don't think we should create such a linkage.

Section 4.6.3.3 includes:
.... In addition, the Logout Response indicates how long the target will continue to hold resources for recovery (e.g., command execution that continues on a new connection)....

This and many other places where Time2Wait and Time2Retain are discussed, the points all have to do with command continuation; no mention of I_T state, or RESERVE state, or mode pages, or anything else.

Section 7.5 says:
.... Time2Wait is the initial "respite time" before attempting an explicit/implicit Logout for the CID in question or task reassignment for the affected tasks (if any)....

Or, task reassignment of affected tasks; with no mention of I_T state.

Section 7.6 ties the termination of tasks to the Time2Wait / Time2Retain timers.  Section 11.14.5 makes the same statements about the task termination linkage to those timers.

Section 11.15.3 says those timers are "...the minimum amount of time, in seconds, to wait before attempting task reassignment.".

Section 8.3 defines Session State.  And there is one sentence that I can find in all 345 pages that associates that session state with these timers.  It is in section 11.15.4 where it says: If it is the last connection of a session, the whole session state is discarded after Time2Retain.

I don't see anywhere that these timers are associated with any SCSI state, or with the RESERVE state.  Attempting to tie RESERVE state to these timers is a NEW requirement.  Our goal here was specifically to NOT create any new requirements.

We do not want to impact existing iSCSI implementations.  Could we associate the action that occurred with the observable behavior the host sees?  I don't like putting SCSI layer stuff in a transport layer spec, but it should just be informative.  Something like:

If the initiator receives a UA: 29/00 or 29/01 or 29/04 then the RESERVE state has been lost.  (Maybe 29/04 belongs in a RESERVE state unknown list).

If the initiator receives a UA: 29/07 then the RESERVE state has been preserved.

I didn't list 29/02 or 29/03 or 29/05 or 29/06 since I view those as Parallel SCSI specific.  We can debate which items belong in which list, but would this kind of observable behavior approach be better than a new requirement?  FYI - I didn't invent this; I copied it from SAM-5r11 (sub-clause 6.3.4) where it states it as a requirement on the target -  that when an I_T NEXUS LOSS event occurs, if the state is retained, 29/07 is returned, and if the state is not retained, then 29/01 is returned.

We also don't want to create any new requirement now in this consolidated draft that conflicts with this SAM-5 text, since we will eventually have to comply with SAM-5 and its follow-ons.

Another approach would be to ignore this for the consolidated draft, and force it into the iSCSI-SAM draft - which references SAM-4 and SAM-5 where I_T Nexus loss is already defined and the above text already exists.

	Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallikarjun Chadalapaka
Sent: Tuesday, September 25, 2012 9:39 PM
To: Black, David; [email-masked]
Subject: Re: [storm] SPC-2 reserve/release: Proposed text - version 4

VERSION 4:

VERSION 5:

Thanks.

Mallikarjun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Tuesday, September 25, 2012 2:39 PM
To: [email-masked]
Subject: [storm] FW: SPC-2 reserve/release: Proposed text - version 4

version 4 changes:

version 3 changes:

version 2 changes:

--- version 4 follows ---

<WG chair hat off>

4.4.3.1. I_T Nexus State

OLD

NEW TEXT (second draft):

4.4.3.2. Reservations

-----------------------

---------------

Thanks,
--David

---

From: "Black, David" <[email-masked]>
Date: Wed, 26 Sep 2012 10:51:04 -0400

Fred,

> I don't see anywhere that these timers are associated with any SCSI state, or
> with the RESERVE state.  Attempting to tie RESERVE state to these timers is a
> NEW requirement.  Our goal here was specifically to NOT create any new
> requirements.

I think you have a point that this is too specific.  What if we just delete
mention of those timers?  The bullet in question could then simply say:

      to remove that reservation state.

That captures the primary concern that I wanted to alert implementers to.

> We do not want to impact existing iSCSI implementations.  Could we associate
> the action that occurred with the observable behavior the host sees?  I don't
> like putting SCSI layer stuff in a transport layer spec, but it should just be
> informative.

The text that follows explicitly lists the SCSI ASC/Q values (e.g., 29/07, in
hex).  That's something I'd prefer to avoid, e.g., as T10 could easily add
additional ASC/Q values that are relevant to this situation.

As an alternative, I suggest that we state the principle and point to SAM-4
for the details, e.g., add the following text to the end of 4.4.3.1:

   The specific Unit Attention condition that results from session
   re-establishment indicates whether or not nexus state was preserved,
   see Section 6.3.4 of [SAM4].

Would that be ok?

Thanks,
--David

> From: Knight, Frederick [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2012 8:39 AM
> To: Mallikarjun Chadalapaka; Black, David; [email-masked]
> Subject: RE: SPC-2 reserve/release: Proposed text - version 4
>
> I'm concerned about this new link between Time2Wait and RESERVE state.  Such a
> link has not previously existed.  I don't think we should create such a
> linkage.
>
> .... In addition, the Logout Response indicates how long the target will
> continue to hold resources for recovery (e.g., command execution that
> continues on a new connection)....
>
> This and many other places where Time2Wait and Time2Retain are discussed, the
> points all have to do with command continuation; no mention of I_T state, or
> RESERVE state, or mode pages, or anything else.
>
> Section 7.5 says:
> .... Time2Wait is the initial "respite time" before attempting an
> explicit/implicit Logout for the CID in question or task reassignment for the
> affected tasks (if any)....
>
> Section 7.6 ties the termination of tasks to the Time2Wait / Time2Retain
> timers.  Section 11.14.5 makes the same statements about the task termination
> linkage to those timers.
>
> Section 11.15.3 says those timers are "...the minimum amount of time, in
> seconds, to wait before attempting task reassignment.".
>
> Section 8.3 defines Session State.  And there is one sentence that I can find
> in all 345 pages that associates that session state with these timers.  It is
> in section 11.15.4 where it says: If it is the last connection of a session,
> the whole session state is discarded after Time2Retain.
>
> I don't see anywhere that these timers are associated with any SCSI state, or
> with the RESERVE state.  Attempting to tie RESERVE state to these timers is a
> NEW requirement.  Our goal here was specifically to NOT create any new
> requirements.
>
> We do not want to impact existing iSCSI implementations.  Could we associate
> the action that occurred with the observable behavior the host sees?  I don't
> like putting SCSI layer stuff in a transport layer spec, but it should just be
> informative.  Something like:
>
> If the initiator receives a UA: 29/00 or 29/01 or 29/04 then the RESERVE state
> has been lost.  (Maybe 29/04 belongs in a RESERVE state unknown list).
>
> I didn't list 29/02 or 29/03 or 29/05 or 29/06 since I view those as Parallel
> SCSI specific.  We can debate which items belong in which list, but would this
> kind of observable behavior approach be better than a new requirement?  FYI -
> I didn't invent this; I copied it from SAM-5r11 (sub-clause 6.3.4) where it
> states it as a requirement on the target -  that when an I_T NEXUS LOSS event
> occurs, if the state is retained, 29/07 is returned, and if the state is not
> retained, then 29/01 is returned.
>
> We also don't want to create any new requirement now in this consolidated
> draft that conflicts with this SAM-5 text, since we will eventually have to
> comply with SAM-5 and its follow-ons.
>
> Another approach would be to ignore this for the consolidated draft, and force
> it into the iSCSI-SAM draft - which references SAM-4 and SAM-5 where I_T Nexus
> loss is already defined and the above text already exists.
>
>       Fred
>
> That is, it should reinstate the session via iSCSI session reinstatement
> (Section 6.3.5) or continue via session continuation (Section 6.3.6).
>
> I moved a paragraph break in response to Ralph's comments, and rewrote the
> first additional consideration to reference the connection timeout values in
> general.  I also found some minor problems that need correction in Section
> 4.6.3.3 (see end of this message).
>
> Here's an initial attempt to propose text to deal with the reserve/ release
> topic in the consolidated iSCSI draft.  Please comment, correct, suggest
> edits, etc.
>
> First, for clarity, the following change should be made in the above 4.4.3.1
> text to better identify the recovery mechanism:
>
> OLD
> wording for reserve/release reservation state preservation requirements, as
> SPC-2 is vague on this topic and I'm rather uncomfortable with placing a
> requirement as strong as a "SHOULD" on an obsolete mechanism that "SHOULD NOT"
> be used.
>
> ---------------
>
> Time2Wait and Time2Retain are not text keys - they're binary fields in the
> Logout Response PDU.  Two changes are in order:

---

From: "Knight, Frederick" <[email-masked]>
Date: Wed, 26 Sep 2012 15:39:36 +0000

Yes, I think we've got it.  Since I can't define "an extended period of time", here's my take:

  - When connection failure causes the iSCSI session to fail, and
      the session is not reinstated or continued, target retention
      of that session's reserve/release reservation state
      may require an initiator to issue a
      reset (e.g., LOGICAL UNIT RESET, see section 11.5) in order
      to remove that reservation state.

	Fred

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2012 10:51 AM
To: Knight, Frederick; [email-masked]
Subject: RE: SPC-2 reserve/release: Proposed text - version 4

Fred,

> I don't see anywhere that these timers are associated with any SCSI 
> state, or with the RESERVE state.  Attempting to tie RESERVE state to 
> these timers is a NEW requirement.  Our goal here was specifically to 
> NOT create any new requirements.

I think you have a point that this is too specific.  What if we just delete mention of those timers?  The bullet in question could then simply say:

> We do not want to impact existing iSCSI implementations.  Could we 
> associate the action that occurred with the observable behavior the 
> host sees?  I don't like putting SCSI layer stuff in a transport layer 
> spec, but it should just be informative.

The text that follows explicitly lists the SCSI ASC/Q values (e.g., 29/07, in hex).  That's something I'd prefer to avoid, e.g., as T10 could easily add additional ASC/Q values that are relevant to this situation.

As an alternative, I suggest that we state the principle and point to SAM-4 for the details, e.g., add the following text to the end of 4.4.3.1:

Would that be ok?

Thanks,
--David

> I'm concerned about this new link between Time2Wait and RESERVE state.  
> Such a link has not previously existed.  I don't think we should 
> create such a linkage.
>
> .... In addition, the Logout Response indicates how long the target 
> will continue to hold resources for recovery (e.g., command execution 
> that continues on a new connection)....
>
> This and many other places where Time2Wait and Time2Retain are 
> discussed, the points all have to do with command continuation; no 
> mention of I_T state, or RESERVE state, or mode pages, or anything else.
>
> Section 7.5 says:
> explicit/implicit Logout for the CID in question or task reassignment 
> for the affected tasks (if any)....
>
> Section 7.6 ties the termination of tasks to the Time2Wait / 
> Time2Retain timers.  Section 11.14.5 makes the same statements about 
> the task termination linkage to those timers.
>
> Section 11.15.3 says those timers are "...the minimum amount of time, 
> in seconds, to wait before attempting task reassignment.".
>
> Section 8.3 defines Session State.  And there is one sentence that I 
> can find in all 345 pages that associates that session state with 
> these timers.  It is in section 11.15.4 where it says: If it is the 
> last connection of a session, the whole session state is discarded after Time2Retain.
>
> I don't see anywhere that these timers are associated with any SCSI 
> state, or with the RESERVE state.  Attempting to tie RESERVE state to 
> these timers is a NEW requirement.  Our goal here was specifically to 
> NOT create any new requirements.
>
> We do not want to impact existing iSCSI implementations.  Could we 
> associate the action that occurred with the observable behavior the 
> host sees?  I don't like putting SCSI layer stuff in a transport layer 
> spec, but it should just be informative.  Something like:
>
> If the initiator receives a UA: 29/00 or 29/01 or 29/04 then the 
> RESERVE state has been lost.  (Maybe 29/04 belongs in a RESERVE state unknown list).
>
> I didn't list 29/02 or 29/03 or 29/05 or 29/06 since I view those as 
> Parallel SCSI specific.  We can debate which items belong in which 
> list, but would this kind of observable behavior approach be better 
> than a new requirement?  FYI - I didn't invent this; I copied it from 
> SAM-5r11 (sub-clause 6.3.4) where it states it as a requirement on the 
> target -  that when an I_T NEXUS LOSS event occurs, if the state is 
> retained, 29/07 is returned, and if the state is not retained, then 29/01 is returned.
>
> We also don't want to create any new requirement now in this 
> consolidated draft that conflicts with this SAM-5 text, since we will 
> eventually have to comply with SAM-5 and its follow-ons.
>
> Another approach would be to ignore this for the consolidated draft, 
> and force it into the iSCSI-SAM draft - which references SAM-4 and 
> SAM-5 where I_T Nexus loss is already defined and the above text already exists.
>
>       Fred
>
> That is, it should reinstate the session via iSCSI session 
> reinstatement (Section 6.3.5) or continue via session continuation (Section 6.3.6).
>
> 2) For proposed new text, I have tweaked the version 4 sentence below, 
> keeping the existing implementations in view:
>
> VERSION 4:
> I removed that sentence, removed I_T Nexus from new section title and 
> tweaked the persistent reservation text to talk about state in general 
> as opposed to I_T Nexus state in particular.
>
> > 4) Session recovery does not necessarily preserve the I_T nexus 
> > state (recovery may not occur within Time2Wait+Time2Retain, and may 
> > not use the same ISID when it occurs), but session reinstatement and 
> > session continuation certainly should.
>
> values in general.  I also found some minor problems that need 
> correction in Section
> First, for clarity, the following change should be made in the above 
> 4.4.3.1 text to better identify the recovery mechanism:
>
> OLD
> SPC-2 is vague on this topic and I'm rather uncomfortable with placing 
> a requirement as strong as a "SHOULD" on an obsolete mechanism that "SHOULD NOT"
> be used.
>
> ---------------
>
> Time2Wait and Time2Retain are not text keys - they're binary fields in 
> the Logout Response PDU.  Two changes are in order:
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748

---

From: "Black, David" <[email-masked]>
Date: Wed, 26 Sep 2012 11:46:38 -0400

That text looks good to me, but I have one more minor change ...
... I'd prefer to put the second paragraph at the end of 4.4.3.1,
as it applies to all nexus state not just reservations:

Thanks,
--David

> Sent: Wednesday, September 26, 2012 11:40 AM

---

From: "Knight, Frederick" <[email-masked]>
Date: Wed, 26 Sep 2012 16:40:09 +0000

Agreed

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2012 11:47 AM
To: Knight, Frederick; [email-masked]
Subject: RE: SPC-2 reserve/release: Proposed text - version 4

That text looks good to me, but I have one more minor change ...
... I'd prefer to put the second paragraph at the end of 4.4.3.1, as it applies to all nexus state not just reservations:

Thanks,
--David

> > state, or with the RESERVE state.  Attempting to tie RESERVE state 
> > to these timers is a NEW requirement.  Our goal here was 
> > specifically to NOT create any new requirements.
>
> I think you have a point that this is too specific.  What if we just 
> delete mention of those timers?  The bullet in question could then simply say:
>
> > host sees?  I don't like putting SCSI layer stuff in a transport 
> > layer spec, but it should just be informative.
>
> The text that follows explicitly lists the SCSI ASC/Q values (e.g., 
> 29/07, in hex).  That's something I'd prefer to avoid, e.g., as T10 
> could easily add additional ASC/Q values that are relevant to this situation.
>
> As an alternative, I suggest that we state the principle and point to 
> SAM-4 for the details, e.g., add the following text to the end of 4.4.3.1:
>
> > will continue to hold resources for recovery (e.g., command 
> > execution that continues on a new connection)....
> >
> > explicit/implicit Logout for the CID in question or task 
> > reassignment for the affected tasks (if any)....
> >
> > Section 11.15.3 says those timers are "...the minimum amount of 
> > time, in seconds, to wait before attempting task reassignment.".
> >
> > last connection of a session, the whole session state is discarded 
> > after
> Time2Retain.
> >
> > state, or with the RESERVE state.  Attempting to tie RESERVE state 
> > to these timers is a NEW requirement.  Our goal here was 
> > specifically to NOT create any new requirements.
> >
> > host sees?  I don't like putting SCSI layer stuff in a transport 
> > layer spec, but it should just be informative.  Something like:
> >
> > RESERVE state has been lost.  (Maybe 29/04 belongs in a RESERVE 
> > state
> unknown list).
> >
> > SAM-5r11 (sub-clause 6.3.4) where it states it as a requirement on 
> > the target -  that when an I_T NEXUS LOSS event occurs, if the state 
> > is retained, 29/07 is returned, and if the state is not retained, 
> > then 29/01 is
> returned.
> >
> > consolidated draft that conflicts with this SAM-5 text, since we 
> > will eventually have to comply with SAM-5 and its follow-ons.
> >
> > SAM-5 where I_T Nexus loss is already defined and the above text 
> > already
> exists.
> >
> >       Fred
> >
> > reinstatement (Section 6.3.5) or continue via session continuation 
> > (Section
> 6.3.6).
> >
> > 2) For proposed new text, I have tweaked the version 4 sentence 
> > below, keeping the existing implementations in view:
> >
> > VERSION 4:
> >      iSCSI session failure because that state is part of the I_T 
> > nexus
> state.
> >
> >
> > Thanks.
> >
> > Mallikarjun
> >
> >
> > More changes for Mallikarjun's comments, mostly a rewrite of the 
> > first additional caveat bullet.  I've chosen not to reference Annex 
> > B of
> > like
> iSCSI.
> > I removed that sentence, removed I_T Nexus from new section title 
> > and tweaked the persistent reservation text to talk about state in 
> > general as opposed to I_T Nexus state in particular.
> >
> > > 2) Hard reset is not an LU reset - it is either an iSCSI Target 
> > > Warm Reset, or (more likely) an iSCSI Target Cold Reset. In either 
> > > case, any of the three resets should clear the reserve/release state.
> >
> > > state (recovery may not occur within Time2Wait+Time2Retain, and 
> > > may not use the same ISID when it occurs), but session 
> > > reinstatement and session continuation certainly should.
> >
> > I moved a paragraph break in response to Ralph's comments, and 
> > rewrote the first additional consideration to reference the 
> > connection timeout values in general.  I also found some minor 
> > problems that need correction in Section
> > SPC-2 is vague on this topic and I'm rather uncomfortable with 
> > placing a requirement as strong as a "SHOULD" on an obsolete 
> > mechanism that "SHOULD
> NOT"
> > be used.
> >
> > ---------------
> >
> > David L. Black, Distinguished Engineer EMC Corporation, 176 South 
> > St., Hopkinton, MA  01748

---

From: Julian Satran <[email-masked]>
Date: Wed, 26 Sep 2012 21:09:19 +0200

Fred,

I don't think there is any new requirement. Time2retain indicates that a session (an it nexus) exists. As long as the session exits you can't talk abut nexus loss - even if you have no connection active.

Julo

Sent from my iPad

---

From: Julian Satran <[email-masked]>
Date: Wed, 26 Sep 2012 21:25:51 +0200

as for time2wait whether you mention the linkage or not it exists in iSCSI.
associting state other than that mentioned in 3270 with the sessiom/it nexus is a thing that should be relegated to t10 as a target should not behave differently whenaccessed through iscsi or fcp as far as state is concerned. the only logic that could allow for a slightly different behavior is a link to the mechanism by which the trasport perceives the nexus loss. that may require to mention time2wait for iscsi.

Sent from my iPad

---

From: Julian Satran <[email-masked]>
Date: Wed, 26 Sep 2012 21:30:23 +0200

and overall i think that all the new text for reserve/release does more harm than good.
i would mention only that the state that must be maintained while the session is maintained includes the reseve/release and leave it to that.

Sent from my iPad