Re: [storm] iSCSI Level and Version

"Knight, Frederick" <Frederick.Knight@netapp.com> Wed, 17 August 2011 05:13 UTC

Return-Path: <Frederick.Knight@netapp.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 E0DC521F86EA for <storm@ietfa.amsl.com>; Tue, 16 Aug 2011 22:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpWUg31hpD47 for <storm@ietfa.amsl.com>; Tue, 16 Aug 2011 22:13:38 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE04721F8A4F for <storm@ietf.org>; Tue, 16 Aug 2011 22:13:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,237,1312182000"; d="scan'208";a="571442333"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Aug 2011 22:14:26 -0700
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7H5EQDX014836; Tue, 16 Aug 2011 22:14:26 -0700 (PDT)
Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Aug 2011 22:14:25 -0700
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Aug 2011 01:14:24 -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: Wed, 17 Aug 2011 01:13:45 -0400
Message-ID: <AC32D7C72530234288643DD5F1435D5310C4A997@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <SNT131-ds1075B498B0A57BB28BD25AA0280@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI Level and Version
Thread-Index: Acxcirlk82lZzM1gTs6Zi3TFVeLecAADeY+g
References: <SNT131-ds1075B498B0A57BB28BD25AA0280@phx.gbl>
From: "Knight, Frederick" <Frederick.Knight@netapp.com>
To: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>, <storm@ietf.org>
X-OriginalArrivalTime: 17 Aug 2011 05:14:24.0008 (UTC) FILETIME=[8736F080:01CC5C9C]
Subject: Re: [storm] iSCSI Level and Version
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: Wed, 17 Aug 2011 05:13:42 -0000

The new SAM features draft changes the format of some PDUs.

The current Version-max/min/active are fields within a PDU.

The iSCSIProtocolLevel tells the end points which format to use for the
PDUs, so the end point can find the fields within the PDU.  This lets us
have different format PDUs AFTER the negotiation of this key.  The
creation of the iSCSIProtocolLevel key allows us to write future drafts
that make changes more radical than what the new SAM features draft
contains.

You need to know the iSCSIProtocolLevel to know which PDU format to use.
So this makes me wonder, if we should move the negotiation of
iSCSIProtocolLevel from the full feature phase to the login phase
(should the negotiation of iSCSIProtocolLevel come earlier)?  Might we
ever want to change the format of any of the PDUs used during login?

	Fred

-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] 
Sent: Tuesday, August 16, 2011 11:14 PM
To: storm@ietf.org
Subject: [storm] iSCSI Level and Version

In doing an internal review of the iSCSI Last Call drafts, someone asked
me
this.  I want to run this response by the larger WG to see if we're all
in
agreement.

Question: What is the difference between
Version-max/Version-min/Version-active values exchanged during the iSCSI
Login phase, and the negotiated value of iSCSIProtocolLevel key?

Answer: The V-* values agreed to during the Login process determine the
operating version of the iSCSI protocol, and announce if any other
versions
can be supported by either side.  The operational iSCSIProtocolLevel key
on
the other hand determines the specific protocol features that may be
used on
an iSCSI session, within the "Version-active" versioned iSCSI protocol.

If this sounds reasonable, it is worth capturing this clarification in
the
SAM-4 draft where this key is defined.

Thanks.

Mallikarjun



_______________________________________________
storm mailing list
storm@ietf.org
https://www.ietf.org/mailman/listinfo/storm