From mailman-bounces@ietf.org Mon Nov 1 06:01:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16511 for ; Mon, 1 Nov 2004 06:01:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COaBa-0004MB-Rx for rddp-web-archive@ietf.org; Mon, 01 Nov 2004 06:17:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZJY-0004Ol-Pd for rddp-web-archive@ietf.org; Mon, 01 Nov 2004 05:21:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rddp-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:06:50 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rddp-web-archive@ietf.org: List Password // URL ---- -------- rddp@ietf.org jOsP https://www1.ietf.org/mailman/options/rddp/rddp-web-archive%40ietf.org From rddp-bounces@ietf.org Fri Nov 5 19:55:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07297 for ; Fri, 5 Nov 2004 19:55:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQErO-00015l-12 for rddp-web-archive@ietf.org; Fri, 05 Nov 2004 19:55:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEcS-00034R-KQ; Fri, 05 Nov 2004 19:39:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEYG-0002L0-3D; Fri, 05 Nov 2004 19:35:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05460; Fri, 5 Nov 2004 19:35:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEYH-0000UX-IE; Fri, 05 Nov 2004 19:35:33 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CQERk-00088H-5c; Fri, 05 Nov 2004 19:28:48 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 05 Nov 2004 19:28:48 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rddp mailing list , Internet Architecture Board , rddp chair , RFC Editor Subject: [rddp] Document Action: 'Remote Direct Memory Access (RDMA) over IP Problem Statement' to Informational RFC X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The IESG has approved the following document: - 'Remote Direct Memory Access (RDMA) over IP Problem Statement ' as an Informational RFC This document is the product of the Remote Direct Data Placement Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document demonstrates the fundamental motivation for RDDP, and explains the background of RDMA for the uninitiated. It shows how RDDP helps to avoid copy overhead bottlenecking in systems connected to high-speed networks, and introduces some of the security concerns associated with this approach. Working Group Summary The advancement of this draft was supported by the RDDP WG. Protocol Quality This document was reviewed for the IESG by Jon Peterson. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Nov 6 18:38:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17478 for ; Sat, 6 Nov 2004 18:38:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQa8u-0001JB-HX for rddp-web-archive@ietf.org; Sat, 06 Nov 2004 18:38:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQa4X-0002AL-CO; Sat, 06 Nov 2004 18:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQZv3-0000JN-Cw for rddp@megatron.ietf.org; Sat, 06 Nov 2004 18:24:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16359 for ; Sat, 6 Nov 2004 18:24:26 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQZvD-0000xl-Ux for rddp@ietf.org; Sat, 06 Nov 2004 18:24:43 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA6NOG9s001081; Sat, 6 Nov 2004 18:24:21 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Nov 2004 18:24:18 -0500 Message-ID: To: sgupta@silverbacksystems.com, rddp@ietf.org Subject: RE: [rddp] IPsec & Markers Date: Sat, 6 Nov 2004 18:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.6.0 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, TO_HAS_SPACES 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Somesh, > As far as MPA is concerned, a lot of the discussion > held previously was under the context of an > experimental draft. Actually, MPA is currently targeted to be Informational. > My assumption is that if it is changes to go on > the standards track, it would be entirely open > for another round of discussions. I don't think so. My plan is to resolve technical issues, get the draft through WG Last Call and then determine whether to make it standards track in consultation with the ADs. I believe the rough consensus of the WG is that it is desirable that MPA be standards track. How do you think Informational vs. Standards track affects the technical content of the MPA draft? Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On > Behalf Of Somesh Gupta > Sent: Saturday, October 09, 2004 4:28 PM > To: rddp@ietf.org; Black > Subject: RE: [rddp] IPsec & Markers > > > David, > > As far as MPA is concerned, a lot of the discussion > held previously was under the context of an > experimental draft. > > My assumption is that if it is changes to go on > the standards track, it would be entirely open > for another round of discussions. > > Looking forward to your comments on the topic. > > Thanks, > Somesh > > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Nov 6 18:47:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17840 for ; Sat, 6 Nov 2004 18:47:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQaHi-0001Rt-FF for rddp-web-archive@ietf.org; Sat, 06 Nov 2004 18:47:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQaFA-0004t8-AB; Sat, 06 Nov 2004 18:45:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQaCc-0004PB-4v for rddp@megatron.ietf.org; Sat, 06 Nov 2004 18:42:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17623 for ; Sat, 6 Nov 2004 18:42:34 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQaCo-0001Mq-US for rddp@ietf.org; Sat, 06 Nov 2004 18:42:52 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iA6NgYCk002963 for ; Sat, 6 Nov 2004 18:42:34 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Nov 2004 18:42:34 -0500 Message-ID: To: rddp@ietf.org Date: Sat, 6 Nov 2004 18:42:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.6.0 X-PerlMx-Spam: Gauge=, SPAM=7%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [rddp] DC Agenda X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Better late than never, here's a draft agenda for DC. Sorry for the delay, --David Washington, DC IETF Meeting November 7-12, 2004 --------------------------- Remote Direct Data Placement WG (rddp) CHAIR: David L. Black The RDDP WG works on Remote Direct Data Placement and Remote Direct Memory Access functionality. For more information, please refer to the rddp charter at: http://www.ietf.org/html.charters/rddp-charter.html AGENDA: Subject to change MONDAY, November 8, 2004, 1930-2200 ------------------------------------- - Agenda Bashing and Administrivia (5 min) - Blue Sheets - NOTE WELL - Volunteer to take minutes - Status of drafts (10 min) Drafts need to have clear mandatory to implement security requirements *before* going to WG Last Call. - Security (45 min) (draft-ietf-rddp-security-05.txt) Looks like the -06 update to this draft didn't make it. - RDMAP and DDP (5 min) (draft-ietf-rddp-rdmap-02.txt) (draft-ietf-rddp-ddp-03.txt) Status update - only open issues should be security. - MPA (25 min) (draft-ietf-rddp-mpa-01.txt) Status update. Treatment of marker at start of FPDU. - SCTP mapping and applicability statement (10 min) (draft-ietf-rddp-sctp-01.txt) (draft-ietf-rddp-applicability-02.txt) Status update. Note: WG chair intends to run two rounds of WG Last Calls once suitable drafts are available: 1 - RDMAP, DDP, Security. 2 - MPA, SCTP, Applicability. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 9 16:55:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17740 for ; Tue, 9 Nov 2004 16:55:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdyJ-0007oK-SD for rddp-web-archive@ietf.org; Tue, 09 Nov 2004 16:56:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdnn-0008Jl-Uc; Tue, 09 Nov 2004 16:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdlk-00080H-0v for rddp@megatron.ietf.org; Tue, 09 Nov 2004 16:43:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16394 for ; Tue, 9 Nov 2004 16:43:13 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdmY-0007UP-TT for rddp@ietf.org; Tue, 09 Nov 2004 16:44:07 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 9 Nov 2004 13:42:43 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 13:42:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Nov 2004 13:42:43 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 9 Nov 2004 13:42:42 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Nov 2004 13:42:42 -0800 Message-ID: Thread-Topic: interoperability with RDMAC and IETF Thread-Index: AcTGfu9UCmjF6fUgSte9xovhPfurag== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 09 Nov 2004 21:42:42.0908 (UTC) FILETIME=[0AF701C0:01C4C6A5] X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Subject: [rddp] interoperability with RDMAC and IETF X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0502294270==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a multi-part message in MIME format. --===============0502294270== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C6A5.0AFBA9B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C6A5.0AFBA9B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A quick update on interoperating between RDMAC and IETF RDMAP/DDP/MPA wire protocols. Wanted to get a quick summary of a possible approach out to see if the work group felt this was a reasonable approach. =20 Post meeting, over several beers last night, John Carrier and I think we have a solution that defines a 3x3 interoperability matrix where 7 out of the 9 cells allow interoperability (the other 2 must abort because markers were disabled on one side but not the other). We're going to write up a proposal soon. It entails minor changes to IETF MPA (primarily change the version number of the initial negotiation to one), and also defines the new capabilities that would need to be present in an IETF RNIC if the implementer wants to be downward compatible (primary issue is being able to tell the RNIC for a specific QP to generate DDP/RDMAP packets with version number =3D 0).=20 =20 It entails no changes to the RDMAC specifications, but does require RDMAC RNIC ULPs to communicate in streaming mode prior to transition to RDMA mode, and that the format of the data be the MPA initial negotiation (REQ/REP) frames defined within the IETF, but using a version number of zero. =20 David, does this high level description of the approach seem reasonable? =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C4C6A5.0AFBA9B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A quick update on interoperating between RDMAC and = IETF RDMAP/DDP/MPA wire protocols. Wanted to get a quick summary of a = possible approach out to see if the work group felt this was a reasonable = approach.

 

Post meeting, over several beers last night, John = Carrier and I think we have a solution that defines a 3x3 interoperability = matrix where 7 out of the 9 cells allow interoperability (the other 2 must abort = because markers were disabled on one side but not the other). We’re going = to write up a proposal soon. It entails minor changes to IETF MPA = (primarily change the version number of the initial negotiation to one), and also defines = the new capabilities that would need to be present in an IETF RNIC if the = implementer wants to be downward compatible (primary issue is being able to tell the = RNIC for a specific QP to generate DDP/RDMAP packets with version number =3D = 0).

 

It entails no changes to the RDMAC specifications, = but does require RDMAC RNIC ULPs to communicate in streaming mode prior to = transition to RDMA mode, and that the format of the data be the MPA initial = negotiation (REQ/REP) frames defined within the IETF, but using a version number of = zero.

 

David, does this high level description of the = approach seem reasonable?

 

 

Jim

 

 

 

