Re: [storm] Plan for iSCSI work
"Hemal Shah" <hemal@broadcom.com> Tue, 28 June 2011 18:34 UTC
Return-Path: <hemal@broadcom.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 D0C6521F8686 for <storm@ietfa.amsl.com>; Tue, 28 Jun 2011 11:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 fCnO3HUawH+i for <storm@ietfa.amsl.com>; Tue, 28 Jun 2011 11:34:05 -0700 (PDT)
Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5021E21F8684 for <storm@ietf.org>; Tue, 28 Jun 2011 11:34:02 -0700 (PDT)
Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 28 Jun 2011 11:38:35 -0700
X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A
Received: from IRVEXCHCCR02.corp.ad.broadcom.com ([10.9.200.183]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 28 Jun 2011 11:33:31 -0700
From: Hemal Shah <hemal@broadcom.com>
To: Mallikarjun Chadalapaka <cbm@chadalapaka.com>, "david.black@emc.com" <david.black@emc.com>, "storm@ietf.org" <storm@ietf.org>
Date: Tue, 28 Jun 2011 11:32:39 -0700
Thread-Topic: [storm] Plan for iSCSI work
Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJQIRzTq9AgfEPyEC0X+ZOALMKXeKluOzE3CAEQD0gA==
Message-ID: <76DBE161893C324BA6D4BB507EE4C3849513370AB5@IRVEXCHCCR02.corp.ad.broadcom.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> <SNT131-ds2DE0F0F2022D63A4AD747A0760@phx.gbl> <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds117065D22D7BF8583485DBA0790@phx.gbl> <76DBE161893C324BA6D4BB507EE4C38495124C4828@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds219B987FD6FA0437A497FDA06D0@phx.gbl>
In-Reply-To: <SNT131-ds219B987FD6FA0437A497FDA06D0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 6214C0213B410223401-01-01
Content-Type: multipart/alternative; boundary="_000_76DBE161893C324BA6D4BB507EE4C3849513370AB5IRVEXCHCCR02c_"
Subject: Re: [storm] Plan for iSCSI work
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, 28 Jun 2011 18:34:10 -0000
Thanks Mallikarjun! I would still like to confirm my understanding of what you describe as "MUST implement, but MUST negotiate". Here is my understanding: 1. The implementation of TaskReporting is required and NotUnderstood response for TaskReporting key is not permitted based on the following text from RFC5048 and Section 6.2 of the consolidated draft: All keys defined in [RFC3720] MUST be supported by all compliant implementations; a NotUnderstood answer on any of the [RFC3720] keys therefore MUST be considered a protocol error and handled accordingly. 2. To enable FastAbort on a session, the negotiation of TaskReporting key is required. 3. Only when the TaskReporting=FastAbort functionality is supported, the protocol behavior specified in Section 4.2.3.4 is required to be implemented and exhibited. There are several places in the spec that indicate this type of conditionality. a. Section 4.2.3.5: If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 13.23)... b. Section 4.2.2.3.3: Whenever the TaskReporting key (Section 12.23 "Task Reporting") is negotiated to ResponseFence or FastAbort for an iSCSI session... c. Section 4.2.2.3.4: Whenever the TaskReporting key (Section 13.23) is negotiated to ResponseFence or FastAbort for an iSCSI session... 4. If TaskReporting=FastAbort functionality is not supported, then the protocol behavior specified in Section 4.2.3.4 is not required to be implemented or exhibited. If this is true, then the first sentence in section 4.2.3.4 is misleading and should be removed or prefixed with some text like "Only when the TaskReporting=FastAbort functionality is supported..". Hemal -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] Sent: Friday, June 17, 2011 3:32 PM To: Hemal Shah; david.black@emc.com; storm@ietf.org Subject: RE: [storm] Plan for iSCSI work Hi Hemal, During RFC 5048 effort, I recall we settled on the "MUST implement, but MUST negotiate" formulation after some list deliberation. With plain RFC 3720 semantics, there are some multi-initiator scenarios where multi-task aborts could essentially lead to target deadlocks, waiting on initiators on third-party sessions that may never respond. With the "Clarified" semantics in RFC 5048, the third-party deadlocks aren't a problem anymore, but issuing initiator could still experience timeouts and escalate error recovery - depending on the number of LUs, sessions, connections and tasks affected with the issued TMF. Escalated error recovery is usually something we want to avoid as it adds more delays/alerts/logs/failovers/failbacks etc. Finally, "Updated" semantics in RFC 5048 are meant to address this timeout problem - they permit targets to provide accelerated responses and allow them to deal with book-keeping/quiescing operations in a lazy fashion (which are the real culprits that trigger timeouts). Given all the above, the WG settled on FastAbort as a MUST-implement. The "MUST negotiate" part then is to enable backwards-compatibility with RFC 3720 implementations. At this point, I'd rather not loosen the Consolidated iSCSI draft requirement from what it is in RFC 5048. I suggest we leave it the way it is. Mallikarjun From: Hemal Shah [mailto:hemal@broadcom.com] Sent: Thursday, June 09, 2011 3:57 PM To: Mallikarjun Chadalapaka; david.black@emc.com; storm@ietf.org Subject: RE: [storm] Plan for iSCSI work Thanks Mallikarjun! The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the consolidated draft, the implementation of "FastAbort" feature is a MUST. >From the first paragraph text from Section 4.1.3 of RFC5048, the first sentence mandates that all iSCSI implementation comply to this section but the second sentence say that the requirement in this section is conditional to the negotiation of "FastAbort" key. Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. This is confusing. I think it will be better to remove the first sentence from 4.2.3.4 and clarify that the requirements in this section is conditional. I suggest rewording the first two sentences to below: iSCSI implementations may negotiate the TaskReporting (Section 9.1) key to "FastAbort" on an iSCSI session. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. Hemal -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] Sent: Friday, May 27, 2011 5:29 PM To: Hemal Shah; david.black@emc.com; storm@ietf.org Subject: RE: [storm] Plan for iSCSI work Hi Hemal, The text in this draft came verbatim from section 4.1.3 of RFC 5048. There have been no changes in this area. The new text (as well as the old text) requires the TaskReporting key to be negotiated to "FastAbort" before the multi-task abort semantics can be used on an iSCSI session. Thanks. Mallikarjun -----Original Message----- From: Hemal Shah [mailto:hemal@broadcom.com] Sent: Friday, May 27, 2011 4:51 PM To: Mallikarjun Chadalapaka; david.black@emc.com; storm@ietf.org Subject: RE: [storm] Plan for iSCSI work Mallikarjun and David, I noticed one problematic item in the consolidated draft. This item is the requirement to support FastAbort. This feature was already defined in the implementation guide, but it was optional. In this draft, it became a required feature MUST - see in section 4.2.3.4. Do you know why the requirement was changed in the consolidated draft? I would like to keep the requirement optional as stated in the implementation guide and not break backward compatibility. Hemal -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka Sent: Thursday, May 26, 2011 6:50 PM To: david.black@emc.com; storm@ietf.org Subject: Re: [storm] Plan for iSCSI work Hi David, The list of changes you have called out are already done in the latest draft. I assume then that you are suggesting that the list itself should be included in the next revision of the draft. Here's what I recall we have done so far: 1) iSCSIProtocolLevel specified as "1", and added a related normative reference to iSCSI-SAM draft 2) Markers and related keys were removed 3) SPKM authentication and related keys were removed 4) Added a new section on responding to obsoleted keys 5) Have explicitly allowed initiator+target implementations throughout the text 6) Clarified that implementations SHOULD NOT rely on SLP-based discovery 7) Added UML diagrams, and related conventions The above is of course in addition to consolidating the different RFCs, and making the related editorial changes. Thanks. Mallikarjun -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: Friday, May 20, 2011 2:49 PM To: storm@ietf.org Subject: [storm] Plan for iSCSI work I thought I'd offer some advance planning/warning on this, as the consolidated iSCSI draft (draft-ietf-storm-iscsi-cons) is large (over 300 pages). The current plan is to run a simultaneous WG Last Call on both this draft and the new features draft (draft-ietf-storm-iscsi-sam) starting in mid- June (probably the week of June 13, after I get back from a badly needed vacation). That WG Last Call will run longer than the typical 2-week time period, due to the total size of the drafts, but will end by July 5th at the latest so that the status of the drafts and the next steps are known prior to the T10 (SCSI standards) meetings during the week of July 11. As July 11th is also the draft cutoff deadline for the Quebec City IETF meetings, revised draft versions may not show up until that meeting week (week of July 24th). This is also a good point to announce that the storm WG will meet in Quebec City. I've only requested a 1-hour session, as we get most of our work done on the mailing list. Among the items for that meeting will be figuring out what to do with the RDMA extensions draft (despite its name, draft-ietf-storm- rdmap-ext-00, it's not currently an official work item for the storm WG). One thing that's missing from the consolidated iSCSI draft (and is a reason why we're going to need a -03 version) is the changes that it makes to the RFCs that it consolidates. Off the top of my head, the major changes are: - Removal of SPKM authentication - Removal of the Marker appendix - Removal of the SHOULD requirement for SLP implementation. Have I missed anything significant? The summary of this will need to be added to that draft. WG Last Call will be an opportunity (in fact the final opportunity) to discuss whether anything else should be removed from iSCSI, but there's no need to wait - I encourage people to review both drafts and post comments whenever they can. In parallel, work will get started on any iSCSI MIB changes that are needed. So far, I only see one MIB change - the iSCSIProtocolLevel from the new features draft needs to be added to the MIB, probably with a structure analogous to the iSCSI version support that's already in the MIB. Thanks, --David (storm WG co-chair) ---------------------------------------------------- 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] Plan for iSCSI work david.black
- Re: [storm] Plan for iSCSI work Mallikarjun Chadalapaka
- Re: [storm] Plan for iSCSI work Hemal Shah
- Re: [storm] Plan for iSCSI work Mallikarjun Chadalapaka
- Re: [storm] Plan for iSCSI work Hemal Shah
- Re: [storm] Plan for iSCSI work Mallikarjun Chadalapaka
- Re: [storm] Plan for iSCSI work Hemal Shah
- Re: [storm] Plan for iSCSI work Mallikarjun Chadalapaka
- Re: [storm] Plan for iSCSI work Pat Thaler
- Re: [storm] Plan for iSCSI work Mallikarjun Chadalapaka
- Re: [storm] Plan for iSCSI work Hemal Shah
- Re: [storm] Plan for iSCSI work david.black