From arkady.kanevsky@gmail.com Tue May 3 09:42:28 2011 Return-Path: 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 B5459E087F for ; Tue, 3 May 2011 09:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Qh8K7XP8o-cB for ; Tue, 3 May 2011 09:42:27 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBB2E0843 for ; Tue, 3 May 2011 09:42:24 -0700 (PDT) Received: by pwi5 with SMTP id 5so161165pwi.31 for ; Tue, 03 May 2011 09:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=7PRjr5WAwVvvlRZFhGK/UY03Wk3m1v2qKtN8ETf4ezI=; b=aCUChMrzzKlZelD+OHIYUL5RpjBJO9T3ybMEEJUUgj8L4Ue5vVAXmEZL+O/EHuU98N IwZE1B+VJkPIMMifkJei3fPGNfsYY5Odc5NHdPyO3PNr4RopK+4cv2OmEMkfHq0PbrGW k/AvECwgKzormYq3QWM6aaUdQKZhLntI0v+ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AFEbXKy0nP+Lp5uxViknyJblTasXeNzqbwpTp7gYKnsZnbpRuhTHICFZ/Osa4OGQQ4 zuzhdp748G+AkOQTpLW3KYbnr4TlTJkI04N8xCRV34M5SXA4k494FACqfejgcxO++oMI F82PYjGWYh3fKb/mnozjnFkvQtFr4IdznyPR8= MIME-Version: 1.0 Received: by 10.142.7.12 with SMTP id 12mr24478wfg.181.1304440944512; Tue, 03 May 2011 09:42:24 -0700 (PDT) Received: by 10.142.214.19 with HTTP; Tue, 3 May 2011 09:42:24 -0700 (PDT) Date: Tue, 3 May 2011 12:42:24 -0400 Message-ID: From: arkady kanevsky To: storm@ietf.org, "Sharp, Robert O" Content-Type: multipart/alternative; boundary=00504502bc6320cf7c04a261d320 Subject: [storm] comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 16:42:28 -0000 --00504502bc6320cf7c04a261d320 Content-Type: text/plain; charset=ISO-8859-1 Here are a few comments on the draft: In Glossary it is stated: Atomic Operation - is an operation that results in an execution of a 64-bit operation at a specific address on a remote node. The consumer can use atomic operations to read, modify and write at the destination address while at the same time guarantee that no other read or write operation will occur across any other RDMAP/DDP Streams on an RNIC at the Data Sink. later in section 5 it is stated: The operations atomically read, modify and write back the contents of the destination address and guarantee that atomic operations on this address by other Queue Pairs (QPs) on the same RNIC do not occur between the read and the write. in 5.3. Atomicity Guarantees Atomicity of the RMW on the responder's node by the Atomic Operation SHALL be assured in the presence of concurrent atomic accesses by other QPs on the same RNIC. The three statements are very different. The cases that need to be handled are: other operation of the same QP, the same RNIC, other devices, local ULP access. 2. It is stated: The discovery of whether the atomic operations are implemented or not is outside the scope of this specification and it should be handled by the ULPs or applications. Is this really the best way? Should the connection setup extension draft which I submitted be extended to exchange this info also? That is which version of RDMA protocol the remote side supports or requests to support. The reason I am asking it it not clear to me what option does ULP have if atomic or immediate data is not supported. 3. What is the Endian(ness) format of Add Data for fetchadd? ditto for cmpswp. 4. Is there a separate memory registration (Stag creation) for atomic operation? Or any registered memory can be used for atomic op? 5. How does the requester knows that Stag+remote tagged offset does corresponds to a naturally aligned buffer address? 6. "The Swap atomic operation result is unknown when the buffer address is not naturally aligned." feels a bit loose. I would assume that RNIC will at least not change any data outside memory specified by Stag. Also in 5.2.1 #4 states: At the Remote Peer, when an invalid Atomic Operation Request Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced. It sounds like breaking natural alignment is not an error. That is it will break the connection. Also: 6. At the Remote Peer, when an invalid Atomic Operation Response Message is delivered to the Remote Peer's RDMAP layer, an error is surfaced. Does the error carries the request identifier? 7. Any guidance for sizing ORD/IRD for atomic ops? Does this doc requires my doc with ORD/IRD negotiation at connect time? 8. If the same memory has two Stag (overlapping memory regions) is atomic op ordering only preserved for a single QP/connection? What happens if natural alignment is less then 64-bit? Is there any order guaranteed per Stag (if two QPs use the same Stag for atomic or RDMA ops)? 9. It is strange that for atomic op we are using 64-bit terminology but for immediate data we use 8-byte terminology. 10.Suggest to specify which queues and buffers immediate data message uses? Arkady -- Cheers, Arkady Kanevsky --00504502bc6320cf7c04a261d320 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here are a few comments on the draft:
In Glossary it is stated:
=
Atomic Operation - is an operation that results in an execution of a
   64-bit operation at a specific address on a remote node. The
   consumer can use atomic operations to read, modify and write at the
   destination address while at the same time guarantee that no other
   read or write operation will occur across any other RDMAP/DDP
   Streams on an RNIC at the Data Sink.

later in section 5 it is sta=
ted:
The
   operations atomically read, modify and write back the contents of
   the destination address and guarantee that atomic operations on this
   address by other Queue Pairs (QPs) on the same RNIC do not occur
   between the read and the write.

in
=
5.3. Atomicity Guarantees
   Atomicity of the RMW on the res=
ponder's node by the Atomic Operation
   SHALL be assured in the presence of concurrent atomic accesses by
   other QPs on the same RNIC.

The three statements are very differe=
nt. The cases that need to be handled are:
other operation of the same Q=
P, the same RNIC, other devices, local ULP access.
2. It is stated= :
The discovery of whether the
   atomic operations are implemented or not is outside the scope of
   this specification and it should be handled by the ULPs or
   applications.
Is this really the best way? Should the connection setup extension draft which I submitted be extended to exchange this info also? That is which version of RDMA protocol the remote side supports or requests to=20 support. The reason I am asking it it not clear to me what option does=20 ULP have if atomic or immediate data is not supported.

3. What is the Endian(ness) format of Add Data for fetchadd? ditto for = cmpswp.

4. Is there a separate memory registration (Stag creation) for atomic=20 operation? Or any registered memory can be used for atomic op?

5. How does the requester knows that Stag+remote tagged offset does cor= responds to=A0 a naturally aligned buffer address?

6. "The Swap atomic operation result is unknown when the buffer address is not naturally aligned." feels a bit loos= e. I would assume that RNIC will at least not change any data outside=20 memory specified by Stag.
Also in 5.2.1 #4 states:
At the Remote=
 Peer, when an invalid Atomic Operation Request
      Message is delivered to the Remote Peer's RDMAP layer, an error
      is surfaced.
It sounds like breaking natural alignment is not an error. That is it= will break the connection.

Also:
6. At the Remote Peer, whe=
n an invalid Atomic Operation Response
      Message is delivered to the Remote Peer's RDMAP layer, an error
      is surfaced.

Does the error carries the request identifier?<= br>
7. Any guidance for sizing ORD/IRD for atomic ops? Does this doc req= uires my doc with ORD/IRD negotiation at connect time?

8. If the same memory has two Stag (overlapping memory regions) is atomic=20 op ordering only preserved for a single QP/connection? What happens if=20 natural alignment is less then 64-bit? Is there any order guaranteed per Stag (if two QPs use the same Stag for atomic or RDMA ops)?

9. It is strange that for atomic op we are using 64-bit terminology but= for immediate data we use 8-byte terminology.

10.Suggest to specify= which queues and buffers immediate data message uses?

Arkady