------_=_NextPart_001_01C4C6A5.0AFBA9B7-- --===============0502294270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0502294270==-- From rddp-bounces@ietf.org Fri Nov 12 17:52:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08929 for ; Fri, 12 Nov 2004 17:52:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkJC-0004nk-DI for rddp-web-archive@ietf.org; Fri, 12 Nov 2004 17:54:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSkEi-0002f3-WB; Fri, 12 Nov 2004 17:49:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSk8s-0000v5-Qg for rddp@megatron.ietf.org; Fri, 12 Nov 2004 17:43:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08069 for ; Fri, 12 Nov 2004 17:43:39 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSkAL-0004PZ-5B for rddp@ietf.org; Fri, 12 Nov 2004 17:45:13 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AC93B51900BC; Fri, 12 Nov 2004 17:43:31 -0500 From: "Barry Reinhold" To: "RDDP" Date: Fri, 12 Nov 2004 17:43:25 -0500 Message-ID: <008201c4c909$084c18f0$217fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: iwarp-tech@iol.unh.edu Subject: [rddp] Conformance Question X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Working on an interoperability issue related to section 3.6.1.1 (CRC bit paragraph) of MPA, which states: This bit (CRC bit) declares an endpoint's preferred CRC usage. When this field is '0' in the "MPA Request Frame" and the "MPA Reply Frame", CRCs MUST not be checked and need not be generated by either endpoint. When this bit is '1' in either the "MPA Request Frame" or "MPA Reply Frame", CRCs MUST be generated and checked by both endpoints. The question: If an MPA request frame has set the CRC bit to 1, can the MPA replay frame's CRC bit be set to 0 without violating the draft. >From a strict reading of the draft there does not seem to be a requirement that a "1" in the request results in a "1" in the reply, only that both devices must use CRCs. So is the meaning of a "0" in the reply frame "I'm not using CRCs, or is it I didn't want to use CRCs". Further if the requester sees a 0 in the reply frame after setting the CRC bit to 1 in the request frame should it reset the connection? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Nov 13 09:39:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08061 for ; Sat, 13 Nov 2004 09:39:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSz56-0002JP-Gf for rddp-web-archive@ietf.org; Sat, 13 Nov 2004 09:40:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSytx-0000Bp-A2; Sat, 13 Nov 2004 09:29:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSyjG-0005i5-JH for rddp@megatron.ietf.org; Sat, 13 Nov 2004 09:18:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07301 for ; Sat, 13 Nov 2004 09:18:13 -0500 (EST) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSykr-0001RM-2h for rddp@ietf.org; Sat, 13 Nov 2004 09:19:53 -0500 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id iADEHfW07585; Sat, 13 Nov 2004 06:17:42 -0800 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id iADEHfx08658; Sat, 13 Nov 2004 06:17:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Nov 2004 06:17:42 -0800 Message-ID: Thread-Topic: iwarp-tech Conformance Question thread-index: AcTJCR7CZMdSevNfTBKEGVWqkhRTqwAgVy4g From: "Carrier, John" To: "Barry Reinhold" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: iwarp-tech@iol.unh.edu, RDDP Subject: [rddp] RE: iwarp-tech Conformance Question X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Hi Barry, my understanding is that CRCs are required unless both sides set the CRC = bit to '0'. If the reply frame from the responder has the C bit set to = zero after the request frame had it set to one, then CRCs are required. = The responder may not be using them on receive, but it has to accept = them from the initiator and it has to generate them on transmit=20 --jc > -----Original Message----- > From: owner-iwarp-tech@io.iol.unh.edu > [mailto:owner-iwarp-tech@io.iol.unh.edu]On Behalf Of Barry Reinhold > Sent: Friday, November 12, 2004 2:43 PM > To: RDDP > Cc: iwarp-tech@iol.unh.edu > Subject: iwarp-tech Conformance Question >=20 >=20 > Working on an interoperability issue related to section=20 > 3.6.1.1 (CRC bit > paragraph) of MPA, which states: >=20 > This bit (CRC bit) declares an endpoint's preferred CRC=20 > usage. When this > field is '0' in the "MPA Request Frame" and the "MPA Reply=20 > Frame", CRCs > MUST not be checked and need not be generated by either endpoint. When > this bit is '1' in either the "MPA Request Frame" or "MPA=20 > Reply Frame", > CRCs MUST be generated and checked by both endpoints. >=20 > The question: >=20 > If an MPA request frame has set the CRC bit to 1, can the MPA replay > frame's CRC bit be set to 0 without violating the draft. >=20 > >From a strict reading of the draft there does not seem to be a > requirement that a "1" in the request results in a "1" in the reply, > only that both devices must use CRCs. >=20 > So is the meaning of a "0" in the reply frame "I'm not using=20 > CRCs, or is > it I didn't want to use CRCs". Further if the requester sees=20 > a 0 in the > reply frame after setting the CRC bit to 1 in the request frame should > it reset the connection? >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Sat Nov 13 14:38:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25594 for ; Sat, 13 Nov 2004 14:38:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT3kh-0006zz-V1 for rddp-web-archive@ietf.org; Sat, 13 Nov 2004 14:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT3ba-00042P-Jl; Sat, 13 Nov 2004 14:30:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CT3U3-0003Dc-6k for rddp@megatron.ietf.org; Sat, 13 Nov 2004 14:22:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24887 for ; Sat, 13 Nov 2004 14:22:50 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CT3Vf-0006NG-TN for rddp@ietf.org; Sat, 13 Nov 2004 14:24:33 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iADJMI7S828734 for ; Sat, 13 Nov 2004 14:22:18 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iADJMLCC081918 for ; Sat, 13 Nov 2004 12:22:21 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iADJMHpt026232 for ; Sat, 13 Nov 2004 12:22:17 -0700 Received: from d03nm130.boulder.ibm.com (d03nm130.boulder.ibm.com [9.17.195.174]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iADJMHvZ026223 for ; Sat, 13 Nov 2004 12:22:17 -0700 To: RDDP X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Sat, 13 Nov 2004 13:22:14 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 11/13/2004 12:22:17 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Subject: [rddp] RDMAP Security Section X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1315042644==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e --===============1315042644== Content-type: multipart/alternative; Boundary="0__=09BBE5D8DFFB37F08f9e8a93df938690918c09BBE5D8DFFB37F0" Content-Disposition: inline --0__=09BBE5D8DFFB37F08f9e8a93df938690918c09BBE5D8DFFB37F0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, At Monday's IETF-61 RDDP WG session, we discussed the security section= of the RDMAP specification. We proposed that we discuss and review on thi= s reflector the overall structure of the security section. Once we have general agreement on the normative contents of that section, the autho= rs (which will now include Bernard Metzler) will submit an updated RDMAP specification draft with the proposed text. Sooo... following is a recap of what was discussed on Monday and the proposed normative statements. Of course, each normative statement wil= l have a little informative wrapper that puts the normative text in conte= xt, but that text will be vetted out when the update to the RDMAP spec is published. Recap of the RDMAP Security Secion content - As discussed on Monday. The RDMAP Spec's security section will include normative text that describes **all** the security semantics that are relevant to the RD= MA Protocol and associated informative text. The latter will include extensive references to the RDMASEC for details. The proposed RDMAP Spec's security sections, consist of: Summary of the Security Model and General Assumptions Type of section =3D Informative Contents: Attackable Resources Types of Attackers and Types of Attacks Trust and Resource Sharing Summary of RDMAP specific Security Requirements Type of section =3D Normative Contents: Security Mechanisms RDMAP Implementation Requirements Non-Contents: Responsibilities of the ULP are left in [RDMASEC] Security Services for RDMAP Type of section =3D Mix Contents: Informative summary of Available Security Services Normative Requirements for IPsec Services for RDMAP (Xref RFC3723) Proposed Normative Statements for the "Summary of RDMAP specific Securi= ty Requirements" section: Two components MUST be provided to implement the RDMAP: an RDMA enab= led NIC (RNIC) and a Privileged Resource Manager (PRM). The RNIC MUST implement the RDMA wire Protocol and perform the security semantics described in this section. The PRM MUST implement the security seman= tics described in this section. RDMAP enabled NIC (RNIC) Requirements An RNIC MUST ensure that a specific Stream in a specific Protecti= on Domain cannot access an STag in a different Protection Domain. An RNIC MUST ensure that if an STag is limited in scope to a sing= le Stream, no other Stream can use the STag. An RNIC MUST ensure that a Remote Peer is not able to access memo= ry outside of the buffer specified when the STag was enabled for rem= ote access. An RNIC MUST provide a mechanism for the ULP to establish and rev= oke the association of a ULP Buffer to an STag and TO range. An RNIC MUST provide a mechanism for the ULP to establish and rev= oke read, write, or read and write access to the ULP Buffer reference= d by an STag. An RNIC MUST ensure that the network interface can no longer modi= fy an advertised buffer after the ULP revokes remote access rights f= or an STag. An RNIC MUST NOT enable sharing a CQ across ULPs that do not shar= e partial mutual trust. An RNIC MUST ensure that if a CQ overflows, any Streams which do = not use the CQ MUST remain unaffected. An RNIC implementation SHOULD provide a mechanism to cap the numb= er of outstanding RDMA Read Requests. An RNIC MUST NOT enable firmware to be loaded on the RNIC directl= y from an untrusted Local Peer or Remote Peer, unless the Peer is properly authenticated (by a mechanism outside the scope of this specification. The mechanism presumably entails authenticating th= at the remote ULP has the right to perform the update), and the upda= te is done via a secure protocol, such as IPsec. Privileged Resources Manager Requirement All Non-Privileged ULP interactions with the RNIC Engine that cou= ld affect other ULPs MUST be done using the Privileged Resource Mana= ger as a proxy. All ULP resource allocation requests for scarce resources MUST al= so be done using a Privileged Resource Manager. The Privileged Resource Manager MUST NOT assume different ULPs sh= are Partial Mutual Trust unless there is a mechanism to ensure that t= he ULPs do indeed share partial mutual trust. If Non-Privileged ULPs are supported, the Privileged Resource Man= ager MUST verify that the Non-Privileged ULP has the right to access a= specific Data Buffer before allowing an STag for which the ULP ha= s access rights to be associated with a specific Data Buffer. The Privileged Resource Manager MUST control the allocation of CQ= entries. The Privileged Resource Manager SHOULD prevent a Local Peer from allocating more than its fair share of resources. RDMA Read Request Queue resource consumption MUST be controlled b= y the Privileged Resource Manager such that RDMAP/DDP Streams which= do not share Partial Mutual Trust do not share RDMA Read Request Que= ue resources. If an RNIC provides the ability to share receive buffers across multiple Streams, the combination of the RNIC and the Privileged Resource Manager MUST be able to detect if the Remote Peer is attempting to consume more than its fair share of resources so th= at the Local Peer can apply countermeasures to detect and prevent th= e attack. Please review the above normative text proposal for completeness and accuracy. Thanks, Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685= --0__=09BBE5D8DFFB37F08f9e8a93df938690918c09BBE5D8DFFB37F0 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Folks,

At Monday's IETF-61 RDDP WG session, we discussed the security section= of the RDMAP specification. We proposed that we discuss and review on= this reflector the overall structure of the security section. Once we= have general agreement on the normative contents of that section, the= authors (which will now include Bernard Metzler) will submit an update= d RDMAP specification draft with the proposed text.

Sooo... following is a recap of what was discussed on Monday and the p= roposed normative statements. Of course, each normative statement will= have a little informative wrapper that puts the normative text in cont= ext, but that text will be vetted out when the update to the RDMAP spe= c is published.

Recap of the RDMAP Security Secion content - As discussed on Monday.

    The RDMAP Spec's security section will include normative text that = describes **all** the security semantics that are relevant to the RDMA = Protocol and associated informative text. The latter will include exte= nsive references to the RDMASEC for details.

    The proposed RDMAP Spec's security sections, consist of:
      Summary of the Security Model and General Assumptions
        Type of section =3D Informative
        Contents:
          Attackable Resources
          Types of Attackers and Types of Attacks
          Trust and Resource Sharing
      Summary of RDMAP specific Security Requirements
        Type of section =3D Normative
        Contents:
          Security Mechanisms
          RDMAP Implementation Requirements
        Non-Contents:
          Responsibilities of the ULP are left in [RDMASEC]
      Security Services for RDMAP
        Type of section =3D Mix
        Contents:
          Informative summary of Available Security Services
          Normative Requirements for IPsec Services for RDMAP (Xref RFC3723)
        =

Proposed Normative Statements for the "Summary of RDMAP specific S= ecurity Requirements" section:
    Two components MUST be provided to implement the RDMAP: an RDMA ena= bled NIC (RNIC) and a Privileged Resource Manager (PRM). The RNIC MUST= implement the RDMA wire Protocol and perform the security semantics de= scribed in this section. The PRM MUST implement the security semantics = described in this section.
    RDMAP enabled NIC (RNIC) Requirements
      An RNIC MUST ensure that a specific Stream in a specific Protection= Domain cannot access an STag in a different Protection Domain.
      An RNIC MUST ensure that if an STag is limited in scope to a single Str= eam, no other Stream can use the STag.
      An RNIC MUST ensure that a Remote Peer is not able to access memory out= side of the buffer specified when the STag was enabled for remote acces= s.
      An RNIC MUST provide a mechanism for the ULP to establish and revoke th= e association of a ULP Buffer to an STag and TO range.
      An RNIC MUST provide a mechanism for the ULP to establish and revoke re= ad, write, or read and write access to the ULP Buffer referenced by an = STag.
      An RNIC MUST ensure that the network interface can no longer modify an = advertised buffer after the ULP revokes remote access rights for an STa= g.
      An RNIC MUST NOT enable sharing a CQ across ULPs that do not share part= ial mutual trust.
      An RNIC MUST ensure that if a CQ overflows, any Streams which do not us= e the CQ MUST remain unaffected.
      An RNIC implementation SHOULD provide a mechanism to cap the number of = outstanding RDMA Read Requests.
      An RNIC MUST NOT enable firmware to be loaded on the RNIC directly=0Bfr= om an untrusted Local Peer or Remote Peer, unless the Peer is properly = authenticated (by a mechanism outside the scope of this specification. = The mechanism presumably entails authenticating that the remote ULP has= the right to perform the update), and the update is done via a secure = protocol, such as IPsec.
    Privileged Resources Manager Requirement
      All Non-Privileged ULP interactions with the RNIC Engine that could= affect other ULPs MUST be done using the Privileged Resource Manager a= s a proxy.
      All ULP resource allocation requests for scarce resources MUST also be = done using a Privileged Resource Manager.
      The Privileged Resource Manager MUST NOT assume different ULPs share Pa= rtial Mutual Trust unless there is a mechanism to ensure that the ULPs = do indeed share partial mutual trust.
      If Non-Privileged ULPs are supported, the Privileged Resource Manager M= UST verify that the Non-Privileged ULP has the right to access a specif= ic Data Buffer before allowing an STag for which the ULP has access rig= hts to be associated with a specific Data Buffer.
      The Privileged Resource Manager MUST control the allocation of CQ entri= es.
      The Privileged Resource Manager SHOULD prevent a Local Peer from alloca= ting more than its fair share of resources.
      RDMA Read Request Queue resource consumption MUST be controlled by the = Privileged Resource Manager such that RDMAP/DDP Streams which do not sh= are Partial Mutual Trust do not share RDMA Read Request Queue resources= .
      If an RNIC provides the ability to share receive buffers across multipl= e Streams, the combination of the RNIC and the Privileged Resource Mana= ger MUST be able to detect if the Remote Peer is attempting to consume = more than its fair share of resources so that the Local Peer can apply = countermeasures to detect and prevent the attack.

Please review the above normative text proposal for completeness and ac= curacy.

Thanks,

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685
= --0__=09BBE5D8DFFB37F08f9e8a93df938690918c09BBE5D8DFFB37F0-- --===============1315042644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1315042644==-- From rddp-bounces@ietf.org Sun Nov 14 19:51:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26416 for ; Sun, 14 Nov 2004 19:51:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTV80-0000Mh-Mg for rddp-web-archive@ietf.org; Sun, 14 Nov 2004 19:53:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTV4m-0000Oe-4L; Sun, 14 Nov 2004 19:50:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTV1N-00007q-3C for rddp@megatron.ietf.org; Sun, 14 Nov 2004 19:47:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26204 for ; Sun, 14 Nov 2004 19:47:03 -0500 (EST) Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTV3D-0000Dy-8G for rddp@ietf.org; Sun, 14 Nov 2004 19:49:02 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 41F655F2; Sun, 14 Nov 2004 18:46:30 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 14 Nov 2004 18:46:30 -0600 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] RE: iwarp-tech Conformance Question Date: Sun, 14 Nov 2004 18:46:28 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762F08A689@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] RE: iwarp-tech Conformance Question Thread-Index: AcTJCR7CZMdSevNfTBKEGVWqkhRTqwAgVy4gAEhd5vA= From: "Culley, Paul" To: "Carrier, John" , "Barry Reinhold" X-OriginalArrivalTime: 15 Nov 2004 00:46:30.0070 (UTC) FILETIME=[8BBB2560:01C4CAAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: iwarp-tech@iol.unh.edu, RDDP X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable If the requestor has set his to 1, then it does not matter what the reply frame has in it, CRCs must be generated by both ends, and to be compliant, must also be checked by both ends. I suppose that a non-compliant implementation could not check, or could tear down in this case, but then it is not an IETF RNIC. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Carrier, John > Sent: Saturday, November 13, 2004 8:18 AM > To: Barry Reinhold > Cc: iwarp-tech@iol.unh.edu; RDDP > Subject: [rddp] RE: iwarp-tech Conformance Question >=20 > Hi Barry, >=20 > my understanding is that CRCs are required unless both sides=20 > set the CRC bit to '0'. If the reply frame from the=20 > responder has the C bit set to zero after the request frame=20 > had it set to one, then CRCs are required. The responder may=20 > not be using them on receive, but it has to accept them from=20 > the initiator and it has to generate them on transmit=20 >=20 > --jc >=20 > > -----Original Message----- > > From: owner-iwarp-tech@io.iol.unh.edu > > [mailto:owner-iwarp-tech@io.iol.unh.edu]On Behalf Of Barry Reinhold > > Sent: Friday, November 12, 2004 2:43 PM > > To: RDDP > > Cc: iwarp-tech@iol.unh.edu > > Subject: iwarp-tech Conformance Question > >=20 > >=20 > > Working on an interoperability issue related to section > > 3.6.1.1 (CRC bit > > paragraph) of MPA, which states: > >=20 > > This bit (CRC bit) declares an endpoint's preferred CRC usage. When=20 > > this field is '0' in the "MPA Request Frame" and the "MPA Reply=20 > > Frame", CRCs MUST not be checked and need not be generated=20 > by either=20 > > endpoint. When this bit is '1' in either the "MPA Request Frame" or=20 > > "MPA Reply Frame", CRCs MUST be generated and checked by both=20 > > endpoints. > >=20 > > The question: > >=20 > > If an MPA request frame has set the CRC bit to 1, can the=20 > MPA replay=20 > > frame's CRC bit be set to 0 without violating the draft. > >=20 > > >From a strict reading of the draft there does not seem to be a > > requirement that a "1" in the request results in a "1" in=20 > the reply,=20 > > only that both devices must use CRCs. > >=20 > > So is the meaning of a "0" in the reply frame "I'm not=20 > using CRCs, or=20 > > is it I didn't want to use CRCs". Further if the requester=20 > sees a 0 in=20 > > the reply frame after setting the CRC bit to 1 in the request frame=20 > > should it reset the connection? > >=20 > > Barry Reinhold > > Lamprey Networks > > bbr@lampreynetworks.com > > (603) 868-8411 > > =20 > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Nov 15 11:25:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07179 for ; Mon, 15 Nov 2004 11:25:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTjhW-0001zP-Sk for rddp-web-archive@ietf.org; Mon, 15 Nov 2004 11:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTje1-0003qh-Or; Mon, 15 Nov 2004 11:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTjaK-0003DY-1N for rddp@megatron.ietf.org; Mon, 15 Nov 2004 11:20:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06269 for ; Mon, 15 Nov 2004 11:20:05 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTjcB-0001nv-JT for rddp@ietf.org; Mon, 15 Nov 2004 11:22:13 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A72727AE0134; Mon, 15 Nov 2004 11:19:51 -0500 From: "Barry Reinhold" To: "RDDP" Date: Mon, 15 Nov 2004 11:19:46 -0500 Message-ID: <001b01c4cb2e$ef32bb30$7f90fea9@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Subject: [rddp] RE: Conformance Question X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Ok, I think I am hearing that the consensus of the group is that a conformant MPA device SHALL NOT reset a TCP connection if it receives a MPA Startup Reply frame in which the CRC bit is 0 when it sent out a MPA Startup Request frame with the bit set to 1. Any objections to this understanding? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Nov 15 19:20:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29981 for ; Mon, 15 Nov 2004 19:20:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTr6x-0006f9-RF for rddp-web-archive@ietf.org; Mon, 15 Nov 2004 19:22:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTr2N-0008NU-MT; Mon, 15 Nov 2004 19:17:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTr0e-00082y-KC for rddp@megatron.ietf.org; Mon, 15 Nov 2004 19:15:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29463 for ; Mon, 15 Nov 2004 19:15:45 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTr2k-0006Xx-Hf for rddp@ietf.org; Mon, 15 Nov 2004 19:17:58 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAG0Fjc2007970 for ; Mon, 15 Nov 2004 19:15:45 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Nov 2004 19:15:45 -0500 Message-ID: To: rddp@ietf.org Date: Mon, 15 Nov 2004 19:15:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.15.3 X-PerlMx-Spam: Gauge=, SPAM=7%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [rddp] Draft DC minutes X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 This is also an opportunity for anyone on the list to object to decisions taken in DC - they're flagged in [square brackets]. In the absence of objection, those decisions are the rough consensus of the RDDP WG. Also note that "?" is a bullet in this (Microsoft strikes again ...), it does not introduce a question or open issue - those are indicated by "?" after a word (generally end of a line of text). Thanks, --David RDDP Minutes - 61st IETF Meeting DRAFT 11/8/2004 Washington D.C. -------------------------------- Thanks to Hemal V. Shah for taking the minutes * Agenda bashing * Status of drafts (from all authors) o Problem statement has been in RFC editor queue. o Architecture document very close to being in RFC editor queue. o RDMAP/DDP drafts are not ready for WG last call at this point. Security sections need to be checked for MUST implement IPsec (RFC 3723). Only open issues are security requirements. o Applicability draft (when to use SCTP versus TCP) in process. o Once we have security requirements in RDMAP/DDP drafts, then security, DDP, and RDMAP drafts will go to the first round of WG Last Call. o Second batch of last calls will be MPA, SCTP, and Applicability. * Security draft (Presenter: Jim Pinkerton) [B] o Major changes ? Quickly iterated -03, -04, and -05 in one month. ? Changed the draft to be standards track ? Resolved several TBDs: channel binding, connection hijacking, finished summary tables of attacks in appendix ? New or substantially revised appendices: appendix A is normative, appendices B & C are informative. o Major new normative statements ? Most RECOMMENDED statements were changed to MUST/MAY. ? IPsec is MUST implement and OPTIONAL to use ? Resource manager * MUST be used if a scarce resource * MUST NOT assume shared partial mutual trust o Planned changes to -06 draft ? Resolve some more TBDs. ? Need review. * RDMAP Security issues (Presenter: Renato Recio) [C] o RDMAP and DDP drafts need to have security requirements. o Approach ? List out informative text ? Summary of RDMAP specific security requirements ? Security services for RDMAP o Security Model and general assumptions ? Mainly list the attacks, attack types, and resources. Details are in RDMA security draft. o RDMAP specific security requirements ? Privileged resource manager requirements o There are some requirements that might be added to RDMAP and RDMA security drafts o Need to revise MUST requirement on firmware load in RDMA security draft. o List of normative requirements will be sent to the reflector. o Email discussion on the reflector on the normative text. o DDP draft will address the requirements on the list through the discussions and then it will be added to the draft. * MPA (Presenter: Paul Culley) [D] o Issues ? Need to add text from the security draft ? Marker pointer clarification ? Minor clarification of meaning of "connection establishment" o Zero-markers ? Where do the non-zero markers of the FPDU point to? * ULPDU_length * Or Zero-marker ? Marker should point to ULPDU_length instead of start of FPDU-Hdr [sense of room] o IPsec requirement is it needed in MPA? ? Need to cross-reference requirement from DDP. * Safest thing to do is have MPA list IPsec as MUST implement and optional to use. Derived from DDP requirement as DDP is the only protocol that can be above MPA. [no objection] * SCTP mapping (Presenter: Caitlin Bestler) [E] o Main changes ? Updated to new boilerplate (e.g., IPR) ? SCTP/MPA differences noted * Size of private data 512 B for SCTP mapping * MPA requires first FPDU come from initiating side * In MPA spec, we need specify that MPA MUST allow private data up to 512B. ? Session control changed to align with MPA * Only one exchange per side. Eliminated negotiate message. * Added explicit reject message. ? Dealt with small PDUs * iWARP interoperability w/RDMAC versions + APIs (Presenter: John Carrier) [F] o Interoperability on the wire ? RDMAC/IETF RDMAP/DDP protocols have same semantics and wire protocol format, but they both use different versions. ? No standard way for ULPs to exchange version information that could be used to configure the RNICs ? If IETF implementation decides to turn markers off, then IETF RNIC won't interoperate with RDMAC RNIC. o Interoperability above RDDP ? Discussion on standardizing private data format - Not appropriate to specify ULP data format [sense of room] ? Add a requirement on that version information should be available to ULP [sense of room] ? No consensus on the private data format. * Worry around breaking the existing implementations. ? Within a week, the text on the interoperability will be generated and sent to list. It'll be headed for appendices of the MPA, DDP, and RDMAP protocol drafts. [no objection] * Next steps o Revise security draft. o Add appropriate security requirements in DDP & RDMAP. * Meeting adjourned @ 9:30pm on November 8, 2004. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 16 00:36:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05139 for ; Tue, 16 Nov 2004 00:36:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTw2v-0003vP-8c for rddp-web-archive@ietf.org; Tue, 16 Nov 2004 00:38:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw02-0006d8-QD; Tue, 16 Nov 2004 00:35:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTvzF-0006XP-IK for rddp@megatron.ietf.org; Tue, 16 Nov 2004 00:34:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05065 for ; Tue, 16 Nov 2004 00:34:38 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTw1O-0003tu-BZ for rddp@ietf.org; Tue, 16 Nov 2004 00:36:54 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Nov 2004 21:34:09 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 15 Nov 2004 21:34:09 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 15 Nov 2004 21:34:08 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 15 Nov 2004 21:34:08 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] RE: Conformance Question Date: Mon, 15 Nov 2004 21:34:08 -0800 Message-ID: Thread-Topic: [rddp] RE: Conformance Question Thread-Index: AcTLNRu/nSIzwhVrTia/dcc8qTWh8wANYvUg From: "Jim Pinkerton" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 16 Nov 2004 05:34:08.0413 (UTC) FILETIME=[E4EB0CD0:01C4CB9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable I agree with the summary, but am concerned on re-reading the text. I'd suggest a couple of minor changes for clarity: I would recommend we clarify some text elsewhere in the document. Specifically section 5.2 CRC Calculation. The text that states=20 "(2) only negotiate the non-use of CRC on the explicit request of the ..." We change to "only attempt to negotiate..." And a little after this, also in section 5.2 states: "If an MPA instance has declared that it does not require CRCs, it MUST turn off CRC checking immediately after receipt of an MPA mode declaration indicating that its peer also does not require CRCs." Should be changed to say (note that MPA mode declaration is not a defined term in the spec): "If an MPA stream has successfully negotiated during the MPA Startup Phase (see section 6) for CRCs to not be enabled, it MUST turn off CRC checking immediately after receipt of the first (and only) MPA Startup Phase Message."=20 Jim > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Barry Reinhold > Sent: Monday, November 15, 2004 8:20 AM > To: RDDP > Subject: [rddp] RE: Conformance Question >=20 > Ok, > I think I am hearing that the consensus of the group is that a > conformant MPA device SHALL NOT reset a TCP connection if it receives a > MPA Startup Reply frame in which the CRC bit is 0 when it sent out a MPA > Startup Request frame with the bit set to 1. >=20 > Any objections to this understanding? >=20 >=20 >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Nov 17 06:54:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17503 for ; Wed, 17 Nov 2004 06:54:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUOQk-0006vT-Qa for rddp-web-archive@ietf.org; Wed, 17 Nov 2004 06:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUONF-0007P6-9S; Wed, 17 Nov 2004 06:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUOJb-0006ju-Al for rddp@megatron.ietf.org; Wed, 17 Nov 2004 06:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17055 for ; Wed, 17 Nov 2004 06:49:32 -0500 (EST) Received: from bay4-dav27.bay4.hotmail.com ([65.54.171.57] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUOM0-0006nb-1v for rddp@ietf.org; Wed, 17 Nov 2004 06:52:04 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Nov 2004 03:49:02 -0800 Received: from 203.197.250.24 by BAY4-DAV27.phx.gbl with DAV; Wed, 17 Nov 2004 11:48:25 +0000 X-Originating-IP: [203.197.250.24] X-Originating-Email: [rajiv_das@msn.com] X-Sender: rajiv_das@msn.com From: "Rajiv Das" To: Date: Wed, 17 Nov 2004 17:13:59 +0530 Organization: Rajiv(Personal) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcTMmrhzZsQ3rvLLTj6JyTA+rmKe6g== Importance: High Message-ID: X-OriginalArrivalTime: 17 Nov 2004 11:49:02.0073 (UTC) FILETIME=[6E98EE90:01C4CC9B] X-Spam-Score: 3.9 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [rddp] Suggestions for Consolidation the Specification Documents X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Hi, I was just going through all the RDDP Internet Drafts last weekend and I get a feeling that: 1. The Definitions/Glossary section needs to refer to a master copy so that variations are not there. 2. The Security section in all the drafts should refer to the Security draft to reduce redundancy. It's my feeling that the Architecture document should probably provide the backbone, something which is not really self-evident now. The diagram below is intended to show, what I feel can be a reasonable cross-reference scenario. I realize that the reader must get a complete idea of what each document intends to convey without too many references, but current feeling is like the documents aren't tied together anywhere. I believe a federal structure is the optimum. I feel that with this consolidation, the documents will provide an even better picture of RDDP. |==============| | 1.Concerns | |==============| | --------------------------------- | V +==============================================+ +========================================+ + 2. ARCHITECTURE + | 3/4/5/6. RDMA/DDP Spec,RDMA Appl,Prb St| +----------------------------------------------+ |----------------------------------------| + Definitions +<--------| Norm Ref to Definitions | +----------------------------------------------+ |----------------------------------------| + Overview of RDMA/DDP Operations etc. + | Norm Ref to Security |-| +----------------------------------------------+ |----------------------------------------| | + Normative Reference to RDMA Specification + | Other Contents | | +----------------------------------------------+ +========================================+ | + Normative Reference to DDP Specification + | +----------------------------------------------+ +==============+ | + Normative Reference to Security +------------->+ 7.Security +<--------------------- +----------------------------------------------+ +==============+ + Normative Reference to RDMA Applicablility + +==============================================+ I believe I have been brief :-) ---------------------- Thanks, Rajiv Das Wipro Technologies _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Thu Nov 18 02:01:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08966 for ; Thu, 18 Nov 2004 02:01:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUgLE-0001ZQ-0c for rddp-web-archive@ietf.org; Thu, 18 Nov 2004 02:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUgCA-0005I3-IL; Thu, 18 Nov 2004 01:55:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUg66-0003oW-6T for rddp@megatron.ietf.org; Thu, 18 Nov 2004 01:48:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06625 for ; Thu, 18 Nov 2004 01:48:48 -0500 (EST) Received: from bay4-dav13.bay4.hotmail.com ([65.54.170.117] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUg8c-0001K0-8r for rddp@ietf.org; Thu, 18 Nov 2004 01:51:29 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Nov 2004 22:47:01 -0800 Message-ID: Received: from 203.197.250.24 by BAY4-DAV13.phx.gbl with DAV; Thu, 18 Nov 2004 06:46:58 +0000 X-Originating-IP: [203.197.250.24] X-Originating-Email: [rajiv_das@msn.com] X-Sender: rajiv_das@msn.com From: "Rajiv Das" To: Date: Thu, 18 Nov 2004 12:12:23 +0530 Organization: Rajiv(Personal) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcTNOQnQu9J+wKtXTKS1Xm56F07dJgAAGXHgAAAOoeA= X-OriginalArrivalTime: 18 Nov 2004 06:47:01.0474 (UTC) FILETIME=[684AB420:01C4CD3A] X-Spam-Score: 3.7 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [rddp] Suggestions for Consolidation the Specification Documents X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Hi, [This is a repost with modifications] I was just going through all the RDDP Internet Drafts last weekend and I get a feeling that: 1. The Definitions/Glossary section needs to refer to a master copy so that variations are not there. 2. The Security section in all the drafts should refer to the Security draft to reduce redundancy. It's my feeling that the Architecture document should probably provide the backbone, something which is not really self-evident now. The diagram below is intended to show, what I feel can be a reasonable cross-reference scenario. I realize that the reader must get a complete idea of what each document intends to convey without too many references, but the current feeling is like the documents aren't tied together anywhere. I believe a federal structure is the optimum. I feel that with this consolidation, the documents will provide an even better picture of RDDP. |==============| | 1.Concerns | |==============| | V +==============================================+ + 2. ARCHITECTURE + +----------------------------------------------+ + Definitions +<------- +----------------------------------------------+ | + Overview of RDMA/DDP Operations etc. + | +----------------------------------------------+ | + Normative Reference to RDMA Specification + | +----------------------------------------------+ | + Normative Reference to DDP Specification + | +----------------------------------------------+ | + Normative Reference to Security +---- | +----------------------------------------------+ | | + Normative Reference to RDMA Applicablility + | | +==============================================+ | | | | +========================+--------------------------|--| + 3/4/5/6. RDMA/DDP Spec | | | RDMA Appl,Prb St | | |------------------------| | | Norm Ref to Definitions| | |------------------------| | | Norm Ref to Security |-| | |------------------------| | | | Other Contents | | | +========================+ | | | | | | +==============+ | | + 7.Security +<-----------<-----------------------| +==============+ I believe I have got my understanding correct and hope I've been brief :-) ---------------------- Thanks, Rajiv Das Wipro Technologies _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Thu Nov 18 09:35:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28741 for ; Thu, 18 Nov 2004 09:35:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnQX-0002g3-9g for rddp-web-archive@ietf.org; Thu, 18 Nov 2004 09:38:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnEi-00078o-0k; Thu, 18 Nov 2004 09:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUn7f-0004j4-1d for rddp@megatron.ietf.org; Thu, 18 Nov 2004 09:18:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27328 for ; Thu, 18 Nov 2004 09:18:52 -0500 (EST) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnAH-0002Fk-Ry for rddp@ietf.org; Thu, 18 Nov 2004 09:21:38 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAIEIMCB207982 for ; Thu, 18 Nov 2004 09:18:22 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAIEIMZa261566 for ; Thu, 18 Nov 2004 07:18:22 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iAIEIMiY032556 for ; Thu, 18 Nov 2004 07:18:22 -0700 Received: from d03nm130.boulder.ibm.com (d03nm130.boulder.ibm.com [9.17.195.174]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iAIEILus032546 for ; Thu, 18 Nov 2004 07:18:21 -0700 Subject: Re: [rddp] Suggestions for Consolidation the Specification Documents To: X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Thu, 18 Nov 2004 08:18:20 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 11/18/2004 07:18:21 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1182314534==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e --===============1182314534== Content-type: multipart/related; Boundary="0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C" --0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: multipart/alternative; Boundary="1__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C" --1__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Rajiv, It seems to me that each protocol document needs to be able to stand on= its own. That is, the reader of a protocol document must get within that document all the normative references that are applicable to that proto= col. It seems to me that we had that to some extent in the protocol RDMAP, D= DP, and MPA documents, but it was not complete. It seems to me that using= the text from my earlier post, titled "RDMAP Security Section", would provi= de a complete set of normative security references. Additionally, the RDMAP= specification would reference "[RDMASEC]" Security draft for all the details and would include a brief informative overview, as described i= n that same post. However, the normative references do need to be review= ed by the RDDP WG to make sure they are complete. We discussed the above plan at IETF 61's RDDP WG session and there seem= ed to be general concensus on the approach. Are we all still OK with that? Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 = "Rajiv Das" = m> cc: = Sent by: Subject: [rddp] Suggest= ions for Consolidation the Specification Documents rddp-bounces@ietf = .org = = = 11/18/2004 12:42 = AM = = = Hi, [This is a repost with modifications] I was just going through all the RDDP Internet Drafts last weekend and = I get a feeling that: 1. The Definitions/Glossary section needs to refer to a master copy so = that variations are not there. 2. The Security section in all the drafts should refer to the Security draft to reduce redundancy. It's my feeling that the Architecture document should probably provide = the backbone, something which is not really self-evident now. The diagram b= elow is intended to show, what I feel can be a reasonable cross-reference scenario. I realize that the reader must get a complete idea of what ea= ch document intends to convey without too many references, but the current= feeling is like the documents aren't tied together anywhere. I believe = a federal structure is the optimum. I feel that with this consolidation, = the documents will provide an even better picture of RDDP. |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | 1.Concerns | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | V +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ + 2. ARCHITECTURE + +----------------------------------------------+ + Definitions +<------- +----------------------------------------------+ | + Overview of RDMA/DDP Operations etc. + | +----------------------------------------------+ | + Normative Reference to RDMA Specification + | +----------------------------------------------+ | + Normative Reference to DDP Specification + | +----------------------------------------------+ | + Normative Reference to Security +---- | +----------------------------------------------+ | | + Normative Reference to RDMA Applicablility + | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = | | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +--------------------------|--| + 3/4/5/6. RDMA/DDP Spec | | | RDMA Appl,Prb St | | |------------------------| | | Norm Ref to Definitions| | |------------------------| | | Norm Ref to Security |-| | |------------------------| | | | Other Contents | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | | | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | = | + 7.Security +<-----------<-----------------------| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ I believe I have got my understanding correct and hope I've been brief = :-) ---------------------- Thanks, Rajiv Das Wipro Technologies _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp = --1__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Rajiv,

It seems to me that each protocol document needs to be able to stand on= its own. That is, the reader of a protocol document must get within t= hat document all the normative references that are applicable to that p= rotocol. It seems to me that we had that to some extent in the protoco= l RDMAP, DDP, and MPA documents, but it was not complete. It seems to= me that using the text from my earlier post, titled "RDMAP Securi= ty Section", would provide a complete set of normative security re= ferences. Additionally, the RDMAP specification would reference "= [RDMASEC]" Security draft for all the details and would include a = brief informative overview, as described in that same post. However, = the normative references do need to be reviewed by the RDDP WG to make = sure they are complete.

We discussed the above plan at IETF 61's RDDP WG session and there seem= ed to be general concensus on the approach.

Are we all still OK with that?


Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

3D"Inactive"Rajiv Das" <rajiv_das@msn.c= om>




          "Rajiv Das" <rajiv_das@msn.com>=
          Sent by: rddp-bounces@ietf.org

          11/18/2004 12:42 AM

3D""

To: <rddp@ietf.org>
cc:
Subject: [rddp] Suggestions f= or Consolidation the Specification Documents


Hi,
[This is a repost with modifications]
I was just going through all the RDDP Internet Drafts last weekend and = I get
a feeling that:
1. The Definitions/Glossary section needs to refer to a master copy so = that
variations are not there.
2. The Security section in all the drafts should refer to the Security = draft
to reduce redundancy.

It's my feeling that the Architecture document should probably provide = the
backbone, something which is not really self-evident now. The diagram b= elow
is intended to show, what I feel can be a reasonable cross-reference scenario. I realize that the reader must get a complete idea of what ea= ch
document intends to convey without too many references, but the current=
feeling is like the documents aren't tied together anywhere. I believe = a
federal structure is the optimum. I feel that with this consolidation, = the
documents will provide an even better picture of RDDP.

|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
| 1.Concerns |
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|
V
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
= + 2. ARCHITECTURE +
+----------------------------------------------+
+ Definitions +<-------
+----------------------------------------------+ |
+ Overview of RDMA/DDP Operations etc. + |
+----------------------------------------------+ |
+ Normative Reference to RDMA Specification + |
+----------------------------------------------+ |
+ Normative Reference to DDP Specification + |
+----------------------------------------------+ |
+ Normative Reference to Security +---- |
+----------------------------------------------+ | |
+ Normative Reference to RDMA Applicablility + | |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = | |
| |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +--------------------------|--|
+ 3/4/5/6. RDMA/DDP Spec | |
| RDMA Appl,Prb St | |
|------------------------| |
| Norm Ref to Definitions| |
|------------------------| |
| Norm Ref to Security |-| |
|------------------------| | |
| Other Contents | | |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | |
| |
| |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | = |
+ 7.Security +<-----------<-----------------------|
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+


I believe I have got my understanding correct and hope I've been brief = :-)

----------------------
Thanks,
Rajiv Das
Wipro Technologies

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
 = --1__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C-- --0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE5C3DFDD842C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE5C3DFDD842C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C Content-type: image/gif; name="pic17238.gif" Content-Disposition: inline; filename="pic17238.gif" Content-ID: <30__=09BBE5C3DFDD842C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE5C3DFDD842C8f9e8a93df938690918c09BBE5C3DFDD842C-- --===============1182314534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1182314534==-- From rddp-bounces@ietf.org Mon Nov 22 16:56:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25821 for ; Mon, 22 Nov 2004 16:56:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMDw-0003Q5-84 for rddp-web-archive@ietf.org; Mon, 22 Nov 2004 16:59:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLvf-0003Iu-SI; Mon, 22 Nov 2004 16:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWLfR-0001hz-9Q for rddp@megatron.ietf.org; Mon, 22 Nov 2004 16:24:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20415 for ; Mon, 22 Nov 2004 16:24:11 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWLix-0006gh-Ab for rddp@ietf.org; Mon, 22 Nov 2004 16:27:52 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 13:23:40 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 13:23:40 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 13:23:40 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Mon, 22 Nov 2004 13:23:39 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] Suggestions for Consolidation the Specification Documents Date: Mon, 22 Nov 2004 13:23:38 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [rddp] Suggestions for Consolidation the Specification Documents Thread-Index: AcTNe/kWZL3ZwORfSGeKLWTA9FIuOADXXwxA From: "Jim Pinkerton" To: "Renato Recio" , X-OriginalArrivalTime: 22 Nov 2004 21:23:39.0235 (UTC) FILETIME=[88A71B30:01C4D0D9] X-Spam-Score: 0.9 (/) X-Scan-Signature: f2a5dc784731617f446f668f2c529db6 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1919494960==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 This is a multi-part message in MIME format. --===============1919494960== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C4D0D9.8A8CD652" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D0D9.8A8CD652 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4D0D9.8A8CD652" ------_=_NextPart_002_01C4D0D9.8A8CD652 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I think this path is reasonable. =20 =20 Jim =20 =20 =20 =20 ________________________________ From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Renato Recio Sent: Thursday, November 18, 2004 6:18 AM To: rddp@ietf.org Subject: Re: [rddp] Suggestions for Consolidation the Specification Documents =20 Rajiv, It seems to me that each protocol document needs to be able to stand on its own. That is, the reader of a protocol document must get within that document all the normative references that are applicable to that protocol. It seems to me that we had that to some extent in the protocol RDMAP, DDP, and MPA documents, but it was not complete. It seems to me that using the text from my earlier post, titled "RDMAP Security Section", would provide a complete set of normative security references. Additionally, the RDMAP specification would reference "[RDMASEC]" Security draft for all the details and would include a brief informative overview, as described in that same post. However, the normative references do need to be reviewed by the RDDP WG to make sure they are complete. We discussed the above plan at IETF 61's RDDP WG session and there seemed to be general concensus on the approach. Are we all still OK with that? Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 "Rajiv Das" =20 =20 "Rajiv Das" Sent by: rddp-bounces@ietf.org=20 11/18/2004 12:42 AM =20 To: cc:=20 Subject: [rddp] Suggestions for Consolidation the Specification Documents Hi, [This is a repost with modifications] I was just going through all the RDDP Internet Drafts last weekend and I get a feeling that: 1. The Definitions/Glossary section needs to refer to a master copy so that variations are not there. 2. The Security section in all the drafts should refer to the Security draft to reduce redundancy. It's my feeling that the Architecture document should probably provide the backbone, something which is not really self-evident now. The diagram below is intended to show, what I feel can be a reasonable cross-reference scenario. I realize that the reader must get a complete idea of what each document intends to convey without too many references, but the current feeling is like the documents aren't tied together anywhere. I believe a federal structure is the optimum. I feel that with this consolidation, the documents will provide an even better picture of RDDP.=20 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | 1.Concerns | |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | V +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ + 2. ARCHITECTURE + +----------------------------------------------+ + Definitions +<------- +----------------------------------------------+ | + Overview of RDMA/DDP Operations etc. + | +----------------------------------------------+ | + Normative Reference to RDMA Specification + | +----------------------------------------------+ | + Normative Reference to DDP Specification + | +----------------------------------------------+ | + Normative Reference to Security +---- | +----------------------------------------------+ | | + Normative Reference to RDMA Applicablility + | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +--------------------------|--| + 3/4/5/6. RDMA/DDP Spec | | | RDMA Appl,Prb St | | |------------------------| | | Norm Ref to Definitions| | |------------------------| | | Norm Ref to Security |-| | |------------------------| | | | Other Contents | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | | | | | | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | | + 7.Security +<-----------<-----------------------| +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ I believe I have got my understanding correct and hope I've been brief :-) ---------------------- Thanks, Rajiv Das Wipro Technologies _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp ------_=_NextPart_002_01C4D0D9.8A8CD652 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I think this path is = reasonable.

 

 

