Re: [storm] iSCSI version descriptors (for SCSI SPC-4)

Mallikarjun Chadalapaka <cbm@chadalapaka.com> Wed, 22 September 2010 20:42 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 3D39B28C126 for <storm@core3.amsl.com>; Wed, 22 Sep 2010 13:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.719
X-Spam-Level:
X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, J_CHICKENPOX_33=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 qau-e9eQ0+gF for <storm@core3.amsl.com>; Wed, 22 Sep 2010 13:42:51 -0700 (PDT)
Received: from snt0-omc3-s38.snt0.hotmail.com (snt0-omc3-s38.snt0.hotmail.com [65.55.90.177]) by core3.amsl.com (Postfix) with ESMTP id 3EDFB28C124 for <storm@ietf.org>; Wed, 22 Sep 2010 13:42:51 -0700 (PDT)
Received: from SNT131-DS18 ([65.55.90.137]) by snt0-omc3-s38.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Sep 2010 13:43:18 -0700
X-Originating-IP: [131.107.0.103]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds18200FA5D5895F2DB143B5A0600@phx.gbl>
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: <david.black@emc.com>, <Frederick.Knight@netapp.com>, <storm@ietf.org>
References: <C2D311A6F086424F99E385949ECFEBCB01C74EFC@CORPUSMX80B.corp.emc.com> <AC32D7C72530234288643DD5F1435D53089106E4@RTPMVEXC1-PRD.hq.netapp.com> <SNT131-ds71316F14FD0848639C66FA0350@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E03D1A6CE53@MX14A.corp.emc <SNT131-ds15A68E0A6EF5FC683C4081A0600@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E03D1AEDEA9@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1AEDEA9@MX14A.corp.emc.com>
Date: Wed, 22 Sep 2010 13:43:17 -0700
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: AQJSALfQZOMZyP0iM4xt+lW6eaY6/wJ8qx92AphUHCQB4C08xwEoyPC5kdA4fRA=
Content-Language: en-us
X-OriginalArrivalTime: 22 Sep 2010 20:43:18.0892 (UTC) FILETIME=[C9E392C0:01CB5A96]
Subject: Re: [storm] iSCSI version descriptors (for SCSI SPC-4)
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: Wed, 22 Sep 2010 20:42:53 -0000

Markers and auth mechanisms are unimplemented per WG consensus so far, so
they alone should not be the reason for a distinct version # for
consolidated specification.

We have made a few minor changes here and there elsewhere in the draft -
mostly around iSCSI Node concept to accommodate a target and an initiator
node within it in order to cleanly explain XCOPY semantics.  Almost all
other editing is a result of the consolidation process.  We might though
make other TBD changes before we wrap up - in any case, as I said, it is
only a "to be safe" precaution given the size of the draft.  I do not yet
strongly feel about this one way or the other.

Mallikarjun

