Re: [storm] iSER - one last issue
<david.black@emc.com> Wed, 18 January 2012 23:11 UTC
Return-Path: <david.black@emc.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 0877711E80B9 for <storm@ietfa.amsl.com>; Wed, 18 Jan 2012 15:11:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.775
X-Spam-Level:
X-Spam-Status: No, score=-108.775 tagged_above=-999 required=5 tests=[AWL=1.823, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jFZHm7ta4Bo for <storm@ietfa.amsl.com>; Wed, 18 Jan 2012 15:11:07 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DB71211E80A2 for <storm@ietf.org>; Wed, 18 Jan 2012 15:10:00 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0IN9smP013830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2012 18:09:55 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 18 Jan 2012 18:09:39 -0500
Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0IN9cKu007457; Wed, 18 Jan 2012 18:09:38 -0500
Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Wed, 18 Jan 2012 18:09:38 -0500
From: david.black@emc.com
To: Michael@huaweisymantec.com, storm@ietf.org
Date: Wed, 18 Jan 2012 18:09:35 -0500
Thread-Topic: iSER - one last issue
Thread-Index: AczWFoVrW51B5C1cRpS/cSPbLNSzJgAHkZHw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF0CF7@MX14A.corp.emc.com>
References: <20120115134011.27535.67315.idtracker@ietfa.amsl.com> <BA395993A32345F6898D0CD255E01020@china.huawei.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF06E5@MX14A.corp.emc.com> <6315937B35624B2E9C599A392DDB8EA1@china.huawei.com>
In-Reply-To: <6315937B35624B2E9C599A392DDB8EA1@china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF0CF7MX14Acorpemcc_"
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] iSER - one last issue
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: Wed, 18 Jan 2012 23:11:11 -0000
Mike, Thank you for the explanation, but I don't believe you've correctly stated the intent of RFC 5046. Here are some examples from RFC 5046's text: 1.5. SCSI Read Overview The iSER Message is transferred to the target using a SendSE Message. The iSER layer at the target uses a SendInvSE Message to transfer the SCSI Response PDU back to the iSER layer at the initiator. Similar language occurs in 1.6 SCSI Write Overview. 5.2.1. Normal Connection Termination at the Initiator The iSER layer at the initiator MUST use a SendSE Message to send the Logout Request PDU to the target. Similar language occurs in 5.2.2 for target side normal connection termination, and more importantly in 7.3.1 SCSI Command: The iSER layer at the initiator MUST send the SCSI command in a SendSE Message to the target. None of the quoted text permits use of Send instead of SendSE or SendInv instead of SendInvSE. What you propose to do effectively changes "MUST" to "should" (lower case, weaker than "SHOULD"), and that sure looks like a change to RFC 5046. Are there good implementation-based reasons to weaken these requirements now? Does anyone else have a viewpoint on this topic? Thanks, --David From: Michael Ko [mailto:Michael@huaweisymantec.com] Sent: Wednesday, January 18, 2012 2:22 PM To: Black, David; storm@ietf.org Subject: Re: iSER - one last issue David, Here is my rationale for using the lower case "should". The intent of RFC5046 is that the Send Message type must be used instead of RDMA Reads or Writes. The Solicited Event feature of the Send Message is provided as a convenience. The receiver must still do the right thing in handling the Send Message regardless of whether the SE feature is used. In other words, the sender is responsible for using the right format for the message (Send vs RDMA) but the receiver must not rely on the sender to determine how to handle the received message. The same rationale goes for the Invalidate feature. Mike ----- Original Message ----- From: david.black@emc.com<mailto:david.black@emc.com> To: Michael@huaweisymantec.com<mailto:Michael@huaweisymantec.com> ; storm@ietf.org<mailto:storm@ietf.org> Sent: Monday, January 16, 2012 2:06 PM Subject: iSER - one last issue Mike, Thanks for getting the -08 version of the iSER draft posted. I think that draft addresses all of the open issues, but I have a question for the WG about how to express the SendSE and SendInvSE requirements from RFC 5046. The -08 version of the iSER draft expresses requirements for the SendSE and SendInvSE messages (this is primarily for iSER over RDDP/iWARP) as: The SendSE Message should be used if supported by the RCaP layer (e.g., iWARP). My reading of RFC 5046 is that its requirements are tighter - to accurately reflect RFC 5046, I would replace "should" with "MUST" in the above text, at least for iWARP. In the alternative, if the "should"s remain, an explanatory item needs to be added to the Appendix A list of changes from RFC 5046. What do others think the right course of action is here, use "MUST" or explain weakening of requirement to "should" ? Thanks, --David From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Michael Ko Sent: Sunday, January 15, 2012 8:43 AM To: storm@ietf.org Subject: Re: [storm] I-D Action: draft-ietf-storm-iser-08.txt This version contains all the updates as discussed in the latest exchanges with Hemal Shah and David Black. Mike ----- Original Message ----- From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Cc: storm@ietf.org<mailto:storm@ietf.org> Sent: Sunday, January 15, 2012 5:40 AM Subject: [storm] I-D Action: draft-ietf-storm-iser-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the STORage Maintenance Working Group of the IETF. Title : iSCSI Extensions for RDMA Specification Author(s) : Michael Ko Alexander Nezhinsky Filename : draft-ietf-storm-iser-08.txt Pages : 95 Date : 2012-01-15 iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iser-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iser-08.txt _______________________________________________ storm mailing list storm@ietf.org<mailto:storm@ietf.org> https://www.ietf.org/mailman/listinfo/storm
- [storm] I-D Action: draft-ietf-storm-iser-08.txt internet-drafts
- Re: [storm] I-D Action: draft-ietf-storm-iser-08.… Michael Ko
- [storm] iSER - one last issue david.black
- Re: [storm] iSER - one last issue Michael Ko
- Re: [storm] iSER - one last issue david.black
- Re: [storm] iSER - one last issue Hemal Shah
- Re: [storm] iSER - one last issue Tom Talpey
- Re: [storm] iSER - one last issue Hemal Shah
- Re: [storm] iSER - one last issue Tom Talpey
- Re: [storm] iSER - one last issue Hemal Shah
- Re: [storm] iSER - one last issue Michael Ko