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

["Black, David" <[e-mail]>]

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).

<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. I_T Nexus State: Reservations

  The state of an I_T Nexus includes SCSI reservation state.  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.

  The I_T Nexus state for persistent reservations is generally 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 - nonetheless,
  when reserve/release reservations are supported by an iSCSI target,
  the preferred implementation approach is to preserve reserve/release
  reservation state along with other I_T Nexus state for iSCSI session
  recovery or continuation via connection reinstatement.

  Two additional caveats apply to reserve/release reservations:

  - Retention of reserve/release reservation state for an extended
	period of time after connection failure may require a hard reset
      (e.g., LOGICAL UNIT RESET, see section 11.5) in order to remove
      that reservation state when connection reinstatement is not
      performed.  When reserve/release reservation state is retained
      after connection failure, the need for such hard resets may be
      reduced via suitable selection of the Time2Wait and Time2Retain
      timeout values that control the duration of that retention
      (see Section 7.5).
 
  - 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
[phone]              FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

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