Re: [storm] iSCSI drafts - T10 and T11 references

["Knight, Frederick" <[e-mail]>]

FK> INLINE

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:[e-mail]] 
Sent: Tuesday, September 25, 2012 1:34 PM
To: Black, David; Knight, Frederick; [e-mail]
Subject: RE: iSCSI drafts - T10 and T11 references

David,

Thanks for the suggestions. I am largely in agreement.

A couple of questions:

>2) [SAM2] and [SAM3] ought to be normative references

Don't know the related T10 history here, but I no longer see SAM-3 spec on the T10 web site. Any insights?

FK> Look down under the withdrawn standards.  BTW - should we really normatively referencing something that INCITS/T10 withdrew?

>[SAM-4] ought to be an informative reference

Was the concept of I_T nexus loss notification introduced in SAM-3 or SAM-4? (I can't tell because I don't see SAM-3... If the notification were introduced in SAM-4, that could make SAM-4 a normative reference.

FK> It was introduced in SAM-3.

	Fred

SAM-2 does not formally discuss I_T nexus loss notification, other than an oblique reference to the related check condition in clause 5.3.2, status precedence discussion.

Thanks.

Mallikarjun




-----Original Message-----
From: Black, David [mailto:[e-mail]]
Sent: Monday, September 24, 2012 8:37 AM
To: Knight, Frederick; Mallikarjun Chadalapaka; [e-mail]
Subject: RE: iSCSI drafts - T10 and T11 references

Fred,

Thank you for the discussion, particularly around the dependence on SAM-3.

In light of that, and a few other things (e.g., a strong preference that the iSCSI consolidated draft not reference work in progress), my recommendations on the T10 and T11 references are:

--- T10 (SCSI) ---

1) [SBC2] and [SPC3] are the current published standards; those should be the correct references for the iSCSI consolidated draft.  [SPC3] is clearly normative, but I think [SBC2] is (and ought to be) informative - [SBC2] is only cited once in what looks like an informative fashion in Appendix E.2:

	In addition, SCSI standards documents (such as [SAM2] and [SBC2])
	define additional clearing actions that may take place for several
	SCSI objects on SCSI events such as LU resets and power-on resets.

Moreover, there is no requirement to implement the SBC command set for all iSCSI implementations, whereas the SPC command set is a requirement for obvious reasons (P = Primary).

2) [SAM2] and [SAM3] ought to be normative references, in that we're drawing some concepts from [SAM-3].  OTOH, [SAM-4] ought to be an informative reference, as the TPGT text that is referred to in SAM-4:

> "[SAM2] and [SAM3] specifications note in their informative text that 
> TPGT value should be non-zero, note that it is incorrect.  A zero 
> value is allowed as a legal value for TPGT. This discrepancy currently 
> stands corrected in [SAM4]."

is an informative table footnote in an annex.  Further,

> Additionally, SAM4 reference is also used in citing the new ASC/ASCQ 
> codes that it defines, in Section 11.14.5 of the draft.

That new ASC/Q code's name does not occur in the body of SAM-4, so I would remove that second citation of SAM-4.

3) The [SAS] reference needs to be expanded ;-).  The current informative [SAS] reference needs to be replaced by references to SAS-2.1, SPL and SPL Amendment 1, see:

	http://www.t10.org/drafts.htm#SCSI3_SAS

4) OTOH, I recommend removing the [SRP] reference and related material, 'namely the definition of "SCSI RDMA Protocol" and the alternative expansion of the SRP acronym.  The SRP-2 standards project to update SRP was abandoned by T10 in 2005 due to lack of interest (see T10/05-097r0), leaving us with a vintage-2002 SRP document.

--- T11 (Fibre Channel) ---

The FC-FS reference ought to be replaced by a reference to the current published FS-FS-3 standard.

Thanks,
--David

