Subject: [storm] iSER - discussion

From: <[email-masked]>
Date: Wed, 23 Jun 2010 17:16:03 -0400

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------