[storm] iSER draft progress!

"Black, David" <david.black@emc.com> Mon, 17 September 2012 15:30 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BAEBA21F867F for <storm@ietfa.amsl.com>; Mon, 17 Sep 2012 08:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id In4Rj01GsZsO for <storm@ietfa.amsl.com>; Mon, 17 Sep 2012 08:30:19 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id 01E5021F8610 for <storm@ietf.org>; Mon, 17 Sep 2012 08:30:18 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8HFUDNh017462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2012 11:30:16 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com []) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 17 Sep 2012 11:29:51 -0400
Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8HFTptq025381; Mon, 17 Sep 2012 11:29:51 -0400
Received: from mx15a.corp.emc.com ([]) by mxhub04.corp.emc.com ([]) with mapi; Mon, 17 Sep 2012 11:29:50 -0400
From: "Black, David" <david.black@emc.com>
To: Michael Ko <mkosjc@gmail.com>
Date: Mon, 17 Sep 2012 11:29:49 -0400
Thread-Topic: iSER draft progress!
Thread-Index: Ac2UL4Vi7wcV05IqSwSkpSuWNXVIoAAuIQ0A
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DCD16C7@MX15A.corp.emc.com>
References: <CAP_=6dLGh8D_0WUeSLcej0QJ4_k2KPtxh_JZBy+HpEizrEjfFA@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE71208F127E3@MX15A.corp.emc.com> <CAP_=6dKKntRy77oxMdmradM68aKTCCpAmhdeGG6d1FufqmwYEw@mail.gmail.com> <8D3D17ACE214DC429325B2B98F3AE7120DCD1566@MX15A.corp.emc.com> <CAP_=6d+mNeVHu61Hg3xkfTAaCiHdp-_JOz1CWbP5NtVP=g=hsg@mail.gmail.com>
In-Reply-To: <CAP_=6d+mNeVHu61Hg3xkfTAaCiHdp-_JOz1CWbP5NtVP=g=hsg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_004_8D3D17ACE214DC429325B2B98F3AE7120DCD16C7MX15Acorpemccom_"
MIME-Version: 1.0
Cc: "storm@ietf.org" <storm@ietf.org>
Subject: [storm] iSER draft progress!
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: Mon, 17 Sep 2012 15:30:23 -0000


That new -12 version of the iSER draft looks fine, so I've sent it onward to our AD (Martin) for further review, along with a minor change to the PROTO writeup (new writeup is attached).  I do hope that this third attempt to complete this stage of storm WG technical work on iSER turns out to be the charm :).  Thank you for the quick turn-around on the new draft version.

Many thanks to everyone who's contributed to working through the iSER issues since the start of the year.  Although the delays to the iSER draft have not been ideal, they've occurred for good reasons, as we do need to make sure that the technical content of the draft is actually correct and matches the implementations.

Also - RDMAP draft authors - this is your heads-up that I will get to taking a look at the RDMAP draft in the next week or so ...

--David (storm WG co-chair)

From: Michael Ko [mailto:mkosjc@gmail.com]
Sent: Sunday, September 16, 2012 1:20 PM
To: Black, David
Cc: storm@ietf.org
Subject: Re: [storm] Proposed text changes for the connection allocation problem


I have submiited a new version of the iSER draft incorporating all the latest changes so far, including your recommendations below.  I have also reword item #7 in the summary of changes to reflect the new use of the iSERHelloRequired key.

On Fri, Sep 14, 2012 at 5:25 PM, Black, David <david.black@emc.com<mailto:david.black@emc.com>> wrote:

I apologize for the delay in getting to this.  I think your latest text is close to what's
needed, but I want to rewrite the latter part of your second paragraph for clarity and to
remove a "MUST" that appears easy to misinterpret (IMHO):

   To prevent the potential problem caused by the target sending the number of
   unexpected iSCSI control-type PDUs as determined by the MaxOustandingUnexpectedPDUs
   key allowed in the FullFeaturePhase when "late" connection allocation is practised,
   the iSER Hello exchanges MUST be used.  This allows the initiator to allocate the
   connection resources before sending the iSER Hello Messages.  The iSERHelloRequired
   key is used by the initiator to determine if it is dealing with a target that
   supports the iSER Hello exchanges.
   An initiator that employs "late" connection allocation may encounter problems (e.g.,
   RCaP connection closure) with a target that sends unexpected iSCSI PDUs immediately
   upon transitioning to Full Feature Phase, as allowed by the negotiated value of the
   the MaxOustandingUnexpectedPDUs key.  The only way to prevent this situation in
   full generality is to use iSER Hello Messages, as they enable the initiator to allocate
   its connection resources before sending its iSER Hello Message.  The iSERHelloRequired
   key is used by the initiator to determine if it is dealing with a target that
   supports the iSER Hello exchanges.  Fortunately, known iSER target implementations
   do not take full advantage of the number of allowed unexpected PDUs immediately upon
   transition into full feature phase, enabling an initiator workaround that involves
   a smaller quantity of connection resources prior to full-feature phase, as explained
   further below.

Would you please go ahead and submit a revised version of the draft with the text changes
that we've agreed to.  I'll want to review the changes one more time in the context of an
entire draft before (finally) sending it to our AD with a request to publish it as an RFC.

Thank you for your patience with this.