From Black_David@emc.com Wed Mar 11 16:27:47 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF50C3A6957; Wed, 11 Mar 2009 16:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8sXj7WzMrQI; Wed, 11 Mar 2009 16:27:46 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 851173A67DB; Wed, 11 Mar 2009 16:27:46 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2BNSLku025577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 19:28:21 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Wed, 11 Mar 2009 19:28:13 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2BNS4ME010538; Wed, 11 Mar 2009 19:28:13 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 19:28:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 19:28:10 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Storage Maintenance (storm) BOF reminder & requests Thread-Index: AcmioQqSkUT1te6rS+uCXVPIvobxAQ== X-Priority: 1 Priority: Urgent Importance: high To: , X-OriginalArrivalTime: 11 Mar 2009 23:28:11.0514 (UTC) FILETIME=[0B05E5A0:01C9A2A1] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com Subject: [imss] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:27:47 -0000 This is a reminder that the Storage Maintenance BOF will be held in about 2 weeks at the IETF meetings in San Francisco. Please plan to attend if you're interested: THURSDAY, March 26, 2009 Continental 1&2 TSV storm Storage Maintenance BOF The BOF description is at: http://www.ietf.org/mail-archive/web/ips/current/msg02669.html The initial agenda is here: http://www.ietf.org/mail-archive/web/ips/current/msg02670.html I'm going to go upload that initial agenda as the BOF agenda, and it can be bashed at the meeting. The primary purpose of this BOF is to answer two questions: (1) What storage maintenance work (IP Storage, Remote Direct Data Placement) should be done? (2) Should an IETF Working Group be formed to undertake that work? Everyone gets to weigh in on these decisions, even those who can't attend the BOF meeting. Anyone who thinks that there is work that should be done, and who cannot come to the BOF meeting should say so on the IPS or RDDP mailing lists (and it'd be a good idea for those who can come to do this). As part of the email, please indicate how you're interested in helping (author or co-author of specific drafts, promise to review and comment on specific drafts). Here's a summary of the initial draft list of work items: - iSCSI: Combine RFCs into one document, removing unused features. - iSCSI: Interoperability report on what has been implemented and interoperates in support of Draft Standard status for iSCSI. - iSCSI: Add backwards-compatible features to support SAM-4. - iFCP: The Address Translation mode of iFCP needs to be deprecated. - RDDP MPA: Small startup update for MPI application support. - iSER: A few minor updates based on InfiniBand experience. Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, updated ipsec security profile [i.e., IKEv2-based]) is possible if there's interest. There are (at least) four possible outcomes: (A) None of this work needs to be done. (B) There are some small work items that make sense. Individual drafts with a draft shepherd (i.e., David Black) will suffice. (C) A working group is needed to undertake more complex work items and reach consensus on design issues. The WG can be "virtual" and operate mostly via the mailing list until/unless controversial/contentious issues arise. (D) There is a lot of complex work that is needed, and a WG that will plan to meet at every IETF meeting should be formed. Please note that the IETF "rough consensus" process requires a working group in practice to be effective. This makes outcome (C) look attractive to me, as: - I'm coming under increasing pressure to limit travel, and the next two IETF meetings after San Francisco are not in the US. - I'd rather have the "rough consensus" process available and not need it than need it and not have it available. Setting an example for how to express interest ... --------------- I think that the iSCSI single RFC and interoperability report are good ideas, but I want to see a bunch of people expressing interest in these, as significant effort is involved. It might make sense to do the single iSCSI RFC but put off the interoperability report (the resulting RFC would remain at Proposed Standard rather than going to Draft Standard), as I'm not hearing about major iSCSI interoperability issues. I think the latter four items (SAM-4 for iSCSI, deprecate iFCP address translation, MPI fix to MPA and iSER fixes) should all be done. I plan to author the iFCP address translation deprecation draft, and review all other drafts. I think that a virtual WG should be formed that plans to do its work primarily via the mailing list. I believe the SAM-4 work by itself is complex enough to need a working group - I would expect design issues to turn up at least there and in determining whether to remove certain iSCSI features, but I'm cautiously optimistic that the mailing list is sufficient to work these issues out (and concerned that travel restrictions are likely to force use of the mailing list). ----------------- Ok, who wants to go next? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 ---------------------------------------------------- From Black_David@emc.com Wed Mar 11 16:34:17 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C3F3A67DB; Wed, 11 Mar 2009 16:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8gVjKR-eWqv; Wed, 11 Mar 2009 16:34:16 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id A9AA63A67D4; Wed, 11 Mar 2009 16:34:16 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2BNYqTH001631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Mar 2009 19:34:52 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Wed, 11 Mar 2009 19:34:49 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2BNYmRu016234; Wed, 11 Mar 2009 19:34:48 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Mar 2009 19:34:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2009 19:34:47 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A01F736BF@CORPUSMX80A.corp.emc.com> In-reply-to: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STORM BOF time Thread-Index: AcmioQqSkUT1te6rS+uCXVPIvobxAQAALMaQ X-Priority: 1 Priority: Urgent Importance: high References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> To: , X-OriginalArrivalTime: 11 Mar 2009 23:34:47.0891 (UTC) FILETIME=[F7483A30:01C9A2A1] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com Subject: [imss] STORM BOF time X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 23:34:18 -0000 I put everything in there except the meeting time. Try this: THURSDAY, March 26, 2009 *** 0900-1130 Morning Session I *** Continental 1&2 TSV storm Storage Maintenance BOF Sorry, --David =20 > -----Original Message----- > From: Black, David=20 > Sent: Wednesday, March 11, 2009 7:28 PM > To: ips@ietf.org; rddp@ietf.org > Cc: imss@ietf.org; Black, David > Subject: Storage Maintenance (storm) BOF reminder & requests > Importance: High >=20 > This is a reminder that the Storage Maintenance BOF will > be held in about 2 weeks at the IETF meetings in San Francisco. > Please plan to attend if you're interested: >=20 > THURSDAY, March 26, 2009 > Continental 1&2 TSV storm Storage Maintenance BOF >=20 > The BOF description is at: > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html >=20 > The initial agenda is here: > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html >=20 > I'm going to go upload that initial agenda as the BOF agenda, > and it can be bashed at the meeting. >=20 > The primary purpose of this BOF is to answer two questions: > (1) What storage maintenance work (IP Storage, Remote Direct > Data Placement) should be done? > (2) Should an IETF Working Group be formed to undertake that > work? >=20 > Everyone gets to weigh in on these decisions, even those who > can't attend the BOF meeting. Anyone who thinks that there is > work that should be done, and who cannot come to the BOF meeting > should say so on the IPS or RDDP mailing lists (and it'd be a > good idea for those who can come to do this). As part of the > email, please indicate how you're interested in helping (author > or co-author of specific drafts, promise to review and comment > on specific drafts). >=20 > Here's a summary of the initial draft list of work items: > - iSCSI: Combine RFCs into one document, removing unused features. > - iSCSI: Interoperability report on what has been implemented and > interoperates in support of Draft Standard status for iSCSI. > - iSCSI: Add backwards-compatible features to support SAM-4. > - iFCP: The Address Translation mode of iFCP needs to be deprecated. > - RDDP MPA: Small startup update for MPI application support. > - iSER: A few minor updates based on InfiniBand experience. >=20 > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, > updated ipsec security profile [i.e., IKEv2-based]) is possible if > there's interest. >=20 > There are (at least) four possible outcomes: > (A) None of this work needs to be done. > (B) There are some small work items that make sense. Individual > drafts with a draft shepherd (i.e., David Black) will > suffice. > (C) A working group is needed to undertake more complex work > items and reach consensus on design issues. The WG can > be "virtual" and operate mostly via the mailing list > until/unless controversial/contentious issues arise. > (D) There is a lot of complex work that is needed, and a WG > that will plan to meet at every IETF meeting should be > formed. >=20 > Please note that the IETF "rough consensus" process requires a > working group in practice to be effective. This makes outcome > (C) look attractive to me, as: > - I'm coming under increasing pressure to limit travel, and > the next two IETF meetings after San Francisco are not > in the US. > - I'd rather have the "rough consensus" process available and > not need it than need it and not have it available. >=20 > Setting an example for how to express interest ... >=20 > --------------- > I think that the iSCSI single RFC and interoperability report are > good ideas, but I want to see a bunch of people expressing interest > in these, as significant effort is involved. It might make sense > to do the single iSCSI RFC but put off the interoperability report > (the resulting RFC would remain at Proposed Standard rather than > going to Draft Standard), as I'm not hearing about major iSCSI > interoperability issues. >=20 > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP > address translation, MPI fix to MPA and iSER fixes) should all > be done. >=20 > I plan to author the iFCP address translation deprecation draft, > and review all other drafts. >=20 > I think that a virtual WG should be formed that plans to do its > work primarily via the mailing list. I believe the SAM-4 work > by itself is complex enough to need a working group - I would > expect design issues to turn up at least there and in determining > whether to remove certain iSCSI features, but I'm cautiously > optimistic that the mailing list is sufficient to work these > issues out (and concerned that travel restrictions are likely to > force use of the mailing list). >=20 > ----------------- >=20 > Ok, who wants to go next? >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > 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 > ---------------------------------------------------- >=20 From steph@cs.uchicago.edu Wed Mar 11 18:05:43 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B331428C151 for ; Wed, 11 Mar 2009 18:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNJU22Do0AtV for ; Wed, 11 Mar 2009 18:05:42 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 925CE28C130 for ; Wed, 11 Mar 2009 18:05:42 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id Rq7Q1b00R0cQ2SLA516LHW; Thu, 12 Mar 2009 01:06:20 +0000 Received: from [10.81.152.54] ([32.152.140.93]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id S15Z1b00D216ArC8W15mkY; Thu, 12 Mar 2009 01:06:18 +0000 Mime-Version: 1.0 X-Mailer: SnapperMail 2.3.6.01 by Snapperfish To: , , Message-ID: <7225-SnapperMsgD1C71620C5DE1084@[10.81.152.54]> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> From: Stephen Bailey Date: Wed, 11 Mar 2009 18:05:00 -0700 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailman-Approved-At: Thu, 12 Mar 2009 08:05:45 -0700 Cc: imss@ietf.org, Black_David@emc.com Subject: Re: [imss] [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:05:43 -0000 Any chance we could dramatically exceed our brief on this project and totally rewrite everything? :-) ...... Original Message ....... On Wed, 11 Mar 2009 19:28:10 -0400 wrote: >This is a reminder that the Storage Maintenance BOF will >be held in about 2 weeks at the IETF meetings in San Francisco. >Please plan to attend if you're interested: > >THURSDAY, March 26, 2009 >Continental 1&2 TSV storm Storage Maintenance BOF > >The BOF description is at: >http://www.ietf.org/mail-archive/web/ips/current/msg02669.html > >The initial agenda is here: >http://www.ietf.org/mail-archive/web/ips/current/msg02670.html > >I'm going to go upload that initial agenda as the BOF agenda, >and it can be bashed at the meeting. > >The primary purpose of this BOF is to answer two questions: >(1) What storage maintenance work (IP Storage, Remote Direct > Data Placement) should be done? >(2) Should an IETF Working Group be formed to undertake that > work? > >Everyone gets to weigh in on these decisions, even those who >can't attend the BOF meeting. Anyone who thinks that there is >work that should be done, and who cannot come to the BOF meeting >should say so on the IPS or RDDP mailing lists (and it'd be a >good idea for those who can come to do this). As part of the >email, please indicate how you're interested in helping (author >or co-author of specific drafts, promise to review and comment >on specific drafts). > >Here's a summary of the initial draft list of work items: >- iSCSI: Combine RFCs into one document, removing unused features. >- iSCSI: Interoperability report on what has been implemented and > interoperates in support of Draft Standard status for iSCSI. >- iSCSI: Add backwards-compatible features to support SAM-4. >- iFCP: The Address Translation mode of iFCP needs to be deprecated. >- RDDP MPA: Small startup update for MPI application support. >- iSER: A few minor updates based on InfiniBand experience. > >Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, >updated ipsec security profile [i.e., IKEv2-based]) is possible if >there's interest. > >There are (at least) four possible outcomes: >(A) None of this work needs to be done. >(B) There are some small work items that make sense. Individual > drafts with a draft shepherd (i.e., David Black) will > suffice. >(C) A working group is needed to undertake more complex work > items and reach consensus on design issues. The WG can > be "virtual" and operate mostly via the mailing list > until/unless controversial/contentious issues arise. >(D) There is a lot of complex work that is needed, and a WG > that will plan to meet at every IETF meeting should be > formed. > >Please note that the IETF "rough consensus" process requires a >working group in practice to be effective. This makes outcome >(C) look attractive to me, as: >- I'm coming under increasing pressure to limit travel, and > the next two IETF meetings after San Francisco are not > in the US. >- I'd rather have the "rough consensus" process available and > not need it than need it and not have it available. > >Setting an example for how to express interest ... > >--------------- >I think that the iSCSI single RFC and interoperability report are >good ideas, but I want to see a bunch of people expressing interest >in these, as significant effort is involved. It might make sense >to do the single iSCSI RFC but put off the interoperability report >(the resulting RFC would remain at Proposed Standard rather than >going to Draft Standard), as I'm not hearing about major iSCSI >interoperability issues. > >I think the latter four items (SAM-4 for iSCSI, deprecate iFCP >address translation, MPI fix to MPA and iSER fixes) should all >be done. > >I plan to author the iFCP address translation deprecation draft, >and review all other drafts. > >I think that a virtual WG should be formed that plans to do its >work primarily via the mailing list. I believe the SAM-4 work >by itself is complex enough to need a working group - I would >expect design issues to turn up at least there and in determining >whether to remove certain iSCSI features, but I'm cautiously >optimistic that the mailing list is sufficient to work these >issues out (and concerned that travel restrictions are likely t From lars.eggert@nokia.com Thu Mar 12 02:35:48 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBEC3A67CC; Thu, 12 Mar 2009 02:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHaeHAPNVcz8; Thu, 12 Mar 2009 02:35:47 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 2B2203A63D3; Thu, 12 Mar 2009 02:35:46 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n2C9a9eQ011568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Mar 2009 11:36:10 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <341DF3E8-58A4-46B3-9324-1B6DCB549D6E@nokia.com> From: Lars Eggert To: Black_David@emc.com In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> Content-Type: multipart/signed; boundary=Apple-Mail-102-845332165; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 12 Mar 2009 11:36:09 +0200 References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> X-Mailer: Apple Mail (2.930.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Thu, 12 Mar 2009 11:36:10 +0200 (EET) X-Virus-Scanned: ClamAV 0.94.2/9098/Thu Mar 12 09:20:36 2009 on fit.nokia.com X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 12 Mar 2009 08:05:45 -0700 Cc: "imss@ietf.org" , "ips@ietf.org" , "rddp@ietf.org" Subject: Re: [imss] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 09:35:49 -0000 --Apple-Mail-102-845332165 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI, the IESG is in the process of figuring out if a more useful remote participation mechanism can be set up for SF than our usual audio streaming and jabber room. If that can be done, STORM may want to make use of it, given that some of your key folks won't be attending. On 2009-3-12, at 1:28, Black_David@emc.com wrote: > This is a reminder that the Storage Maintenance BOF will > be held in about 2 weeks at the IETF meetings in San Francisco. > Please plan to attend if you're interested: > > THURSDAY, March 26, 2009 > Continental 1&2 TSV storm Storage Maintenance BOF > > The BOF description is at: > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html > > The initial agenda is here: > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html > > I'm going to go upload that initial agenda as the BOF agenda, > and it can be bashed at the meeting. > > The primary purpose of this BOF is to answer two questions: > (1) What storage maintenance work (IP Storage, Remote Direct > Data Placement) should be done? > (2) Should an IETF Working Group be formed to undertake that > work? > > Everyone gets to weigh in on these decisions, even those who > can't attend the BOF meeting. Anyone who thinks that there is > work that should be done, and who cannot come to the BOF meeting > should say so on the IPS or RDDP mailing lists (and it'd be a > good idea for those who can come to do this). As part of the > email, please indicate how you're interested in helping (author > or co-author of specific drafts, promise to review and comment > on specific drafts). > > Here's a summary of the initial draft list of work items: > - iSCSI: Combine RFCs into one document, removing unused features. > - iSCSI: Interoperability report on what has been implemented and > interoperates in support of Draft Standard status for iSCSI. > - iSCSI: Add backwards-compatible features to support SAM-4. > - iFCP: The Address Translation mode of iFCP needs to be deprecated. > - RDDP MPA: Small startup update for MPI application support. > - iSER: A few minor updates based on InfiniBand experience. > > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, > updated ipsec security profile [i.e., IKEv2-based]) is possible if > there's interest. > > There are (at least) four possible outcomes: > (A) None of this work needs to be done. > (B) There are some small work items that make sense. Individual > drafts with a draft shepherd (i.e., David Black) will > suffice. > (C) A working group is needed to undertake more complex work > items and reach consensus on design issues. The WG can > be "virtual" and operate mostly via the mailing list > until/unless controversial/contentious issues arise. > (D) There is a lot of complex work that is needed, and a WG > that will plan to meet at every IETF meeting should be > formed. > > Please note that the IETF "rough consensus" process requires a > working group in practice to be effective. This makes outcome > (C) look attractive to me, as: > - I'm coming under increasing pressure to limit travel, and > the next two IETF meetings after San Francisco are not > in the US. > - I'd rather have the "rough consensus" process available and > not need it than need it and not have it available. > > Setting an example for how to express interest ... > > --------------- > I think that the iSCSI single RFC and interoperability report are > good ideas, but I want to see a bunch of people expressing interest > in these, as significant effort is involved. It might make sense > to do the single iSCSI RFC but put off the interoperability report > (the resulting RFC would remain at Proposed Standard rather than > going to Draft Standard), as I'm not hearing about major iSCSI > interoperability issues. > > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP > address translation, MPI fix to MPA and iSER fixes) should all > be done. > > I plan to author the iFCP address translation deprecation draft, > and review all other drafts. > > I think that a virtual WG should be formed that plans to do its > work primarily via the mailing list. I believe the SAM-4 work > by itself is complex enough to need a working group - I would > expect design issues to turn up at least there and in determining > whether to remove certain iSCSI features, but I'm cautiously > optimistic that the mailing list is sufficient to work these > issues out (and concerned that travel restrictions are likely to > force use of the mailing list). > > ----------------- > > Ok, who wants to go next? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > 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 > ---------------------------------------------------- > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips --Apple-Mail-102-845332165 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTAzMTIwOTM2MTBaMCMGCSqGSIb3DQEJBDEWBBQme2kJWCBiSehU vQqFN73Xmh9vODCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAAKFS0+L9i5ek8PGrRdfkBvt+zr0DrPljqe2V0/kYx8+vwyUZvMOh 5P2gPkeucucU+ii/vc+TMLJj/+8V/RCIbG3Xbiwd4u/ShaSwqbF7DnaTyZcMoaRRNKR8v6XGVf2d mmSA3E3ISJwas8TA8E8mlGlB4hhClI92zn4WeQuRQ1v0buIJagdEPBkyOMo+dp2YsVJ1QEbRdQdz /iQq4V+veO/aDcMv7p7KVda3mD3h+A/rIDn86ei7Rkh4iPyWii7/mw+nCFRRmWWtsIe33dwMyE+7 k4cxYrXJFPrEIriQAd2nSHtXq4lbEih0/xRAu/vBhltKnpox26bKyp757Mj4kwAAAAAAAA== --Apple-Mail-102-845332165-- From Frederick.Knight@netapp.com Thu Mar 12 08:25:08 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA6E3A6B84; Thu, 12 Mar 2009 08:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlawFkGXD4Jx; Thu, 12 Mar 2009 08:25:06 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id E7E253A6BC8; Thu, 12 Mar 2009 08:25:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,351,1233561600"; d="scan'208";a="139647927" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 12 Mar 2009 08:25:41 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n2CFPfYb008529; Thu, 12 Mar 2009 08:25:41 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 08:25:25 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 11:25:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Mar 2009 11:20:11 -0400 Message-ID: In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Storage Maintenance (storm) BOF reminder & requests Thread-Index: AcmioQqSkUT1te6rS+uCXVPIvobxAQAd7onA From: "Knight, Frederick" To: , , X-OriginalArrivalTime: 12 Mar 2009 15:25:22.0939 (UTC) FILETIME=[C2D1E4B0:01C9A326] X-Mailman-Approved-At: Fri, 13 Mar 2009 08:24:53 -0700 Cc: imss@ietf.org Subject: Re: [imss] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 15:25:08 -0000 Hello David, I'll be seeing you there in San Francisco. We have a high interest in these areas. As we've discussed I plan to author the SAM-4/5 feature additions, and contribute heavily to the other items you've listed. I too believe your option "C" is the minimum, and we'll have to see if "D" is needed from time to time. Fred Knight -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Wednesday, March 11, 2009 7:28 PM To: ips@ietf.org; rddp@ietf.org Cc: imss@ietf.org; Black_David@emc.com Subject: [Ips] Storage Maintenance (storm) BOF reminder & requests Importance: High This is a reminder that the Storage Maintenance BOF will be held in about 2 weeks at the IETF meetings in San Francisco. Please plan to attend if you're interested: THURSDAY, March 26, 2009 Continental 1&2 TSV storm Storage Maintenance BOF The BOF description is at: http://www.ietf.org/mail-archive/web/ips/current/msg02669.html The initial agenda is here: http://www.ietf.org/mail-archive/web/ips/current/msg02670.html I'm going to go upload that initial agenda as the BOF agenda, and it can be bashed at the meeting. The primary purpose of this BOF is to answer two questions: (1) What storage maintenance work (IP Storage, Remote Direct Data Placement) should be done? (2) Should an IETF Working Group be formed to undertake that work? Everyone gets to weigh in on these decisions, even those who can't attend the BOF meeting. Anyone who thinks that there is work that should be done, and who cannot come to the BOF meeting should say so on the IPS or RDDP mailing lists (and it'd be a good idea for those who can come to do this). As part of the email, please indicate how you're interested in helping (author or co-author of specific drafts, promise to review and comment on specific drafts). Here's a summary of the initial draft list of work items: - iSCSI: Combine RFCs into one document, removing unused features. - iSCSI: Interoperability report on what has been implemented and interoperates in support of Draft Standard status for iSCSI. - iSCSI: Add backwards-compatible features to support SAM-4. - iFCP: The Address Translation mode of iFCP needs to be deprecated. - RDDP MPA: Small startup update for MPI application support. - iSER: A few minor updates based on InfiniBand experience. Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, updated ipsec security profile [i.e., IKEv2-based]) is possible if there's interest. There are (at least) four possible outcomes: (A) None of this work needs to be done. (B) There are some small work items that make sense. Individual drafts with a draft shepherd (i.e., David Black) will suffice. (C) A working group is needed to undertake more complex work items and reach consensus on design issues. The WG can be "virtual" and operate mostly via the mailing list until/unless controversial/contentious issues arise. (D) There is a lot of complex work that is needed, and a WG that will plan to meet at every IETF meeting should be formed. Please note that the IETF "rough consensus" process requires a working group in practice to be effective. This makes outcome (C) look attractive to me, as: - I'm coming under increasing pressure to limit travel, and the next two IETF meetings after San Francisco are not in the US. - I'd rather have the "rough consensus" process available and not need it than need it and not have it available. Setting an example for how to express interest ... --------------- I think that the iSCSI single RFC and interoperability report are good ideas, but I want to see a bunch of people expressing interest in these, as significant effort is involved. It might make sense to do the single iSCSI RFC but put off the interoperability report (the resulting RFC would remain at Proposed Standard rather than going to Draft Standard), as I'm not hearing about major iSCSI interoperability issues. I think the latter four items (SAM-4 for iSCSI, deprecate iFCP address translation, MPI fix to MPA and iSER fixes) should all be done. I plan to author the iFCP address translation deprecation draft, and review all other drafts. I think that a virtual WG should be formed that plans to do its work primarily via the mailing list. I believe the SAM-4 work by itself is complex enough to need a working group - I would expect design issues to turn up at least there and in determining whether to remove certain iSCSI features, but I'm cautiously optimistic that the mailing list is sufficient to work these issues out (and concerned that travel restrictions are likely to force use of the mailing list). ----------------- Ok, who wants to go next? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From cb_mallikarjun@yahoo.com Sat Mar 14 17:47:10 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141D3A6A07 for ; Sat, 14 Mar 2009 17:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V38lgVmGT1jH for ; Sat, 14 Mar 2009 17:47:09 -0700 (PDT) Received: from web110801.mail.gq1.yahoo.com (web110801.mail.gq1.yahoo.com [67.195.13.224]) by core3.amsl.com (Postfix) with SMTP id 1A92A3A6AAE for ; Sat, 14 Mar 2009 17:47:09 -0700 (PDT) Received: (qmail 61670 invoked by uid 60001); 15 Mar 2009 00:47:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237078069; bh=GAIMXLVqp3UlWf3e+C6CUEmc6SYP7E9Hs09QcdV3sQs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wykAaqcJE389lfwp21sZ/5eup7FHj1ZsJZAnIkk6tkzsM+/+SF8ZpIuyTVhvym0CTH3GXx+tnz+sDZMj8JtPdKV3NtLjmmJEO+TtItjbBEXASxoaJyM8pIssbG8XMV80jgnJxwmJU6ZGOVdEdnTrWUFYsmaPRCvyyNBmbk/k2JA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0uA7KGabCCCpbzEP61+2W68L6/gCsh/7uUkCQXk8uRq+4gVLDxeZQ/1qpzNSQAmxuPX4+mMCyIgorhswMD07QFrq9XrCdRwGDjhhX2ad0h9E2az3iYBp9KNdDLheCdr3zQ1iHiMiesI/h3Th7t6moaOMaDMcLwG3UoTt6GaFxe8=; Message-ID: <348174.61265.qm@web110801.mail.gq1.yahoo.com> X-YMail-OSG: hFTClzYVM1l3SjOvMBFhQmv7F5ZTDs1P1KaCQjD2iKwd5CMUocctLW4JQrqBuA0vrQBRLQt4aSlQnslqL6.ovVMa2kGFMmDGY4rEnuPYEKjIItW.NNrRerwthYH3ZAE3eya5if3QAc9zqCj15xSlpGqty5rWy5Ia7Z9Qk_fOH.kfG8dV_db7.Fa3MEOAfeuMyE3Mv0fV4wSH7tj2U1vIbB.8gR2kJ2QFWGQpHXBC_7b4kSwgphqkY6uUisi7icVkriTKfsk5cOGEMO2fJ3FVLZePdmg- Received: from [64.30.124.230] by web110801.mail.gq1.yahoo.com via HTTP; Sat, 14 Mar 2009 17:47:49 PDT X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> Date: Sat, 14 Mar 2009 17:47:49 -0700 (PDT) From: "Mallikarjun C." To: Black_David@emc.com, ips@ietf.org, rddp@ietf.org In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Mar 2009 17:58:06 -0700 Cc: imss@ietf.org, Black_David@emc.com Subject: Re: [imss] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 00:47:10 -0000 Hi David,=0A=0AMy recommendation would be to defer the interoperability sur= vey and draft consolidation work for iSCSI.=A0 I do believe however that at= least iSCSI SAM-4 compliance work in a backwards compatible fashion is req= uired.=A0 I currently plan to contribute to/author this work, although I un= fortunately will not be able to attend the San Francisco meeting in person.= =0A=0AI tend to prefer your option C for the same reasons you cited.=A0=A0O= ption B=A0*might be* workable as the next preferred option.=A0 One other=A0= suggestion I have=A0is that even with a virtual WG (option C), I believe we= will need to move at a relatively slower pace compared to the IPS WG becau= se given the economy, everyone has enough workload on their plates in their= companies and has fewer cycles to stay on top of the WG mailing list.=A0 I= MHO, this will need to be factored into milestones and such in the=A0planni= ng process.=A0 =0A=0AThanks.=A0--=0AMallikarjun Chadalapaka =0A=0A=0A=0A---= -- Original Message ----=0A> From: "Black_David@emc.com" =0A> To: ips@ietf.org; rddp@ietf.org=0A> Cc: imss@ietf.org; Black_David@= emc.com=0A> Sent: Wednesday, March 11, 2009 4:28:10 PM=0A> Subject: [Ips] S= torage Maintenance (storm) BOF reminder & requests=0A> =0A> This is a remin= der that the Storage Maintenance BOF will=0A> be held in about 2 weeks at t= he IETF meetings in San Francisco.=0A> Please plan to attend if you're inte= rested:=0A> =0A> THURSDAY, March 26, 2009=0A> Continental 1&2=A0 =A0=A0=A0 = TSV=A0 =A0=A0=A0 storm=A0 =A0=A0=A0 Storage Maintenance BOF=0A> =0A> The BO= F description is at:=0A> http://www.ietf.org/mail-archive/web/ips/current/m= sg02669.html=0A> =0A> The initial agenda is here:=0A> http://www.ietf.org/m= ail-archive/web/ips/current/msg02670.html=0A> =0A> I'm going to go upload t= hat initial agenda as the BOF agenda,=0A> and it can be bashed at the meeti= ng.=0A> =0A> The primary purpose of this BOF is to answer two questions:=0A= > (1) What storage maintenance work (IP Storage, Remote Direct=0A> =A0=A0= =A0 Data Placement) should be done?=0A> (2) Should an IETF Working Group be= formed to undertake that=0A> =A0=A0=A0 work?=0A> =0A> Everyone gets to wei= gh in on these decisions, even those who=0A> can't attend the BOF meeting.= =A0 Anyone who thinks that there is=0A> work that should be done, and who c= annot come to the BOF meeting=0A> should say so on the IPS or RDDP mailing = lists (and it'd be a=0A> good idea for those who can come to do this).=A0 A= s part of the=0A> email, please indicate how you're interested in helping (= author=0A> or co-author of specific drafts, promise to review and comment= =0A> on specific drafts).=0A> =0A> Here's a summary of the initial draft li= st of work items:=0A> - iSCSI: Combine RFCs into one document, removing unu= sed features.=0A> - iSCSI: Interoperability report on what has been impleme= nted and=0A> =A0=A0=A0 interoperates in support of Draft Standard status fo= r iSCSI.=0A> - iSCSI: Add backwards-compatible features to support SAM-4.= =0A> - iFCP: The Address Translation mode of iFCP needs to be deprecated.= =0A> - RDDP MPA: Small startup update for MPI application support.=0A> - iS= ER: A few minor updates based on InfiniBand experience.=0A> =0A> Additional= work (e.g., updated/improved iSNS for iSCSI, MIB changes,=0A> updated ipse= c security profile [i.e., IKEv2-based]) is possible if=0A> there's interest= .=0A> =0A> There are (at least) four possible outcomes:=0A> (A) None of thi= s work needs to be done.=0A> (B) There are some small work items that make = sense.=A0 Individual=0A> =A0=A0=A0 drafts with a draft shepherd (i.e., Davi= d Black) will=0A> =A0=A0=A0 suffice.=0A> (C) A working group is needed to u= ndertake more complex work=0A> =A0=A0=A0 items and reach consensus on desig= n issues.=A0 The WG can=0A> =A0=A0=A0 be "virtual" and operate mostly via t= he mailing list=0A> =A0=A0=A0 until/unless controversial/contentious issues= arise.=0A> (D) There is a lot of complex work that is needed, and a WG=0A>= =A0=A0=A0 that will plan to meet at every IETF meeting should be=0A> =A0= =A0=A0 formed.=0A> =0A> Please note that the IETF "rough consensus" process= requires a=0A> working group in practice to be effective.=A0 This makes ou= tcome=0A> (C) look attractive to me, as:=0A> - I'm coming under increasing = pressure to limit travel, and=0A> =A0=A0=A0 the next two IETF meetings afte= r San Francisco are not=0A> =A0=A0=A0 in the US.=0A> - I'd rather have the = "rough consensus" process available and=0A> =A0=A0=A0 not need it than need= it and not have it available.=0A> =0A> Setting an example for how to expre= ss interest ...=0A> =0A> ---------------=0A> I think that the iSCSI single = RFC and interoperability report are=0A> good ideas, but I want to see a bun= ch of people expressing interest=0A> in these, as significant effort is inv= olved.=A0 It might make sense=0A> to do the single iSCSI RFC but put off th= e interoperability report=0A> (the resulting RFC would remain at Proposed S= tandard rather than=0A> going to Draft Standard), as I'm not hearing about = major iSCSI=0A> interoperability issues.=0A> =0A> I think the latter four i= tems (SAM-4 for iSCSI, deprecate iFCP=0A> address translation, MPI fix to M= PA and iSER fixes) should all=0A> be done.=0A> =0A> I plan to author the iF= CP address translation deprecation draft,=0A> and review all other drafts.= =0A> =0A> I think that a virtual WG should be formed that plans to do its= =0A> work primarily via the mailing list.=A0 I believe the SAM-4 work=0A> b= y itself is complex enough to need a working group - I would=0A> expect des= ign issues to turn up at least there and in determining=0A> whether to remo= ve certain iSCSI features, but I'm cautiously=0A> optimistic that the maili= ng list is sufficient to work these=0A> issues out (and concerned that trav= el restrictions are likely to=0A> force use of the mailing list).=0A> =0A> = -----------------=0A> =0A> Ok, who wants to go next?=0A> =0A> Thanks,=0A> -= -David=0A> ----------------------------------------------------=0A> David L= . Black, Distinguished Engineer=0A> EMC Corporation, 176 South St., Hopkint= on, MA=A0 01748=0A> =A0+1...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508)= 293-7786=0A> black_david@emc.com=A0 =A0 =A0 =A0 Mobile: =A0+1=A0(978)=A039= 4-7754=A0=0A> ----------------------------------------------------=0A> ____= ___________________________________________=0A> Ips mailing list=0A> Ips@ie= tf.org=0A> https://www.ietf.org/mailman/listinfo/ips=0A=0A=0A=0A From rdr@iol.unh.edu Sun Mar 22 08:41:13 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3C228C236; Sun, 22 Mar 2009 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6NJgVmJcrbb; Sun, 22 Mar 2009 08:41:12 -0700 (PDT) Received: from postal.iol.unh.edu (postal.iol.unh.edu [132.177.123.84]) by core3.amsl.com (Postfix) with ESMTP id EE6B328C246; Sun, 22 Mar 2009 08:41:11 -0700 (PDT) Received: from postal.iol.unh.edu (localhost [127.0.0.1]) by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id n2MFftaP017556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 22 Mar 2009 11:41:55 -0400 Received: from localhost (rdr@localhost) by postal.iol.unh.edu (8.14.0/8.14.0/Submit) with ESMTP id n2MFftrA017550; Sun, 22 Mar 2009 11:41:55 -0400 X-Authentication-Warning: postal.iol.unh.edu: rdr owned process doing -bs Date: Sun, 22 Mar 2009 11:41:55 -0400 (EDT) From: "Robert D. Russell" To: Black_David@emc.com In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> Message-ID: References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 23 Mar 2009 09:28:31 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [imss] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 15:58:48 -0000 David: There are 2 issues I would like to suggest for discussion at the BOF meeting later this week. Both have to do with the iSER spec, RFC 5046. 1. At the present time, as far as I know, no existing hardware, neither Infiniband nor iWARP, is capable of opening a connection in "normal" TCP mode and then transitioning it into zero-copy mode. Unfortunately, the iSER spec requires that. Can't we just replace that part of the iSER spec? Otherwise, all hardware and all implementations are non-standard. 2. The OFED stack is used to access both Infiniband and iWARP hardware. This software requires 2 extra 64-bit fields for addressing on both Infiniband and iWARP hardware, but these fields are not allowed for in the current iSER Header Format. Can't we just add those extra fields to the iSER spec? If someday some other implementation doesn't need those fields, they can be just set to 0 (which is what is implied by the current iSER standard anyway). Again, by not doing this, all implementations are non-standard. In other words, I'm suggesting that we consider replacing the relevant parts of the current iSER specs with the current OFED specs on these 2 issues. Thanks for your consideration, Bob Russell Note: The following (old) posting by Mike Ko states that the extra header fields are needed only by IB, not by IETF (i.e., iWARP), because IB uses nZBVA, whereas iWARP uses ZBVA. But are there any IETF/iWARP implementations out there that actually use ZBVA with iWARP RNICs? (I don't mean software simulations of the iWARP protocol.) We have built an iSER implementation that uses the OFED stack to access both IB and iWARP hardware, and for both of them we need to use the extra iSER header fields (nZBVA). Perhaps this is an issue with the design of the OFED stack, which was built primarily to access IB hardware and therefore reflects the needs of the IB hardware. But we found that the only way to access iWARP hardware via the OFED stack was to used the expanded (nZBVA) iSER header (and to use a meaningful value in the extra field, NOT to just set it to zero). In any case, rather than have 2 different versions of the iSER header, it would be better to have just one, regardless of the underlying technology involved (after all, isn't that what a standard is for??). This is especially relevant when using the OFED stack, because, as we have demonstrated, software built on top of the OFED stack can (AND SHOULD!) be able to run with EITHER IB or iWARP hardware, with NO change to that software. Having 2 different iSER headers does NOT make that possible! > 2008/4/15 Mike Ko : > > VA is a concept introduced in an Infiniband annex to support iSER. It > appears in the expanded iSER header for Infiniband use only to support the > non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA > used in IETF. Mike - could you please put me in contact with someone who has actually implemented iSER on top of IETF/iWARP hardware NICs using ZBVA? > > "The DataDescriptorOut describes the I/O buffer starting with the immediate > unsolicited data (if any), followed by the non-immediate unsolicited data > (if any) and solicited data." If non-ZBVA mode is used, then VA points to > the beginning of this buffer. So in your example, the VA field in the > expanded iSER header will be zero. Note that for IETF, ZBVA is assumed and > there is no provision to specify a different VA in the iSER header. Mike - I believe this VA field in the expanded iSER header is almost NEVER zero -- it is always an actual virtual address. > > Tagged offset (TO) refers to the offset within a tagged buffer in RDMA Write > and RDMA Read Request Messages. When sending non-immediate unsolicited > data, Send Message types are used and the TO field is not present. Instead, > the buffer offset is appropriately represented by the Buffer Offset field in > the SCSI Data-Out PDU. Note that Tagged Offset is not the same as write VA > and it does not appear in the iSER header. > >Mike On Wed, 11 Mar 2009, Black_David@emc.com wrote: > This is a reminder that the Storage Maintenance BOF will > be held in about 2 weeks at the IETF meetings in San Francisco. > Please plan to attend if you're interested: > > THURSDAY, March 26, 2009 > Continental 1&2 TSV storm Storage Maintenance BOF > > The BOF description is at: > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html > > The initial agenda is here: > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html > > I'm going to go upload that initial agenda as the BOF agenda, > and it can be bashed at the meeting. > > The primary purpose of this BOF is to answer two questions: > (1) What storage maintenance work (IP Storage, Remote Direct > Data Placement) should be done? > (2) Should an IETF Working Group be formed to undertake that > work? > > Everyone gets to weigh in on these decisions, even those who > can't attend the BOF meeting. Anyone who thinks that there is > work that should be done, and who cannot come to the BOF meeting > should say so on the IPS or RDDP mailing lists (and it'd be a > good idea for those who can come to do this). As part of the > email, please indicate how you're interested in helping (author > or co-author of specific drafts, promise to review and comment > on specific drafts). > > Here's a summary of the initial draft list of work items: > - iSCSI: Combine RFCs into one document, removing unused features. > - iSCSI: Interoperability report on what has been implemented and > interoperates in support of Draft Standard status for iSCSI. > - iSCSI: Add backwards-compatible features to support SAM-4. > - iFCP: The Address Translation mode of iFCP needs to be deprecated. > - RDDP MPA: Small startup update for MPI application support. > - iSER: A few minor updates based on InfiniBand experience. > > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, > updated ipsec security profile [i.e., IKEv2-based]) is possible if > there's interest. > > There are (at least) four possible outcomes: > (A) None of this work needs to be done. > (B) There are some small work items that make sense. Individual > drafts with a draft shepherd (i.e., David Black) will > suffice. > (C) A working group is needed to undertake more complex work > items and reach consensus on design issues. The WG can > be "virtual" and operate mostly via the mailing list > until/unless controversial/contentious issues arise. > (D) There is a lot of complex work that is needed, and a WG > that will plan to meet at every IETF meeting should be > formed. > > Please note that the IETF "rough consensus" process requires a > working group in practice to be effective. This makes outcome > (C) look attractive to me, as: > - I'm coming under increasing pressure to limit travel, and > the next two IETF meetings after San Francisco are not > in the US. > - I'd rather have the "rough consensus" process available and > not need it than need it and not have it available. > > Setting an example for how to express interest ... > > --------------- > I think that the iSCSI single RFC and interoperability report are > good ideas, but I want to see a bunch of people expressing interest > in these, as significant effort is involved. It might make sense > to do the single iSCSI RFC but put off the interoperability report > (the resulting RFC would remain at Proposed Standard rather than > going to Draft Standard), as I'm not hearing about major iSCSI > interoperability issues. > > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP > address translation, MPI fix to MPA and iSER fixes) should all > be done. > > I plan to author the iFCP address translation deprecation draft, > and review all other drafts. > > I think that a virtual WG should be formed that plans to do its > work primarily via the mailing list. I believe the SAM-4 work > by itself is complex enough to need a working group - I would > expect design issues to turn up at least there and in determining > whether to remove certain iSCSI features, but I'm cautiously > optimistic that the mailing list is sufficient to work these > issues out (and concerned that travel restrictions are likely to > force use of the mailing list). > > ----------------- > > Ok, who wants to go next? > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > 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 > ---------------------------------------------------- > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www.ietf.org/mailman/listinfo/ips > From Black_David@emc.com Mon Mar 23 19:03:13 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6263A6B19; Mon, 23 Mar 2009 19:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REedeqhiwKtv; Mon, 23 Mar 2009 19:03:12 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5D16F28C1B2; Mon, 23 Mar 2009 19:03:11 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2O23xsk020179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 22:04:00 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 23 Mar 2009 22:03:54 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2O23pNX012989; Mon, 23 Mar 2009 22:03:51 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 22:03:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 22:03:48 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0234A317@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STORM WG - draft charter Thread-Index: AcmsJMV1xvlvkU8dSCyDoEce3SV0LQ== To: , X-OriginalArrivalTime: 24 Mar 2009 02:03:51.0309 (UTC) FILETIME=[C6EE83D0:01C9AC24] X-EMM-EM: Active Cc: imss@ietf.org Subject: [imss] STORM WG - draft charter X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:03:13 -0000 I promised a draft charter before the BOF, so here it is. This should look very familiar as it's based on the BOF proposal that has been out for a while. The FCIP item below (may be possible to return an IP Protocol Number to IANA) is new. If the recommendation of the BOF is to form a Working Group, the revised charter (with work items and milestones) will be published to these lists for further review and comment before the actual WG request goes to the IESG. Proposed Working Group: STORM (STORage Maintenance) Transport (TSV) Area Proposed Charter (First Draft) - March 23, 2009 ----------------------------------------------------------- The IETF ips (IP Storage) and rddp (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER, FCIP and iFCP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. Initial draft list of work items (subject to change at the BOF): - iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft, removing features that are not implemented in practice (e.g., markers). - iSCSI: Interoperability report on what has been implemented and is known to interoperate in support of Draft Standard RFC status for the new iSCSI RFC. The decision about whether to target Draft Standard RFC status will be discussed in the BOF in San Francisco - this may entail updates to RFC 3722 [stringprep for iSCSI] and RFC 3723 [security]. =20 - iSCSI: Add features to support SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the first bullet. - FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. It may be possible to return this IP Protocol number to IANA for future reallocation. - iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. It is intended to do this with a short document that updates RFC 4172 (i.e., not via a complete rewrite of RFC 4172). - RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. - iSER: Make a few minor updates based on experience with InfiniBand and other implementations to reflect what has been done in practice. Actual Goals and Milestones will be determined at the BOF. ------------------------------------------------------------ Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 ---------------------------------------------------- From felix@chelsio.com Mon Mar 23 09:37:53 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACAA3A690D; Mon, 23 Mar 2009 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAGRoU8p2Gl; Mon, 23 Mar 2009 09:37:51 -0700 (PDT) Received: from stargate.chelsio.com (stargate.chelsio.com [12.22.49.110]) by core3.amsl.com (Postfix) with ESMTP id ADA813A67F2; Mon, 23 Mar 2009 09:37:51 -0700 (PDT) Received: from maui.asicdesigners.com (maui.asicdesigners.com [10.192.180.15]) by stargate.chelsio.com (8.13.1/8.13.1) with SMTP id n2NGcYmE004391; Mon, 23 Mar 2009 08:38:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 09:36:44 -0700 Message-ID: <8A71B368A89016469F72CD08050AD33404C26FF2@maui.asicdesigners.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Junk released by Allow List] Re: [rddp] [Ips] Storage Maintenance (storm) BOF reminder & requests Thread-Index: Acmr1Mx8hpWqu5d9RiGHrTpQdCL9SgAAFt+g References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> From: "Felix Marti" To: "Robert D. Russell" , X-Mailman-Approved-At: Tue, 24 Mar 2009 09:05:13 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [imss] [Junk released by Allow List] Re: [rddp] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:37:53 -0000 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Robert D. Russell > Sent: Sunday, March 22, 2009 8:42 AM > To: Black_David@emc.com > Cc: imss@ietf.org; ips@ietf.org; rddp@ietf.org > Subject: [Junk released by Allow List] Re: [rddp] [Ips] Storage > Maintenance (storm) BOF reminder & requests >=20 > David: >=20 > There are 2 issues I would like to suggest for discussion at the BOF > meeting later this week. Both have to do with the iSER spec, RFC 5046. >=20 > 1. At the present time, as far as I know, no existing hardware, > neither Infiniband nor iWARP, is capable of opening a connection > in "normal" TCP mode and then transitioning it into zero-copy mode. > Unfortunately, the iSER spec requires that. > Can't we just replace that part of the iSER spec? > Otherwise, all hardware and all implementations are non-standard. [felix] Note that iWarp does start life as a 'streaming' connection (normal) and is then upgraded to iWarp (zero-copy). However, you might refer to the fact that linux doesn't support this, as the linux network stack maintainers are unwilling to properly integrate iWarp devices. =20 >=20 > 2. The OFED stack is used to access both Infiniband and iWARP hardware. > This software requires 2 extra 64-bit fields for addressing > on both Infiniband and iWARP hardware, but these fields > are not allowed for in the current iSER Header Format. > Can't we just add those extra fields to the iSER spec? > If someday some other implementation doesn't need those > fields, they can be just set to 0 (which is what is implied by > the current iSER standard anyway). Again, by not doing this, > all implementations are non-standard. >=20 > In other words, I'm suggesting that we consider replacing the relevant > parts of the current iSER specs with the current OFED specs on these > 2 issues. >=20 > Thanks for your consideration, > Bob Russell >=20 > Note: The following (old) posting by Mike Ko states that the > extra header fields are needed only by IB, not by IETF > (i.e., iWARP), because IB uses nZBVA, whereas iWARP uses ZBVA. >=20 > But are there any IETF/iWARP implementations out there that actually > use ZBVA with iWARP RNICs? (I don't mean software simulations of > the iWARP protocol.) We have built an iSER implementation that > uses the OFED stack to access both IB and iWARP hardware, and for > both of them we need to use the extra iSER header fields (nZBVA). > Perhaps this is an issue with the design of the OFED stack, which > was built primarily to access IB hardware and therefore reflects > the needs of the IB hardware. But we found that the only way to > access iWARP hardware via the OFED stack was to used the expanded > (nZBVA) iSER header (and to use a meaningful value in the extra field, > NOT to just set it to zero). >=20 > In any case, rather than have 2 different versions of the iSER header, > it would be better to have just one, regardless of the underlying > technology involved (after all, isn't that what a standard is for??). > This is especially relevant when using the OFED stack, because, > as we have demonstrated, software built on top of the OFED stack can > (AND SHOULD!) be able to run with EITHER IB or iWARP hardware, > with NO change to that software. Having 2 different iSER headers > does NOT make that possible! >=20 >=20 > > 2008/4/15 Mike Ko : > > > > VA is a concept introduced in an Infiniband annex to support iSER. It > > appears in the expanded iSER header for Infiniband use only to > support the > > non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the > ZBVA > > used in IETF. >=20 > Mike - could you please put me in contact with someone who has actually > implemented iSER on top of IETF/iWARP hardware NICs using ZBVA? >=20 > > > > "The DataDescriptorOut describes the I/O buffer starting with the > immediate > > unsolicited data (if any), followed by the non-immediate unsolicited > data > > (if any) and solicited data." If non-ZBVA mode is used, then VA > points to > > the beginning of this buffer. So in your example, the VA field in the > > expanded iSER header will be zero. Note that for IETF, ZBVA is > assumed and > > there is no provision to specify a different VA in the iSER header. >=20 > Mike - I believe this VA field in the expanded iSER header is almost > NEVER zero -- it is always an actual virtual address. >=20 > > > > Tagged offset (TO) refers to the offset within a tagged buffer in > RDMA Write > > and RDMA Read Request Messages. When sending non-immediate > unsolicited > > data, Send Message types are used and the TO field is not present. > Instead, > > the buffer offset is appropriately represented by the Buffer Offset > field in > > the SCSI Data-Out PDU. Note that Tagged Offset is not the same as > write VA > > and it does not appear in the iSER header. > > > >Mike >=20 > On Wed, 11 Mar 2009, Black_David@emc.com wrote: >=20 > > This is a reminder that the Storage Maintenance BOF will > > be held in about 2 weeks at the IETF meetings in San Francisco. > > Please plan to attend if you're interested: > > > > THURSDAY, March 26, 2009 > > Continental 1&2 TSV storm Storage Maintenance BOF > > > > The BOF description is at: > > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html > > > > The initial agenda is here: > > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html > > > > I'm going to go upload that initial agenda as the BOF agenda, > > and it can be bashed at the meeting. > > > > The primary purpose of this BOF is to answer two questions: > > (1) What storage maintenance work (IP Storage, Remote Direct > > Data Placement) should be done? > > (2) Should an IETF Working Group be formed to undertake that > > work? > > > > Everyone gets to weigh in on these decisions, even those who > > can't attend the BOF meeting. Anyone who thinks that there is > > work that should be done, and who cannot come to the BOF meeting > > should say so on the IPS or RDDP mailing lists (and it'd be a > > good idea for those who can come to do this). As part of the > > email, please indicate how you're interested in helping (author > > or co-author of specific drafts, promise to review and comment > > on specific drafts). > > > > Here's a summary of the initial draft list of work items: > > - iSCSI: Combine RFCs into one document, removing unused features. > > - iSCSI: Interoperability report on what has been implemented and > > interoperates in support of Draft Standard status for iSCSI. > > - iSCSI: Add backwards-compatible features to support SAM-4. > > - iFCP: The Address Translation mode of iFCP needs to be deprecated. > > - RDDP MPA: Small startup update for MPI application support. > > - iSER: A few minor updates based on InfiniBand experience. > > > > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, > > updated ipsec security profile [i.e., IKEv2-based]) is possible if > > there's interest. > > > > There are (at least) four possible outcomes: > > (A) None of this work needs to be done. > > (B) There are some small work items that make sense. Individual > > drafts with a draft shepherd (i.e., David Black) will > > suffice. > > (C) A working group is needed to undertake more complex work > > items and reach consensus on design issues. The WG can > > be "virtual" and operate mostly via the mailing list > > until/unless controversial/contentious issues arise. > > (D) There is a lot of complex work that is needed, and a WG > > that will plan to meet at every IETF meeting should be > > formed. > > > > Please note that the IETF "rough consensus" process requires a > > working group in practice to be effective. This makes outcome > > (C) look attractive to me, as: > > - I'm coming under increasing pressure to limit travel, and > > the next two IETF meetings after San Francisco are not > > in the US. > > - I'd rather have the "rough consensus" process available and > > not need it than need it and not have it available. > > > > Setting an example for how to express interest ... > > > > --------------- > > I think that the iSCSI single RFC and interoperability report are > > good ideas, but I want to see a bunch of people expressing interest > > in these, as significant effort is involved. It might make sense > > to do the single iSCSI RFC but put off the interoperability report > > (the resulting RFC would remain at Proposed Standard rather than > > going to Draft Standard), as I'm not hearing about major iSCSI > > interoperability issues. > > > > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP > > address translation, MPI fix to MPA and iSER fixes) should all > > be done. > > > > I plan to author the iFCP address translation deprecation draft, > > and review all other drafts. > > > > I think that a virtual WG should be formed that plans to do its > > work primarily via the mailing list. I believe the SAM-4 work > > by itself is complex enough to need a working group - I would > > expect design issues to turn up at least there and in determining > > whether to remove certain iSCSI features, but I'm cautiously > > optimistic that the mailing list is sufficient to work these > > issues out (and concerned that travel restrictions are likely to > > force use of the mailing list). > > > > ----------------- > > > > Ok, who wants to go next? > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > 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 > > ---------------------------------------------------- > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www.ietf.org/mailman/listinfo/rddp From mhagen@iol.unh.edu Mon Mar 23 09:41:09 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74A528C191; Mon, 23 Mar 2009 09:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihPl0e41knPN; Mon, 23 Mar 2009 09:41:08 -0700 (PDT) Received: from postal.iol.unh.edu (postal.iol.unh.edu [132.177.123.84]) by core3.amsl.com (Postfix) with ESMTP id 433EF3A67F2; Mon, 23 Mar 2009 09:41:08 -0700 (PDT) Received: from [10.3.163.172] (72-254-113-165.client.stsn.net [72.254.113.165]) (authenticated bits=0) by postal.iol.unh.edu (8.14.0/8.14.0) with ESMTP id n2NGfmxl026870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2009 12:41:50 -0400 Message-ID: <49C7BBCC.30607@iol.unh.edu> Date: Mon, 23 Mar 2009 12:41:48 -0400 From: Mikkel Hagen User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Felix Marti References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> <8A71B368A89016469F72CD08050AD33404C26FF2@maui.asicdesigners.com> In-Reply-To: <8A71B368A89016469F72CD08050AD33404C26FF2@maui.asicdesigners.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.94/9152/Mon Mar 23 09:15:24 2009 on postal.iol.unh.edu X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 24 Mar 2009 09:05:13 -0700 Cc: "Robert D. Russell" , imss@ietf.org, ips@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: Re: [imss] [rddp] [Junk released by Allow List] Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:41:09 -0000 My impression is that while it does technically start in streaming mode, if it receives anything other than a MPA request it will abort the connection, thus not being usable at all?
Mikkel Hagen
Research and Development
Data Center Bridging/FC/OFA/SAS/SATA/iSCSI/iWARP Consortiums
Phone:1-603-862-5083  Fax:1-603-862-4181
UNH-IOL
121 Technology Drive, Suite 2
Durham, NH 03824


