[storm] iSER - discussion

<david.black@emc.com> Wed, 23 June 2010 21:16 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 71E6C3A6994 for <storm@core3.amsl.com>; Wed, 23 Jun 2010 14:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.646
X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id JeHKUKVjUzZU for <storm@core3.amsl.com>; Wed, 23 Jun 2010 14:16:05 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id B59663A69E4 for <storm@ietf.org>; Wed, 23 Jun 2010 14:16:03 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o5NLGAFC018266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Wed, 23 Jun 2010 17:16:10 -0400
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Wed, 23 Jun 2010 17:16:07 -0400
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o5NLG1IC004674 for <storm@ietf.org>; Wed, 23 Jun 2010 17:16:06 -0400
Received: from CORPUSMX80B.corp.emc.com ([]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 17:16:04 -0400
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Jun 2010 17:16:03 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB02ED5A34@CORPUSMX80B.corp.emc.com>
Thread-Topic: iSER - discussion
Thread-Index: AcsTGUlBil1KwxobT2GKTr5fE1bKug==
From: <david.black@emc.com>
To: <storm@ietf.org>
X-OriginalArrivalTime: 23 Jun 2010 21:16:04.0279 (UTC) FILETIME=[49C29470:01CB1319]
X-EMM-EM: Active
Subject: [storm] iSER - discussion
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, 23 Jun 2010 21:16:17 -0000

Mike Ko's been waiting patiently for discussion of the iSER draft, so here goes ... see Section 14 of the iSER draft (draft-ietf-storm-iser-01.txt).

Item 1 (allow open in zero-copy mode in addition to "normal" mode) and Item 2 (observe segment length limits in both directions for NOP data) seem ok to me.

Items 3 and 4 add text keys (MaxAHSLength and WriteAddressForSolicitedDataOnly) to negotiate the changes.  IANA needs to be instructed to register these keys in the iSCSI Login/Text Keys at http://www.iana.org/assignments/iscsi-parameters .  In addition, the [iSER] reference in that registry for the existing iSER keys is wrong, and IANA needs to be instructed to update it to the RFC that results from this draft.  Both of these need to go into the currently-empty IANA Considerations section of the draft (Section 12).

Item 5 is still bothering me:

   5. Added two 64-bit fields in iSER header in section 9.2 for the 
      Read Virtual Address and the Write Virtual Address to conform to 
      the Infiniband format as proposed by Bob Russell.  This allows 
      one implementation such as the OFED stack to be used in both the 
      Infiniband and the iWARP environment.

This is *not* backwards compatible.  What is the actual state of "running code" out there? Any iSER implementation that uses the iSER header format specified in RFC 5046 will get broken by this change.

Item 6 (proposed in Section 14.1) falls into the same "*not* backwards compatible" category:

   6. Alex Nezhinsky stated that iSER Hello and iSER HelloReply 
      messages are not implemented in practice.  He argued that we 
      should update the spec to remove the requirement to exchange the 
      iSER Hello and iSER HelloReply messages.

Again, what is the actual state of "running code" out there?  Any iSER implementation that uses these messages it at risk of getting broken by this proposed change.

My view of items 5 and 6 is that there has to be *no* running code that does these things as they were specified in RFC 5046 in order to make this sort of incompatible change w/o negotiating it, and the draft will need to state that all known implementations do it the "new" way.

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