> -----Original Message-----
> From: david.black@emc.com [mailto:david.black@emc.com]
> Sent: Wednesday, September 22, 2010 1:03 PM
> To: cbm@chadalapaka.com; Frederick.Knight@netapp.com; storm@ietf.org
> Subject: RE: iSCSI version descriptors (for SCSI SPC-4)
> 
> So, far, I believe all the functionality that we've decided to remove in
the
> consolidated draft is unimplemented.  Assuming that remains the case, I'm
not
> clear on the rationale for a functional distinction between [3720, 5048
and
> friends] vs. the new consolidated specification.
> 
> Thanks,
> --David
> 
> 
> > -----Original Message-----
> > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > Sent: Wednesday, September 22, 2010 3:49 PM
> > To: Black, David; Frederick.Knight@netapp.com; storm@ietf.org
> > Subject: RE: iSCSI version descriptors (for SCSI SPC-4)
> >
> > Hi David,
> >
> > Thanks for circling back to this.
> >
> > Your outline looks good overall, I like the proposed ability to let
> > the relevant IETF WG choose the iSCSI version descriptors and
> > associated semantics - based on a "pre-approved" numbering space from
> > T10, albeit the "pre-approval" might in fact happen at the end as you
> > say once we have the RFC numbers and an established IANA registry.
> >
> > I have two specific comments:
> >
> > 1) To be safe, I think we need one more defined value for
> > iSCSIProtocolLevel:
> > 	0: No version claimed (legacy implementations)
> > 	1: RFC 3720+RFC 5048 (iSCSI protocol, with corrections and
> > clarifications)
> > 	2: RFC-iSCSI-consolidated (with obsoleted markers & auth mechanisms
> > and all other tweaks relative to previous baseline)
> > 	3: RFC-SAM-4 (with SAM-4 compliance support)
> >
> > 2) If the above looks reasonable, particularly the ordering (with
> > implied superset semantics), seems to me that the iSCSIProtocolLevel
> > key definition has to be in the RFC-iSCSI-consolidated for it to be
> > able to claim a smaller number (as smaller numbers indicate
chronological
> predecessors).
> >
> > Thanks.
> >
> > Mallikarjun
> >
> > > -----Original Message-----
> > > From: david.black@emc.com [mailto:david.black@emc.com]
> > > Sent: Monday, September 20, 2010 8:46 AM
> > > To: cbm@chadalapaka.com; Frederick.Knight@netapp.com; storm@ietf.org
> > > Cc: david.black@emc.com
> > > Subject: iSCSI version descriptors (for SCSI SPC-4)
> > >
> > > It's time to come back to this topic.
> > >
> > > I believe that what should happen is to have SPC-4 point to an IANA
> > registry for
> > > all iSCSI version descriptors other than the existing "(no version
> > claimed)"
> > > descriptor (might be SPC-5 by the time we get all the pieces in
place).
> > The
> > > reason for doing this is to put IETF in a position to create new
> > > version descriptors for iSCSI without having to ask T10 to do so
> > > (although, it
> > makes
> > > sense to ask T10 to reflect the currently-valid version descriptors
> > > for
> > iSCSI in
> > > each version of SPC).
> > >
> > > Getting this to happen requires some work.  For starters, note that
> > > the
> > existing
> > > 0x960 iSCSI version descriptor can be used by any version of iSCSI -
> > > "no
> > version
> > > claimed" means that no assumptions can be made about presence or
> > > absence
> > of
> > > functionality.  For that reason, my personal (not as WG chair)
> > > preference
> > is that
> > > we create a version descriptor for RFC 3720 + RFC 5048 as reflected
> > > in the
> > new
> > > combined iSCSI draft, in order to provide a means for an
> > > implementation to promise support for the corrections and
> > > clarifications in RFC 5048 - that descriptor should also promise
> > > support for NAA iSCSI names (RFC 3980) and
> > the
> > > Node Architecture key (RFC 4850).  Not using any iSCSI version
> > > descriptor,
> > or
> > > using the existing 0x960 version descriptor, doesn't declare absence
> > > of
> > support -
> > > the only valid inference that an application client (initiator) can
> > > make
> > is "don't
> > > know".  We do need to get to a conclusion on whether to define this
> > version
> > > descriptor.
> > >
> > > The actual mechanics for coordinating this across IETF and T10
> > > involve
> > several
> > > steps:
> > > (1) The "iSCSIProtocolLevel" key should be defined in the
> > > consolidated
> > iSCSI
> > > draft, including creation of an IANA registry for its values (range:
> > > 0 -
> > 31) and
> > > defining the first two values:
> > > 	0 - unknown (equivalent to a NotUnderstood response to the key)
> > > 	1 - 3720 + 5048, etc., as reflected in the consolidated iSCSI draft.
> > > I included 0 for completeness - it's not strictly necessary.  This
> > > moves
> > creation of
> > > that key from the SAM 4/5 features update draft to the main
> > > consolidated
> > draft
> > > (2) The new SAM-4/5 features draft then defines the value 2 and adds
> > > it to
> > that
> > > IANA registry.
> > > (3) As an interim measure, after WG last call is completed, we (that
> > probably
> > > means Fred and I) write a T10 proposal to create the version
> > > descriptors
> > 0x961
> > > and 0x962 (corresponding to the values 1 and 2 for the
> > "iSCSIProtocolLevel"
> > > key).  That makes both version descriptors usable, and provides an
> > opportunity
> > > for the (inevitable) T10 input on exactly how the values of the
> > > "iSCSIProtocolLevel" key are specified.
> > > (4) After the RFCs are published for both drafts (yes, I'm an
> > > optimist),
> > another
> > > T10 proposal then updates SPC-4 to cross-reference the IANA registry.
> > >
> > > Combining steps (3) and (4) at T10 would require both early creation
> > > of
> > the IANA
> > > registry and early assignment of the RFC numbers.  It's not
> > > immediately
> > clear to
> > > me that this should be done - we can figure out whether/how to do
> > > this at
> > the
> > > time when the first T10 proposal needs to be written.
> > >
> > > Comments?
> > >
> > > Thanks,
> > > --David
> > >
> > >
> > > > -----Original Message-----
> > > > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > > > Sent: Monday, March 08, 2010 2:06 AM
> > > > To: 'Knight, Frederick'; Black, David; storm@ietf.org
> > > > Subject: RE: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > > >
> > > > Agreed on the SAM-5 version descriptor.  I assume the new draft
> > > > will in addition reference SAM-4.
> > > >
> > > > On the iSCSI version descriptions, I actually think creating a
> > > > 3720+5048 version descriptor is a good start.  As Fred says,
> > > > 3720+existing
> > > > implementations will be initially not reporting this so the
> > > > initiator is left to other means to figure out the compliance
> > > > level (and iSCSI provides the hooks to discern that).  However, I
> > > > believe this new version descriptor will help provide clarity down
> > > > the road as existing implementations catch up to the standard - as
> > > > opposed to leaving it open-ended until all implementations catch
> > > > up to the SAM-5 draft (which
> > takes
> > > even longer to get to).
> > > >
> > > > So I guess my preference is to create a 3720+5048 version
> > > > descriptor, assuming it's OK to approach T10 any time in future
> > > > with a request to add additional milestones based on implementation
> feedback from the WG.
> > > >
> > > > Thanks.
> > > >
> > > > Mallikarjun
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
> > > > > Behalf Of Knight, Frederick
> > > > > Sent: Tuesday, March 02, 2010 10:20 AM
> > > > > To: Black_David@emc.com; storm@ietf.org
> > > > > Subject: Re: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > > > >
> > > > > I agree, we need to request a frozen SAM-5 version descriptor,
> > > > > and see what they say.
> > > > >
> > > > > I'm reluctant to create a new descriptor to indicate compliance
> > > > > with something old (3720+5048).
> > > > >
> > > > > All those existing implementations that support 3720+5048 will
> > > > > NOT have that descriptor.  What is an initiator to think?  How
> > > > > will the initiator tell an old compliant device that supports
> > > > > 3720+5048 with no descriptor from the new compliant device that
> > > > > supports 3720+5048 but has the descriptor?  My fear is a host
> > > > > that assumes that if the
> > > > > 3720+5048 descriptor you propose is NOT present, then the device
> > > > > 3720+must
> > > NOT be 3720+5048 compliant.
> > > > >
> > > > > I'm reluctant to punish existing compliant devices by creating a
> > > > > descriptor that they will not report.  The horse is already out
> > > > > of the barn, what good will it do to post a "please close the
door" sign?
> > > > >
> > > > > We should however, request that T10 create a descriptor that
> > > > > indicates compliance with the new SAM features draft (which
> > > > > therefore means
> > > > > 3720+5048+xxx; where xxx=the new SAM features RFC).  If the
> > > > > 3720+5048+device doesn't
> > > > > report this new descriptor, then you must use iSCSI mechanisms
> > > > > to determine if the device is 3720 only, or 3720+5048.
> > > > >
> > > > > 	Fred Knight
> > > > >
> > > > > -----Original Message-----
> > > > > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > > > > Sent: Monday, March 01, 2010 5:53 PM
> > > > > To: storm@ietf.org
> > > > > Subject: [storm] SCSI Version Descriptors - iSCSI and SAM-5
> > > > >
> > > > > <WG Chair Hat On>
> > > > >
> > > > > We have some interesting technical decisions to make around
> > > > > asking for some SCSI version descriptor values.  For those not
> > > > > familiar with them, a SCSI device can return up to 8 2-byte
> > > > > version descriptors in bytes 58-73 of standard INQUIRY data (see
> > > > > section
> > > > > 6.4.2 in SPC-3 or the latest draft of SPC- 4).  A version
> > > > > descriptor
> > value
> > > specifies both a standard and a revision.
> > > > > Version descriptor values are defined by explicit action at T10;
> > > > > this serves as an indirect control over which versions of
> > > > > standards to which a device can claim to comply, and discourages
> > > > > compliance with revisions that are unstable or otherwise
> > > > > unsuitable.  T10 only assigns version descriptors to drafts of
> > > > > standards that T10 believes
> > to be
> > > stable (e.g., suitable to implement from).
> > > > >
> > > > > The straightforward decision is that the iSCSI features update
> > > > > draft
> > > > > (draft-
> > > > > ietf-storm-iscsi-sam) will need to reference a stable version of
> > > > > the
> > > > > SAM-5 standard (under development) prior to the completion of
> > > > > SAM-5
> > work
> > > at T10.
> > > > I
> > > > > suggest that Fred Knight (editor of the draft) and I discuss
> > > > > this at next week's meeting of T10 (specifically, the CAP WG in
> > > > > T10) in a couple of weeks and bring the resulting recommendation
> > > > > to the storm WG list and the Anaheim meeting.  Based on what's
> > > > > in the current draft of SAM-5, T10 may assign a version
> > > > > descriptor, or recommend that we wait for some more things that
are
> known to be inbound.
> > > > >
> > > > > The more interesting decision is version descriptors for iSCSI.
> > > > > Currently, there's only a generic version descriptor value ,
> > > > > 0x960h "iSCSI (no version claimed)".  There are an additional 31
> > > > > descriptor values available to iSCSI, and so the question to the
> > > > > storm WG is -
> > what
> > > would we like to see defined?
> > > > >
> > > > > I have two initial suggestions:
> > > > > 1) I suggest asking that a version descriptor be defined for the
> > combination
> > > > > 	of RFC 3720 (iSCSI) and RFC 5048 (iSCSI corrections and
> > clarifications)
> > > > > 	to enable a device to claim that it has implemented RFC
5048.
> > > > > We
> > could
> > > > > 	add additional RFCs to this set, e.g., RFC 3980 for NAA
names,
> > although
> > > > > 	I'm not sure that's useful to know post-login.'
> > > > > 2) I strongly suggest *not* asking that a version descriptor be
> > defined
> > > > > 	for RFC 3720 by itself, as I'm concerned that such a
descriptor
> > would
> > > > > 	serve as a (small) disincentive to implement RFC 5048.
> > > > > Please comment on these.
> > > > >
> > > > > Thanks,
> > > > > --David
> > > > > ----------------------------------------------------
> > > > > David L. Black, Distinguished Engineer EMC Corporation, 176
> > > > > South St., Hopkinton, MA  01748
> > > > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > > > black_david@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
> > > >
> >
> >