Felix Marti wrote: 
  
-----Original Message-----
From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf
    
Of
  
Robert D. Russell
Sent: Sunday, March 22, 2009 8:42 AM
To: Black_David@emc.com
Cc: imss@ietf.org; ips@ietf.org; rddp@ietf.org
Subject: [Junk released by Allow List] Re: [rddp] [Ips] Storage
Maintenance (storm) BOF reminder & requests

David:

There are 2 issues I would like to suggest for discussion at the BOF
meeting later this week.  Both have to do with the iSER spec, RFC
    
5046.
  
1. At the present time, as far as I know, no existing hardware,
    neither Infiniband nor iWARP, is capable of opening a connection
    in "normal" TCP mode and then transitioning it into zero-copy
    
mode.
  
    Unfortunately, the iSER spec requires that.
    Can't we just replace that part of the iSER spec?
    Otherwise, all hardware and all implementations are non-standard.
    
[felix] Note that iWarp does start life as a 'streaming' connection
(normal) and is then upgraded to iWarp (zero-copy). However, you might
refer to the fact that linux doesn't support this, as the linux network
stack maintainers are unwilling to properly integrate iWarp devices.
 
  
2. The OFED stack is used to access both Infiniband and iWARP
    
hardware.
  
    This software requires 2 extra 64-bit fields for addressing
    on both Infiniband and iWARP hardware, but these fields
    are not allowed for in the current iSER Header Format.
    Can't we just add those extra fields to the iSER spec?
    If someday some other implementation doesn't need those
    fields, they can be just set to 0 (which is what is implied by
    the current iSER standard anyway).  Again, by not doing this,
    all implementations are non-standard.