Jim

 

 

 

 

From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Renato Recio
Sent: Thursday, November = 18, 2004 6:18 AM
To: rddp@ietf.org
Subject: Re: [rddp] = Suggestions for Consolidation the Specification Documents

 

Rajiv,

It seems to me that each protocol document needs to be able to stand on = its own. That is, the reader of a protocol document must get within that = document all the normative references that are applicable to that protocol. It = seems to me that we had that to some extent in the protocol RDMAP, DDP, and MPA documents, but it was not complete. It seems to me that using the text = from my earlier post, titled "RDMAP Security Section", would provide a complete set of normative security references. Additionally, the RDMAP specification would reference "[RDMASEC]" Security draft for = all the details and would include a brief informative overview, as described in = that same post. However, the normative references do need to be reviewed by = the RDDP WG to make sure they are complete.

We discussed the above plan at IETF 61's RDDP WG session and there = seemed to be general concensus on the approach.

Are we all still OK with that?


Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

3D"Inactive"Rajiv Das" <rajiv_das@msn.com>

"Rajiv Das" <rajiv_das@msn.com>
Sent by: = rddp-bounces@ietf.org

11/18/2004 12:42 AM



To: <rddp@ietf.org>
cc:
Subject: [rddp] = Suggestions for Consolidation the Specification Documents



