Re: [storm] iSCSI SAM update: login key

"Mallikarjun Chadalapaka" <cbm@chadalapaka.com> Tue, 30 March 2010 17: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 137933A693B for <storm@core3.amsl.com>; Tue, 30 Mar 2010 10:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.169
X-Spam-Level:
X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 ou6lHBHskvla for <storm@core3.amsl.com>; Tue, 30 Mar 2010 10:12:49 -0700 (PDT)
Received: from snt0-omc1-s28.snt0.hotmail.com (snt0-omc1-s28.snt0.hotmail.com [65.55.90.39]) by core3.amsl.com (Postfix) with ESMTP id ED8BE3A67A5 for <storm@ietf.org>; Tue, 30 Mar 2010 10:12:48 -0700 (PDT)
Received: from SNT131-DS1 ([65.55.90.9]) by snt0-omc1-s28.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Mar 2010 10:13:17 -0700
X-Originating-IP: [15.251.201.70]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds17A17D8A2F5FEEC9234C6A01F0@phx.gbl>
From: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>
To: "'Julian Satran'" <julian.satran@gmail.com>, <Black_David@emc.com>
References: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com> <SNT131-ds10A1204F54D78F9972EB8FA0220@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com> <4BADAC54.10705@gmail.com> <SNT131-ds5790403C32823DD1AD5C9A01F0@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02163229@CORPUSMX80B.corp.emc.com> <9F004C34-312E-45D5-B868-8DAF62CBD43E@gmail.com>
In-Reply-To: <9F004C34-312E-45D5-B868-8DAF62CBD43E@gmail.com>
Date: Tue, 30 Mar 2010 10:13:15 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrPw3Ow0rqhdNZxRTCeRCywxoqlsQAZIGHA
Content-Language: en-us
X-OriginalArrivalTime: 30 Mar 2010 17:13:17.0131 (UTC) FILETIME=[49F371B0:01CAD02C]
Cc: Black_David@emc.com, storm@ietf.org
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: Tue, 30 Mar 2010 17:12:51 -0000

I tend to agree with David that "iSCSIProtocolLevel" is a reasonable name
given the precedent.

To Julian's point, just like ErrorRecoveryLevel, I suggest each value of
iSCSIProtocolLevel to be a logical superset of prior values - any deprecated
features should be automatically covered in this scheme assuming that each
such RFC that deprecates a feature requests a protocol level milestone.

I suggest the following verbiage to the new key description to make this
very clear:


Negotiation of iSCSIProtocolLevel key to a value claimed by an RFC indicates
that both negotiating parties are compliant to the RFC in question, and
agree to support the corresponding semantics on that iSCSI session.  An
operational value of iSCSIProtocolLevel=x on an iSCSI session requires that
the iSCSI protocol semantics on that iSCSI session be a logical superset of
the capabilities in all RFCs that have claimed values of iSCSIProtocolLevel
< x.


Thanks.

Mallikarjun



> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of
> Julian Satran
> Sent: Monday, March 29, 2010 9:43 PM
> To: <Black_David@emc.com>
> Cc: Black_David@emc.com; <storm@ietf.org>
> Subject: Re: [storm] iSCSI SAM update: login key
> 
> It was just cosmetics. Anyhow with error recovery level really meant
> level. I wonder if with protocol we want every level to include all
> the preceding levels (including some obsolition) - in which case level
> is appropriate or merely a combination of things in which case I would
> suggest bundle. Also if it level the negotiation is numeric while for
> a combination it is boolean.
> 
> Regards,
> Julo
> 
> On 30/03/2010, at 04:59, <Black_David@emc.com> wrote:
> 
> > <WG co-chair hat OFF>
> >
> > We already have ErrorRecoveryLevel, so I don't see a problem with a
> > second key that ends in "Level".
> >
> > Thanks,
> > --David
> >
> >
> >> -----Original Message-----
> >> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> >> Sent: Monday, March 29, 2010 8:15 PM
> >> To: 'Julian Satran'; Black, David
> >> Cc: storm@ietf.org
> >> Subject: RE: [storm] iSCSI SAM update: login key
> >>
> >> OK, I then suggest iSCSIProtocolTier
> >>
> >> I would be OK with iSCSIProtocolLevel as well.
> >>
> >> Glad to see the consensus, thanks.
> >>
> >> Mallikarjun
> >>
> >>> -----Original Message-----
> >>> From: Julian Satran [mailto:julian.satran@gmail.com]
> >>> Sent: Friday, March 26, 2010 11:57 PM
> >>> To: Black_David@emc.com
> >>> Cc: cbm@chadalapaka.com; storm@ietf.org
> >>> Subject: Re: [storm] iSCSI SAM update: login key
> >>>
> >>>  I would suggest gen instead of level (level has too much of a
> > value
> >>> connotation - at least it my part of the world :-))
> >>>
> >>> Julo
> >>>
> >>>
> >>> On 27/03/10 08:52, Black_David@emc.com wrote:
> >>>> 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