In other words, I'm suggesting that we consider replacing the relevant
parts of the current iSER specs with the current OFED specs on these
2 issues.

Thanks for your consideration,
Bob Russell

Note: The following (old) posting by Mike Ko states that the
extra header fields are needed only by IB, not by IETF
(i.e., iWARP), because IB uses nZBVA, whereas iWARP uses ZBVA.

But are there any IETF/iWARP implementations out there that actually
use ZBVA with iWARP RNICs?  (I don't mean software simulations of
the iWARP protocol.)  We have built an iSER implementation that
uses the OFED stack to access both IB and iWARP hardware, and for
both of them we need to use the extra iSER header fields (nZBVA).
Perhaps this is an issue with the design of the OFED stack, which
was built primarily to access IB hardware and therefore reflects
the needs of the IB hardware.  But we found that the only way to
access iWARP hardware via the OFED stack was to used the expanded
(nZBVA) iSER header (and to use a meaningful value in the extra field,
NOT to just set it to zero).

In any case, rather than have 2 different versions of the iSER header,
it would be better to have just one, regardless of the underlying
technology involved (after all, isn't that what a standard is for??).
This is especially relevant when using the OFED stack, because,
as we have demonstrated, software built on top of the OFED stack can
(AND SHOULD!) be able to run with EITHER IB or iWARP hardware,
with NO change to that software.  Having 2 different iSER headers
does NOT make that possible!


    
2008/4/15 Mike Ko <mako at almaden.ibm.com>:

VA is a concept introduced in an Infiniband annex to support iSER.
      
It
  
appears in the expanded iSER header for Infiniband use only to
      
support the
    
non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the
      
ZBVA
    
used in IETF.
      
Mike - could you please put me in contact with someone who has
    
actually
  
implemented iSER on top of IETF/iWARP hardware NICs using ZBVA?

    
"The DataDescriptorOut describes the I/O buffer starting with the
      
immediate
    
unsolicited data (if any), followed by the non-immediate unsolicited
      
data
    
(if any) and solicited data." If non-ZBVA mode is used, then VA
      
points to
    
the beginning of this buffer. So in your example, the VA field in
      
the
  
expanded iSER header will be zero. Note that for IETF, ZBVA is
      
assumed and
    
there is no provision to specify a different VA in the iSER header.
      
Mike - I believe this VA field in the expanded iSER header is almost
NEVER zero -- it is always an actual virtual address.

    
Tagged offset (TO) refers to the offset within a tagged buffer in
      
RDMA Write
    
and RDMA Read Request Messages. When sending non-immediate
      
unsolicited
    
data, Send Message types are used and the TO field is not present.
      
Instead,
    
the buffer offset is appropriately represented by the Buffer Offset
      
field in
    
the SCSI Data-Out PDU. Note that Tagged Offset is not the same as
      
write VA
    
and it does not appear in the iSER header.

Mike
      
On Wed, 11 Mar 2009, Black_David@emc.com wrote:

    
This is a reminder that the Storage Maintenance BOF will
be held in about 2 weeks at the IETF meetings in San Francisco.
Please plan to attend if you're interested:

THURSDAY, March 26, 2009
Continental 1&2  	TSV  	storm  	 Storage Maintenance BOF

The BOF description is at:
http://www.ietf.org/mail-archive/web/ips/current/msg02669.html

The initial agenda is here:
http://www.ietf.org/mail-archive/web/ips/current/msg02670.html

I'm going to go upload that initial agenda as the BOF agenda,
and it can be bashed at the meeting.

The primary purpose of this BOF is to answer two questions:
(1) What storage maintenance work (IP Storage, Remote Direct
	Data Placement) should be done?
(2) Should an IETF Working Group be formed to undertake that
	work?

Everyone gets to weigh in on these decisions, even those who
can't attend the BOF meeting.  Anyone who thinks that there is
work that should be done, and who cannot come to the BOF meeting
should say so on the IPS or RDDP mailing lists (and it'd be a
good idea for those who can come to do this).  As part of the
email, please indicate how you're interested in helping (author
or co-author of specific drafts, promise to review and comment
on specific drafts).

