Re: [storm] iSCSI SAM update: login key

<Black_David@emc.com> Thu, 22 April 2010 23:34 UTC

Return-Path: <Black_David@emc.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 E28F13A689B for <storm@core3.amsl.com>; Thu, 22 Apr 2010 16:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4]
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 puj0rU7M-a8C for <storm@core3.amsl.com>; Thu, 22 Apr 2010 16:34:31 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 37A563A6781 for <storm@ietf.org>; Thu, 22 Apr 2010 16:34:29 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o3MNYGuL001922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 19:34:16 -0400
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 22 Apr 2010 19:34:09 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o3MNY8l5007371; Thu, 22 Apr 2010 19:34:08 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 19:34:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Apr 2010 19:34:07 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB025AD05D@CORPUSMX80B.corp.emc.com>
In-Reply-To: <SNT131-ds1804A1C2B9A036C2EB73B6A00B0@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI SAM update: login key
thread-index: AcrNFN17PQ3xD5CNTO+maRmCN0ae/gARsz8AAAVitKADBP1YwAF4XjIwAMK+zBA=
References: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com><SNT131-ds10A1204F54D78F9972EB8FA0220@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com><0beb01cad986$a0f0ef70$0600a8c0@china.huawei.com> <SNT131-ds1804A1C2B9A036C2EB73B6A00B0@phx.gbl>
From: <Black_David@emc.com>
To: <cbm@chadalapaka.com>, <ietfdbh@comcast.net>, <storm@ietf.org>
X-OriginalArrivalTime: 22 Apr 2010 23:34:08.0649 (UTC) FILETIME=[4E049F90:01CAE274]
X-EMM-EM: Active
Cc: Black_David@emc.com
Subject: Re: [storm] iSCSI SAM update: login key
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: Thu, 22 Apr 2010 23:34:33 -0000

<WG chair hat off>

I concur with Mallikarjun, as this is not about individual feature
negotiation - iSCSI has lots of text keys to negotiate individual
features, and it's straightforward to add more - see the iSCSI
Login/Text Keys Registry here:
http://www.iana.org/assignments/iscsi-parameters .

Rather, this is about putting in some low level changes in iSCSI (as a
SCSI transport) to match changes in SCSI architecture and functionality
since iSCSI was first defined.  The established practice in SCSI is to
use a single version descriptor value to report this sort of
functionality (see Annex D.8 in the current working draft of SPC-4).

Overall, I think "Level" is consistent with what this key is
negotiating, in large part because in iSCSI, separate "(independent)
features" ought to be handled by separate (independent) keys, for which
there are plenty of existing examples.  In Dave Harrington's example,
the (IMHO) right approach would be to define three text keys, one for
each of RFCs 7501, 7522, and 7599 ... using meaningful key names rather
than RFC numbers ;-).

Thanks,
--David


> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
Of Mallikarjun Chadalapaka
> Sent: Sunday, April 18, 2010 10:31 PM
> To: 'David Harrington'; storm@ietf.org
> Subject: Re: [storm] iSCSI SAM update: login key
> 
> Hi David,
> 
> I would guess that the iSCSI-equivalent of the bit string approach
would be
> a comma-separated list of RFC numbers exchanged as text key values
during
> the login dialog.
> 
> Personally, I guess I do not see the need for the flexibility to pick
and
> choose RFCs out of order.  My first reaction was that doing so might
not
> always be workable anyways if the later RFCs implicitly or explicitly
use
> the concepts or terminology defined in one of the earlier RFCs.  But I
guess
> other protocols obviously must have addressed this issue.
> 
> I agree with you though that "Level" has the "everything earlier is
> supported" connotation, and should we choose to make this a
non-requirement
> (although I am comfortable with the current approach), we need to
rename the
> key.
> 
> Mallikarjun
> 
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
Behalf Of
> > David Harrington
> > Sent: Sunday, April 11, 2010 7:53 AM
> > To: storm@ietf.org
> > Subject: Re: [storm] iSCSI SAM update: login key
> >
> > <as individual contributor>
> >
> > Level seems to imply that anything earlier is supported, so (using
> > rfc#s as levels for my example):
> > if there existed (independent) features in rfc 7501, 7522, and 7599,
> > then level=rfc7599 would imply that 7501 and 7522 MUST be supported
as
> > well?
> > And nothing could ever be not-backwards-compatible.
> > Maybe that is what the WG wants.
> >
> > I wonder if it might be more flexible to define an approach, such as
> > bits in a bit string, so different combinations could be supported:
> > 	bit 1: 7501
> > 	bit 2: 7522
> > 	bit 3: 7599
> >
> > so an implementation could support, for example, rfcs 7501 and 7599
> > but not 7522.
> > Many IETF protocols allow for this type of RFC mix-and-match
> > compliance flexibility.
> >
> > Or does the WG consider this flexibility undesirable?
> >
> > dbh
> >
> > > -----Original Message-----
> > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org]
> > > On Behalf Of Black_David@emc.com
> > > Sent: Saturday, March 27, 2010 1:52 AM
> > > To: cbm@chadalapaka.com; storm@ietf.org
> > > Subject: Re: [storm] iSCSI SAM update: login key
> > >
> > > Mallikarjun,
> > >
> > > That makes sense (decouple from PDU structure changes), and
> > > suggests that we need a key name that doesn't use "PDUFormat" ...
> > > ... How about iSCSIProtocolLevel ?
> > >
> > > It will be necessary to be conservative in defining new
> > > values - the requirement to publish a standards track RFC to
> > > define a new value should help with that.
> > >
> > > Thanks,
> > > --David
> > >
> > > > -----Original Message-----
> > > > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > > > Sent: Saturday, March 27, 2010 12:28 AM
> > > > To: Black, David; storm@ietf.org
> > > > Subject: RE: [storm] iSCSI SAM update: login key
> > > >
> > > > > This will be an IETF key whose values are assigned by
> > > IETF standards action
> > > > > (standards-track RFC); it is not linked to SAM versions
> > > (e.g., a new version
> > > > > of SAM is not a prerequisite to assigning the value 3).
> > > >
> > > > Decoupling this key from SAM numbering space is a good idea.
> > > >
> > > > I also suggest decoupling it from PDU structure changes.
> > > Any new iSCSI standards track RFC, whether
> > > > or not it extends/changes PDU format, should be able to
> > > claim a number by WG consensus.  Reasons for
> > > > claiming a new number could include things like:
> > > > 1) New feature introduction (e.g. new Opcodes, new TMF
> > > Codes, new Async codes)
> > > > 2) Major bug fix to the iSCSI protocol that affects end
> > > node processing
> > > > 3) Change in semantics to keep up with changing SCSI semantics
> > > > 4) A PDU Format enhancement
> > > > 5) TBD reason by WG consensus
> > > >
> > > > Reasons 1-3 may not have associated PDU format changes,
> > > unlike 4.  I suggest these should all be
> > > > grounds for the WG to consider assigning a number.
> > > >
> > > > Doing this allows implementations to negotiate a shared
> > > milestone at an RFC granularity (if that RFC
> > > > has a number), as opposed to feature-by-feature negotiation
> > > (e.g. TaskReporting="FastAbort") with some
> > > > gray areas that we had to resort to so far.
> > > >
> > > > Thanks.
> > > >
> > > > Mallikarjun
> > > >
> > > > > -----Original Message-----
> > > > > From: storm-bounces@ietf.org
> > > [mailto:storm-bounces@ietf.org] On Behalf Of
> > > > > Black_David@emc.com
> > > > > Sent: Friday, March 26, 2010 11:48 AM
> > > > > To: storm@ietf.org
> > > > > Cc: Black_David@emc.com
> > > > > Subject: [storm] iSCSI SAM update: login key
> > > > >
> > > > > Based on discussion in the Anaheim meeting, here's the
> > > proposal that emerged
> > > > > for the login key to negotiate usage of the new features
> > > in the iSCSI SAM
> > > > > update draft (draft-ietf-storm-iscsi-sam-00).
> > > > >
> > > > > Past concerns (that I can recall) about this have been:
> > > > > - Key needs to negotiate iSCSI PDU format/content changes
only.
> > > > > - Detecting device support or lack thereof for SCSI features
> > > > > 	should be handled at the SCSI level (e.g., via SCSI
> commands).
> > > > > - Using a SAM version number in this iSCSI key is not a good
> > idea.
> > > > > - Would like something that can accommodate future changes.
> > > > > - Changing the key name from what's in the draft may be
desired.
> > > > >
> > > > > The proposal that emerged is:
> > > > >
> > > > > The key name will be PDUFormatLevel.  It's a numeric (not
> > > boolean) key with
> > > > > two defined values:
> > > > > 	- 1 = Current iSCSI (all four RFCs - 3720, 3980, 4850
and
> > 5048,
> > > > > 		but no change to required vs. optional
features).
> > > > > 	- 2 = Current iSCSI plus features in update draft.
> > > > > Usage is Leading Only (LO), scope is Session Wide (SW).
> > > > > Default value is 1, result function is Minimum.
> > > > >
> > > > > This will be an IETF key whose values are assigned by
> > > IETF standards action
> > > > > (standards-track RFC); it is not linked to SAM versions
> > > (e.g., a new version
> > > > > of SAM is not a prerequisite to assigning the value 3).
> > > > >
> > > > > This key also provides a clean way to handle definition
> > > of iSCSI version
> > > > > descriptors in SPC-4:
> > > > > - 0960h would remain "iSCSI (no version claimed)"
> > > > > - The range 0961h-097Fh would be defined as 0960h + value
> > > > > 	of PDUFormatLevel key used by the device.
> > > > > That results in one place (IANA registry) covering both
> > > definitions (key &
> > > > > version descriptor).
> > > > >
> > > > > In order to support iSCSI version descriptors, we would
> > > ask IANA to put the
> > > > > values of the PDUFormatLevel key into a separate registry
> > > with its own URL,
> > > > > and then ask T10 to modify SPC-4.  The latter is not an
> > > immediate action - I
> > > > > would not anticipate bringing the SPC-4 proposal for that
> > > to T10 until after
> > > > > the RFC is published and the IANA registry is created.
> > > > >
> > > > > This was the sense of the room + WebEx in Anaheim.
> > > Absence of objection on
> > > > > the list will confirm the above as the approach to be
> > > taken (rough consensus
> > > > > of the storm WG).
> > > > >
> > > > > 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
> > >
> >
> > _______________________________________________
> > 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