Hi,
[This is a repost with modifications]
I was just going through all the RDDP Internet Drafts last weekend and I = get
a feeling that:
1. The Definitions/Glossary section needs to refer to a master copy so = that
variations are not there.
2. The Security section in all the drafts should refer to the Security = draft
to reduce redundancy.

It's my feeling that the Architecture document should probably provide = the
backbone, something which is not really self-evident now. The diagram = below
is intended to show, what I feel can be a reasonable cross-reference
scenario. I realize that the reader must get a complete idea of what = each
document intends to convey without too many references, but the = current
feeling is like the documents aren't tied together anywhere. I believe = a
federal structure is the optimum. I feel that with this consolidation, = the
documents will provide an even better picture of RDDP.

|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
| 1.Concerns |
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
|
V
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
+ 2. ARCHITECTURE +
+----------------------------------------------+
+ Definitions +<-------
+----------------------------------------------+ |
+ Overview of RDMA/DDP Operations etc. + |
+----------------------------------------------+ |
+ Normative Reference to RDMA Specification + |
+----------------------------------------------+ |
+ Normative Reference to DDP Specification + |
+----------------------------------------------+ |
+ Normative Reference to Security +---- |
+----------------------------------------------+ | |
+ Normative Reference to RDMA Applicablility + | |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | = |
| |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +--------------------------|--|
+ 3/4/5/6. RDMA/DDP Spec | |
| RDMA Appl,Prb St | |
|------------------------| |
| Norm Ref to Definitions| |
|------------------------| |
| Norm Ref to Security |-| |
|------------------------| | |
| Other Contents | | |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + | |
| |
| |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | |
+ 7.Security +<-----------<-----------------------|
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+


I believe I have got my understanding correct and hope I've been brief = :-)

----------------------
Thanks,
Rajiv Das
Wipro Technologies

_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.or= g/mailman/listinfo/rddp

------_=_NextPart_002_01C4D0D9.8A8CD652-- ------_=_NextPart_001_01C4D0D9.8A8CD652 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C4D0D9.8A8CD652 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhSAABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== ------_=_NextPart_001_01C4D0D9.8A8CD652 Content-Type: image/gif; name="image003.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.gif Content-Location: image003.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlh4QABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== ------_=_NextPart_001_01C4D0D9.8A8CD652 Content-Type: image/gif; name="image004.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.gif Content-Location: image004.gif Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhAQABAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAAAB AAEAgAAAAAECAwICRAEAOw== ------_=_NextPart_001_01C4D0D9.8A8CD652-- --===============1919494960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1919494960==-- From rddp-bounces@ietf.org Mon Nov 22 20:25:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16868 for ; Mon, 22 Nov 2004 20:25:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWPUC-0006XB-Ch for rddp-web-archive@ietf.org; Mon, 22 Nov 2004 20:28:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWPIw-0002HN-CI; Mon, 22 Nov 2004 20:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWP4J-0007QU-3Y for rddp@megatron.ietf.org; Mon, 22 Nov 2004 20:02:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14496 for ; Mon, 22 Nov 2004 20:02:06 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWP7q-0003T8-UT for rddp@ietf.org; Mon, 22 Nov 2004 20:05:48 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAN1235L012004 for ; Mon, 22 Nov 2004 20:02:03 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Nov 2004 20:02:02 -0500 Message-ID: To: rddp@ietf.org Subject: RE: [rddp] Draft DC minutes Date: Mon, 22 Nov 2004 20:02:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.22.29 X-PerlMx-Spam: Gauge=, SPAM=7%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Having seen no comments, these are now the final minutes that will be sent to the secretariat for the proceedings, and the sense of the room decisions from DC are now the rough consensus of the RDDP WG. Thanks, --David > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On > Behalf Of Black_David@emc.com > Sent: Monday, November 15, 2004 7:16 PM > To: rddp@ietf.org > Subject: [rddp] Draft DC minutes > > This is also an opportunity for anyone on the list > to object to decisions taken in DC - they're flagged > in [square brackets]. In the absence of objection, > those decisions are the rough consensus of the RDDP WG. > Also note that "?" is a bullet in this (Microsoft > strikes again ...), it does not introduce a question > or open issue - those are indicated by "?" after a > word (generally end of a line of text). > > Thanks, > --David > > RDDP Minutes - 61st IETF Meeting DRAFT > 11/8/2004 > Washington D.C. > -------------------------------- > > Thanks to Hemal V. Shah for taking the minutes > > * Agenda bashing > > * Status of drafts (from all authors) > o Problem statement has been in RFC editor queue. > o Architecture document very close to being in RFC editor queue. > o RDMAP/DDP drafts are not ready for WG last call at this point. > Security sections need to be checked for MUST implement > IPsec (RFC 3723). Only open issues are security requirements. > o Applicability draft (when to use SCTP versus TCP) in process. > o Once we have security requirements in RDMAP/DDP drafts, then > security, DDP, and RDMAP drafts will go to the first round > of WG Last Call. > o Second batch of last calls will be MPA, SCTP, and > Applicability. > > * Security draft (Presenter: Jim Pinkerton) [B] > o Major changes > ? Quickly iterated -03, -04, and -05 in one month. > ? Changed the draft to be standards track > ? Resolved several TBDs: channel binding, connection hijacking, > finished summary tables of attacks in appendix > ? New or substantially revised appendices: appendix A is > normative, appendices B & C are informative. > o Major new normative statements > ? Most RECOMMENDED statements were changed to MUST/MAY. > ? IPsec is MUST implement and OPTIONAL to use > ? Resource manager > * MUST be used if a scarce resource > * MUST NOT assume shared partial mutual trust > o Planned changes to -06 draft > ? Resolve some more TBDs. > ? Need review. > > * RDMAP Security issues (Presenter: Renato Recio) [C] > o RDMAP and DDP drafts need to have security requirements. > o Approach > ? List out informative text > ? Summary of RDMAP specific security requirements > ? Security services for RDMAP > o Security Model and general assumptions > ? Mainly list the attacks, attack types, and resources. > Details are in RDMA security draft. > o RDMAP specific security requirements > ? Privileged resource manager requirements > o There are some requirements that might be added to RDMAP and > RDMA security drafts > o Need to revise MUST requirement on firmware load in RDMA > security draft. > o List of normative requirements will be sent to the reflector. > o Email discussion on the reflector on the normative text. > o DDP draft will address the requirements on the list through > the discussions and then it will be added to the draft. > > * MPA (Presenter: Paul Culley) [D] > o Issues > ? Need to add text from the security draft > ? Marker pointer clarification > ? Minor clarification of meaning of "connection establishment" > o Zero-markers > ? Where do the non-zero markers of the FPDU point to? > * ULPDU_length > * Or Zero-marker > ? Marker should point to ULPDU_length instead of start of > FPDU-Hdr [sense of room] > o IPsec requirement is it needed in MPA? > ? Need to cross-reference requirement from DDP. > * Safest thing to do is have MPA list IPsec as MUST > implement and optional to use. Derived from DDP > requirement as DDP is the only protocol that can > be above MPA. [no objection] > > * SCTP mapping (Presenter: Caitlin Bestler) [E] > o Main changes > ? Updated to new boilerplate (e.g., IPR) > ? SCTP/MPA differences noted > * Size of private data 512 B for SCTP mapping > * MPA requires first FPDU come from initiating side > * In MPA spec, we need specify that MPA MUST allow > private data up to 512B. > ? Session control changed to align with MPA > * Only one exchange per side. Eliminated negotiate > message. > * Added explicit reject message. > ? Dealt with small PDUs > > * iWARP interoperability w/RDMAC versions + APIs (Presenter: John Carrier) [F] > o Interoperability on the wire > ? RDMAC/IETF RDMAP/DDP protocols have same semantics and > wire protocol format, but they both use different versions. > ? No standard way for ULPs to exchange version information that > could be used to configure the RNICs > ? If IETF implementation decides to turn markers off, then IETF > RNIC won't interoperate with RDMAC RNIC. > o Interoperability above RDDP > ? Discussion on standardizing private data format - Not appropriate > to specify ULP data format [sense of room] > ? Add a requirement on that version information should be > available to ULP [sense of room] > ? No consensus on the private data format. > * Worry around breaking the existing implementations. > ? Within a week, the text on the interoperability will be generated > and sent to list. It'll be headed for appendices of the > MPA, DDP, and RDMAP protocol drafts. [no objection] > > * Next steps > o Revise security draft. > o Add appropriate security requirements in DDP & RDMAP. > > * Meeting adjourned @ 9:30pm on November 8, 2004. > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 23 15:02:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16274 for ; Tue, 23 Nov 2004 15:02:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgvc-0002XP-47 for rddp-web-archive@ietf.org; Tue, 23 Nov 2004 15:06:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWggx-0005eR-AC; Tue, 23 Nov 2004 14:51:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgan-0004VO-7k for rddp@megatron.ietf.org; Tue, 23 Nov 2004 14:44:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12663 for ; Tue, 23 Nov 2004 14:44:47 -0500 (EST) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgeV-0008Oa-LY for rddp@ietf.org; Tue, 23 Nov 2004 14:48:40 -0500 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id iANJiGW07429 for ; Tue, 23 Nov 2004 11:44:16 -0800 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id iANJiGx01428 for ; Tue, 23 Nov 2004 11:44:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2004 11:44:16 -0800 Message-ID: Thread-Topic: draft-carrier-rddp-rnic-interop-00.txt Thread-Index: AcTRlKpNMqHPfD0yQ4eYNFfZxgYY0Q== From: "Carrier, John" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Subject: [rddp] draft-carrier-rddp-rnic-interop-00.txt X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 22 Nov 2004 15:38:09 -0500 Subject: I-D ACTION:draft-carrier-rddp-rnic-interop-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : RNIC Interoperability Author(s) : J. Carrier, J. Pinkerton Filename : draft-carrier-rddp-rnic-interop-00.txt Pages : 18 Date : 2004-11-22 =09 This document describes a mechanism for enabling RDMA Network=20 Interface Cards (RNICs) that implement both the IETF and RDMAC=20 versions of the DDP and RDMAP protocols to interoperate with legacy=20 RNICs that are based on the RDMAC version of the protocols. The=20 proposed scheme uses MPA Request/Reply Frames to negotiate the=20 protocol version as well as MPA marker and MPA CRC. A ULP or other=20 supporting entity must perform this negotiation on behalf of the=20 RDMAC RNIC because RDMAC MPA does not define an MPA connection=20 scheme using MPA Request/Reply frames. This draft also makes=20 specific recommendations for minor changes to the IETF MPA, DDP, and=20 RDMAP internet drafts to aid in interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carrier-rddp-rnic-interop-00.tx= t _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 23 21:49:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05507 for ; Tue, 23 Nov 2004 21:49:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWnHQ-0001AU-P9 for rddp-web-archive@ietf.org; Tue, 23 Nov 2004 21:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWn9z-0008Um-4J; Tue, 23 Nov 2004 21:45:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWn68-0007dV-05 for rddp@megatron.ietf.org; Tue, 23 Nov 2004 21:41:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04887 for ; Tue, 23 Nov 2004 21:41:33 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWn9u-0000Km-7d for rddp@ietf.org; Tue, 23 Nov 2004 21:45:30 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 18:41:03 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Nov 2004 18:41:02 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1247); Tue, 23 Nov 2004 18:41:04 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Tue, 23 Nov 2004 18:41:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt Date: Tue, 23 Nov 2004 18:40:52 -0800 Message-ID: Thread-Topic: [rddp] draft-carrier-rddp-rnic-interop-00.txt Thread-Index: AcTRlKpNMqHPfD0yQ4eYNFfZxgYY0QAOg6EA From: "Jim Pinkerton" To: X-OriginalArrivalTime: 24 Nov 2004 02:41:01.0556 (UTC) FILETIME=[092C7340:01C4D1CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Feedback is appreciated on this draft. This was a result of an informal group working over beers after the RDDP work group meeting gave us direction to try to solve interoperability as an informative appendix to the MPA specification.=20 John and I tried to be very specific about the exact recommended text changes for the various drafts, to hopefully expedite the review process with something concrete to shoot at. Jim > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Carrier, John > Sent: Tuesday, November 23, 2004 11:44 AM > To: rddp@ietf.org > Subject: [rddp] draft-carrier-rddp-rnic-interop-00.txt >=20 >=20 > To: i-d-announce@ietf.org > From: Internet-Drafts@ietf.org > Date: Mon, 22 Nov 2004 15:38:09 -0500 > Subject: I-D ACTION:draft-carrier-rddp-rnic-interop-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : RNIC Interoperability > Author(s) : J. Carrier, J. Pinkerton > Filename : draft-carrier-rddp-rnic-interop-00.txt > Pages : 18 > Date : 2004-11-22 >=20 > This document describes a mechanism for enabling RDMA Network > Interface Cards (RNICs) that implement both the IETF and RDMAC > versions of the DDP and RDMAP protocols to interoperate with legacy > RNICs that are based on the RDMAC version of the protocols. The > proposed scheme uses MPA Request/Reply Frames to negotiate the > protocol version as well as MPA marker and MPA CRC. A ULP or other > supporting entity must perform this negotiation on behalf of the > RDMAC RNIC because RDMAC MPA does not define an MPA connection > scheme using MPA Request/Reply frames. This draft also makes > specific recommendations for minor changes to the IETF MPA, DDP, and > RDMAP internet drafts to aid in interoperability. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carrier-rddp-rnic-interop-00.t xt >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Nov 24 15:00:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24104 for ; Wed, 24 Nov 2004 15:00:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3NK-0004jx-Bc for rddp-web-archive@ietf.org; Wed, 24 Nov 2004 15:04:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3FS-0004l0-7W; Wed, 24 Nov 2004 14:56:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3Cx-0003nZ-Ct for rddp@megatron.ietf.org; Wed, 24 Nov 2004 14:53:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23595 for ; Wed, 24 Nov 2004 14:53:41 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3Gs-0004ZH-VC for rddp@ietf.org; Wed, 24 Nov 2004 14:57:47 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAOJrc4O013455 for ; Wed, 24 Nov 2004 14:53:38 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Nov 2004 14:53:38 -0500 Message-ID: To: rddp@ietf.org Date: Wed, 24 Nov 2004 14:53:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.24.19 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [rddp] Draft progress & schedule X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f A couple of updates from your WG chair: (1) I believe that the text changes needed to clear the final IESG issues on the RDDP architecture draft are understood, and I've asked the draft editor to produce a new version. Both issues were minor: - When using a multi-destination transport like SCTP, the effect of a transfer via an stags can't depend on which IP address receives the packets. If this can't be accomplished, don't use RDDP. - Add text stating the MUST implement IPsec security requirement. The RFC Editor will publish the RDDP problem statement and architecture as a set of RFCs (i.e., they'll appear together). (2) I want to see ready-for-WG-Last-Call versions of the DDP, RDMAP, and Security drafts by the end of next week (submit them to the secretariat by Fri, Dec 3 and cc: me on the submission email). This is so that this WG Last Call can be finished before the end-of-December holidays divert everyone's attention. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Nov 24 15:30:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28705 for ; Wed, 24 Nov 2004 15:30:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3q3-0005Zf-Nt for rddp-web-archive@ietf.org; Wed, 24 Nov 2004 15:34:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3k2-000200-VF; Wed, 24 Nov 2004 15:27:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CX3dw-0006Oi-Nz for rddp@megatron.ietf.org; Wed, 24 Nov 2004 15:21:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27423 for ; Wed, 24 Nov 2004 15:21:34 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CX3hs-0005Lt-MC for rddp@ietf.org; Wed, 24 Nov 2004 15:25:40 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iAOKLX1w012923 for ; Wed, 24 Nov 2004 15:21:34 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Nov 2004 15:21:33 -0500 Message-ID: To: rddp@ietf.org Date: Wed, 24 Nov 2004 15:21:33 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.11.24.19 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __HAS_X_PRIORITY 0, X_PRIORITY_HIGH 0, __X_PRI_HI 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [rddp] IPR disclosures X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I think there was at least one attempt to submit an IPR notice that failed because the secretariat was testing the submission page. The secretariat wished to apologize for the confusion - the IETF IPR disclosure page is now up and running at: https://datatracker.ietf.org/public/ipr_disclosure.cgi This is the place to start for both making and finding disclosures. If you think you've made an IPR disclosure in the past, but can't find it from that web page, the disclosure does not exist and needs to be resubmitted. **PLEASE** make any IPR disclosure on the RDMAP, DDP or Security drafts by next Friday, December 3rd. I intend to include a list of disclosures in the WG Last Call, so that I can confidently say that the WG considered the IPR disclosures during WG Last Call in order to avoid subsequent problems/delays. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Thu Nov 25 03:04:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11783 for ; Thu, 25 Nov 2004 03:04:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEgd-00046N-Jl for rddp-web-archive@ietf.org; Thu, 25 Nov 2004 03:09:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEb3-0003Oh-H8; Thu, 25 Nov 2004 03:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXEWS-0002Du-Tv for rddp@megatron.ietf.org; Thu, 25 Nov 2004 02:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10613 for ; Thu, 25 Nov 2004 02:58:35 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXEaU-0003u7-EF for rddp@ietf.org; Thu, 25 Nov 2004 03:02:46 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Draft progress & schedule Date: Wed, 24 Nov 2004 23:57:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [rddp] Draft progress & schedule Thread-Index: AcTSYEkroIAT7RcWQG2vrFrmtBt++wAY7/4A From: "Caitlin Bestler" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Wednesday, November 24, 2004 11:54 AM > To: rddp@ietf.org > Subject: [rddp] Draft progress & schedule >=20 > A couple of updates from your WG chair: >=20 > (1) I believe that the text changes needed to clear the > final IESG issues on the RDDP architecture draft > are understood, and I've asked the draft editor to > produce a new version. Both issues were minor: > - When using a multi-destination transport like SCTP, > the effect of a transfer via an stags can't > depend on which IP address receives the packets. > If this can't be accomplished, don't use RDDP. That could certainly be added, but it is already the logical Conclusion of the specification. The DDP layer only knows that DDP Segments have been delivered reliably according to the ordering rules. Having the behavior depend on which IP Address was used would be just as incorrect as having it depend on the Ethernet MAC address. =20 -- Caitlin Bestler Director Software Architecture Siliquent Technologies caitlinb@siliquent.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Nov 29 14:25:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21738 for ; Mon, 29 Nov 2004 14:25:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrEM-0000xs-TH for rddp-web-archive@ietf.org; Mon, 29 Nov 2004 14:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYr4x-0005M9-QF; Mon, 29 Nov 2004 14:20:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYr1O-000510-Er for rddp@megatron.ietf.org; Mon, 29 Nov 2004 14:17:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21037 for ; Mon, 29 Nov 2004 14:17:13 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYr6L-0000l6-E1 for rddp@ietf.org; Mon, 29 Nov 2004 14:22:22 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id 303421887 for ; Mon, 29 Nov 2004 11:17:11 -0800 (PST) Received: from MK73191c.cup.hp.com ([15.244.200.66]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA02234 for ; Mon, 29 Nov 2004 11:14:35 -0800 (PST) Message-Id: <6.1.2.0.2.20041129094713.01e8eec0@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 11:11:26 -0800 To: From: Michael Krause Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928983924==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 225414c974e0d6437992164e91287a51 --===============1928983924== Content-Type: multipart/alternative; boundary="=====================_6999965==.ALT" --=====================_6999965==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:40 PM 11/23/2004, Jim Pinkerton wrote: >Feedback is appreciated on this draft. This was a result of an informal >group working over beers after the RDDP work group meeting gave us >direction to try to solve interoperability as an informative appendix to >the MPA specification. > >John and I tried to be very specific about the exact recommended text >changes for the various drafts, to hopefully expedite the review process >with something concrete to shoot at. Initial comments. Mike (1) It is not clear to me where there is ambiguity within the specifications. The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b. The table in section 6.8 states that a remote operation error is generated for a RDMAP version error. The RDMAC RDMAP specification contains the same language but states the version MUST be 00b. As such, it clear what the version must be and the error that should be returned if there is a version mismatch which contradicts the assertions made in section 3 of the interop draft. (2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be set to 1. Section 7.2 states that an invalid version must be returned upon detecting a mismatch and section 7.1 states that upon error detection, DDP must stop placing segments and return an error to the ULP. In this case, it would be to surface an error to RDMA. The RDMAC DDP specification contains the same language but states the version MUST be 00b. Again, this contradicts the assertions made in section 3 of the interop draft. (3) I agree that there are three cases of implementations that can exist. However, it seems that the specifications are relatively clear on what the versions must be for each set of specifications. It is also clear what the expected behavior should be as well, i.e. the generation / surfacing of an error. As such, a RDMAC implementation would require the version to be 0 to be compliant while the IETF implementations would require the version to be 1. The only way to achieve interoperability is to set the appropriate version number prior to a connection transition to RDMA / DDP mode. (4) A RDMAC-only implementation would not negotiate MPA since this is not part of the RDMAC specifications. The draft implies that any RDMAC compliant implementation would be augmented to provide MPA negotiation. I don't see how this can be required - at best, it is an option to implement and may or may not be present on a given endnode. If this is not implemented, the two sides will simply fail the RDMA stream establishment. In general, the tables showing the negotiation at the MPA level look reasonable. (5) It is not clear that new verbs extensions are required for interoperability. The verbs specification section 9.3 already states how a version mismatch (DDP or RDMA) should be surfaced. There is value in being able to configure a RNIC (on a per session basis) as to what version to support. This should be done once and cause all layers to use a consistent version for a given QP. The value should be set at QP creation and then updated upon session establishment if the RNIC can support both RDMAC and IETF specifications. I also see value in having the query what the current version is. I don't see why a ModifyQP is required as one knows up front what is desired and the implementation if permissive, would negotiate accordingly. Therefore all that is needed is to understand the result. --=====================_6999965==.ALT Content-Type: text/html; charset="us-ascii" At 06:40 PM 11/23/2004, Jim Pinkerton wrote:


Feedback is appreciated on this draft. This was a result of an informal
group working over beers after the RDDP work group meeting gave us
direction to try to solve interoperability as an informative appendix to
the MPA specification.

John and I tried to be very specific about the exact recommended text
changes for the various drafts, to hopefully expedite the review process
with something concrete to shoot at.

Initial comments.

Mike

(1) It is not clear to me where there is ambiguity within the specifications.  The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b.  The table in section 6.8 states that a remote operation error is generated for a RDMAP version error.  The RDMAC RDMAP specification contains the same language but states the version MUST be 00b.  As such, it clear what the version must be and the error that should be returned if there is a version mismatch which contradicts the assertions made in section 3 of the interop draft.

(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be set to 1.  Section 7.2 states that an invalid version must be returned upon detecting a mismatch and section 7.1 states that upon error detection, DDP  must stop placing segments and return an error to the ULP.  In this case, it would be to surface an error to RDMA.  The RDMAC DDP specification contains the same language but states the version MUST be 00b.  Again, this contradicts the assertions made in section 3 of the interop draft.

(3) I agree that there are three cases of implementations that can exist.  However, it seems that the specifications are relatively clear on what the versions must be for each set of specifications.  It is also clear what the expected behavior should be as well, i.e. the generation / surfacing of an error.  As such, a RDMAC implementation would require the version to be 0 to be compliant while the IETF implementations would require the version to be 1.  The only way to achieve interoperability is to set the appropriate version number prior to a connection transition to RDMA / DDP mode. 

(4) A RDMAC-only implementation would not negotiate MPA since this is not part of the RDMAC specifications.  The draft implies that any RDMAC compliant implementation would be augmented to provide MPA negotiation.  I don't see how this can be required - at best, it is an option to implement and may or may not be present on a given endnode.  If this is not implemented, the two sides will simply fail the RDMA stream establishment.  In general, the tables showing the negotiation at the MPA level look reasonable.

(5) It is not clear that new verbs extensions are required for interoperability.  The verbs specification section 9.3 already states how a version mismatch (DDP or RDMA) should be surfaced.  There is value in being able to configure a RNIC (on a per session basis) as to what version to support.  This should be done once and cause all layers to use a consistent version for a given QP.  The value should be set at QP creation and then updated upon session establishment if the RNIC can support both RDMAC and IETF specifications.  I also see value in having the query what the current version is.  I don't see why a ModifyQP is required as one knows up front what is desired and the implementation if permissive, would negotiate accordingly.  Therefore all that is needed is to understand the result. --=====================_6999965==.ALT-- --===============1928983924== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1928983924==-- From rddp-bounces@ietf.org Mon Nov 29 15:11:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26275 for ; Mon, 29 Nov 2004 15:11:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrwl-0001yy-Vb for rddp-web-archive@ietf.org; Mon, 29 Nov 2004 15:16:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrlM-0007mx-1T; Mon, 29 Nov 2004 15:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrhV-0004TG-HS for rddp@megatron.ietf.org; Mon, 29 Nov 2004 15:00:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24998 for ; Mon, 29 Nov 2004 15:00:44 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYrmS-0001lf-SP for rddp@ietf.org; Mon, 29 Nov 2004 15:05:53 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 12:00:12 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 12:00:25 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 12:00:11 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Mon, 29 Nov 2004 12:00:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt Date: Mon, 29 Nov 2004 12:00:10 -0800 Message-ID: Thread-Topic: [rddp] draft-carrier-rddp-rnic-interop-00.txt thread-index: AcTWSVgpDWuDECb6R2WURPVPpPXvCQAA9z3w From: "Jim Pinkerton" To: "Michael Krause" , X-OriginalArrivalTime: 29 Nov 2004 20:00:11.0502 (UTC) FILETIME=[08B3F0E0:01C4D64E] X-Spam-Score: 2.6 (++) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1296172808==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 This is a multi-part message in MIME format. --===============1296172808== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D64E.08822EE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D64E.08822EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Commenting to 5), the reason why both CreateQP and ModifyQP is needed is because some protocols (notably ISER) don't want to negotiate RDMA capability unless they know that resources are available for RDMA. So I would expect this class of protocols to first do a CreateQP before exchanging keys. At this time, you don't know what the version number will be negotiated to (assuming the interoperability protocol suggested in the draft), thus only after reception of a REQ/REP frame do you set the version number, which must be done using a ModifyQP. =20 On 4), possibly the wording could be improved. It really comes down to RDMAC versions which wish to interoperate with IETF versions. Those that don't try, won't :-) =20 Mike, with the exceptions of the concerns on changes to MPA/DDP/RDMAP to give the right level of "escape hatch", does the approach appear sound? Note that the ambiguity in some of them has to work the other way - make it more ambiguous - i.e. if you are able to talk with version 0, allow you to do so (current text prohibits it). =20 =20 =20 Jim =20 =20 =20 ________________________________ From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Michael Krause Sent: Monday, November 29, 2004 11:11 AM To: rddp@ietf.org Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt =20 At 06:40 PM 11/23/2004, Jim Pinkerton wrote: Feedback is appreciated on this draft. This was a result of an informal group working over beers after the RDDP work group meeting gave us direction to try to solve interoperability as an informative appendix to the MPA specification.=20 John and I tried to be very specific about the exact recommended text changes for the various drafts, to hopefully expedite the review process with something concrete to shoot at. Initial comments. Mike (1) It is not clear to me where there is ambiguity within the specifications. The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b. The table in section 6.8 states that a remote operation error is generated for a RDMAP version error. The RDMAC RDMAP specification contains the same language but states the version MUST be 00b. As such, it clear what the version must be and the error that should be returned if there is a version mismatch which contradicts the assertions made in section 3 of the interop draft. (2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be set to 1. Section 7.2 states that an invalid version must be returned upon detecting a mismatch and section 7.1 states that upon error detection, DDP must stop placing segments and return an error to the ULP. In this case, it would be to surface an error to RDMA. The RDMAC DDP specification contains the same language but states the version MUST be 00b. Again, this contradicts the assertions made in section 3 of the interop draft. (3) I agree that there are three cases of implementations that can exist. However, it seems that the specifications are relatively clear on what the versions must be for each set of specifications. It is also clear what the expected behavior should be as well, i.e. the generation / surfacing of an error. As such, a RDMAC implementation would require the version to be 0 to be compliant while the IETF implementations would require the version to be 1. The only way to achieve interoperability is to set the appropriate version number prior to a connection transition to RDMA / DDP mode. =20 (4) A RDMAC-only implementation would not negotiate MPA since this is not part of the RDMAC specifications. The draft implies that any RDMAC compliant implementation would be augmented to provide MPA negotiation. I don't see how this can be required - at best, it is an option to implement and may or may not be present on a given endnode. If this is not implemented, the two sides will simply fail the RDMA stream establishment. In general, the tables showing the negotiation at the MPA level look reasonable. (5) It is not clear that new verbs extensions are required for interoperability. The verbs specification section 9.3 already states how a version mismatch (DDP or RDMA) should be surfaced. There is value in being able to configure a RNIC (on a per session basis) as to what version to support. This should be done once and cause all layers to use a consistent version for a given QP. The value should be set at QP creation and then updated upon session establishment if the RNIC can support both RDMAC and IETF specifications. I also see value in having the query what the current version is. I don't see why a ModifyQP is required as one knows up front what is desired and the implementation if permissive, would negotiate accordingly. Therefore all that is needed is to understand the result. ------_=_NextPart_001_01C4D64E.08822EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Commenting to 5), the reason why = both CreateQP and ModifyQP is needed is because some protocols (notably ISER) = don’t want to negotiate RDMA capability unless they know that resources are = available for RDMA.  So I would expect this class of protocols to first do a = CreateQP before exchanging keys. At this time, you don’t know what the = version number will be negotiated to (assuming the interoperability protocol = suggested in the draft), thus only after reception of a REQ/REP frame do you set = the version number, which must be done using a ModifyQP.

 

On 4), possibly the wording could = be improved. It really comes down to RDMAC versions which wish to = interoperate with IETF versions. Those that don’t try, won’t = J

 

Mike, with the exceptions of the = concerns on changes to MPA/DDP/RDMAP to give the right level of “escape = hatch”, does the approach appear sound? Note that the ambiguity in some of them = has to work the other way – make it more ambiguous – i.e. if you = are able to talk with version 0, allow you to do so (current text prohibits = it).

 

 

 

Jim

 

 

 

From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Michael Krause
Sent: Monday, November = 29, 2004 11:11 AM
To: rddp@ietf.org
Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt

 

At 06:40 PM 11/23/2004, Jim Pinkerton wrote:



Feedback is appreciated on this draft. This was a result of an = informal
group working over beers after the RDDP work group meeting gave us
direction to try to solve interoperability as an informative appendix = to
the MPA specification.

John and I tried to be very specific about the exact recommended = text
changes for the various drafts, to hopefully expedite the review = process
with something concrete to shoot at.


Initial comments.

Mike