Here's a summary of the initial draft list of work items:
- iSCSI: Combine RFCs into one document, removing unused features.
- iSCSI: Interoperability report on what has been implemented and
	interoperates in support of Draft Standard status for iSCSI.
- iSCSI: Add backwards-compatible features to support SAM-4.
- iFCP: The Address Translation mode of iFCP needs to be deprecated.
- RDDP MPA: Small startup update for MPI application support.
- iSER: A few minor updates based on InfiniBand experience.

Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes,
updated ipsec security profile [i.e., IKEv2-based]) is possible if
there's interest.

There are (at least) four possible outcomes:
(A) None of this work needs to be done.
(B) There are some small work items that make sense.  Individual
	drafts with a draft shepherd (i.e., David Black) will
	suffice.
(C) A working group is needed to undertake more complex work
	items and reach consensus on design issues.  The WG can
	be "virtual" and operate mostly via the mailing list
	until/unless controversial/contentious issues arise.
(D) There is a lot of complex work that is needed, and a WG
	that will plan to meet at every IETF meeting should be
	formed.

Please note that the IETF "rough consensus" process requires a
working group in practice to be effective.  This makes outcome
(C) look attractive to me, as:
- I'm coming under increasing pressure to limit travel, and
	the next two IETF meetings after San Francisco are not
	in the US.