> -----Original Message-----
> From: Knight, Frederick [mailto:[e-mail]]
> Sent: Sunday, September 23, 2012 6:38 AM
> To: Mallikarjun Chadalapaka; Black, David; [e-mail]
> Subject: RE: iSCSI drafts - T10 and T11 references
> 
> Interesting, I just came across a question in a related area (only for SAM-2).
> 
> RFC3720 was written in between SAM-2 and SAM-3; some concepts were 
> drawn from SAM-2, and some from SAM-3.
> 
> We have references to I_T NEXUS LOSS events in RFC3720.  The I_T Nexus 
> loss concept does not exist in SAM-2.  SAM-2 does include references 
> to RESERVE and RELEASE commands.  SAM-3 includes I_T Nexus loss, but 
> it has no reference to RESERVE state.  There are allusions in RFC3720 
> about the intersection of RESERVE/RELEASE and I_T NEXUS LOSS, but 
> there is nothing explicit.  RFC3720 references other documents (SAM2, 
> SAM3, SBC, SPC3), none of which address the situation.
> 
> Consider text such as the following:
> 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.
> 
> Is RESERVE state - explicit state?  When an I_T nexus is 
> reestablished, initiator-specific mode pages are preserved.  That 
> implies that an I_T nexus loss should be treated in the way that SAM-2 
> describes via CLEAR TASK SET (where mode pages and RESERVE state are 
> preserved).  If a session reestablishment caused saved mode pages to 
> be restored rather than the established initiator-specific mode pages 
> to be restored, then it would be like a LU reset (where the RESERVE 
> state is lost).  Is RESERVE state explicit state that is to be preserved?
> 
> Appendix E covers clearing effects during various events, but it never 
> mentions RESERVE state.
> 
> Section E.2 contains the following text:
> 
>   The only iSCSI protocol action that can effect clearing actions on
>   SCSI objects is the "I_T nexus loss" notification (Section 6.3.5.1
>   Loss of Nexus notification). [SPC3] describes the clearing effects
>   of this notification on a variety of SCSI attributes. In addition,
>   SCSI standards documents (such as [SAM2] and [SBC]) define
>   additional clearing actions that may take place for several SCSI
>   objects on SCSI events such as LU resets and power-on resets.
> 
> I could not find any text in SPC3 that describes these clearing 
> effects (I don't know if this SPC3 reference is incorrect, but at a 
> minimum, it is ineffective).  The SAM2 text for LU resets and power-on 
> resets is easily found, and clearly says that any RESERVE is released 
> in those cases.  As an aside, the reference to section 6.3.5.1 is a 
> circular reference).  The text in
> E.2 goes on:
> 
>   Since iSCSI defines a target cold reset as a protocol-equivalent
>   to a target power-cycle, the iSCSI target cold reset must also be
>   considered as the power-on reset event in interpreting the actions
>   defined in the SCSI standards.
> 
>   When the iSCSI session is reconstructed (between the same SCSI
>   ports with the same nexus identifier) reestablishing the same I_T
>   nexus, all SCSI objects that are defined to not clear on the "I_T
>   nexus loss" notification event, such as persistent reservations,
>   are automatically associated to this new session.
> 
> So, it is clear what happens to PERSISTENT RESERVE state, but not so 
> clear about RESERVE state.  It also states that all SCSI objects that 
> are defined to not clear on the I_T nexus loss are retained.  But 
> again, the only list I can find of what is cleared is here in this 
> Appendix, since SAM-2, SAM-3, SAM-4 are all silent on the interaction between RESERVE and I_T Nexus loss.
> 
> T10 has never had to deal with this because they removed RESERVE 
> before they added I_T Nexus loss.  However, iSCSI did not do that; we 
> discuss BOTH, but we fail to describe how they interact.  iSCSI also 
> has the feature of reestablishment of a session that does not exist in
> SAM-2 (SAM-2 was still parallel SCSI focused, where connections didn't 
> exist).  So again, if session reestablishment is examined in the light 
> of parallel SCSI, the intent would be to retain the RESERVE state.  Here is another section on the topic:
> 
> 6.3.5.1. Loss of Nexus Notification
> 
>   The iSCSI layer provides the SCSI layer with the "I_T nexus loss"
>   notification when any one of the following events happens:
> 
>      Successful completion of session reinstatement.
>      Session closure event.
>      Session timeout event.
> 
>   Certain SCSI object clearing actions may result due to the
>   notification in the SCSI end nodes, as documented in Appendix F. -
>   Clearing Effects of Various Events on Targets.
> 
> FWIW - the reference above is incorrect - there is no Appendix F in 
> the consolidated draft - this should be Appendix E (and also, BTW - 
> this is a circular reference).
> 
> So anyway, it seems like the intent was that session reinstatement 
> would preserve the RESERVE state across the I_T Nexus loss event.
> 
> So aside from the incorrect reference (and circular nature of it), any 
> thoughts on whether we should get explicit about this situation?
> Should we remain silent; should we tweak Appendix E along these lines 
> (or other lines that others might suggest):
> 
> 4.4.3.1. I_T Nexus State
> 
>   Certain nexus relationships contain an explicit state (e.g.,
>   initiator-specific mode pages, and RESERVE state) 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)....
> 
> 	Fred Knight
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Mallikarjun Chadalapaka
> Sent: Sunday, September 23, 2012 1:34 AM
> To: [e-mail]; [e-mail]
> Subject: Re: [storm] iSCSI drafts - T10 and T11 references
> 
> Hi David,
> 
> I have noticed this comment as I am working through all Last Call comments.
> 
> The references to SAM-3 and SAM-4 are keyed to this paragraph in Section 13.9:
> 
> "[SAM2] and [SAM3] specifications note in their informative text that 
> TPGT value should be non-zero, note that it is incorrect.  A zero 
> value is allowed as a legal value for TPGT. This discrepancy currently 
> stands corrected in [SAM4]."
> 
> Additionally, SAM4 reference is also used in citing the new ASC/ASCQ 
> codes that it defines, in Section 11.14.5 of the draft.
> 
> So, I believe references to all three SAM specs would continue to be 
> appropriate.
> 
> The current draft references FC-FS in discussing the NAA format in a 
> few places, so the current reference at the end is intentionally the 
> same. Is the older reference a problem? If so, I suppose we can 
> replace all references to FC-FS-4, but that seems to be still in early
> stages(0.1 spec posted on April 2012), so perhaps we should use FC-FS3?
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of [e-mail]
> Sent: Thursday, July 26, 2012 6:47 AM
> To: [e-mail]
> Subject: [storm] iSCSI drafts - T10 and T11 references
> 
> In making up the lists of T10 and T11 documents that are currently 
> referenced, some of those references don't look right to me, for example:
> 
> - T10: I'm not sure whether we need to reference SAM-2, -3 and -4.
> - T11: The FC-FS reference is out of date.
> 
> As part of dealing with the comments from IETF Last Call, we'll need 
> to go over all of the T10 and T11 references (and should check all the
> references) to make sure that they're up to date and necessary.
> 
> 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
> 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm