Re: [storm] iSCSI drafts - T10 and T11 references
Mallikarjun Chadalapaka <cbm@chadalapaka.com> Tue, 25 September 2012 17:34 UTC
Return-Path: <cbm@chadalapaka.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 3476B21F88C3 for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 10:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 FEn32SRFIMqA for <storm@ietfa.amsl.com>; Tue, 25 Sep 2012 10:34:37 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id B084221F887B for <storm@ietf.org>; Tue, 25 Sep 2012 10:34:36 -0700 (PDT)
Received: from mail48-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 25 Sep 2012 17:34:35 +0000
Received: from mail48-va3 (localhost [127.0.0.1]) by mail48-va3-R.bigfish.com (Postfix) with ESMTP id 794F5A009E; Tue, 25 Sep 2012 17:34:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.117; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -29
X-BigFish: PS-29(zz9371I146fI542M1432I4015I1447Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh137ah13b6h1155h)
Received-SPF: pass (mail48-va3: domain of chadalapaka.com designates 157.56.240.117 as permitted sender) client-ip=157.56.240.117; envelope-from=cbm@chadalapaka.com; helo=BL2PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ;
Received: from mail48-va3 (localhost.localdomain [127.0.0.1]) by mail48-va3 (MessageSwitch) id 1348594472428924_24040; Tue, 25 Sep 2012 17:34:32 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.253]) by mail48-va3.bigfish.com (Postfix) with ESMTP id 62DF9140047; Tue, 25 Sep 2012 17:34:32 +0000 (UTC)
Received: from BL2PRD0610HT004.namprd06.prod.outlook.com (157.56.240.117) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Sep 2012 17:34:30 +0000
Received: from BL2PRD0610MB361.namprd06.prod.outlook.com ([169.254.12.31]) by BL2PRD0610HT004.namprd06.prod.outlook.com ([10.255.101.39]) with mapi id 14.16.0190.008; Tue, 25 Sep 2012 17:34:29 +0000
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: "Black, David" <david.black@emc.com>, "Knight, Frederick" <Frederick.Knight@netapp.com>, "storm@ietf.org" <storm@ietf.org>
Thread-Topic: iSCSI drafts - T10 and T11 references
Thread-Index: Ac1rNRGDFlJk/LPPRq2a5Pa224AxSwuFP5jwAAlZtBAAPXLRYAA3F3tA
Date: Tue, 25 Sep 2012 17:34:28 +0000
Message-ID: <E160851FCED17643AE5F53B5D4D0783A451DBA78@BL2PRD0610MB361.namprd06.prod.outlook.com>
References: <8D3D17ACE214DC429325B2B98F3AE71208DD94B1@MX15A.corp.emc.com> <E160851FCED17643AE5F53B5D4D0783A451D98FC@BL2PRD0610MB361.namprd06.prod.outlook.com> <FFEE311F0EC80C4EA64EC8757CAD0CD208EA277E@SACEXCMBX04-PRD.hq.netapp.com> <8D3D17ACE214DC429325B2B98F3AE7120DE79192@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120DE79192@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.174.24]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: chadalapaka.com
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 17:34:38 -0000
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: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