- I'd rather have the "rough consensus" process available and
	not need it than need it and not have it available.

Setting an example for how to express interest ...

---------------
I think that the iSCSI single RFC and interoperability report are
good ideas, but I want to see a bunch of people expressing interest
in these, as significant effort is involved.  It might make sense
to do the single iSCSI RFC but put off the interoperability report
(the resulting RFC would remain at Proposed Standard rather than
going to Draft Standard), as I'm not hearing about major iSCSI
interoperability issues.

I think the latter four items (SAM-4 for iSCSI, deprecate iFCP
address translation, MPI fix to MPA and iSER fixes) should all
be done.

I plan to author the iFCP address translation deprecation draft,
and review all other drafts.

I think that a virtual WG should be formed that plans to do its
work primarily via the mailing list.  I believe the SAM-4 work
by itself is complex enough to need a working group - I would
expect design issues to turn up at least there and in determining
whether to remove certain iSCSI features, but I'm cautiously
optimistic that the mailing list is sufficient to work these
issues out (and concerned that travel restrictions are likely to
force use of the mailing list).

-----------------

Ok, who wants to go next?

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
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
----------------------------------------------------
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips

      
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www.ietf.org/mailman/listinfo/rddp
    
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www.ietf.org/mailman/listinfo/rddp
From BMT@zurich.ibm.com Tue Mar 24 08:26:02 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C04A28C103; Tue, 24 Mar 2009 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQRF3stOQRGr; Tue, 24 Mar 2009 08:26:00 -0700 (PDT) Received: from mtagate6.de.ibm.com (mtagate6.de.ibm.com [195.212.29.155]) by core3.amsl.com (Postfix) with ESMTP id ED95128C0D0; Tue, 24 Mar 2009 08:25:59 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.14.3/8.13.8) with ESMTP id n2OFQXtG643090; Tue, 24 Mar 2009 15:26:33 GMT Received: from d12av06.megacenter.de.ibm.com (d12av06.megacenter.de.ibm.com [9.149.165.230]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2OFQX7F2846914; Tue, 24 Mar 2009 16:26:33 +0100 Received: from d12av06.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av06.megacenter.de.ibm.com (8.13.1/8.13.3) with ESMTP id n2OFQWYU009319; Tue, 24 Mar 2009 16:26:33 +0100 Received: from d12ml302.megacenter.de.ibm.com (d12ml302.megacenter.de.ibm.com [9.149.166.18]) by d12av06.megacenter.de.ibm.com (8.13.1/8.12.11) with ESMTP id n2OFQWSD009315; Tue, 24 Mar 2009 16:26:32 +0100 In-Reply-To: To: "Robert D. Russell" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 From: Bernard Metzler Message-ID: Date: Tue, 24 Mar 2009 07:26:29 -0800 X-MIMETrack: Serialize by Router on D12ML302/12/M/IBM(Release 8.0.1|February 07, 2008) at 24/03/2009 16:26:32, Serialize complete at 24/03/2009 16:26:32 Content-Type: multipart/alternative; boundary="=_alternative 005E89DCC1257582_=" X-Mailman-Approved-At: Tue, 24 Mar 2009 09:05:13 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp-bounces@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: Re: [imss] [rddp] [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 15:26:02 -0000 This is a multipart message in MIME format. --=_alternative 005E89DCC1257582_= Content-Type: text/plain; charset="US-ASCII" Hi Robert, an RNIC would be happy to transition an established socket into RDMA mode if the user wants to. No problem - as far as i know - to transition from TOE mode to RDMA mode at least. It is a question of envrionmental support to allow that. To allow that, the environment (aka OFED) wold have to integrate late socket translation, which allows RNIC drivers to officially do TOE to RDMA mode transition or to take over a socket (where the OS would have to expose a well-defined TCP context reallocation scheme). Maybe it is not a good idea to change an end-to-end protocol because a host environment has functional limitations which may stem from historical transport (IB) limitations or OS considerations. many thanks, bernard. rddp-bounces@ietf.org wrote on 03/22/2009 04:41:55 PM: > David: > > There are 2 issues I would like to suggest for discussion at the BOF > meeting later this week. Both have to do with the iSER spec, RFC 5046. > > 1. At the present time, as far as I know, no existing hardware, > neither Infiniband nor iWARP, is capable of opening a connection > in "normal" TCP mode and then transitioning it into zero-copy mode. > Unfortunately, the iSER spec requires that. > Can't we just replace that part of the iSER spec? > Otherwise, all hardware and all implementations are non-standard. > > 2. The OFED stack is used to access both Infiniband and iWARP hardware. > This software requires 2 extra 64-bit fields for addressing > on both Infiniband and iWARP hardware, but these fields > are not allowed for in the current iSER Header Format. > Can't we just add those extra fields to the iSER spec? > If someday some other implementation doesn't need those > fields, they can be just set to 0 (which is what is implied by > the current iSER standard anyway). Again, by not doing this, > all implementations are non-standard. > > In other words, I'm suggesting that we consider replacing the relevant > parts of the current iSER specs with the current OFED specs on these > 2 issues. > > Thanks for your consideration, > Bob Russell > > Note: The following (old) posting by Mike Ko states that the > extra header fields are needed only by IB, not by IETF > (i.e., iWARP), because IB uses nZBVA, whereas iWARP uses ZBVA. > > But are there any IETF/iWARP implementations out there that actually > use ZBVA with iWARP RNICs? (I don't mean software simulations of > the iWARP protocol.) We have built an iSER implementation that > uses the OFED stack to access both IB and iWARP hardware, and for > both of them we need to use the extra iSER header fields (nZBVA). > Perhaps this is an issue with the design of the OFED stack, which > was built primarily to access IB hardware and therefore reflects > the needs of the IB hardware. But we found that the only way to > access iWARP hardware via the OFED stack was to used the expanded > (nZBVA) iSER header (and to use a meaningful value in the extra field, > NOT to just set it to zero). > > In any case, rather than have 2 different versions of the iSER header, > it would be better to have just one, regardless of the underlying > technology involved (after all, isn't that what a standard is for??). > This is especially relevant when using the OFED stack, because, > as we have demonstrated, software built on top of the OFED stack can > (AND SHOULD!) be able to run with EITHER IB or iWARP hardware, > with NO change to that software. Having 2 different iSER headers > does NOT make that possible! > > > > 2008/4/15 Mike Ko : > > > > VA is a concept introduced in an Infiniband annex to support iSER. It > > appears in the expanded iSER header for Infiniband use only to support the > > non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA > > used in IETF. > > Mike - could you please put me in contact with someone who has actually > implemented iSER on top of IETF/iWARP hardware NICs using ZBVA? > > > > > "The DataDescriptorOut describes the I/O buffer starting with the immediate > > unsolicited data (if any), followed by the non-immediate unsolicited data > > (if any) and solicited data." If non-ZBVA mode is used, then VA points to > > the beginning of this buffer. So in your example, the VA field in the > > expanded iSER header will be zero. Note that for IETF, ZBVA is assumed and > > there is no provision to specify a different VA in the iSER header. > > Mike - I believe this VA field in the expanded iSER header is almost > NEVER zero -- it is always an actual virtual address. > > > > > Tagged offset (TO) refers to the offset within a tagged buffer in RDMA Write > > and RDMA Read Request Messages. When sending non-immediate unsolicited > > data, Send Message types are used and the TO field is not present. Instead, > > the buffer offset is appropriately represented by the Buffer Offset field in > > the SCSI Data-Out PDU. Note that Tagged Offset is not the same as write VA > > and it does not appear in the iSER header. > > > >Mike > > On Wed, 11 Mar 2009, Black_David@emc.com wrote: > > > This is a reminder that the Storage Maintenance BOF will > > be held in about 2 weeks at the IETF meetings in San Francisco. > > Please plan to attend if you're interested: > > > > THURSDAY, March 26, 2009 > > Continental 1&2 TSV storm Storage Maintenance BOF > > > > The BOF description is at: > > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html > > > > The initial agenda is here: > > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html > > > > I'm going to go upload that initial agenda as the BOF agenda, > > and it can be bashed at the meeting. > > > > The primary purpose of this BOF is to answer two questions: > > (1) What storage maintenance work (IP Storage, Remote Direct > > Data Placement) should be done? > > (2) Should an IETF Working Group be formed to undertake that > > work? > > > > Everyone gets to weigh in on these decisions, even those who > > can't attend the BOF meeting. Anyone who thinks that there is > > work that should be done, and who cannot come to the BOF meeting > > should say so on the IPS or RDDP mailing lists (and it'd be a > > good idea for those who can come to do this). As part of the > > email, please indicate how you're interested in helping (author > > or co-author of specific drafts, promise to review and comment > > on specific drafts). > > > > Here's a summary of the initial draft list of work items: > > - iSCSI: Combine RFCs into one document, removing unused features. > > - iSCSI: Interoperability report on what has been implemented and > > interoperates in support of Draft Standard status for iSCSI. > > - iSCSI: Add backwards-compatible features to support SAM-4. > > - iFCP: The Address Translation mode of iFCP needs to be deprecated. > > - RDDP MPA: Small startup update for MPI application support. > > - iSER: A few minor updates based on InfiniBand experience. > > > > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, > > updated ipsec security profile [i.e., IKEv2-based]) is possible if > > there's interest. > > > > There are (at least) four possible outcomes: > > (A) None of this work needs to be done. > > (B) There are some small work items that make sense. Individual > > drafts with a draft shepherd (i.e., David Black) will > > suffice. > > (C) A working group is needed to undertake more complex work > > items and reach consensus on design issues. The WG can > > be "virtual" and operate mostly via the mailing list > > until/unless controversial/contentious issues arise. > > (D) There is a lot of complex work that is needed, and a WG > > that will plan to meet at every IETF meeting should be > > formed. > > > > Please note that the IETF "rough consensus" process requires a > > working group in practice to be effective. This makes outcome > > (C) look attractive to me, as: > > - I'm coming under increasing pressure to limit travel, and > > the next two IETF meetings after San Francisco are not > > in the US. > > - I'd rather have the "rough consensus" process available and > > not need it than need it and not have it available. > > > > Setting an example for how to express interest ... > > > > --------------- > > I think that the iSCSI single RFC and interoperability report are > > good ideas, but I want to see a bunch of people expressing interest > > in these, as significant effort is involved. It might make sense > > to do the single iSCSI RFC but put off the interoperability report > > (the resulting RFC would remain at Proposed Standard rather than > > going to Draft Standard), as I'm not hearing about major iSCSI > > interoperability issues. > > > > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP > > address translation, MPI fix to MPA and iSER fixes) should all > > be done. > > > > I plan to author the iFCP address translation deprecation draft, > > and review all other drafts. > > > > I think that a virtual WG should be formed that plans to do its > > work primarily via the mailing list. I believe the SAM-4 work > > by itself is complex enough to need a working group - I would > > expect design issues to turn up at least there and in determining > > whether to remove certain iSCSI features, but I'm cautiously > > optimistic that the mailing list is sufficient to work these > > issues out (and concerned that travel restrictions are likely to > > force use of the mailing list). > > > > ----------------- > > > > Ok, who wants to go next? > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > 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 > > ---------------------------------------------------- > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www.ietf.org/mailman/listinfo/ips > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www.ietf.org/mailman/listinfo/rddp --=_alternative 005E89DCC1257582_= Content-Type: text/html; charset="US-ASCII"
Hi Robert,

