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

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

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

It's a defined term in SAM-3 (3.1.44) and specified in clause 6 of SAM-3.

Thanks,
--David

> -----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?
> 
> >[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.
> 
> 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
> 
>