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

[Ralph Weber <[e-mail]>]

David,

I believe a paragraph break is needed as shown in the following:

>   Reserve/release reservations are obsolete [SPC3] and SHOULD NOT be
>   used; persistent reservations SHOULD be used instead.  [break] The 
> I_T Nexus
>   state for persistent reservations is generally required ...

The chances of confusion are high when a paragraph that begins
with a discussion of reserve/release reservations continues into
the persistent reservations territory.

Also please be aware that Annex B of SPC-4 describes the means
by which the use of reserve/release reservations can be adapted
to employ persistent reservations. I am not sure this an appropriate
informative reference for an RFC, but it seems worthy of mention
on this reflector.

All the best,

.Ralph

On 9/25/2012 10:44 AM, Black, David wrote:
> <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 (first 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 may require a hard reset (e.g., LOGICAL UNIT RESET,
>        see section 11.5) in order to remove that state when connection
>        reinstatement is not performed.  The DefaultTime2Wait value
>        can be used to limit this retention time period (see section 13.15).
>
>    - 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.
>
> 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
>
>