an RNIC would be happy to transition an established socket
into RDMA mode if the user wants to. No problem - as far as i know -
to transition from TOE mode to RDMA mode at least. It is a question
of envrionmental support to allow that. To allow that,
the environment (aka OFED) wold have to integrate late
socket translation, which allows RNIC drivers to officially do
TOE to RDMA mode transition or to take over a socket
(where the OS would have to expose a well-defined TCP
context reallocation scheme).
Maybe it is not a good idea to change an end-to-end protocol
because a host environment has functional limitations
which may stem from historical transport (IB) limitations or
OS considerations.

many thanks,
bernard.

rddp-bounces@ietf.org wrote on 03/22/2009 04:41:55 PM:

> David:
>
> There are 2 issues I would like to suggest for discussion at the BOF
> meeting later this week.  Both have to do with the iSER spec, RFC 5046.
>
> 1. At the present time, as far as I know, no existing hardware,
>     neither Infiniband nor iWARP, is capable of opening a connection
>     in "normal" TCP mode and then transitioning it into zero-copy mode.
>     Unfortunately, the iSER spec requires that.
>     Can't we just replace that part of the iSER spec?
>     Otherwise, all hardware and all implementations are non-standard.
>
> 2. The OFED stack is used to access both Infiniband and iWARP hardware.
>     This software requires 2 extra 64-bit fields for addressing
>     on both Infiniband and iWARP hardware, but these fields
>     are not allowed for in the current iSER Header Format.
>     Can't we just add those extra fields to the iSER spec?
>     If someday some other implementation doesn't need those
>     fields, they can be just set to 0 (which is what is implied by
>     the current iSER standard anyway).  Again, by not doing this,
>     all implementations are non-standard.
>
> In other words, I'm suggesting that we consider replacing the relevant
> parts of the current iSER specs with the current OFED specs on these
> 2 issues.
>
> Thanks for your consideration,
> Bob Russell
>
> Note: The following (old) posting by Mike Ko states that the
> extra header fields are needed only by IB, not by IETF
> (i.e., iWARP), because IB uses nZBVA, whereas iWARP uses ZBVA.
>
> But are there any IETF/iWARP implementations out there that actually
> use ZBVA with iWARP RNICs?  (I don't mean software simulations of
> the iWARP protocol.)  We have built an iSER implementation that
> uses the OFED stack to access both IB and iWARP hardware, and for
> both of them we need to use the extra iSER header fields (nZBVA).
> Perhaps this is an issue with the design of the OFED stack, which
> was built primarily to access IB hardware and therefore reflects
> the needs of the IB hardware.  But we found that the only way to
> access iWARP hardware via the OFED stack was to used the expanded
> (nZBVA) iSER header (and to use a meaningful value in the extra field,
> NOT to just set it to zero).
>
> In any case, rather than have 2 different versions of the iSER header,
> it would be better to have just one, regardless of the underlying
> technology involved (after all, isn't that what a standard is for??).
> This is especially relevant when using the OFED stack, because,
> as we have demonstrated, software built on top of the OFED stack can
> (AND SHOULD!) be able to run with EITHER IB or iWARP hardware,
> with NO change to that software.  Having 2 different iSER headers
> does NOT make that possible!
>
>
> > 2008/4/15 Mike Ko <mako at almaden.ibm.com>:
> >
> > VA is a concept introduced in an Infiniband annex to support iSER. It
> > appears in the expanded iSER header for Infiniband use only to support the
> > non-Zero Based Virtual Address (non-ZBVA) used in Infiniband vs the ZBVA
> > used in IETF.
>
> Mike - could you please put me in contact with someone who has actually
> implemented iSER on top of IETF/iWARP hardware NICs using ZBVA?
>
> >
> > "The DataDescriptorOut describes the I/O buffer starting with the immediate
> > unsolicited data (if any), followed by the non-immediate unsolicited data
> > (if any) and solicited data." If non-ZBVA mode is used, then VA points to
> > the beginning of this buffer. So in your example, the VA field in the
> > expanded iSER header will be zero. Note that for IETF, ZBVA is assumed and
> > there is no provision to specify a different VA in the iSER header.
>
> Mike - I believe this VA field in the expanded iSER header is almost
> NEVER zero -- it is always an actual virtual address.
>
> >
> > Tagged offset (TO) refers to the offset within a tagged buffer in RDMA Write
> > and RDMA Read Request Messages. When sending non-immediate unsolicited
> > data, Send Message types are used and the TO field is not present. Instead,
> > the buffer offset is appropriately represented by the Buffer Offset field in
> > the SCSI Data-Out PDU. Note that Tagged Offset is not the same as write VA
> > and it does not appear in the iSER header.
> >
> >Mike
>
> On Wed, 11 Mar 2009, Black_David@emc.com wrote:
>
> > This is a reminder that the Storage Maintenance BOF will
> > be held in about 2 weeks at the IETF meetings in San Francisco.
> > Please plan to attend if you're interested:
> >
> > THURSDAY, March 26, 2009
> > Continental 1&2     TSV     storm      Storage Maintenance BOF
> >
> > The BOF description is at:
> > http://www.ietf.org/mail-archive/web/ips/current/msg02669.html
> >
> > The initial agenda is here:
> > http://www.ietf.org/mail-archive/web/ips/current/msg02670.html
> >
> > I'm going to go upload that initial agenda as the BOF agenda,
> > and it can be bashed at the meeting.
> >
> > The primary purpose of this BOF is to answer two questions:
> > (1) What storage maintenance work (IP Storage, Remote Direct
> >    Data Placement) should be done?
> > (2) Should an IETF Working Group be formed to undertake that
> >    work?
> >
> > Everyone gets to weigh in on these decisions, even those who
> > can't attend the BOF meeting.  Anyone who thinks that there is
> > work that should be done, and who cannot come to the BOF meeting
> > should say so on the IPS or RDDP mailing lists (and it'd be a
> > good idea for those who can come to do this).  As part of the
> > email, please indicate how you're interested in helping (author
> > or co-author of specific drafts, promise to review and comment
> > on specific drafts).
> >
> > Here's a summary of the initial draft list of work items:
> > - iSCSI: Combine RFCs into one document, removing unused features.
> > - iSCSI: Interoperability report on what has been implemented and
> >    interoperates in support of Draft Standard status for iSCSI.
> > - iSCSI: Add backwards-compatible features to support SAM-4.
> > - iFCP: The Address Translation mode of iFCP needs to be deprecated.
> > - RDDP MPA: Small startup update for MPI application support.
> > - iSER: A few minor updates based on InfiniBand experience.
> >
> > Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes,
> > updated ipsec security profile [i.e., IKEv2-based]) is possible if
> > there's interest.
> >
> > There are (at least) four possible outcomes:
> > (A) None of this work needs to be done.
> > (B) There are some small work items that make sense.  Individual
> >    drafts with a draft shepherd (i.e., David Black) will
> >    suffice.
> > (C) A working group is needed to undertake more complex work
> >    items and reach consensus on design issues.  The WG can
> >    be "virtual" and operate mostly via the mailing list
> >    until/unless controversial/contentious issues arise.
> > (D) There is a lot of complex work that is needed, and a WG
> >    that will plan to meet at every IETF meeting should be
> >    formed.
> >
> > Please note that the IETF "rough consensus" process requires a
> > working group in practice to be effective.  This makes outcome
> > (C) look attractive to me, as:
> > - I'm coming under increasing pressure to limit travel, and
> >    the next two IETF meetings after San Francisco are not
> >    in the US.
> > - I'd rather have the "rough consensus" process available and
> >    not need it than need it and not have it available.
> >
> > Setting an example for how to express interest ...
> >
> > ---------------
> > I think that the iSCSI single RFC and interoperability report are
> > good ideas, but I want to see a bunch of people expressing interest
> > in these, as significant effort is involved.  It might make sense
> > to do the single iSCSI RFC but put off the interoperability report
> > (the resulting RFC would remain at Proposed Standard rather than
> > going to Draft Standard), as I'm not hearing about major iSCSI
> > interoperability issues.
> >
> > I think the latter four items (SAM-4 for iSCSI, deprecate iFCP
> > address translation, MPI fix to MPA and iSER fixes) should all
> > be done.
> >
> > I plan to author the iFCP address translation deprecation draft,
> > and review all other drafts.
> >
> > I think that a virtual WG should be formed that plans to do its
> > work primarily via the mailing list.  I believe the SAM-4 work
> > by itself is complex enough to need a working group - I would
> > expect design issues to turn up at least there and in determining
> > whether to remove certain iSCSI features, but I'm cautiously
> > optimistic that the mailing list is sufficient to work these
> > issues out (and concerned that travel restrictions are likely to
> > force use of the mailing list).
> >
> > -----------------
> >
> > Ok, who wants to go next?
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > 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
> > ----------------------------------------------------
> > _______________________________________________
> > Ips mailing list
> > Ips@ietf.org
> > https://www.ietf.org/mailman/listinfo/ips
> >
> _______________________________________________
> rddp mailing list
> rddp@ietf.org
> https://www.ietf.org/mailman/listinfo/rddp
 --=_alternative 005E89DCC1257582_=-- From Black_David@emc.com Tue Mar 24 09:57:54 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41A5728C2F8; Tue, 24 Mar 2009 09:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoS5xNUOliBL; Tue, 24 Mar 2009 09:57:53 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 5259428C2F9; Tue, 24 Mar 2009 09:57:53 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2OGwg0M010093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 12:58:43 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 24 Mar 2009 12:58:38 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2OGwcIB001372; Tue, 24 Mar 2009 12:58:38 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 12:58:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 12:58:34 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0234A854@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STORM BOF: Presentations posted Thread-Index: AcmsocRzuWAmDg5ETIe2d3loLwHpFw== X-Priority: 1 Priority: Urgent Importance: high To: , X-OriginalArrivalTime: 24 Mar 2009 16:58:34.0997 (UTC) FILETIME=[C4E73A50:01C9ACA1] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com Subject: [imss] STORM BOF: Presentations posted X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:57:54 -0000 The presentations for the STORM BOF on Thursday are now posted at: https://datatracker.ietf.org/meeting/74/materials.html Scroll that page down to find the STORM BOF in the Transport Area. IMPORTANT: If you cannot attend the BOF in person and think that a WG should be formed, please say so on the list. My advice is that if you believe that any of the proposed work should be done, then a WG is a *very good* idea because a WG enables IETF's "rough consensus" techniques to be applied (ensures work won't bog down in design issues). I've done a "brain dump" into the main slide set - there are a number of small items listed on the slides that have been pointed out to me as worthy of attention. One new item that I want to call attention to is that once upon a time (2000), an IP Protocol Number was allocated for what I believe to have been a precursor to the FCIP protocol. FCIP does not use its own IP Protocol Number because it uses TCP. It would be a "good thing" for the new STORM WG to investigate whether this number is actually unused and hence can be returned to IANA for reassignment (these numbers are a scarce resource). Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 ---------------------------------------------------- From Black_David@emc.com Tue Mar 24 13:27:17 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0112528C319; Tue, 24 Mar 2009 13:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkRb2WeaPU8p; Tue, 24 Mar 2009 13:27:16 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 1C2003A69A1; Tue, 24 Mar 2009 13:27:15 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2OKS4Od011754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 16:28:05 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Tue, 24 Mar 2009 16:27:59 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2OKRurA007781; Tue, 24 Mar 2009 16:27:59 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:27:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 16:27:55 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0234AAB7@CORPUSMX80A.corp.emc.com> In-reply-to: <18889.12274.355346.791684@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] STORM WG - draft charter Thread-Index: AcmstBjK/krqClTfSuirccs6lpfO8AACuLKg References: <9FA859626025B64FBC2AF149D97C944A0234A317@CORPUSMX80A.corp.emc.com> <18889.12274.355346.791684@gargle.gargle.HOWL> To: X-OriginalArrivalTime: 24 Mar 2009 20:27:57.0156 (UTC) FILETIME=[04889240:01C9ACBF] X-EMM-EM: Active Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [imss] [Ips] STORM WG - draft charter X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:27:17 -0000 It's a "just in case" placeholder. Thanks, --David =20 > -----Original Message----- > From: Paul Koning [mailto:Paul_Koning@Dell.com]=20 > Sent: Tuesday, March 24, 2009 3:10 PM > To: Black, David > Cc: ips@ietf.org; rddp@ietf.org; imss@ietf.org > Subject: Re: [Ips] STORM WG - draft charter >=20 > Question... >=20 > The second bullet says, among other things: "this may entail updates > to RFC 3722 [stringprep for iSCSI] and RFC 3723 [security]." >=20 > Are there any specific potential changes known, or is this just a > "just in case" placeholder? >=20 > paul >=20 >=20 >=20 >=20 From Black_David@emc.com Tue Mar 24 13:31:33 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20A2C3A6B41; Tue, 24 Mar 2009 13:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2vu6Q9XNhrJ; Tue, 24 Mar 2009 13:31:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 3E74D3A6B02; Tue, 24 Mar 2009 13:31:32 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2OKWK0B016893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Mar 2009 16:32:21 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Tue, 24 Mar 2009 16:32:11 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2OKW8se015407; Tue, 24 Mar 2009 16:32:11 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:32:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 16:32:08 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A0234AAC4@CORPUSMX80A.corp.emc.com> In-reply-to: <18889.12431.733174.628303@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] STORM BOF: Presentations posted Thread-Index: AcmstHggG6m5jsjBS9qE7ZdfY7S+rwACpeTw References: <9FA859626025B64FBC2AF149D97C944A0234A854@CORPUSMX80A.corp.emc.com> <18889.12431.733174.628303@gargle.gargle.HOWL> To: X-OriginalArrivalTime: 24 Mar 2009 20:32:10.0329 (UTC) FILETIME=[9B6FB490:01C9ACBF] X-EMM-EM: Active Cc: imss@ietf.org, ips@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: Re: [imss] [Ips] STORM BOF: Presentations posted X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:31:33 -0000 Paul, Here are the details on that one: This is useful for a target appliance which serves a large number of concurrent sessions with unsolicited data and adjusts the transport windows on a dynamic basis. In particular, inactive sessions (i.e., those which have not issued any SCSI commands for a reasonable time) may have their window reduced to reassign resources to the active sessions. One method is as follows. The target issues an Asynchronous Message -=20 "target requests parameter negotiation" to provoke the initiator into consuming a command. The target responds to the Text request with an empty Text response and repeats the procedure until the window has been reduced to the desired level. If this is considered important ("this is not a problem in practice" opinions are welcome), there are obvious opportunities for improvement. Thanks, --David =20 > -----Original Message----- > From: Paul Koning [mailto:Paul_Koning@Dell.com]=20 > Sent: Tuesday, March 24, 2009 3:12 PM > To: Black, David > Cc: ips@ietf.org; rddp@ietf.org; imss@ietf.org > Subject: Re: [Ips] STORM BOF: Presentations posted >=20 > David, >=20 > On your slides: >=20 > Page 7 mentions "CmdSN window size reduction". Could you elaborate? >=20 > paul >=20 >=20 >=20 From Paul_Koning@Dell.com Tue Mar 24 12:09:11 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E363A6A5E; Tue, 24 Mar 2009 12:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.903 X-Spam-Level: X-Spam-Status: No, score=-103.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_RELAY=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlIAprl4yYqJ; Tue, 24 Mar 2009 12:09:10 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 59C163A698E; Tue, 24 Mar 2009 12:09:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,414,1233554400"; d="scan'208";a="392200869" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 24 Mar 2009 14:09:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18889.12274.355346.791684@gargle.gargle.HOWL> Date: Tue, 24 Mar 2009 15:09:38 -0400 From: Paul Koning To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A0234A317@CORPUSMX80A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 24 Mar 2009 19:09:41.0013 (UTC) FILETIME=[156A0450:01C9ACB4] X-Mailman-Approved-At: Wed, 25 Mar 2009 08:27:19 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [imss] [Ips] STORM WG - draft charter X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:09:11 -0000 Question... The second bullet says, among other things: "this may entail updates to RFC 3722 [stringprep for iSCSI] and RFC 3723 [security]." Are there any specific potential changes known, or is this just a "just in case" placeholder? paul From Paul_Koning@Dell.com Tue Mar 24 12:11:29 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AF63A698E; Tue, 24 Mar 2009 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.251 X-Spam-Level: X-Spam-Status: No, score=-105.251 tagged_above=-999 required=5 tests=[AWL=1.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdzm7mysXR2V; Tue, 24 Mar 2009 12:11:29 -0700 (PDT) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by core3.amsl.com (Postfix) with ESMTP id EB0563A6899; Tue, 24 Mar 2009 12:11:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,414,1233554400"; d="scan'208";a="375663475" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 24 Mar 2009 14:12:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18889.12431.733174.628303@gargle.gargle.HOWL> Date: Tue, 24 Mar 2009 15:12:15 -0400 From: Paul Koning To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A0234A854@CORPUSMX80A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 24 Mar 2009 19:12:18.0695 (UTC) FILETIME=[73666170:01C9ACB4] X-Mailman-Approved-At: Wed, 25 Mar 2009 08:27:19 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [imss] [Ips] STORM BOF: Presentations posted X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:11:30 -0000 David, On your slides: Page 7 mentions "CmdSN window size reduction". Could you elaborate? paul From uri@broadcom.com Tue Mar 24 16:53:37 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE46328C11C; Tue, 24 Mar 2009 16:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+hRnRvDZrqy; Tue, 24 Mar 2009 16:53:36 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 3B35C28C115; Tue, 24 Mar 2009 16:53:36 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 24 Mar 2009 16:54:20 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 24 Mar 2009 16:54:19 -0700 From: "Uri Elzur" To: "Black_David@emc.com" , "ips@ietf.org" , "rddp@ietf.org" Date: Tue, 24 Mar 2009 16:54:18 -0700 Thread-Topic: Storage Maintenance (storm) BOF reminder & requests Thread-Index: AcmioQqSkUT1te6rS+uCXVPIvobxAQKOro1g Message-ID: <164C3CF644AC8E4E81B05EEBA3C234453ED0CC340A@IRVEXCHCCR01.corp.ad.broadcom.com> References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 65D7AD265Y89238954-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 25 Mar 2009 08:27:19 -0700 Cc: "imss@ietf.org" Subject: Re: [imss] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:53:38 -0000 Hi David Unfortunately I won't be able to make it in person to the meeting this week= . However, I'd like to extend our support to the following items: - iSCSI: Add backwards-compatible features to support SAM-4. - RDDP MPA: Small startup update for MPI application support. I think that a virtual WG should be formed that plans to do its work primarily via the mailing list. This will give us an opportunity to f= lush out the issues and have a better assessment of the priorities and effo= rt associated with the activities. At that point, we can decide if/when to = go into formal WG thx Uri ("Oo-ree")=20 W: 949-926-6432=20 C: 949-292-6098=20 -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Black= _David@emc.com Sent: Wednesday, March 11, 2009 4:28 PM To: ips@ietf.org; rddp@ietf.org Cc: imss@ietf.org; Black_David@emc.com Subject: [Ips] Storage Maintenance (storm) BOF reminder & requests Importance: High This is a reminder that the Storage Maintenance BOF will be held in about 2 weeks at the IETF meetings in San Francisco. Please plan to attend if you're interested: THURSDAY, March 26, 2009 Continental 1&2 TSV storm Storage Maintenance BOF The BOF description is at: http://www.ietf.org/mail-archive/web/ips/current/msg02669.html The initial agenda is here: http://www.ietf.org/mail-archive/web/ips/current/msg02670.html I'm going to go upload that initial agenda as the BOF agenda, and it can be bashed at the meeting. The primary purpose of this BOF is to answer two questions: (1) What storage maintenance work (IP Storage, Remote Direct Data Placement) should be done? (2) Should an IETF Working Group be formed to undertake that work? Everyone gets to weigh in on these decisions, even those who can't attend the BOF meeting. Anyone who thinks that there is work that should be done, and who cannot come to the BOF meeting should say so on the IPS or RDDP mailing lists (and it'd be a good idea for those who can come to do this). As part of the email, please indicate how you're interested in helping (author or co-author of specific drafts, promise to review and comment on specific drafts). Here's a summary of the initial draft list of work items: - iSCSI: Combine RFCs into one document, removing unused features. - iSCSI: Interoperability report on what has been implemented and interoperates in support of Draft Standard status for iSCSI. - iSCSI: Add backwards-compatible features to support SAM-4. - iFCP: The Address Translation mode of iFCP needs to be deprecated. - RDDP MPA: Small startup update for MPI application support. - iSER: A few minor updates based on InfiniBand experience. Additional work (e.g., updated/improved iSNS for iSCSI, MIB changes, updated ipsec security profile [i.e., IKEv2-based]) is possible if there's interest. There are (at least) four possible outcomes: (A) None of this work needs to be done. (B) There are some small work items that make sense. Individual drafts with a draft shepherd (i.e., David Black) will suffice. (C) A working group is needed to undertake more complex work items and reach consensus on design issues. The WG can be "virtual" and operate mostly via the mailing list until/unless controversial/contentious issues arise. (D) There is a lot of complex work that is needed, and a WG that will plan to meet at every IETF meeting should be formed. Please note that the IETF "rough consensus" process requires a working group in practice to be effective. This makes outcome (C) look attractive to me, as: - I'm coming under increasing pressure to limit travel, and the next two IETF meetings after San Francisco are not in the US. - I'd rather have the "rough consensus" process available and not need it than need it and not have it available. Setting an example for how to express interest ... --------------- I think that the iSCSI single RFC and interoperability report are good ideas, but I want to see a bunch of people expressing interest in these, as significant effort is involved. It might make sense to do the single iSCSI RFC but put off the interoperability report (the resulting RFC would remain at Proposed Standard rather than going to Draft Standard), as I'm not hearing about major iSCSI interoperability issues. I think the latter four items (SAM-4 for iSCSI, deprecate iFCP address translation, MPI fix to MPA and iSER fixes) should all be done. I plan to author the iFCP address translation deprecation draft, and review all other drafts. I think that a virtual WG should be formed that plans to do its work primarily via the mailing list. I believe the SAM-4 work by itself is complex enough to need a working group - I would expect design issues to turn up at least there and in determining whether to remove certain iSCSI features, but I'm cautiously optimistic that the mailing list is sufficient to work these issues out (and concerned that travel restrictions are likely to force use of the mailing list). ----------------- Ok, who wants to go next? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From Black_David@emc.com Thu Mar 26 21:56:59 2009 Return-Path: X-Original-To: imss@core3.amsl.com Delivered-To: imss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F543A67D9; Thu, 26 Mar 2009 21:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16bFwiBasyGi; Thu, 26 Mar 2009 21:56:58 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 3A7AA3A6407; Thu, 26 Mar 2009 21:56:58 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n2R4vpbl021470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Mar 2009 00:57:51 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Fri, 27 Mar 2009 00:57:44 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n2R4virP011229; Fri, 27 Mar 2009 00:57:44 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Mar 2009 00:57:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Mar 2009 00:57:41 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A023A30C2@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: STORM BOF - Draft minutes Thread-Index: AcmumI819U1O0IOkRweSmVlG4nxrWw== To: , X-OriginalArrivalTime: 27 Mar 2009 04:57:43.0967 (UTC) FILETIME=[90850AF0:01C9AE98] X-EMM-EM: Active Cc: imss@ietf.org, Black_David@emc.com Subject: [imss] STORM BOF - Draft minutes X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 04:57:00 -0000 See below - these are a bit on the long side, as a lot of ground was covered in the BOF. Many thanks to Paul Koning for helping to take notes. We did not actually have a jabber scribe providing running commentary in the jabber room - the assumption/hope was that everyone in the jabber room was listening to the audio feed. If that was a bad assumption, please send me an email directly, and we'll do better in the future. The overall conclusion of the BOF is that a new STORM (STORage Maintenance) WG should be formed to pursue essentially the program of work in the draft charter that I sent to the lists earlier. There will be a new storm@ietf.org mailing list for this WG. As all decisions in IETF meetings are confirmed on mailing lists, now is the time to speak up if: - anyone thinks that a WG should not be formed, or - anyone thinks that one or more of the work items on the draft charter (see minutes) should not be done. I will also be contacting some people directly to try to ensure that there is at least one Internet-Draft author for each work item. Please also provide any other corrections to the minutes (either to the list or directly to me). Thanks, --David Transport Area (TSV) BOF: STORM (STORage Maintenance) THURSDAY, March 26, 2009, 0900-1130 Morning Session I IETF San Francisco Meetings =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D BOF chair: David L. Black, EMC (black_david@emc.com) Minutes - Initial Draft ---------------------- --- Administrivia ---- - Note Well (projected) - Blue Sheets (circulated) - Scribes (minutes, jabber) Jabber room was initially not functioning, but was fixed shortly after BOF started - Purpose of BOF: Question #1: Should an IETF WG be formed? --- Agenda Bashing --- Agenda was bashed to add discussion of possibly related work in T11 (Fibre Channel Standards Organization). The T11 vice chair (and acting chair) was present to discuss the item. -- Draft charter: Initial presentation --- Charter presented, no text bashed. Discussion of possible iSCSI-related work - Consolidated iSCSI RFC - Whether to take iSCSI to Draft Standard status, including implementation report - SAM-4 feature addition Extensive discussion indicated clear strong interest in the SAM-4 feature addition and interest in consolidating the iSCSI RFCs into a single document that could go to Draft Standard status. The resulting plan is to have two drafts: 1) An rfc3720bis draft that consolidates and prunes the current iSCSI RFCs based on current implementations. The intent is that this draft be suitable for Draft Standard status. 2) A "new features" draft that adds (in a backwards compatible fashion) minor new features, starting with the new SAM-4 features. This draft would be intended for Proposed Standard status, and all of its contents would be optional and negotiable (e.g., via text keys at iSCSI login). The "new features" draft would not be limited to SAM-4 features, but all additions would need to be minor. IETF procedures would allow everything to be rolled into one document that could be taken to Draft Standard status after a 6 month waiting period at Proposed Standard, but the sense of the discussion was that the above two-document plan is the better course of action, and that only widely implemented features in current implementations should be considered for a Draft Standard RFC. The BOF chair prefers that the decision as to whether to take iSCSI to Draft Standard status be deferred, and will write charter text to allow this, but not require it. Among the reasons for this are the amount of work involved and potential interactions with other RFC documents that are currently at Proposed Standard status. It seems to make better sense to specify iSCSI support for all new SAM-4 features (as other SCSI transports, such as FCP [SCSI over Fibre Channel] and SAS [Serial Attach SCSI]) have done, rather than only specify selected SAM-4 features. iSCSI could then define multiple text keys to allow support for these features (or groups of them) to be separately negotiated. IETF coordination with T10 is planned to be handled informally. At least David Black (BOF chair) and Fred Knight (one of the presenters on the SAM-4 topic) are active T10 participants who can facilitate this coordination. The formal IETF mechanisms for liaison with other organizations appear unlikely to be needed. --- FC encapsulation-related work (possible) --- - iFCP Address Translation obsolescence - FC(IP) IP Protocol Number Both of these appear to be good ideas. The BOF chair is prepared to write the Internet-Draft for the first item, and the second item is for the WG to investigate whether IP Protocol number 133 (allocated for Fibre Channel in 2000) is unused and should be returned to IANA for future reassignment. - Related T11 activity (RDDP over Ethernet) T11 is the standards organization for Fibre Channel. A proposal has been submitted to T11 for it to work on hosting the RDDP (aka iWARP) protocols on Ethernet directly via IP, see T11 document 09-141v0: http://www.t11.org/ftp/t11/admin/project_proposals/09-141v0.pdf The design proposed in that document appears to require allocation of an IP Protocol number. That can only be done by the IESG, and appears unlikely, as the proposed DCRP protocol is not intended to run over public networks like the Internet, has no congestion control and no security. UDP encapsulation may be a more plausible way forward, but there is a track record of protocols intended for closed networks "escaping" into the broader Internet. The BOF chair (David Black) is also a member of the IETF Transport Directorate and a T11 participant - he will take these concerns to the T11 meetings next week and express a desire for significant consultation between T11 and the IETF before T11 moves this work moves forward. The responsible Transport AD (Lars Eggert) concurs with and supports this course of action. --- RDDP-related work (possible) --- - MPA startup change for MPI There has been a lot of support for this relatively contained proposed work item on the mailing list. --- iSER-related work (possible) --- - Clarifications arising from InfiniBand and other use of iSER There has been support on the mailing list for this proposed work item. --- Any other proposed work items --- Nothing additional proposed. --- Draft charter: Text bashing, round 2 --- No further bashing. --- WG formation discussion --- Clear interest in forming a WG, with a desire to limit travel. Work item discussion took a bit longer. Different people are interested in different work items. A discussion of whether any work items should be deleted from the initial list in the charter did not identify any to be deleted, but acknowledged the BOF chair's preference to not have the charter commit up front to taking iSCSI to Draft Standard status. With that change, the "rough consensus" of the meeting (supported by some comments in the jabber room and emails sent to the list) is that a WG should be formed to take on essentially the plan of work in the draft charter. Discussion about travel and meetings reflected a concern about travel in current economic conditions and a desire to conduct as much work as possible on the mailing list. Beyond that, face-to- face meetings are sometimes needed to resolve issues and make progress - in line with current IETF practice, if a meeting is needed during an IETF meeting week, it'll be scheduled without significant consideration of where that IETF meeting is located. The expected default for the WG will be to not meet face-to-face unless there are clear issues that require a meeting. Interim meetings were suggested as a possibility, but there does not appear to be a geographic concentration of interested people; the BOF chair is aware of likely participants on both coasts of the US, China, Switzerland and Israel. Iceland was half-heartedly suggested as approximately equally inconvenient for all concerned. --- Mailing List Usage --- Organization of the BOF was conducted on the existing ips@ietf.org and rddp@ietf.org mailing lists, with the imss@ietf.org list cc:'d. After some discussion, the mailing list plan going forward is: - Form new storm@ietf.org mailing list for new STORM WG. - Announce this list on the IMSS, IPS and RDDP lists, inviting people to subscribe to the new STORM list. - No further STORM-related activity on the IMSS list after this announcement (and perhaps a few reminders). - Set IPS and RDDP auto-responders to indicate existence of STORM list. - After some period of time, close down the RDDP list, ask the IETF secretariat to set up an auto-responder for email to rddp@ietf.org indicating that storm@ietf.org should be used. - Leave IPS list open with auto-responders modified as above. - Leave IMSS list as it currently is. --- Milestones --- In order to have a charter that can be approved, milestones are needed. A small amount of discussion yielded the following guidelines: - Small stuff (e.g., MPA fix) should make it to Working Group Last Call (WG LC) this year - Other larger things (e.g., SAM-4) may need until latter part of next year to reach WG LC. - iSCSI: The consolidated iSCSI draft may be a 2 year project, but there should be a decent draft in about 1 year. - The charter will allow lazy evaluation of decision about whether to take iSCSI to Draft Standard, and hence not propose any milestones for that. --- Next steps --- - BOF chair to revise charter (with milestones) and send to mailing lists for review. - Assuming no significant objections to WG creation are raised, the secretariat will be asked to create a storm@ietf.org mailing list. - The actual storm WG formation request will probably go to the Area Director (Lars) for presentation to the IESG in about a month. 14 names on blue sheet, about 8 additional jabber room participants.