(1) It is not clear to me where there is ambiguity within the specifications.  The RDMAP specification = (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b.  The table in section 6.8 states that a remote operation error is generated for a = RDMAP version error.  The RDMAC RDMAP specification contains the same = language but states the version MUST be 00b.  As such, it clear what the = version must be and the error that should be returned if there is a version = mismatch which contradicts the assertions made in section 3 of the interop = draft.

(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 = states the DV bits must be set to 1.  Section 7.2 states that an invalid = version must be returned upon detecting a mismatch and section 7.1 states that upon = error detection, DDP  must stop placing segments and return an error to = the ULP.  In this case, it would be to surface an error to RDMA.  = The RDMAC DDP specification contains the same language but states the = version MUST be 00b.  Again, this contradicts the assertions made in section 3 = of the interop draft.

(3) I agree that there are three cases of implementations that can = exist.  However, it seems that the specifications are relatively clear on what = the versions must be for each set of specifications.  It is also clear = what the expected behavior should be as well, i.e. the generation / surfacing = of an error.  As such, a RDMAC implementation would require the version = to be 0 to be compliant while the IETF implementations would require the version = to be 1.  The only way to achieve interoperability is to set the = appropriate version number prior to a connection transition to RDMA / DDP = mode. 

(4) A RDMAC-only implementation would not negotiate MPA since this is = not part of the RDMAC specifications.  The draft implies that any RDMAC = compliant implementation would be augmented to provide MPA negotiation.  I = don't see how this can be required - at best, it is an option to implement and may = or may not be present on a given endnode.  If this is not implemented, the = two sides will simply fail the RDMA stream establishment.  In general, = the tables showing the negotiation at the MPA level look reasonable.

(5) It is not clear that new verbs extensions are required for interoperability.  The verbs specification section 9.3 already = states how a version mismatch (DDP or RDMA) should be surfaced.  There is = value in being able to configure a RNIC (on a per session basis) as to what = version to support.  This should be done once and cause all layers to use a consistent version for a given QP.  The value should be set at QP = creation and then updated upon session establishment if the RNIC can support both = RDMAC and IETF specifications.  I also see value in having the query what = the current version is.  I don't see why a ModifyQP is required as one = knows up front what is desired and the implementation if permissive, would = negotiate accordingly.  Therefore all that is needed is to understand the = result.

------_=_NextPart_001_01C4D64E.08822EE0-- --===============1296172808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1296172808==-- From rddp-bounces@ietf.org Mon Nov 29 17:22:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20031 for ; Mon, 29 Nov 2004 17:22:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYu05-0000nR-Lt for rddp-web-archive@ietf.org; Mon, 29 Nov 2004 17:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYthx-0008E2-BR; Mon, 29 Nov 2004 17:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYsZS-0003CB-Ad for rddp@megatron.ietf.org; Mon, 29 Nov 2004 15:56:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03341 for ; Mon, 29 Nov 2004 15:56:28 -0500 (EST) Received: from magic.adaptec.com ([216.52.22.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYseP-0003zQ-Qw for rddp@ietf.org; Mon, 29 Nov 2004 16:01:38 -0500 Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id iATKtvW17961; Mon, 29 Nov 2004 12:55:57 -0800 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id iATKtvx18511; Mon, 29 Nov 2004 12:55:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt Date: Mon, 29 Nov 2004 12:55:57 -0800 Message-ID: Thread-Topic: [rddp] draft-carrier-rddp-rnic-interop-00.txt Thread-Index: AcTWSWPRnphFKUyuQmmvJ2t/p3EwtwACVPYQ From: "Carrier, John" To: "Michael Krause" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1406446815==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d This is a multi-part message in MIME format. --===============1406446815== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D655.D320BD38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D655.D320BD38 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike, =20 thanks for your comments. =20 =20 On re-reading the drafts, I agree that the DDP draft does state very = clearly that the version fields must match (sec 4.1). However, I find = no such statement in the RDMAP draft (other than stating the field must = be 01b, there is no corresponding statement that the receiver must check = or that, if it checks, what 'valid' means). My error for = over-simplifying to introduce the problem. =20 The interoperability issue I addressed in the RDDP WG meeting was that I = knew there were schemes being considered (external to the IETF) for = allowing RDMAC RNICs to interoperate with IETF RNICs and that unless the = WG offered some informational text describing an interoperability = mechanism, then the results would be open to vendor implementation. =20 =20 In the draft, Jim & I suggest changing the MPA version from 0 to 1 so = that a ULP (or other entity) could do the MPA negotiation for an RDMAC = RNIC (which would use the version of 0). Very clearly an RDMAC-only = RNIC without this other entity could not attempt to interoperate with a = "Permissive" IETF RNIC. For an IETF-only RNIC, the change has no = effect: it can only interoperate with other IETF RNICs. =20 =20 The goal of the draft, then, is to provide a mechanism for ULPs or other = entities (such as the OpenGroup's IT API & RNIC PI) to create a common = interface to RDMAC as well as IETF RNICs that enables interoperability = between the RNICs where possible. =20 --jc -----Original Message----- From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of = Michael Krause Sent: Monday, November 29, 2004 11:11 AM To: rddp@ietf.org Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt At 06:40 PM 11/23/2004, Jim Pinkerton wrote: Feedback is appreciated on this draft. This was a result of an informal group working over beers after the RDDP work group meeting gave us direction to try to solve interoperability as an informative appendix to the MPA specification.=20 John and I tried to be very specific about the exact recommended text changes for the various drafts, to hopefully expedite the review process with something concrete to shoot at. Initial comments. Mike (1) It is not clear to me where there is ambiguity within the = specifications. The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) = section 6.1 states that the RDMA version MUST be 01b. The table in = section 6.8 states that a remote operation error is generated for a = RDMAP version error. The RDMAC RDMAP specification contains the same = language but states the version MUST be 00b. As such, it clear what the = version must be and the error that should be returned if there is a = version mismatch which contradicts the assertions made in section 3 of = the interop draft. (2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 = states the DV bits must be set to 1. Section 7.2 states that an invalid = version must be returned upon detecting a mismatch and section 7.1 = states that upon error detection, DDP must stop placing segments and = return an error to the ULP. In this case, it would be to surface an = error to RDMA. The RDMAC DDP specification contains the same language = but states the version MUST be 00b. Again, this contradicts the = assertions made in section 3 of the interop draft. (3) I agree that there are three cases of implementations that can = exist. However, it seems that the specifications are relatively clear = on what the versions must be for each set of specifications. It is also = clear what the expected behavior should be as well, i.e. the generation = / surfacing of an error. As such, a RDMAC implementation would require = the version to be 0 to be compliant while the IETF implementations would = require the version to be 1. The only way to achieve interoperability = is to set the appropriate version number prior to a connection = transition to RDMA / DDP mode. =20 (4) A RDMAC-only implementation would not negotiate MPA since this is = not part of the RDMAC specifications. The draft implies that any RDMAC = compliant implementation would be augmented to provide MPA negotiation. = I don't see how this can be required - at best, it is an option to = implement and may or may not be present on a given endnode. If this is = not implemented, the two sides will simply fail the RDMA stream = establishment. In general, the tables showing the negotiation at the = MPA level look reasonable. (5) It is not clear that new verbs extensions are required for = interoperability. The verbs specification section 9.3 already states = how a version mismatch (DDP or RDMA) should be surfaced. There is value = in being able to configure a RNIC (on a per session basis) as to what = version to support. This should be done once and cause all layers to = use a consistent version for a given QP. The value should be set at QP = creation and then updated upon session establishment if the RNIC can = support both RDMAC and IETF specifications. I also see value in having = the query what the current version is. I don't see why a ModifyQP is = required as one knows up front what is desired and the implementation if = permissive, would negotiate accordingly. Therefore all that is needed = is to understand the result.=20 ------_=_NextPart_001_01C4D655.D320BD38 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
thanks for your comments.  =
 
On re-reading the drafts, I agree that the = DDP draft=20 does state very clearly that the version fields must match (sec = 4.1). =20 However, I find no such statement in the RDMAP draft (other than=20 stating the field must be 01b, there is no corresponding statement = that the=20 receiver must check or that, if it checks, what 'valid' = means).   My=20 error for over-simplifying to introduce the problem.
 
The interoperability issue I=20 addressed in the RDDP WG meeting was that I knew there were schemes = being=20 considered (external to the IETF) for allowing RDMAC RNICs to = interoperate with=20 IETF RNICs and that unless the WG offered some informational text = describing an=20 interoperability mechanism, then the results would be open to vendor=20 implementation. 
 
In the draft, Jim & I suggest changing = the MPA=20 version from 0 to 1 so that a ULP (or other entity) could do the = MPA=20 negotiation for an RDMAC RNIC (which would use the version of 0).  = Very=20 clearly an RDMAC-only RNIC without this other entity could not attempt = to=20 interoperate with a "Permissive" IETF RNIC.  For an IETF-only = RNIC,=20 the change has no effect: it can only interoperate with other IETF = RNICs. =20
 
The goal of the draft, then, is to provide a = mechanism=20 for ULPs or other entities (such as the OpenGroup's IT API & RNIC = PI) to=20 create a common interface to RDMAC as well as IETF RNICs that enables=20 interoperability between the RNICs where possible.
 
--jc
-----Original Message-----
From: = rddp-bounces@ietf.org=20 [mailto:rddp-bounces@ietf.org]On Behalf Of Michael=20 Krause
Sent: Monday, November 29, 2004 11:11 = AM
To:=20 rddp@ietf.org
Subject: RE: [rddp]=20 draft-carrier-rddp-rnic-interop-00.txt

At=20 06:40 PM 11/23/2004, Jim Pinkerton wrote:


Feedback is = appreciated on this=20 draft. This was a result of an informal
group working over beers = after=20 the RDDP work group meeting gave us
direction to try to solve=20 interoperability as an informative appendix to
the MPA = specification.=20

John and I tried to be very specific about the exact = recommended=20 text
changes for the various drafts, to hopefully expedite the = review=20 process
with something concrete to shoot = at.

Initial=20 comments.

Mike

(1) It is not clear to me where there is=20 ambiguity within the specifications.  The RDMAP specification=20 (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA = version MUST=20 be 01b.  The table in section 6.8 states that a remote operation = error is=20 generated for a RDMAP version error.  The RDMAC RDMAP = specification=20 contains the same language but states the version MUST be 00b.  = As such,=20 it clear what the version must be and the error that should be = returned if=20 there is a version mismatch which contradicts the assertions made in = section 3=20 of the interop draft.

(2) The DDP specification=20 (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be = set to=20 1.  Section 7.2 states that an invalid version must be returned = upon=20 detecting a mismatch and section 7.1 states that upon error detection, = DDP  must stop placing segments and return an error to the = ULP.  In=20 this case, it would be to surface an error to RDMA.  The RDMAC = DDP=20 specification contains the same language but states the version MUST = be=20 00b.  Again, this contradicts the assertions made in section 3 of = the=20 interop draft.

(3) I agree that there are three cases of=20 implementations that can exist.  However, it seems that the=20 specifications are relatively clear on what the versions must be for = each set=20 of specifications.  It is also clear what the expected behavior = should be=20 as well, i.e. the generation / surfacing of an error.  As such, a = RDMAC=20 implementation would require the version to be 0 to be compliant while = the=20 IETF implementations would require the version to be 1.  The only = way to=20 achieve interoperability is to set the appropriate version number = prior to a=20 connection transition to RDMA / DDP mode. 

(4) A = RDMAC-only=20 implementation would not negotiate MPA since this is not part of the = RDMAC=20 specifications.  The draft implies that any RDMAC compliant=20 implementation would be augmented to provide MPA negotiation.  I = don't=20 see how this can be required - at best, it is an option to implement = and may=20 or may not be present on a given endnode.  If this is not = implemented,=20 the two sides will simply fail the RDMA stream establishment.  In = general, the tables showing the negotiation at the MPA level look=20 reasonable.

(5) It is not clear that new verbs extensions are = required=20 for interoperability.  The verbs specification section 9.3 = already states=20 how a version mismatch (DDP or RDMA) should be surfaced.  There = is value=20 in being able to configure a RNIC (on a per session basis) as to what = version=20 to support.  This should be done once and cause all layers to use = a=20 consistent version for a given QP.  The value should be set at QP = creation and then updated upon session establishment if the RNIC can = support=20 both RDMAC and IETF specifications.  I also see value in having = the query=20 what the current version is.  I don't see why a ModifyQP is = required as=20 one knows up front what is desired and the implementation if = permissive, would=20 negotiate accordingly.  Therefore all that is needed is to = understand the=20 result. ------_=_NextPart_001_01C4D655.D320BD38-- --===============1406446815== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1406446815==-- From rddp-bounces@ietf.org Mon Nov 29 18:17:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25291 for ; Mon, 29 Nov 2004 18:17:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuqF-0002EC-S6 for rddp-web-archive@ietf.org; Mon, 29 Nov 2004 18:22:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYujL-0003oR-TU; Mon, 29 Nov 2004 18:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYub4-0008OC-8V for rddp@megatron.ietf.org; Mon, 29 Nov 2004 18:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24164 for ; Mon, 29 Nov 2004 18:06:15 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYufq-00023F-GW for rddp@ietf.org; Mon, 29 Nov 2004 18:11:27 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel10.hp.com (Postfix) with ESMTP id ADB137A195 for ; Mon, 29 Nov 2004 15:06:03 -0800 (PST) Received: from MK73191c.cup.hp.com ([15.244.202.65]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id PAA17121 for ; Mon, 29 Nov 2004 15:03:26 -0800 (PST) Message-Id: <6.1.2.0.2.20041129134111.01e3f228@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 13:44:00 -0800 To: rddp@ietf.org From: Michael Krause Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 2.0 (++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0660135416==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 025f8c5000216988bfe31585db759250 --===============0660135416== Content-Type: multipart/alternative; boundary="=====================_20692554==.ALT" --=====================_20692554==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:55 PM 11/29/2004, Carrier, John wrote: >Hi Mike, > >thanks for your comments. > >On re-reading the drafts, I agree that the DDP draft does state very >clearly that the version fields must match (sec 4.1). However, I find no >such statement in the RDMAP draft (other than stating the field must be >01b, there is no corresponding statement that the receiver must check or >that, if it checks, what 'valid' means). My error for over-simplifying >to introduce the problem. I believe the table I called out below makes it clear what the error to be generated is and what the condition is for RDMAP. > >The interoperability issue I addressed in the RDDP WG meeting was that I >knew there were schemes being considered (external to the IETF) for >allowing RDMAC RNICs to interoperate with IETF RNICs and that unless the >WG offered some informational text describing an interoperability >mechanism, then the results would be open to vendor implementation. > >In the draft, Jim & I suggest changing the MPA version from 0 to 1 so that >a ULP (or other entity) could do the MPA negotiation for an RDMAC RNIC >(which would use the version of 0). Very clearly an RDMAC-only RNIC >without this other entity could not attempt to interoperate with a >"Permissive" IETF RNIC. For an IETF-only RNIC, the change has no effect: >it can only interoperate with other IETF RNICs. > >The goal of the draft, then, is to provide a mechanism for ULPs or other >entities (such as the OpenGroup's IT API & RNIC PI) to create a common >interface to RDMAC as well as IETF RNICs that enables interoperability >between the RNICs where possible. I agree with the intention and the basic tables. I do not agree necessarily with all of the proposed changes to the other specifications. This is all that I'm pointing out in my feedback. Mike > >--jc >-----Original Message----- >From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of >Michael Krause >Sent: Monday, November 29, 2004 11:11 AM >To: rddp@ietf.org >Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt > >At 06:40 PM 11/23/2004, Jim Pinkerton wrote: > > >>Feedback is appreciated on this draft. This was a result of an informal >>group working over beers after the RDDP work group meeting gave us >>direction to try to solve interoperability as an informative appendix to >>the MPA specification. >> >>John and I tried to be very specific about the exact recommended text >>changes for the various drafts, to hopefully expedite the review process >>with something concrete to shoot at. > >Initial comments. > >Mike > >(1) It is not clear to me where there is ambiguity within the >specifications. The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) >section 6.1 states that the RDMA version MUST be 01b. The table in >section 6.8 states that a remote operation error is generated for a RDMAP >version error. The RDMAC RDMAP specification contains the same language >but states the version MUST be 00b. As such, it clear what the version >must be and the error that should be returned if there is a version >mismatch which contradicts the assertions made in section 3 of the interop >draft. > >(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states >the DV bits must be set to 1. Section 7.2 states that an invalid version >must be returned upon detecting a mismatch and section 7.1 states that >upon error detection, DDP must stop placing segments and return an error >to the ULP. In this case, it would be to surface an error to RDMA. The >RDMAC DDP specification contains the same language but states the version >MUST be 00b. Again, this contradicts the assertions made in section 3 of >the interop draft. > >(3) I agree that there are three cases of implementations that can >exist. However, it seems that the specifications are relatively clear on >what the versions must be for each set of specifications. It is also >clear what the expected behavior should be as well, i.e. the generation / >surfacing of an error. As such, a RDMAC implementation would require the >version to be 0 to be compliant while the IETF implementations would >require the version to be 1. The only way to achieve interoperability is >to set the appropriate version number prior to a connection transition to >RDMA / DDP mode. > >(4) A RDMAC-only implementation would not negotiate MPA since this is not >part of the RDMAC specifications. The draft implies that any RDMAC >compliant implementation would be augmented to provide MPA negotiation. I >don't see how this can be required - at best, it is an option to implement >and may or may not be present on a given endnode. If this is not >implemented, the two sides will simply fail the RDMA stream >establishment. In general, the tables showing the negotiation at the MPA >level look reasonable. > >(5) It is not clear that new verbs extensions are required for >interoperability. The verbs specification section 9.3 already states how >a version mismatch (DDP or RDMA) should be surfaced. There is value in >being able to configure a RNIC (on a per session basis) as to what version >to support. This should be done once and cause all layers to use a >consistent version for a given QP. The value should be set at QP creation >and then updated upon session establishment if the RNIC can support both >RDMAC and IETF specifications. I also see value in having the query what >the current version is. I don't see why a ModifyQP is required as one >knows up front what is desired and the implementation if permissive, would >negotiate accordingly. Therefore all that is needed is to understand the >result. --=====================_20692554==.ALT Content-Type: text/html; charset="us-ascii" At 12:55 PM 11/29/2004, Carrier, John wrote:
Hi Mike,
 
thanks for your comments. 
 
On re-reading the drafts, I agree that the DDP draft does state very clearly that the version fields must match (sec 4.1).  However, I find no such statement in the RDMAP draft (other than stating the field must be 01b, there is no corresponding statement that the receiver must check or that, if it checks, what 'valid' means).   My error for over-simplifying to introduce the problem.

I believe the table I called out below makes it clear what the error to be generated is and what the condition is for RDMAP. 

 
The interoperability issue I addressed in the RDDP WG meeting was that I knew there were schemes being considered (external to the IETF) for allowing RDMAC RNICs to interoperate with IETF RNICs and that unless the WG offered some informational text describing an interoperability mechanism, then the results would be open to vendor implementation. 
 
In the draft, Jim & I suggest changing the MPA version from 0 to 1 so that a ULP (or other entity) could do the MPA negotiation for an RDMAC RNIC (which would use the version of 0).  Very clearly an RDMAC-only RNIC without this other entity could not attempt to interoperate with a "Permissive" IETF RNIC.  For an IETF-only RNIC, the change has no effect: it can only interoperate with other IETF RNICs. 
 
The goal of the draft, then, is to provide a mechanism for ULPs or other entities (such as the OpenGroup's IT API & RNIC PI) to create a common interface to RDMAC as well as IETF RNICs that enables interoperability between the RNICs where possible.

I agree with the intention and the basic tables.   I do not agree necessarily with all of the proposed changes to the other specifications.  This is all that I'm pointing out in my feedback.

Mike

 
--jc
-----Original Message-----
From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of Michael Krause
Sent: Monday, November 29, 2004 11:11 AM
To: rddp@ietf.org
Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt
At 06:40 PM 11/23/2004, Jim Pinkerton wrote:


Feedback is appreciated on this draft. This was a result of an informal
group working over beers after the RDDP work group meeting gave us
direction to try to solve interoperability as an informative appendix to
the MPA specification.

John and I tried to be very specific about the exact recommended text
changes for the various drafts, to hopefully expedite the review process
with something concrete to shoot at.

Initial comments.

Mike

(1) It is not clear to me where there is ambiguity within the specifications.  The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b.  The table in section 6.8 states that a remote operation error is generated for a RDMAP version error.  The RDMAC RDMAP specification contains the same language but states the version MUST be 00b.  As such, it clear what the version must be and the error that should be returned if there is a version mismatch which contradicts the assertions made in section 3 of the interop draft.

(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be set to 1.  Section 7.2 states that an invalid version must be returned upon detecting a mismatch and section 7.1 states that upon error detection, DDP  must stop placing segments and return an error to the ULP.  In this case, it would be to surface an error to RDMA.  The RDMAC DDP specification contains the same language but states the version MUST be 00b.  Again, this contradicts the assertions made in section 3 of the interop draft.

(3) I agree that there are three cases of implementations that can exist.  However, it seems that the specifications are relatively clear on what the versions must be for each set of specifications.  It is also clear what the expected behavior should be as well, i.e. the generation / surfacing of an error.  As such, a RDMAC implementation would require the version to be 0 to be compliant while the IETF implementations would require the version to be 1.  The only way to achieve interoperability is to set the appropriate version number prior to a connection transition to RDMA / DDP mode. 

(4) A RDMAC-only implementation would not negotiate MPA since this is not part of the RDMAC specifications.  The draft implies that any RDMAC compliant implementation would be augmented to provide MPA negotiation.  I don't see how this can be required - at best, it is an option to implement and may or may not be present on a given endnode.  If this is not implemented, the two sides will simply fail the RDMA stream establishment.  In general, the tables showing the negotiation at the MPA level look reasonable.

(5) It is not clear that new verbs extensions are required for interoperability.  The verbs specification section 9.3 already states how a version mismatch (DDP or RDMA) should be surfaced.  There is value in being able to configure a RNIC (on a per session basis) as to what version to support.  This should be done once and cause all layers to use a consistent version for a given QP.  The value should be set at QP creation and then updated upon session establishment if the RNIC can support both RDMAC and IETF specifications.  I also see value in having the query what the current version is.  I don't see why a ModifyQP is required as one knows up front what is desired and the implementation if permissive, would negotiate accordingly.  Therefore all that is needed is to understand the result.
--=====================_20692554==.ALT-- --===============0660135416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0660135416==-- From rddp-bounces@ietf.org Mon Nov 29 18:18:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25400 for ; Mon, 29 Nov 2004 18:18:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYurY-0002FP-Fv for rddp-web-archive@ietf.org; Mon, 29 Nov 2004 18:23:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYujM-0003ok-7X; Mon, 29 Nov 2004 18:14:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYub4-0008OF-Ox for rddp@megatron.ietf.org; Mon, 29 Nov 2004 18:06:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24169 for ; Mon, 29 Nov 2004 18:06:16 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYug3-00023q-LV for rddp@ietf.org; Mon, 29 Nov 2004 18:11:28 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id D4BA324C54 for ; Mon, 29 Nov 2004 15:06:16 -0800 (PST) Received: from MK73191c.cup.hp.com ([15.244.202.65]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id PAA17139 for ; Mon, 29 Nov 2004 15:03:38 -0800 (PST) Message-Id: <6.1.2.0.2.20041129135310.01cc7d38@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 13:54:14 -0800 To: From: Michael Krause Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 2.1 (++) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1694624944==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 --===============1694624944== Content-Type: multipart/alternative; boundary="=====================_20692674==.ALT" --=====================_20692674==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable At 12:00 PM 11/29/2004, Jim Pinkerton wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C4D64E.08822EE0" > > >Commenting to 5), the reason why both CreateQP and ModifyQP is needed is=20 >because some protocols (notably ISER) don=92t want to negotiate RDMA=20 >capability unless they know that resources are available for RDMA. So I=20 >would expect this class of protocols to first do a CreateQP before=20 >exchanging keys. At this time, you don=92t know what the version number= will=20 >be negotiated to (assuming the interoperability protocol suggested in the= =20 >draft), thus only after reception of a REQ/REP frame do you set the=20 >version number, which must be done using a ModifyQP. Agreed. >On 4), possibly the wording could be improved. It really comes down to=20 >RDMAC versions which wish to interoperate with IETF versions. Those that=20 >don=92t try, won=92t J Understood. >Mike, with the exceptions of the concerns on changes to MPA/DDP/RDMAP to=20 >give the right level of =93escape hatch=94, does the approach appear sound?= =20 >Note that the ambiguity in some of them has to work the other way =96 make= =20 >it more ambiguous =96 i.e. if you are able to talk with version 0, allow= you=20 >to do so (current text prohibits it). Yes. I agree with the general approach. This is a good first draft so=20 perhaps my comments are being perhaps a bit picky to start. Mike > > > >Jim > > > > >---------- >From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of=20 >Michael Krause >Sent: Monday, November 29, 2004 11:11 AM >To: rddp@ietf.org >Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt > >At 06:40 PM 11/23/2004, Jim Pinkerton wrote: > > > >Feedback is appreciated on this draft. This was a result of an informal >group working over beers after the RDDP work group meeting gave us >direction to try to solve interoperability as an informative appendix to >the MPA specification. > >John and I tried to be very specific about the exact recommended text >changes for the various drafts, to hopefully expedite the review process >with something concrete to shoot at. > >Initial comments. > >Mike > >(1) It is not clear to me where there is ambiguity within the=20 >specifications. The RDMAP specification (draft-ietf-rddp-rdmap-02.txt)=20 >section 6.1 states that the RDMA version MUST be 01b. The table in=20 >section 6.8 states that a remote operation error is generated for a RDMAP= =20 >version error. The RDMAC RDMAP specification contains the same language=20 >but states the version MUST be 00b. As such, it clear what the version=20 >must be and the error that should be returned if there is a version=20 >mismatch which contradicts the assertions made in section 3 of the interop= =20 >draft. > >(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states= =20 >the DV bits must be set to 1. Section 7.2 states that an invalid version= =20 >must be returned upon detecting a mismatch and section 7.1 states that=20 >upon error detection, DDP must stop placing segments and return an error= =20 >to the ULP. In this case, it would be to surface an error to RDMA. The=20 >RDMAC DDP specification contains the same language but states the version= =20 >MUST be 00b. Again, this contradicts the assertions made in section 3 of= =20 >the interop draft. > >(3) I agree that there are three cases of implementations that can=20 >exist. However, it seems that the specifications are relatively clear on= =20 >what the versions must be for each set of specifications. It is also=20 >clear what the expected behavior should be as well, i.e. the generation /= =20 >surfacing of an error. As such, a RDMAC implementation would require the= =20 >version to be 0 to be compliant while the IETF implementations would=20 >require the version to be 1. The only way to achieve interoperability is= =20 >to set the appropriate version number prior to a connection transition to= =20 >RDMA / DDP mode. > >(4) A RDMAC-only implementation would not negotiate MPA since this is not= =20 >part of the RDMAC specifications. The draft implies that any RDMAC=20 >compliant implementation would be augmented to provide MPA negotiation. I= =20 >don't see how this can be required - at best, it is an option to implement= =20 >and may or may not be present on a given endnode. If this is not=20 >implemented, the two sides will simply fail the RDMA stream=20 >establishment. In general, the tables showing the negotiation at the MPA= =20 >level look reasonable. > >(5) It is not clear that new verbs extensions are required for=20 >interoperability. The verbs specification section 9.3 already states how= =20 >a version mismatch (DDP or RDMA) should be surfaced. There is value in=20 >being able to configure a RNIC (on a per session basis) as to what version= =20 >to support. This should be done once and cause all layers to use a=20 >consistent version for a given QP. The value should be set at QP creation= =20 >and then updated upon session establishment if the RNIC can support both=20 >RDMAC and IETF specifications. I also see value in having the query what= =20 >the current version is. I don't see why a ModifyQP is required as one=20 >knows up front what is desired and the implementation if permissive, would= =20 >negotiate accordingly. Therefore all that is needed is to understand the= =20 >result. >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp --=====================_20692674==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 12:00 PM 11/29/2004, Jim Pinkerton wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
        boundary=3D&q= uot;----_=3D_NextPart_001_01C4D64E.08822EE0"

 
Commenting to 5), the reason why both CreateQP and ModifyQP is needed is because some protocols (notably ISER) don=92t want to negotiate RDMA capability unless they know that resources are available for RDMA.  So I would expect this class of protocols to first do a CreateQP before exchanging keys. At this time, you don=92t know what the version number will be negotiated to (assuming the interoperability protocol suggested in the draft), thus only after reception of a REQ/REP frame do you set the version number, which must be done using a ModifyQP.

Agreed.

On 4), possibly the wording could be improved. It really comes down to RDMAC versions which wish to interoperate with IETF versions. Those that don=92t try, won=92t J

Understood.

Mike, with the exceptions of the concerns on changes to MPA/DDP/RDMAP to give the right level of =93escape hatch=94, does the approach appear sound? Note that the ambiguity in some of them has to work the other way =96 make it more ambiguous =96 i.e. if you are able to talk with version 0, allow you to do so (current text prohibits it).

Yes.  I agree with the general approach.  This is a good first draft so perhaps my comments are being perhaps a bit picky to start.

Mike

 
 
 
Jim
 
 
 
From: rddp-bounces@ietf.org [mailto:rddp-bou= nces@ietf.org] On Behalf Of Michael Krause
Sent: Monday, November 29, 2004 11:11 AM
To: rddp@ietf.org
Subject: RE: [rddp] draft-carrier-rddp-rnic-interop-00.txt
 
At 06:40 PM 11/23/2004, Jim Pinkerton wrote:



Feedback is appreciated on this draft. This was a result of an informal
group working over beers after the RDDP work group meeting gave us
direction to try to solve interoperability as an informative appendix to
the MPA specification.

John and I tried to be very specific about the exact recommended text
changes for the various drafts, to hopefully expedite the review process
with something concrete to shoot at.

Initial comments.

Mike

(1) It is not clear to me where there is ambiguity within the specifications.  The RDMAP specification (draft-ietf-rddp-rdmap-02.txt) section 6.1 states that the RDMA version MUST be 01b.  The table in section 6.8 states that a remote operation error is generated for a RDMAP version error.  The RDMAC RDMAP specification contains the same language but states the version MUST be 00b.  As such, it clear what the version must be and the error that should be returned if there is a version mismatch which contradicts the assertions made in section 3 of the interop draft.

(2) The DDP specification (draft-ietf-rddp-ddp-03.txt) section 4.1 states the DV bits must be set to 1.  Section 7.2 states that an invalid version must be returned upon detecting a mismatch and section 7.1 states that upon error detection, DDP  must stop placing segments and return an error to the ULP.  In this case, it would be to surface an error to RDMA.  The RDMAC DDP specification contains the same language but states the version MUST be 00b.  Again, this contradicts the assertions made in section 3 of the interop draft.

(3) I agree that there are three cases of implementations that can exist.  However, it seems that the specifications are relatively clear on what the versions must be for each set of specifications.  It is also clear what the expected behavior should be as well, i.e. the generation / surfacing of an error.  As such, a RDMAC implementation would require the version to be 0 to be compliant while the IETF implementations would require the version to be 1.  The only way to achieve interoperability is to set the appropriate version number prior to a connection transition to RDMA / DDP mode. 

(4) A RDMAC-only implementation would not negotiate MPA since this is not part of the RDMAC specifications.  The draft implies that any RDMAC compliant implementation would be augmented to provide MPA negotiation.  I don't see how this can be required - at best, it is an option to implement and may or may not be present on a given endnode.  If this is not implemented, the two sides will simply fail the RDMA stream establishment.  In general, the tables showing the negotiation at the MPA level look reasonable.

(5) It is not clear that new verbs extensions are required for interoperability.  The verbs specification section 9.3 already states how a version mismatch (DDP or RDMA) should be surfaced.  There is value in being able to configure a RNIC (on a per session basis) as to what version to support.  This should be done once and cause all layers to use a consistent version for a given QP.  The value should be set at QP creation and then updated upon session establishment if the RNIC can support both RDMAC and IETF specifications.  I also see value in having the query what the current version is.  I don't see why a ModifyQP is required as one knows up front what is desired and the implementation if permissive, would negotiate accordingly.  Therefore all that is needed is to understand the result.
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp --=====================_20692674==.ALT-- --===============1694624944== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1694624944==-- From rddp-bounces@ietf.org Tue Nov 30 07:54:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14137 for ; Tue, 30 Nov 2004 07:54:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7bS-0002cP-H8 for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 07:59:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7UC-0006UL-G2; Tue, 30 Nov 2004 07:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7Rj-00064n-Jm for rddp@megatron.ietf.org; Tue, 30 Nov 2004 07:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13815 for ; Tue, 30 Nov 2004 07:49:30 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7Wg-0002WX-Di for rddp@ietf.org; Tue, 30 Nov 2004 07:54:48 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AC4833CF0262; Tue, 30 Nov 2004 07:49:12 -0500 From: "Barry Reinhold" To: , "RDDP" Date: Tue, 30 Nov 2004 07:49:13 -0500 Message-ID: <000901c4d6da$fe812e70$217fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Subject: [rddp] Need some clarification on how to "locate the start of the FPDU unambiguously" X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit If markers are being used is it mandatory to also be using CRCs? This question arises out of the requirements of clause 5.4: Clause 5.4 of MPA states the following: ============ An MPA receiver MUST first verify the FPDU before passing the ULPDU to DDP. To do this, the receiver MUST: * locate the start of the FPDU unambiguously, * verify its CRC (if CRC checking is enabled). If the above conditions are true, the MPA receiver passes the ULPDU to DDP. To detect the start of the FPDU unambiguously one of the following MUST be used: 1: In an ordered TCP stream, the ULPDU Length field in the current FPDU when FPDU has a valid CRC, can be used to identify the beginning of the next FPDU. 2: For receivers that support out of order reception of FPDUs (see section 5.1 MPA Markers on page 16) a Marker can always be used to locate the beginning of an FPDU (in FPDUs with valid CRCs). Since the location of the marker is known in the octet stream (sequence number space), the marker can always be found. 3: Having found an FPDU by means of a Marker, following contiguous FPDUs can be found by using the ULPDU Lengths (from FPDUs with valid CRCs) to establish the next FPDU boundary. ======= If we have an out of order FPDU, and support markers, we use the next available marker to recover stream sync. By item two above, this requires that we validate the FPDU which has the marker in it with a CRC. Hence it appears that an implementation planning on using markers must also require that CRCs be supported. Is this the intent? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 08:41:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17162 for ; Tue, 30 Nov 2004 08:41:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8Ku-0003g8-Mw for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 08:46:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8EZ-0006v0-5U; Tue, 30 Nov 2004 08:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8Aq-0006If-7T for rddp@megatron.ietf.org; Tue, 30 Nov 2004 08:36:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16962 for ; Tue, 30 Nov 2004 08:36:06 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8Fw-0003bY-Pr for rddp@ietf.org; Tue, 30 Nov 2004 08:41:26 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A746DA60060; Tue, 30 Nov 2004 08:36:06 -0500 From: "Barry Reinhold" To: "RDDP" Date: Tue, 30 Nov 2004 08:36:01 -0500 Message-ID: <000c01c4d6e1$8b854850$217fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: iwarp-tech@iol.unh.edu Subject: [rddp] (no subject) X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit I would like to know if there is agreement on the following: Given a Marker supporting Data Source that sends: ++++++++++++++++++++++++++++ | TCP SEG #1 | ++++++++++++++++++++++++++++ Contains FPDU A (write STag 1, loc 100 with 100 A's) ++++++++++++++++++++++++++++ | TCP SEG #2 | ++++++++++++++++++++++++++++ Contains FPDU B (write STag 1, loc 200 with 100 B's) ++++++++++++++++++++++++++++ | TCP SEG #3 | ++++++++++++++++++++++++++++ Contains FPDU C (write STag 1, loc 300 with 100 C's), and FPDU D (Read STag 1, 100 bytes from loc 300) A marker falls in FPDU D. During transmission TCP SEG #2 is lost, such that TCP SEG #3 arrives out of order at the Data Sink. The iWARP receiver recovers FPDU sync by using the marker in FPDU D. TCP SEG #2 then arrives. Is it the case that for a "conformant" Data Sink the contents in the RDMA READ RESPONSE SHALL be "C"s? This is interesting in that there is no gap in the TCP sequence space as delivered by TCP to MPA, but there is a gap in terms of what MPA has "processed". Since clause 5.4 states that: At the Data Sink, DDP MUST Deliver a DDP Message if and only if all of the following are true: * the last DDP Segment of the DDP Message had its Last flag set, * all of the DDP Segments of the DDP Message have been Placed, * all preceding DDP Messages have been Placed, and * each preceding DDP Message has been Delivered to the ULP. I assume that we can expect "C"s in the READ RESPONSE. This is scheduled to become a conformance test, so I would like to ensure there is agreement. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 09:24:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20974 for ; Tue, 30 Nov 2004 09:24:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ90M-0004hX-Ra for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 09:29:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8sZ-0006Zz-8b; Tue, 30 Nov 2004 09:21:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8fp-0004UI-S9 for rddp@megatron.ietf.org; Tue, 30 Nov 2004 09:08:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19425 for ; Tue, 30 Nov 2004 09:08:07 -0500 (EST) Received: from 67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8kt-0004Hl-RV for rddp@ietf.org; Tue, 30 Nov 2004 09:13:27 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Need some clarification on how to "locate the start of theFPDU unambiguously" Date: Tue, 30 Nov 2004 06:07:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [rddp] Need some clarification on how to "locate the start of theFPDU unambiguously" Thread-Index: AcTW2+dKV8Ofgwc4RFu+w8SpSLvEUAACZkoA From: "Caitlin Bestler" To: "Barry Reinhold" , , "RDDP" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Keep in mind that "CRC suppression" does not eliminate the field, only generating it and checking it.=20 So my reading has always been that when CRCs are "suppressed"=20 that the CRC field is always "valid". Given the scenarios identified for suppressing CRCs, when there is equivalent protection from IPSEC or something else, I think it is also clear that this was the intent. > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Barry Reinhold > Sent: Tuesday, November 30, 2004 4:49 AM > To: iwarp-tech@iol.unh.edu; RDDP > Subject: [rddp] Need some clarification on how to "locate the=20 > start of theFPDU unambiguously" >=20 > If markers are being used is it mandatory to also be using CRCs? > This question arises out of the requirements of clause 5.4: >=20 > Clause 5.4 of MPA states the following: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > An MPA receiver MUST first verify the FPDU before passing the ULPDU > to DDP. To do this, the receiver MUST: >=20 >=20 > * locate the start of the FPDU unambiguously, >=20 >=20 > * verify its CRC (if CRC checking is enabled). >=20 >=20 > If the above conditions are true, the MPA receiver passes the ULPDU > to DDP. >=20 >=20 > To detect the start of the FPDU unambiguously one of the following > MUST be used: >=20 >=20 > 1: In an ordered TCP stream, the ULPDU Length field in the current > FPDU when FPDU has a valid CRC, can be used to identify the > beginning of the next FPDU. >=20 >=20 > 2: For receivers that support out of order reception of FPDUs (see > section 5.1 MPA Markers on page 16) a Marker can always be used > to locate the beginning of an FPDU (in FPDUs with valid CRCs). > Since the location of the marker is known in the octet stream > (sequence number space), the marker can always be found. >=20 >=20 > 3: Having found an FPDU by means of a Marker, following contiguous > FPDUs can be found by using the ULPDU Lengths (from FPDUs with > valid CRCs) to establish the next FPDU boundary. > =3D=3D=3D=3D=3D=3D=3D >=20 > If we have an out of order FPDU, and support markers, we use=20 > the next available marker to recover stream sync. By item two=20 > above, this requires that we validate the FPDU which has the=20 > marker in it with a CRC. >=20 > Hence it appears that an implementation planning on using=20 > markers must also require that CRCs be supported. Is this the intent? >=20 > =20 >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 09:32:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21851 for ; Tue, 30 Nov 2004 09:32:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ98V-0004uN-Dx for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 09:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8v7-0007BD-Ue; Tue, 30 Nov 2004 09:23:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8pO-00060H-Hj for rddp@megatron.ietf.org; Tue, 30 Nov 2004 09:18:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20235 for ; Tue, 30 Nov 2004 09:18:00 -0500 (EST) Received: from 67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8uV-0004WQ-VI for rddp@ietf.org; Tue, 30 Nov 2004 09:23:20 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] (no subject) Date: Tue, 30 Nov 2004 06:17:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: [rddp] (no subject) Thread-Index: AcTW4l4RH4Rvhy4hTfOPBfA/WvEWYwABCuHA From: "Caitlin Bestler" To: "Barry Reinhold" , "RDDP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: iwarp-tech@iol.unh.edu X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Barry Reinhold > Sent: Tuesday, November 30, 2004 5:36 AM > To: RDDP > Cc: iwarp-tech@iol.unh.edu > Subject: [rddp] (no subject) >=20 >=20 > I would like to know if there is agreement on the following: >=20 > Given a Marker supporting Data Source that sends: >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #1 | > ++++++++++++++++++++++++++++ > Contains FPDU A (write STag 1, loc 100 with 100 A's) >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #2 | > ++++++++++++++++++++++++++++ > Contains FPDU B (write STag 1, loc 200 with 100 B's) >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #3 | > ++++++++++++++++++++++++++++ > Contains FPDU C (write STag 1, loc 300 with 100 C's), and=20 > FPDU D (Read STag 1, 100 bytes from loc 300) >=20 > A marker falls in FPDU D. >=20 > During transmission TCP SEG #2 is lost, such that TCP SEG #3=20 > arrives out of order at the Data Sink. The iWARP receiver=20 > recovers FPDU sync by using the marker in FPDU D. TCP SEG #2=20 > then arrives. >=20 Recovering the marker for FPDU D allows DDP to process FPDU D. That allows the RDMA Read Request to be *placed*, presumably Into an internal IRD queue. But it cannot be acted upon by The RDMAP layer until it is deliverable, as described in=20 The section you cited (5.4). Therefore all prior writes, including to location 300, will have been placed before FPDU D is "delivered" to the RDMAP layer. And until it=20 is delivered it is not an RDMA Read Request, ad the DDP layer it is just an untagged message to queue 1. > Is it the case that for a "conformant" Data Sink the contents=20 > in the RDMA READ RESPONSE SHALL be "C"s? >=20 > This is interesting in that there is no gap in the TCP=20 > sequence space as delivered by TCP to MPA, but there is a gap=20 > in terms of what MPA has "processed". >=20 > Since clause 5.4 states that: >=20 > At the Data Sink, DDP MUST Deliver a DDP Message if and only if all=20 > of the following are true:=20 >=20 > * the last DDP Segment of the DDP Message had its Last=20 > flag set, =20 >=20 > * all of the DDP Segments of the DDP Message have been Placed,=20 >=20 > * all preceding DDP Messages have been Placed, and=20 >=20 > * each preceding DDP Message has been Delivered to the ULP. >=20 > I assume that we can expect "C"s in the READ RESPONSE. >=20 > This is scheduled to become a conformance test, so I would=20 > like to ensure there is agreement. > =20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 09:54:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24404 for ; Tue, 30 Nov 2004 09:54:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Ty-0005Zo-LA for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 09:59:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9L6-0006Hu-1Q; Tue, 30 Nov 2004 09:50:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9Dt-0003iS-5m for rddp@megatron.ietf.org; Tue, 30 Nov 2004 09:43:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22928 for ; Tue, 30 Nov 2004 09:43:19 -0500 (EST) Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9J0-0005Br-3B for rddp@ietf.org; Tue, 30 Nov 2004 09:48:39 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 0C6EA5F7; Tue, 30 Nov 2004 08:42:48 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 08:42:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Need some clarification on how to "locate the start oftheFPDU unambiguously" Date: Tue, 30 Nov 2004 08:42:46 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762F18E7BF@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] Need some clarification on how to "locate the start oftheFPDU unambiguously" Thread-Index: AcTW2+dKV8Ofgwc4RFu+w8SpSLvEUAACZkoAAAFE+mA= From: "Culley, Paul" To: "Caitlin Bestler" , "Barry Reinhold" , , "RDDP" X-OriginalArrivalTime: 30 Nov 2004 14:42:47.0881 (UTC) FILETIME=[DC3BBB90:01C4D6EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable I agree with Caitlin; when CRCs are not used, then the field is always "valid", so you can proceed with FPDU decoding once you have unambiguously found the start and have the whole FPDU. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Caitlin Bestler > Sent: Tuesday, November 30, 2004 8:07 AM > To: Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP > Subject: RE: [rddp] Need some clarification on how to "locate=20 > the start oftheFPDU unambiguously" >=20 > Keep in mind that "CRC suppression" does not eliminate the=20 > field, only generating it and checking it.=20 >=20 > So my reading has always been that when CRCs are "suppressed"=20 > that the CRC field is always "valid". >=20 > Given the scenarios identified for suppressing CRCs, when=20 > there is equivalent protection from IPSEC or something else,=20 > I think it is also clear that this was the intent. >=20 > > -----Original Message----- > > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]=20 > On Behalf=20 > > Of Barry Reinhold > > Sent: Tuesday, November 30, 2004 4:49 AM > > To: iwarp-tech@iol.unh.edu; RDDP > > Subject: [rddp] Need some clarification on how to "locate=20 > the start of=20 > > theFPDU unambiguously" > >=20 > > If markers are being used is it mandatory to also be using CRCs? > > This question arises out of the requirements of clause 5.4: > >=20 > > Clause 5.4 of MPA states the following: > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > An MPA receiver MUST first verify the FPDU before passing the ULPDU > > to DDP. To do this, the receiver MUST: > >=20 > >=20 > > * locate the start of the FPDU unambiguously, > >=20 > >=20 > > * verify its CRC (if CRC checking is enabled). > >=20 > >=20 > > If the above conditions are true, the MPA receiver=20 > passes the ULPDU > > to DDP. > >=20 > >=20 > > To detect the start of the FPDU unambiguously one of the=20 > following > > MUST be used: > >=20 > >=20 > > 1: In an ordered TCP stream, the ULPDU Length field in=20 > the current > > FPDU when FPDU has a valid CRC, can be used to identify the > > beginning of the next FPDU. > >=20 > >=20 > > 2: For receivers that support out of order reception of=20 > FPDUs (see > > section 5.1 MPA Markers on page 16) a Marker can=20 > always be used > > to locate the beginning of an FPDU (in FPDUs with=20 > valid CRCs). > > Since the location of the marker is known in the octet stream > > (sequence number space), the marker can always be found. > >=20 > >=20 > > 3: Having found an FPDU by means of a Marker, following=20 > contiguous > > FPDUs can be found by using the ULPDU Lengths (from=20 > FPDUs with > > valid CRCs) to establish the next FPDU boundary. > > =3D=3D=3D=3D=3D=3D=3D > >=20 > > If we have an out of order FPDU, and support markers, we=20 > use the next=20 > > available marker to recover stream sync. By item two above, this=20 > > requires that we validate the FPDU which has the marker in=20 > it with a=20 > > CRC. > >=20 > > Hence it appears that an implementation planning on using=20 > markers must=20 > > also require that CRCs be supported. Is this the intent? > >=20 > > =20 > >=20 > > Barry Reinhold > > Lamprey Networks > > bbr@lampreynetworks.com > > (603) 868-8411 > > =20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 10:08:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25832 for ; Tue, 30 Nov 2004 10:08:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9hT-0005wC-GI for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 10:13:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9Xb-0003Uc-H8; Tue, 30 Nov 2004 10:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9MO-0006wE-3W for rddp@megatron.ietf.org; Tue, 30 Nov 2004 09:52:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24103 for ; Tue, 30 Nov 2004 09:52:05 -0500 (EST) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZ9R0-0005TH-37 for rddp@ietf.org; Tue, 30 Nov 2004 09:57:26 -0500 Received: (qmail 26637 invoked from network); 30 Nov 2004 14:50:45 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 30 Nov 2004 14:50:45 -0000 Message-ID: <41AC8901.4050702@fid4.com> Date: Tue, 30 Nov 2004 09:51:45 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: RDDP Subject: Re: [rddp] Need some clarification on how to "locate the start of theFPDU unambiguously" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: > Keep in mind that "CRC suppression" does not eliminate the field, > only generating it and checking it. > > So my reading has always been that when CRCs are "suppressed" > that the CRC field is always "valid". This has been my assumption as well. > Given the scenarios identified for suppressing CRCs, when there > is equivalent protection from IPSEC or something else, I think > it is also clear that this was the intent. Since I'm on the subject of making assumptions explicit... When IPsec is mentioned in this context, doesn't it specifically mean IPsec with Authentication (or Authentication & Encryption)? IPsec with Encryption alone isn't a substitute for CRC32c. This is also assuming that the IPsec SPD is setup to ensure that this policy will happen, e.g. there is no way for the remote peer to negotiate the security policy "down". Regards, MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 10:10:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26116 for ; Tue, 30 Nov 2004 10:10:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9jY-0005zP-LA for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 10:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9bx-0006HB-Iw; Tue, 30 Nov 2004 10:08:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9UU-0001AF-Fs for rddp@megatron.ietf.org; Tue, 30 Nov 2004 10:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24972 for ; Tue, 30 Nov 2004 10:00:28 -0500 (EST) Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9Zc-0005hZ-8O for rddp@ietf.org; Tue, 30 Nov 2004 10:05:48 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 80F1FF160; Tue, 30 Nov 2004 08:59:50 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 08:59:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] (no subject) Date: Tue, 30 Nov 2004 08:59:37 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762F18E7D1@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] (no subject) Thread-Index: AcTW4mF0uuYkAmNUQLO/fnuuL48y7wACShsg From: "Culley, Paul" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 30 Nov 2004 14:59:40.0308 (UTC) FILETIME=[37AFD540:01C4D6ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Cc: iwarp-tech@iol.unh.edu X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable The case you describe must result in reading "Cs" from location 300. It would not matter what order FPDU B and C arrived in, they always place in different locations. And the RDMA Read always takes place after both placements have occurred (when delivered). If your test case was meant to place FPDU C in the same location as FPDU B (location 200) then you can get unexpected results. This is an interesting case, one that was explicitly described in the RDMA spec. I quote from section 7.5 "ordering and completions": 3. RDMA Messages that use Tagged and Untagged Buffers MAY be=20 Placed in any order. If an application uses overlapping=20 buffers (points different Messages or portions of a single=20 Message at the same buffer), then it is possible that the last incoming write to the Data Sink buffer will not be the last=20 outgoing data sent from the Data Source.=20 So if both FPDU B and C placed at location 200, and FPDU B arrived later than FPDU C, then you would read back "Bs" from 200, even though you (as a sender) thought you sent the "Cs" later, and they should have been read back. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Barry Reinhold > Sent: Tuesday, November 30, 2004 7:36 AM > To: RDDP > Cc: iwarp-tech@iol.unh.edu > Subject: [rddp] (no subject) >=20 >=20 > I would like to know if there is agreement on the following: >=20 > Given a Marker supporting Data Source that sends: >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #1 | > ++++++++++++++++++++++++++++ > Contains FPDU A (write STag 1, loc 100 with 100 A's) >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #2 | > ++++++++++++++++++++++++++++ > Contains FPDU B (write STag 1, loc 200 with 100 B's) >=20 > ++++++++++++++++++++++++++++ > | TCP SEG #3 | > ++++++++++++++++++++++++++++ > Contains FPDU C (write STag 1, loc 300 with 100 C's), and=20 > FPDU D (Read STag 1, 100 bytes from loc 300) >=20 > A marker falls in FPDU D. >=20 > During transmission TCP SEG #2 is lost, such that TCP SEG #3=20 > arrives out of order at the Data Sink. The iWARP receiver=20 > recovers FPDU sync by using the marker in FPDU D. TCP SEG #2=20 > then arrives. >=20 > Is it the case that for a "conformant" Data Sink the contents=20 > in the RDMA READ RESPONSE SHALL be "C"s? >=20 > This is interesting in that there is no gap in the TCP=20 > sequence space as delivered by TCP to MPA, but there is a gap=20 > in terms of what MPA has "processed". >=20 > Since clause 5.4 states that: >=20 > At the Data Sink, DDP MUST Deliver a DDP Message if and only if all=20 > of the following are true:=20 >=20 > * the last DDP Segment of the DDP Message had its Last=20 > flag set, =20 >=20 > * all of the DDP Segments of the DDP Message have been Placed,=20 >=20 > * all preceding DDP Messages have been Placed, and=20 >=20 > * each preceding DDP Message has been Delivered to the ULP. >=20 > I assume that we can expect "C"s in the READ RESPONSE. >=20 > This is scheduled to become a conformance test, so I would=20 > like to ensure there is agreement. > =20 >=20 >=20 >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 10:30:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28433 for ; Tue, 30 Nov 2004 10:30:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZA2k-0006RK-OT for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 10:35:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9wJ-0006L2-Ai; Tue, 30 Nov 2004 10:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9ok-0003V8-JM for rddp@megatron.ietf.org; Tue, 30 Nov 2004 10:21:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27502 for ; Tue, 30 Nov 2004 10:21:24 -0500 (EST) Received: from web51907.mail.yahoo.com ([206.190.39.50]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZ9tr-0006D3-Tt for rddp@ietf.org; Tue, 30 Nov 2004 10:26:45 -0500 Received: (qmail 69628 invoked by uid 60001); 30 Nov 2004 15:20:54 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=dCJV72W27xMhMxukvqRCbfklLVnf1BgcD+mldSI3V8M9OYzhZkHvcziB9/CkRWJBpA2qz+yUkkn/Q7LuATrbdOjBRHDkzRgZGQ/7otBGqX9WH9PD921DQ9v/IixWRrU0n3ssFbo4vFtAHZzVl2dtMcHjQUQx+PL7DiQBbjNrI3A= ; Message-ID: <20041130152054.69626.qmail@web51907.mail.yahoo.com> Received: from [67.169.120.65] by web51907.mail.yahoo.com via HTTP; Tue, 30 Nov 2004 07:20:54 PST Date: Tue, 30 Nov 2004 07:20:54 -0800 (PST) From: Sukanta ganguly Subject: Re: [rddp] Need some clarification on how to "locate the start of theFPDU unambiguously" To: "Michael C. Cambria" , RDDP In-Reply-To: <41AC8901.4050702@fid4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 MikeC, IPSec with encryption will also attain the same level of integrity and hence it should be OK. Encryption based on IPSec is a much better mechanism rather than just CRC32c. I am not sure what you mean by "negotiating the policy down". Once the IPSec connection with the remote pair is established that is your policy, which is established at the time of connection setup. SG --- "Michael C. Cambria" wrote: > > > Caitlin Bestler wrote: > > > Keep in mind that "CRC suppression" does not > eliminate the field, > > only generating it and checking it. > > > > So my reading has always been that when CRCs are > "suppressed" > > that the CRC field is always "valid". > > This has been my assumption as well. > > > Given the scenarios identified for suppressing > CRCs, when there > > is equivalent protection from IPSEC or something > else, I think > > it is also clear that this was the intent. > > Since I'm on the subject of making assumptions > explicit... > > When IPsec is mentioned in this context, doesn't it > specifically mean > IPsec with Authentication (or Authentication & > Encryption)? IPsec with > Encryption alone isn't a substitute for CRC32c. > > This is also assuming that the IPsec SPD is setup to > ensure that this > policy will happen, e.g. there is no way for the > remote peer to > negotiate the security policy "down". > > Regards, > MikeC > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 14:26:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22997 for ; Tue, 30 Nov 2004 14:26:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDj6-0004ka-Ga for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 14:31:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDTv-0006im-Mz; Tue, 30 Nov 2004 14:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDKO-0003cj-W0 for rddp@megatron.ietf.org; Tue, 30 Nov 2004 14:06:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21185 for ; Tue, 30 Nov 2004 14:06:19 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDPP-0004A4-Fd for rddp@ietf.org; Tue, 30 Nov 2004 14:11:41 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A4A077E30098; Tue, 30 Nov 2004 14:06:08 -0500 From: "Barry Reinhold" To: "RDDP" Date: Tue, 30 Nov 2004 14:06:01 -0500 Message-ID: <001c01c4d70f$a5733a50$217fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: iwarp-tech@iol.unh.edu Subject: [rddp] Unclear what is required X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Clause 7 of MPA states: " The following errors MUST be detected by MPA and the codes SHOULD be provided to DDP or other consumer: Code Error 1 TCP connection closed, terminated or lost. This includes lost by timeout, too many retries, RST received or FIN received. 2 Received MPA CRC does not match the calculated value for the FPDU. 3 In the event that the CRC is valid, received MPA marker (if enabled) and 'ULPDU Length' fields do not agree on the start of a FPDU. If the FPDU start determined from previous ULPDU Length fields does not match with the MPA marker position, MPA SHOULD deliver an error to DDP. It may not be possible to make this check as a segment arrives, but the check SHOULD be made when a gap creating an out of order sequence is closed and any time a marker points to an already identified FPDU. It is OPTIONAL for a receiver to check each marker, if multiple markers are present in an FPDU, or if the segment is received in order." I am having a hard time understanding what is "MUST", what is "SHOULD" and what is "OPTIONAL" for item 3. Here is how I am taking the above paragraph: 1. A device is not required (MUST) to do anything by item 3. 2. A receiver SHOULD compare a marker to the position shown by the ULPDU length field of the previous FPDU if a TCP segment has arrived that fills in a gap. 3. It is optional for all other cases (based on the "or" clause in the last sentence of item 3). Hence item 3 sums to a suggestion that markers be compared to FPDU start based on ULPDU length when filling in a gap created by out of order TCP segments. Is there another take on this? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Nov 30 14:35:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24545 for ; Tue, 30 Nov 2004 14:35:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDrO-00052D-Vw for rddp-web-archive@ietf.org; Tue, 30 Nov 2004 14:40:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDdY-0000wH-QI; Tue, 30 Nov 2004 14:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDTH-0006OZ-JS for rddp@megatron.ietf.org; Tue, 30 Nov 2004 14:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21835 for ; Tue, 30 Nov 2004 14:15:30 -0500 (EST) From: pat_thaler@agilent.com Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDYR-0004QM-LQ for rddp@ietf.org; Tue, 30 Nov 2004 14:20:52 -0500 Received: from pf-enccos5.cos.agilent.com (enccos5.cos.agilent.com [130.29.152.94]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 505F427BC4 for ; Tue, 30 Nov 2004 12:15:29 -0700 (MST) Received: from enccos5.cos.agilent.com (localhost.localdomain [127.0.0.1]) by localhost.enccos5.cos.agilent.com (Postfix) with SMTP id 127C1C09F for ; Tue, 30 Nov 2004 12:15:29 -0700 (MST) Received: from relcos2.cos.agilent.com (130.29.152.237) by enccos5.cos.agilent.com (Sigaba Gateway v3.83) with ESMTP id 6855104; Tue, 30 Nov 2004 12:15:29 -0700 Received: from wcosvs03.cos.agilent.com (wcosvs03.cos.agilent.com [130.29.152.233]) by relcos2.cos.agilent.com (Postfix) with ESMTP id D16BF21 for ; Tue, 30 Nov 2004 12:15:28 -0700 (MST) Received: from wcosbh22.cos.agilent.com ([130.29.152.178]) by wcosvs03.cos.agilent.com with InterScan Messaging Security Suite; Tue, 30 Nov 2004 12:15:28 -0700 Received: from wcosmb05.cos.agilent.com ([130.29.152.72]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Nov 2004 12:15:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Need some clarification on how to "locate the startoftheFPDU unambiguously" Date: Tue, 30 Nov 2004 12:15:27 -0700 Message-ID: <9418406DEC3B8A4BBDB1B87291D851AF0D23B9@wcosmb05.cos.agilent.com> Thread-Topic: [rddp] Need some clarification on how to "locate the startoftheFPDU unambiguously" Thread-Index: AcTW2+dKV8Ofgwc4RFu+w8SpSLvEUAACZkoAAAFE+mAACYtogA== To: , , , , X-OriginalArrivalTime: 30 Nov 2004 19:15:27.0554 (UTC) FILETIME=[F35BBA20:01C4D710] X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable I agree as well. It would be best to add an explicit statement to that = effect so we don't have to add "(if CRC checking is enabled)" after = every statement about verifying CRC. Pat -----Original Message----- From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]On Behalf Of Culley, Paul Sent: Tuesday, 30 November, 2004 6:43 AM To: Caitlin Bestler; Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP Subject: RE: [rddp] Need some clarification on how to "locate the startoftheFPDU unambiguously" I agree with Caitlin; when CRCs are not used, then the field is always "valid", so you can proceed with FPDU decoding once you have unambiguously found the start and have the whole FPDU. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Caitlin Bestler > Sent: Tuesday, November 30, 2004 8:07 AM > To: Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP > Subject: RE: [rddp] Need some clarification on how to "locate=20 > the start oftheFPDU unambiguously" >=20 > Keep in mind that "CRC suppression" does not eliminate the=20 > field, only generating it and checking it.=20 >=20 > So my reading has always been that when CRCs are "suppressed"=20 > that the CRC field is always "valid". >=20 > Given the scenarios identified for suppressing CRCs, when=20 > there is equivalent protection from IPSEC or something else,=20 > I think it is also clear that this was the intent. >=20 > > -----Original Message----- > > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org]=20 > On Behalf=20 > > Of Barry Reinhold > > Sent: Tuesday, November 30, 2004 4:49 AM > > To: iwarp-tech@iol.unh.edu; RDDP > > Subject: [rddp] Need some clarification on how to "locate=20 > the start of=20 > > theFPDU unambiguously" > >=20 > > If markers are being used is it mandatory to also be using CRCs? > > This question arises out of the requirements of clause 5.4: > >=20 > > Clause 5.4 of MPA states the following: > >=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > An MPA receiver MUST first verify the FPDU before passing the ULPDU > > to DDP. To do this, the receiver MUST: > >=20 > >=20 > > * locate the start of the FPDU unambiguously, > >=20 > >=20 > > * verify its CRC (if CRC checking is enabled). > >=20 > >=20 > > If the above conditions are true, the MPA receiver=20 > passes the ULPDU > > to DDP. > >=20 > >=20 > > To detect the start of the FPDU unambiguously one of the=20 > following > > MUST be used: > >=20 > >=20 > > 1: In an ordered TCP stream, the ULPDU Length field in=20 > the current > > FPDU when FPDU has a valid CRC, can be used to identify the > > beginning of the next FPDU. > >=20 > >=20 > > 2: For receivers that support out of order reception of=20 > FPDUs (see > > section 5.1 MPA Markers on page 16) a Marker can=20 > always be used > > to locate the beginning of an FPDU (in FPDUs with=20 > valid CRCs). > > Since the location of the marker is known in the octet stream > > (sequence number space), the marker can always be found. > >=20 > >=20 > > 3: Having found an FPDU by means of a Marker, following=20 > contiguous > > FPDUs can be found by using the ULPDU Lengths (from=20 > FPDUs with > > valid CRCs) to establish the next FPDU boundary. > > =3D=3D=3D=3D=3D=3D=3D > >=20 > > If we have an out of order FPDU, and support markers, we=20 > use the next=20 > > available marker to recover stream sync. By item two above, this=20 > > requires that we validate the FPDU which has the marker in=20 > it with a=20 > > CRC. > >=20 > > Hence it appears that an implementation planning on using=20 > markers must=20 > > also require that CRCs be supported. Is this the intent? > >=20 > > =20 > >=20 > > Barry Reinhold > > Lamprey Networks > > bbr@lampreynetworks.com > > (603) 868-8411 > > =20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp