Re: [storm] Plan for iSCSI work

"Hemal Shah" <hemal@broadcom.com> Thu, 09 June 2011 22:59 UTC

Return-Path: <hemal@broadcom.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 3545F11E80F5 for <storm@ietfa.amsl.com>; Thu, 9 Jun 2011 15:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUdW2J6qvg2N for <storm@ietfa.amsl.com>; Thu, 9 Jun 2011 15:59:30 -0700 (PDT)
Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id EC7BF11E807A for <storm@ietf.org>; Thu, 9 Jun 2011 15:59:29 -0700 (PDT)
Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 09 Jun 2011 16:03:20 -0700
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from IRVEXCHCCR02.corp.ad.broadcom.com ([10.9.200.183]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Thu, 9 Jun 2011 15:59:10 -0700
From: "Hemal Shah" <hemal@broadcom.com>
To: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>, "david.black@emc.com" <david.black@emc.com>, "storm@ietf.org" <storm@ietf.org>
Date: Thu, 9 Jun 2011 15:56:38 -0700
Thread-Topic: [storm] Plan for iSCSI work
Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJQIRzTq9AgfEPyGW79UNkIAUSvPw
Message-ID: <76DBE161893C324BA6D4BB507EE4C38495124C4828@IRVEXCHCCR02.corp.ad.broadcom.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> <SNT131-ds2DE0F0F2022D63A4AD747A0760@phx.gbl> <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> <SNT131-ds117065D22D7BF8583485DBA0790@phx.gbl>
In-Reply-To: <SNT131-ds117065D22D7BF8583485DBA0790@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 61EF8EB24NS18610548-01-01
Content-Type: multipart/alternative; boundary=_000_76DBE161893C324BA6D4BB507EE4C38495124C4828IRVEXCHCCR02c_
Subject: Re: [storm] Plan for iSCSI work
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: Thu, 09 Jun 2011 22:59:31 -0000

Thanks Mallikarjun!

The way I read Section 4.1.3 of RFC5048 and Section 4.2.3.4 of the consolidated draft, the implementation of "FastAbort" feature is a MUST. From the first paragraph text from Section 4.1.3 of RFC5048, the first sentence mandates that all iSCSI implementation comply to this section but the second sentence say that the requirement in this section is conditional to the negotiation of "FastAbort" key.

Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session.


This is confusing. I think it will be better to remove the first sentence from 4.2.3.4 and clarify that the requirements in this section is conditional. I suggest rewording the first two sentences to below:

iSCSI implementations may negotiate the TaskReporting (Section 9.1) key to "FastAbort" on an iSCSI session. Protocol behavior
defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session.

Hemal


-----Original Message-----
From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
Sent: Friday, May 27, 2011 5:29 PM
To: Hemal Shah; david.black@emc.com; storm@ietf.org
Subject: RE: [storm] Plan for iSCSI work

Hi Hemal,

The text in this draft came verbatim from section 4.1.3 of RFC 5048.  There
have been no changes in this area.

The new text (as well as the old text) requires the TaskReporting key to be
negotiated to "FastAbort" before the multi-task abort semantics can be used
on an iSCSI session.

Thanks.

Mallikarjun




  -----Original Message-----
  From: Hemal Shah [mailto:hemal@broadcom.com]
  Sent: Friday, May 27, 2011 4:51 PM
  To: Mallikarjun Chadalapaka; david.black@emc.com; storm@ietf.org
  Subject: RE: [storm] Plan for iSCSI work

  Mallikarjun and David,

  I noticed one problematic item in the consolidated draft. This item is the
  requirement to support FastAbort. This feature was already defined in the
  implementation guide, but it was optional. In this draft, it became a
  required feature MUST - see in section 4.2.3.4.

  Do you know why the requirement was changed in the consolidated draft?

  I would like to keep the requirement optional as stated in the
  implementation guide and not break backward compatibility.

  Hemal

  -----Original Message-----
  From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
  Of Mallikarjun Chadalapaka
  Sent: Thursday, May 26, 2011 6:50 PM
  To: david.black@emc.com; storm@ietf.org
  Subject: Re: [storm] Plan for iSCSI work

  Hi David,

  The list of changes you have called out are already done in the latest
draft.  I
  assume then that you are suggesting that the list itself should be
included
  in the next revision of the draft.

  Here's what I recall we have done so far:
  1)  iSCSIProtocolLevel specified as "1", and added a related normative
  reference to iSCSI-SAM draft
  2)  Markers and related keys were removed
  3)  SPKM authentication and related keys were removed
  4)  Added a new section on responding to obsoleted keys
  5)  Have explicitly allowed initiator+target implementations throughout
the
  text
  6)  Clarified that implementations SHOULD NOT rely on SLP-based discovery
  7)  Added UML diagrams, and related conventions

  The above is of course in addition to consolidating the different RFCs,
and
  making the related editorial changes.

  Thanks.

  Mallikarjun




    -----Original Message-----
    From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
    Of david.black@emc.com
    Sent: Friday, May 20, 2011 2:49 PM
    To: storm@ietf.org
    Subject: [storm] Plan for iSCSI work

    I thought I'd offer some advance planning/warning on this, as the
    consolidated iSCSI draft (draft-ietf-storm-iscsi-cons) is large (over
300
    pages).  The current plan is to run a simultaneous WG Last Call on both
  this
    draft and the new features draft (draft-ietf-storm-iscsi-sam) starting
in
  mid-
    June (probably the week of June 13, after I get back from a badly needed
    vacation).  That WG Last Call will run longer than the typical 2-week
time
    period, due to the total size of the drafts, but will end by July 5th at
the
    latest so that the status of the drafts and the next steps are known
prior
  to
    the T10 (SCSI standards) meetings during the week of July 11.  As July
11th
    is also the draft cutoff deadline for the Quebec City IETF meetings,
revised
    draft versions may not show up until that meeting week (week of July
    24th).

    This is also a good point to announce that the storm WG will meet in
    Quebec City.
    I've only requested a 1-hour session, as we get most of our work done on
    the mailing list.  Among the items for that meeting will be figuring out
  what
    to do with the RDMA extensions draft (despite its name,
draft-ietf-storm-
    rdmap-ext-00, it's not currently an official work item for the storm
WG).

    One thing that's missing from the consolidated iSCSI draft (and is a
reason
    why we're going to need a -03 version) is the changes that it makes to
the
    RFCs that it consolidates.  Off the top of my head, the major changes
are:
        - Removal of SPKM authentication
        - Removal of the Marker appendix
        - Removal of the SHOULD requirement for SLP implementation.
    Have I missed anything significant?  The summary of this will need to be
    added to that draft.

    WG Last Call will be an opportunity (in fact the final opportunity) to
  discuss
    whether anything else should be removed from iSCSI, but there's no need
    to wait
    - I encourage people to review both drafts and post comments whenever
    they can.

    In parallel, work will get started on any iSCSI MIB changes that are
needed.
    So far, I only see one MIB change - the iSCSIProtocolLevel from the new
    features draft needs to be added to the MIB, probably with a structure
    analogous to the iSCSI version support that's already in the MIB.

    Thanks,
    --David (storm WG co-chair)
    ----------------------------------------------------
    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 mailing list
    storm@ietf.org
    https://www.ietf.org/mailman/listinfo/storm

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