[storm] iSER - discussion

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

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
Subject: [storm] iSER - discussion
Precedence: list

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.

Thanks,
--David
----------------------------------------------------
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
----------------------------------------------------

[storm] iSER - discussion david.black