Re: [storm] iSCSI version descriptors
Mallikarjun Chadalapaka <cbm@chadalapaka.com> Mon, 07 March 2011 22:12 UTC
Return-Path: <cbm@chadalapaka.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3555D3A6820 for <storm@core3.amsl.com>; Mon, 7 Mar 2011 14:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TndAgCzWgCPN for <storm@core3.amsl.com>; Mon, 7 Mar 2011 14:12:18 -0800 (PST)
Received: from snt0-omc3-s13.snt0.hotmail.com (snt0-omc3-s13.snt0.hotmail.com [65.55.90.152]) by core3.amsl.com (Postfix) with ESMTP id 9E8323A67B4 for <storm@ietf.org>; Mon, 7 Mar 2011 14:12:15 -0800 (PST)
Received: from SNT131-DS6 ([65.55.90.136]) by snt0-omc3-s13.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Mar 2011 14:13:29 -0800
X-Originating-IP: [131.107.0.84]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds694BF19F46C40BA6595D7A0C70@phx.gbl>
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: david.black@emc.com, storm@ietf.org
References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com>
Date: Mon, 07 Mar 2011 14:13:28 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNNzi+Ud0BWrbVV/rTxz5nboVM//JEehi3w
Content-Language: en-us
X-OriginalArrivalTime: 07 Mar 2011 22:13:29.0469 (UTC) FILETIME=[E36A9AD0:01CBDD14]
Subject: Re: [storm] iSCSI version descriptors
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 07 Mar 2011 22:12:22 -0000
David, In trying to determine what if any text needs to change in the consolidated spec after this discussion, I did a re-reading of this whole thread - up to DavidH's most recent note. I stumbled on the following: > When we take out a feature in the new iSCSI consolidated draft, the easiest > thing to do is allow a NotUnderstood response to the keys that negotiate > that feature. This should not pose a problem for unimplemented features, > but it would be a behavior change. The completely backwards-compatible > alternative is have the consolidated iSCSI draft list the keys used for > removed features and prohibit a NotUnderstood response to those keys > (Reject would be an acceptable alternative response). I do not believe the consolidated spec needs to change the current negotiation semantics. I suggest a third option: 1) When a feature is completely obsoleted (e.g. markers) relative to 3720, iSCSI consolidated spec requires that the corresponding keys be negotiated to "No" (e.g. OFMarker=No). 2) When a feature *option* is obsoleted (e.g. SPKM1 & SPKM2 for AuthMethod), the spec does nothing special. The existing iSCSI negotiation semantics are comprehensive enough that two spec-compliant implementations will negotiate to the correct result because the obsoleted options for that feature are not offered as negotiables. This should minimize the core protocol changes, and related impacts to existing interop tests. Comments are welcome. With the fast-approaching Prague deadline, I will go ahead with the spec'ing this option if I don't hear any disagreement on this by this Wednesday. Thanks. Mallikarjun -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: Thursday, October 21, 2010 10:15 PM To: storm@ietf.org Subject: [storm] iSCSI version descriptors One more time on this issue. This is for discussion - it's not an announcement of a decision. This is the only real issue that needs to be resolved to complete the new (SAM) features draft for iSCSI. Reminder: we need to define a set of small positive integer values to describe the iSCSI version starting with 0 = "no version claimed". After some private discussions, it appears that we need two additional version values beyond 0. The first observation is that the baseline should be at least RFC 3720 (original iSCSI) + RFC 5048 (Corrections and Clarifications). That would be version value 1. The next observation is that taking features out of the consolidated iSCSI draft may allow a visible behavior change. RFC 3720 has this to say about text keys for negotiation: All keys in this document, except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood. When we take out a feature in the new iSCSI consolidated draft, the easiest thing to do is allow a NotUnderstood response to the keys that negotiate that feature. This should not pose a problem for unimplemented features, but it would be a behavior change. The completely backwards-compatible alternative is have the consolidated iSCSI draft list the keys used for removed features and prohibit a NotUnderstood response to those keys (Reject would be an acceptable alternative response). If we're careful about this, the same version value can apply to 3720/5048 and the consolidated iSCSI draft. I'd suggest that we be careful, and the details of how can be worked out as we finalize the consolidated draft - I think we should have at least one more round of looking at features to remove. After that, we'll need a version value for the new (SAM) features draft additions. The result would be 3 version values: 0 = no version claimed 1 = 3720/5048 or new consolidated draft 2 = (3720/5048 or new consolidated draft) + SAM 4/5 features from the SAM draft. Comments? The SAM 4/5 features draft will expire while draft submission is closed for the Beijing meeting - if we can resolve this issue, the next version of that draft could be submitted shortly after draft submission opens again, and would probably go to WG Last Call shortly thereafter. 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
- Re: [storm] iSCSI version descriptors Paul Koning
- [storm] iSCSI version descriptors david.black
- Re: [storm] iSCSI version descriptors Knight, Frederick
- Re: [storm] iSCSI version descriptors david.black
- Re: [storm] iSCSI version descriptors david.black
- Re: [storm] iSCSI version descriptors David Harrington
- Re: [storm] iSCSI version descriptors Mallikarjun Chadalapaka
- Re: [storm] iSCSI version descriptors Mallikarjun Chadalapaka
- Re: [storm] iSCSI version descriptors david.black
- Re: [storm] iSCSI version descriptors david.black
- Re: [storm] iSCSI version descriptors Mallikarjun Chadalapaka
- Re: [storm] iSCSI version descriptors david.black