--
Cheers,
Arkady Kanevsky
--00504502bc6320cf7c04a261d320-- From robert.o.sharp@intel.com Wed May 4 15:06:58 2011 Return-Path: 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 6E290E06C3 for ; Wed, 4 May 2011 15:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] 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 vRvokA8t5iBL for ; Wed, 4 May 2011 15:06:57 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6D199E06BB for ; Wed, 4 May 2011 15:06:57 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 04 May 2011 15:06:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.64,316,1301900400"; d="scan'208";a="430677047" Received: from azsmsx603.amr.corp.intel.com ([10.2.161.23]) by azsmga001.ch.intel.com with ESMTP; 04 May 2011 15:06:21 -0700 Received: from azsmsx506.amr.corp.intel.com ([10.2.121.72]) by azsmsx603.amr.corp.intel.com ([10.2.161.23]) with mapi; Wed, 4 May 2011 15:06:20 -0700 From: "Sharp, Robert O" To: arkady kanevsky , "storm@ietf.org" Date: Wed, 4 May 2011 15:06:18 -0700 Thread-Topic: comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 Thread-Index: AcwJsR+P+Nk6JUXeSXWVX8ISPYdtPgAvIABQ Message-ID: <2EFBCAEF10980645BBCFB605689E08E904DAC3E5E3@azsmsx506.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [storm] comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap-ext-00 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 22:06:58 -0000 Hi Arkady, Thanks for the comments! Responses below... Thanks, Bob > -----Original Message----- > From: arkady kanevsky [mailto:arkady.kanevsky@gmail.com] > Sent: Tuesday, May 03, 2011 11:42 AM > To: storm@ietf.org; Sharp, Robert O > Subject: comments on http://tools.ietf.org/html/draft-ietf-storm-rdmap- > ext-00 >=20 > Here are a few comments on the draft: > In Glossary it is stated: > Atomic Operation - is an operation that results in an execution of a > 64-bit operation at a specific address on a remote node. The > consumer can use atomic operations to read, modify and write at the > destination address while at the same time guarantee that no other > read or write operation will occur across any other RDMAP/DDP > Streams on an RNIC at the Data Sink. >=20 > later in section 5 it is stated: > The > operations atomically read, modify and write back the contents of > the destination address and guarantee that atomic operations on this > address by other Queue Pairs (QPs) on the same RNIC do not occur > between the read and the write. >=20 > in > 5.3. Atomicity Guarantees > Atomicity of the RMW on the responder's node by the Atomic Operation > SHALL be assured in the presence of concurrent atomic accesses by > other QPs on the same RNIC. >=20 > The three statements are very different. The cases that need to be > handled are: > other operation of the same QP, the same RNIC, other devices, local ULP > access. The intention of the draft is that atomicity is guaranteed on the same or=20 different RDMAP/DDP Streams on a single RNIC. The atomicity guarantees=20 apply to local or remote ULP access as long as both are strictly accessing= =20 the memory referenced by the atomic operation through the same RNIC. Since this is a wire protocol specification, the ULP access description wil= l be considered out of scope. There is clearly an inconsistency in terminolog= y=20 here when QP was used. One clarification that we will make is to replace=20 the QP term with RDMAP/DDP Streams throughout the document. I believe that the sections in the draft are consistent with this description, but if you see something specific that could be made more clear, we'll be happy to=20 address further input. We can certainly add a statement that says that there are no guarantees between different RNICs or other devices if that=20 would help. > 2. It is stated: > The discovery of whether the > atomic operations are implemented or not is outside the scope of > this specification and it should be handled by the ULPs or > applications. > Is this really the best way? Should the connection setup extension > draft which I submitted be extended to exchange this info also? That is > which version of RDMA protocol the remote side supports or requests to > support. The reason I am asking it it not clear to me what option does > ULP have if atomic or immediate data is not supported. >=20 For this draft the statement is appropriate, however we certainly would be interested in building better support into the MPA to exchange the enhanced capabilities between peers at connection setup. I assume that this would be future revision to the MPA draft at this point in time. Do you agree? > 3. What is the Endian(ness) format of Add Data for fetchadd? ditto for > cmpswp. >=20 The wire format (Big Endian) and the conversion to the appropriate=20 Endian(ness) for the host is specified in sections 5.1.1 and 5.1.3. > 4. Is there a separate memory registration (Stag creation) for atomic > operation? Or any registered memory can be used for atomic op? >=20 In practice, applications will likely use separate STags for atomic operations, but there is not a requirement to do so. Any registered memory can be used for atomic operations. > 5. How does the requester knows that Stag+remote tagged offset does > corresponds to=A0 a naturally aligned buffer address? >=20 Applications must exchange STags and tagged offsets in order to expose the target of an atomic operation in a application specific way. It is=20 the responsibility of the application that is exposing the memory to=20 ensure that the buffer is naturally aligned. The requestor must trust the peer to have properly aligned an exposed target of an atomic=20 operation. If the target exposed an improperly aligned STag and tagged=20 offset, an error will be surfaced by the RNIC. > 6. "The Swap atomic operation result is unknown when the buffer address > is not naturally aligned." feels a bit loose. I would assume that RNIC > will at least not change any data outside memory specified by Stag. > Also in 5.2.1 #4 states: > At the Remote Peer, when an invalid Atomic Operation Request > Message is delivered to the Remote Peer's RDMAP layer, an error > is surfaced. > It sounds like breaking natural alignment is not an error. That is it > will break the connection. >=20 There is room for improvement here as you have pointed out. We will add a better description that indicates that the responder RNIC will prevent=20 atomic operation access to a memory location that is not naturally aligned.= =20 This will be an error that is always surfaced. The result will be a=20 terminate message back to the requester. We will add a description of the terminate semantics to the draft. > Also: > 6. At the Remote Peer, when an invalid Atomic Operation Response > Message is delivered to the Remote Peer's RDMAP layer, an error > is surfaced. >=20 > Does the error carries the request identifier? The terminate message generated will carry the RDMAP header of the=20 offending atomic operation request which includes the request identifier. This will be called out in the new description of the terminate semantics. >=20 > 7. Any guidance for sizing ORD/IRD for atomic ops? Does this doc > requires my doc with ORD/IRD negotiation at connect time? >=20 Sizing ORD/IRD is out of scope for this wire format level of draft since the application is responsible for determining the acceptable requirements. As with the new capabilities related to this draft, it would be good to wor= k this in with new MPA enhancements. > 8. If the same memory has two Stag (overlapping memory regions) is > atomic op ordering only preserved for a single QP/connection?=20 STags do not have an impact on the atomic guarantees. Atomicity is guaranteed within the scope of an RNIC across all QPs supported by the RNIC without respect to the STag used to reference a memory location=20 accessed by the atomic operation. > What > happens if natural alignment is less then 64-bit? Is there any order > guaranteed per Stag (if two QPs use the same Stag for atomic or RDMA > ops)? >=20 Operations that violate the natural alignment assumption will be terminated by the responder before the operation is performed per the changes=20 discussed above. > 9. It is strange that for atomic op we are using 64-bit terminology but > for immediate data we use 8-byte terminology. >=20 We intentionally used the separate terminology. We used the "byte" terminology to discuss data payload and the "bit" terminology to discuss fields within the data payload. I believe that we were consistent but if you see something that should be clarified, we'll be happy to make the correction. > 10.Suggest to specify which queues and buffers immediate data message > uses? >=20 The queue number (qn=3D0) and data buffers (untagged buffers) are specified in section 6.3. If additional clarifications would help, please let us kno= w. > Arkady >=20 > -- > Cheers, > Arkady Kanevsky From david.black@emc.com Wed May 18 10:23:36 2011 Return-Path: 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 CB3F0E06C3 for ; Wed, 18 May 2011 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 4N9pS3tJcmhc for ; Wed, 18 May 2011 10:23:36 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 34283E06B9 for ; Wed, 18 May 2011 10:23:35 -0700 (PDT) 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 p4IHNXV2008466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 May 2011 13:23:33 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 18 May 2011 13:23:28 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4IHNJcS029193 for ; Wed, 18 May 2011 13:23:19 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Wed, 18 May 2011 13:23:18 -0400 From: To: Date: Wed, 18 May 2011 13:23:17 -0400 Thread-Topic: iSCSI Consolidated Draft - Proposed Standard Thread-Index: AcwVgEcZa/4ASxrBTRWKUCiEO3IHDQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F42001@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI Consolidated Draft - Proposed Standard X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:23:36 -0000 Having seen only one person express a desire to take the iSCSI consolidated draft to Draft Standard RFC status, I believe the conclusion is to take the current draft to Proposed Standard status. It's always possible to do the implementation survey work later to take it to Draft Standard RFC status. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Wed May 18 10:36:42 2011 Return-Path: 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 0BF9EE074A for ; Wed, 18 May 2011 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 I4kU4D9RWAtL for ; Wed, 18 May 2011 10:36:40 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E65D6E06B3 for ; Wed, 18 May 2011 10:36:39 -0700 (PDT) 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 p4IHadO6018752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 May 2011 13:36:39 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 18 May 2011 13:36:26 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4IHYK3x031243 for ; Wed, 18 May 2011 13:34:50 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 18 May 2011 13:34:26 -0400 From: To: Date: Wed, 18 May 2011 13:34:26 -0400 Thread-Topic: iSER - end of activity Thread-Index: AcvdKFBha0iL1vsLSrW8bNZxoGcF8AAfBBDwDfchseA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F42014@MX14A.corp.emc.com> References: <20110308003002.23256.42238.idtracker@localhost> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5CB2C69@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5CB2C69@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSER - end of activity X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 17:36:42 -0000 A couple of months (March 8th) ago, I wrote: > Let me be clear - if there is no interest in iSER changes > to reflect what's actually been implemented, that work *will be* abandone= d. For those who want to > refresh their memory about what's in that draft, a copy of the expired dr= aft can be found at: >=20 > http://www.watersprings.org/pub/id/draft-ietf-storm-iser-01.txt As I have seen no subsequent sign of interest in continued iSER work, the t= ime has come to abandon that work and remove it from the storm WG's charter. I want to thank Mike Ko fo= r his efforts in working on this draft, but the I do not see support for co= ntinuing this work. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, March 08, 2011 10:32 AM > To: storm@ietf.org > Cc: Black, David > Subject: RDMA extensions draft and iSER > Importance: High >=20 > The RDMA extensions draft (see below) was approved and posted due to a co= mbination of pilot error on > my part and a favor to the authors because they submitted it right at the= -00 cutoff deadline (hint: > that's not a particularly good idea, because if something goes wrong, the= re's no opportunity to > correct and resubmit). >=20 > This draft is **NOT** an official storm WG draft (at least, not right now= ) - the authors would like > the storm WG to consider adopting it as a work item. The draft is certai= nly within the potential > scope of the WG as it updates another one of the RDMA protocols originall= y produced by the rddp WG - > a revised version of the MPA peer connect draft should appear this week, = and will be sent onward to > the ADs for review, IETF Last Call, etc. >=20 > WG consideration of this RDMAP extension draft *will be* coupled with a d= etermination of what to do > about the iSER work item. The iSER draft has expired through no fault of= the author - Mike Ko has > been diligent in updating the iSER draft, but everyone else with an inter= est in iSER appears to have > vanished from the storm WG mailing list. Let me be clear - if there is n= o interest in iSER changes > to reflect what's actually been implemented, that work *will be* abandone= d. For those who want to > refresh their memory about what's in that draft, a copy of the expired dr= aft can be found at: >=20 > http://www.watersprings.org/pub/id/draft-ietf-storm-iser-01.txt >=20 > Comments to the list on both drafts are encouraged. >=20 > Thanks, > --David (storm WG co-chair). > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.o= rg] On Behalf Of Internet- > > Drafts@ietf.org > > Sent: Monday, March 07, 2011 7:30 PM > > To: i-d-announce@ietf.org > > Cc: storm@ietf.org > > Subject: I-D Action:draft-ietf-storm-rdmap-ext-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the STORage Maintenance Working Group of t= he IETF. > > > > > > Title : RDMA Protocol Extensions > > Author(s) : H. Shah, et al. > > Filename : draft-ietf-storm-rdmap-ext-00.txt > > Pages : 29 > > Date : 2011-03-07 > > > > This document specifies extensions to the IETF Remote Direct Memory Acc= ess Protocol (RDMAP > > [RFC5040]). RDMAP provides read and write services directly to applicat= ions and enables data to be > > transferred directly into Upper Layer Protocol (ULP) Buffers without in= termediate data copies. The > > extensions specified in this document provide the following capabilitie= s and/or improvements: > Atomic > > Operations and Immediate Data. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-storm-rdmap-ext-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader implem= entation to automatically > > retrieve the ASCII version of the Internet-Draft. From ietfdbh@comcast.net Fri May 20 08:06:15 2011 Return-Path: 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 37140E06B3 for ; Fri, 20 May 2011 08:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6-ArYqVOpY4p for ; Fri, 20 May 2011 08:06:14 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id D4C50E0688 for ; Fri, 20 May 2011 08:06:13 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id lqNa1g00416LCl051r6EsX; Fri, 20 May 2011 15:06:14 +0000 Received: from davidPC ([67.189.235.106]) by omta06.westchester.pa.mail.comcast.net with comcast id lr6B1g00a2JQnJT3Sr6BHM; Fri, 20 May 2011 15:06:13 +0000 From: "David Harrington" To: , , Date: Fri, 20 May 2011 11:06:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcwW/3OnDAJozBeCSrOODdtKJWAnhg== Subject: [storm] AD Review of draft-ietf-storm-mpa-peer-connect X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 15:06:15 -0000 AD Review of draft-ietf-storm-mpa-peer-connect I have reviewed this document and have comments. I think this work is important, but the way this document explains it could be better. My goal as AD is to have this document go through IETF Last Call and IESG review without any issues delaying advancement. Some comments are technical/process comments that refer to text that will likely cause delays during IESG Evaluation. Some are stylistic, such as capitalization and wording consistency, that are distracting and are likely to make readers wonder "is there something special here that I need to understand?" and to waste time trying to determine if there is or is not something special that led to your capitalizing the text, or using different wording than elsewhere. These could lead to IESG members raising unnecessary questions that would delay advancement. Others are editorial in nature, mostly about writing clear and unambiguous text. Generally, if it is simply a small editorial thing, I ignored it, expecting the RFC Editor to clean up the text a bit. But sometimes, the lack of clarity could lead to differing interpretations of the text, or lack of understanding of the text, and those should be fixed before I bring this to the IESG. In some cases, I have asked a question. If I had to ask a question, then the document apparently didn't explain it clearly enough. The answer to the question usually needs to be explained "in the document", not just in a private email to me. 1) idnits complains about unreachable reference: http://www.rdmaconsortium.org/home/draft-hilland-iwarp-verbs-v1.0-RDMA C.pdf 2) abstracts cannot contain references. 3) in 4.3.2, the conclusion could be stated more clearly, such as "If a nop approach was used, it would require lower layers to know the usage model, and would disrupt the calculations ..." 4) in 4.3.3, I have no idea what this text is saying or why it is relevant to the problem at hand. I don't know what an untagged message is; I don't know why a WC can only be generated by an untagged message. Can you expand on this so readers that are not RDMA experts understand what you're talking about? The IESG will need to review and approve this document, and to my knowledge none of them are RDMA experts. 5) It would be helpful to explain why taking the bit from RES is backwards compatible. Explain why older implementation will not have a problem with the new bit, and why new implemntations will be able to benefit from the new bit. 6) Rev "MUST be set to two"; would this be better as "two or higher?" to allow for a version three+ that would be backward compatible with the enhanced features of version two? 7) I don't understand "The Enhanced Reject function code SHOULD be used to indicate a configuration that would have been accepted." Would have been accepted except was not because of what condition? Why is this only a SHOULD and not a MUST? 8) How can the private data be zero length if it must begin with Enhanced RDMA Connection establishment data? 9) sometimes "Enhanced RDMA Connection Establishment Data" is capitalized, sometimes not. Be consistent. 10) Received extended ... message SHOULD be reported to the ULP. Why is this not a MUST? Anytime there is a SHOULD, the text should identify when the rule is not mandatory - what are the valid exceptions that make this not a MUST? 11) What is "enhanced DDP stream management"? 12) "It should be noted that" - you're noting it, so this lead-in phrase is totally unnecessary. If you leave it as "It should be noted that", then explain WHY it should be noted. If "it is especially important to recognize that" then say that, and explain WHY it is important to recognize. It appears that it is important only because you've made a case for peer-to-peer needing to initiate from either side, and the SCTP adaption layer allows for that already. So you should probably explain why you're duplicating that capability. 13) additional legal sequences - but then you don't seem to define any **sequences**. Is "Legal Sequences" a special term? If so, please explain where it is defined. if not, why is it capitalized? 14) I cannot parse "The protocol layers on which RDMA connection establishment is layered upon [RFC5040] and [RFC5041] define layers and error types." 15) if 5043 and 5044 do not define error codes, then how are the error codes used? are they carried in messages? which messages? 16) In looking for the answer to 15, I found that error codes ARE defined in RFC5044 section 8. So your text is apparently wrong. 17) in section 9, the responder SHOULD NOT set its IRD higher than Initiator ORD. Why is this not a MUST? Under what conditions is it acceptable to set this higher than Initiator ORD? What are the implications of doing so? the responder SHOULD set its ORD lower. What are the valid exceptions to this? 18) the Initiator MUST set its IRD to a value at least as large as the responder ORD if it has sufficient resources "MUST if" means this is a SHOULD, and lack of resources is the exception. If this is truly a MUST (which the following sentences seem to say, requiring a termination if ti doesn't do so, then I would remove the if clause from the first sentence, making it a definite MUST. 19) "Control flag for using" doesn't discuss whatthe values are. Does this mean that if A has a value 1, then FULPDU has a zero length? This section might be better organized by defining what the fields are (control flags and depths), then describing how the values are set. You do that for A,B,C but describe IRD and ORD in-line. 20) In section 9, "If there is no Standard RDMAP Configuration Data in the MPA Reply Frame, and the Enhanced Connection Establishment version number is used, it is the equivalent of setting 'A', 'B' and 'C'. " Why do we need this extra complexity? Why not require that these be set ONE way, not two? I also have concerns about "THE enhanced connectiosn establshment version number"; will this document need to be updated if a version three is ever developed? 21) "Setting no Control Flags in the MPA Reply indicates that an RDMA Send message will be required. As this option will require the initiator ULP to be involved it SHOULD NOT be used unless necessary. " Please define what necessary is. I think this would be better as a MUST NOT. 22) "Initiator or Responder SHOULD generate the TERM message" - why is thi snot a MUST? What are the valid exceptions to this? in section 10: 23) "An initiator SHOULD NOT use the Enhanced DDP Connection Establishment formats or function codes when no enhanced functionality is desired. " what are the valid exceptions that make this a SHOULD rather than a MUST? 24) the paragraph containing "If a responder does not support received extended MPA message, then it MUST close the TCP connection and exit MPA since MPA frame is improperly formatted for it as stated in [RFC5044]." needs a bit of English cleanup. 25) section11 This document defines error codes; so does RFC5044. Implementers and operators will need to hunt through documents to find the various error codes. This document apparently overlooks the error codes defined in 5044 section 8. Should there be a registry, maintained by IANA, for the MPA error codes? section 12: 26) I am always concerned when a security coinsiderations section says this document does not introduce any new security considerations. This is also a red flag during IESG Evaluation. I suggest you document WHY these changes do not impact security compared to 5043 and 5044. Demonstrate that the WG actually **considered** the security issues. 27) expand acronyms on first use (MPA, RDMA, RDDP, ULP, iWARP, etc.) 28) references for sctp, infiniband, 29) in 4.3.1, "required only for one transport" - mention the one transport? 30) an explanation/definition of MPA Fencing would help readers. Maybe a terminology section would be helpful, given all the acronyms, etc. 31) The information in 4.4 would be helful in the Introduction section. This would help to organize the document into "Here's how it works now; here is why the client/server model is undesirable in a P2P environment; and this is how to modify the existing standard to address this problem." 32) Is section 5 a description of how things currently work, or the way this document proposes they work? Section 5 mentions "Enhanced Connection Setup"; is that the same as "Enhanced RDMA Connection Establishment"? if so, then naming section 5 "Enhanced RDMA Connection Establishment" or "Enhanced MPA Connection Setup" might be helful. Use terminology consistently, please. I hope these suggestions help improve the document so we can advance it through the approval process quickly, David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From david.black@emc.com Fri May 20 14:49:09 2011 Return-Path: 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 38E00E06BE for ; Fri, 20 May 2011 14:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 CRV10+LGWsiN for ; Fri, 20 May 2011 14:49:08 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA5EE0677 for ; Fri, 20 May 2011 14:49:07 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4KLn7MC006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2011 17:49:07 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Fri, 20 May 2011 17:48:58 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.221.46.114]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4KLmqmM024914 for ; Fri, 20 May 2011 17:48:53 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Fri, 20 May 2011 17:48:52 -0400 From: To: Date: Fri, 20 May 2011 17:48:51 -0400 Thread-Topic: Plan for iSCSI work Thread-Index: AcwXN7VKMx7Ie8eaTvWbtFFzM0GDVg== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] Plan for iSCSI work X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 21:49:09 -0000 I thought I'd offer some advance planning/warning on this, as the consolida= ted iSCSI draft (draft-ietf-storm-iscsi-cons) is large (over 300 pages). The c= urrent plan is to run a simultaneous WG Last Call on both this draft and the new f= eatures 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 th= e drafts, but will end by July 5th at the latest so that the status of the dr= afts and the next steps are known prior to the T10 (SCSI standards) meetings dur= ing the week of July 11. As July 11th is also the draft cutoff deadline for the Qu= ebec City IETF meetings, revised draft versions may not show up until that meeti= ng 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 th= e mailing list. Among the items for that meeting will be figuring out what to do wit= h 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 ad= ded to that draft. WG Last Call will be an opportunity (in fact the final opportunity) to disc= uss 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 featur= es 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=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From cbm@chadalapaka.com Thu May 26 18:50:13 2011 Return-Path: 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 1B0BAE069D for ; Thu, 26 May 2011 18:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 A55f9Hr2NGIa for ; Thu, 26 May 2011 18:50:12 -0700 (PDT) Received: from snt0-omc3-s8.snt0.hotmail.com (snt0-omc3-s8.snt0.hotmail.com [65.55.90.147]) by ietfa.amsl.com (Postfix) with ESMTP id 458CAE06A5 for ; Thu, 26 May 2011 18:50:12 -0700 (PDT) Received: from SNT131-DS2 ([65.55.90.135]) by snt0-omc3-s8.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 18:50:12 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: , References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> Date: Thu, 26 May 2011 18:50:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJZcPIlAw Content-Language: en-us X-OriginalArrivalTime: 27 May 2011 01:50:12.0176 (UTC) FILETIME=[6AAE3D00:01CC1C10] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 01:50:13 -0000 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. =20 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=20 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=20 The above is of course in addition to consolidating the different RFCs, = and making the related editorial changes. Thanks. Mallikarjun =20 -----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 =20 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). =20 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). =20 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. =20 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. =20 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. =20 Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From hemal@broadcom.com Fri May 27 16:54:07 2011 Return-Path: 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 183F4E0726 for ; Fri, 27 May 2011 16:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qviCmM3xto1g for ; Fri, 27 May 2011 16:54:06 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 60CD2E06BA for ; Fri, 27 May 2011 16:54:06 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 27 May 2011 16:57:51 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR02.corp.ad.broadcom.com ([10.9.200.183]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 27 May 2011 16:53:48 -0700 From: "Hemal Shah" To: "Mallikarjun Chadalapaka" , "david.black@emc.com" , "storm@ietf.org" Date: Fri, 27 May 2011 16:51:26 -0700 Thread-Topic: [storm] Plan for iSCSI work Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJZcPIlAwgAFrDvA= Message-ID: <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> In-Reply-To: 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: 61FEE5F562O1193391-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 23:54:07 -0000 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 i= mplementation guide, but it was optional. In this draft, it became a requir= ed 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 implementati= on guide and not break backward compatibility. Hemal -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of M= allikarjun 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 b= e included in the next revision of the draft. =20 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=20 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=20 The above is of course in addition to consolidating the different RFCs, and making the related editorial changes. Thanks. Mallikarjun =20 -----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 =20 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 tim= e 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 prio= r 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). =20 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). =20 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 th= e 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. =20 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. =20 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. =20 Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 _______________________________________________ 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 From cbm@chadalapaka.com Fri May 27 17:30:18 2011 Return-Path: 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 33237E06BA for ; Fri, 27 May 2011 17:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 UQ7LtJIfsIA1 for ; Fri, 27 May 2011 17:30:17 -0700 (PDT) Received: from snt0-omc1-s3.snt0.hotmail.com (snt0-omc1-s3.snt0.hotmail.com [65.55.90.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3C21EE0618 for ; Fri, 27 May 2011 17:30:17 -0700 (PDT) Received: from SNT131-DS11 ([65.55.90.9]) by snt0-omc1-s3.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 17:30:16 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: "'Hemal Shah'" , , References: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F426C5@MX14A.corp.emc.com> <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <76DBE161893C324BA6D4BB507EE4C384951235CB38@IRVEXCHCCR02.corp.ad.broadcom.com> Date: Fri, 27 May 2011 17:29:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCUfOqLFecrTE8dOe+/hpcfY+kOJQIRzTq9AgfEPyGW79UNkA== Content-Language: en-us X-OriginalArrivalTime: 28 May 2011 00:30:16.0569 (UTC) FILETIME=[6AB06E90:01CC1CCE] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 00:30:18 -0000 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 =20 Mallikarjun and David, =20 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. =20 Do you know why the requirement was changed in the consolidated draft? =20 I would like to keep the requirement optional as stated in the implementation guide and not break backward compatibility. =20 Hemal =20 -----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 =20 Hi David, =20 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. =20 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 =20 The above is of course in addition to consolidating the different = RFCs, and making the related editorial changes. =20 Thanks. =20 Mallikarjun =20 =20 =20 =20 -----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 =20 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). =20 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). =20 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. =20 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. =20 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. =20 Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm =20