Re: [storm] iSCSI drafts - T10 and T11 references
"Black, David" <david.black@emc.com> Tue, 25 September 2012 19:37 UTC
Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4521F897A for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 12:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75aGD8TFg3yB for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 12:37:08 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DAE2321F8976 for <storm@ietf.org>; Tue, 25 Sep 2012 12:37:07 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PJb4TM025454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 15:37:05 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 25 Sep 2012 15:36:55 -0400
Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8PJasTU022642; Tue, 25 Sep 2012 15:36:54 -0400
Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 25 Sep 2012 15:36:54 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 25 Sep 2012 15:36:54 -0400
From: "Black, David" <david.black@emc.com>
To: Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "Knight, Frederick" <Frederick.Knight@netapp.com>, "storm@ietf.org" <storm@ietf.org>
Date: Tue, 25 Sep 2012 15:36:52 -0400
Thread-Topic: iSCSI drafts - T10 and T11 references
Thread-Index: Ac1rNRGDFlJk/LPPRq2a5Pa224AxSwuFP5jwAAlZtBAAPXLRYAA3F3tAAAQmzpAAADrtIAAAeVyw
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DE79521@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208DD94B1@MX15A.corp.emc.com> <E160851FCED17643AE5F53B5D4D0783A451D98FC@BL2PRD0610MB361.namprd06.prod.outlook.com> <FFEE311F0EC80C4EA64EC8757CAD0CD208EA277E@SACEXCMBX04-PRD.hq.netapp.com> <8D3D17ACE214DC429325B2B98F3AE7120DE79192@MX15A.corp.emc.com> <E160851FCED17643AE5F53B5D4D0783A451DBA78@BL2PRD0610MB361.namprd06.prod.outlook.com> <FFEE311F0EC80C4EA64EC8757CAD0CD208EA5FAE@SACEXCMBX04-PRD.hq.netapp.com> <E160851FCED17643AE5F53B5D4D0783A451DBACA@BL2PRD0610MB361.namprd06.prod.outlook.com>
In-Reply-To: <E160851FCED17643AE5F53B5D4D0783A451DBACA@BL2PRD0610MB361.namprd06.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] iSCSI drafts - T10 and T11 references
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Sep 2012 19:37:09 -0000
Yes, that's the right answer, as I had also missed T10's withdrawal of SAM-3. Thanks, --David > -----Original Message----- > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] > Sent: Tuesday, September 25, 2012 3:25 PM > To: Knight, Frederick; Black, David; storm@ietf.org > Subject: RE: iSCSI drafts - T10 and T11 references > > Yes, thanks Fred for pointing this out, I too had realized that SAM-3 was > withdrawn after I sent my previous note. > > IMO, it does not make sense to normatively reference a withdrawn T10 standard > in a new RFC. So my default plan now is to replace all SAM-3 references to > SAM-4, and leave the latter as a normative reference. David? > > Thanks. > > Mallikarjun > > > -----Original Message----- > From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] > Sent: Tuesday, September 25, 2012 12:19 PM > To: Mallikarjun Chadalapaka; Black, David; storm@ietf.org > Subject: RE: iSCSI drafts - T10 and T11 references > > FK> INLINE > > -----Original Message----- > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] > Sent: Tuesday, September 25, 2012 1:34 PM > To: Black, David; Knight, Frederick; storm@ietf.org > 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:david.black@emc.com] > Sent: Monday, September 24, 2012 8:37 AM > To: Knight, Frederick; Mallikarjun Chadalapaka; storm@ietf.org > 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:Frederick.Knight@netapp.com] > > Sent: Sunday, September 23, 2012 6:38 AM > > To: Mallikarjun Chadalapaka; Black, David; storm@ietf.org > > 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: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > > Of Mallikarjun Chadalapaka > > Sent: Sunday, September 23, 2012 1:34 AM > > To: david.black@emc.com; storm@ietf.org > > 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: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > > Of david.black@emc.com > > Sent: Thursday, July 26, 2012 6:47 AM > > To: storm@ietf.org > > 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 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > david.black@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm > > > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm > > > >
- [storm] iSCSI drafts - T10 and T11 references david.black
- Re: [storm] iSCSI drafts - T10 and T11 references Mallikarjun Chadalapaka
- Re: [storm] iSCSI drafts - T10 and T11 references Knight, Frederick
- Re: [storm] iSCSI drafts - T10 and T11 references Mallikarjun Chadalapaka
- Re: [storm] iSCSI drafts - T10 and T11 references Knight, Frederick
- Re: [storm] iSCSI drafts - T10 and T11 references Black, David
- Re: [storm] iSCSI drafts - T10 and T11 references brown, david (eng)
- [storm] RESERVE state - clearing effects Black, David
- Re: [storm] RESERVE state - clearing effects Ralph Weber
- Re: [storm] RESERVE state - clearing effects Roger Cummings
- Re: [storm] RESERVE state - clearing effects Black, David
- Re: [storm] RESERVE state - clearing effects Knight, Frederick
- Re: [storm] RESERVE state - clearing effects Knight, Frederick
- Re: [storm] RESERVE state - clearing effects Black, David
- Re: [storm] RESERVE state - clearing effects Julian Satran
- Re: [storm] RESERVE state - clearing effects Ralph Weber
- Re: [storm] RESERVE state - clearing effects Julian Satran
- Re: [storm] RESERVE state - clearing effects Black, David
- Re: [storm] RESERVE state - clearing effects Ralph Weber
- Re: [storm] iSCSI drafts - T10 and T11 references Milton Scritsmier
- Re: [storm] iSCSI drafts - T10 and T11 references Ralph Weber
- Re: [storm] iSCSI drafts - T10 and T11 references Mallikarjun Chadalapaka
- Re: [storm] iSCSI drafts - T10 and T11 references Black, David
- Re: [storm] iSCSI drafts - T10 and T11 references Knight, Frederick
- Re: [storm] iSCSI drafts - T10 and T11 references Mallikarjun Chadalapaka
- Re: [storm] iSCSI drafts - T10 and T11 references Black, David