From Black_David@emc.com Wed Mar 11 16:27:47 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM BOF time X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 Julian_Satran@il.ibm.com Thu Mar 12 02:30:39 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48423A6403; Thu, 12 Mar 2009 02:30:39 -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 ljgv1ZY6SenW; Thu, 12 Mar 2009 02:30:38 -0700 (PDT) Received: from mtagate8.de.ibm.com (mtagate8.de.ibm.com [195.212.29.157]) by core3.amsl.com (Postfix) with ESMTP id B99403A67CC; Thu, 12 Mar 2009 02:30:35 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.14.3/8.13.8) with ESMTP id n2C9TwMF112568; Thu, 12 Mar 2009 09:29:58 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2C9TwK53997822; Thu, 12 Mar 2009 10:29:58 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2C9TvQT027414; Thu, 12 Mar 2009 10:29:57 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2C9Tvrr027410; Thu, 12 Mar 2009 10:29:57 +0100 In-Reply-To: References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> To: Kalman Meth MIME-Version: 1.0 X-KeepSent: 7B52CD7E:564ECBB6-C2257577:003310DA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Julian Satran Message-ID: Date: Thu, 12 Mar 2009 11:29:56 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 12/03/2009 11:29:57, Serialize complete at 12/03/2009 11:29:57 Content-Type: multipart/alternative; boundary="=_alternative 00339DF2C2257577_=" Cc: ips@ietf.org, "Chadalapaka, Mallikarjun B" , Black_David@emc.com, rddp@ietf.org Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 09:30:40 -0000 This is a multipart message in MIME format. --=_alternative 00339DF2C2257577_= Content-Type: text/plain; charset="US-ASCII" David, For some reason I don't get the ips and rdma mailings. I also interested but will not attend. Thanks, Julo From: Kalman Meth/Haifa/IBM To: Black_David@emc.com Cc: Julian Satran/Haifa/IBM@IBMIL, "Chadalapaka, Mallikarjun B" Date: 12/03/2009 09:27 Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests David, I am interested, but I will be unable to attend. - Kalman Black_David@emc.com Sent by: ips-bounces@ietf.org 12/03/2009 01:28 To , cc imss@ietf.org, Black_David@emc.com Subject [Ips] Storage Maintenance (storm) BOF reminder & requests 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 --=_alternative 00339DF2C2257577_= Content-Type: text/html; charset="US-ASCII" David,

For some reason I don't get the ips and rdma mailings.
I also interested but will not attend.

Thanks,
Julo


From: Kalman Meth/Haifa/IBM
To: Black_David@emc.com
Cc: Julian Satran/Haifa/IBM@IBMIL, "Chadalapaka, Mallikarjun B" <mallikarjun.chadalapaka@hp.com>
Date: 12/03/2009 09:27
Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests



David,
I am interested, but I will be unable to attend.

- Kalman





Black_David@emc.com
Sent by: ips-bounces@ietf.org

12/03/2009 01:28

To
<ips@ietf.org>, <rddp@ietf.org>
cc
imss@ietf.org, Black_David@emc.com
Subject
[Ips] Storage Maintenance (storm) BOF reminder & requests





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

--=_alternative 00339DF2C2257577_=-- From lars.eggert@nokia.com Thu Mar 12 02:35:48 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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 Cc: "imss@ietf.org" , "ips@ietf.org" , "rddp@ietf.org" Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 steph@cs.uchicago.edu Wed Mar 11 18:06:43 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF1928C15A for ; Wed, 11 Mar 2009 18:06: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 oFCphBuqOBgd for ; Wed, 11 Mar 2009 18:06:43 -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 292DC28C13D for ; Wed, 11 Mar 2009 18:06:43 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id S00Y1b00H0cQ2SLA516LHX; 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:06:12 -0700 Cc: imss@ietf.org, Black_David@emc.com Subject: Re: [Ips] [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 01:06: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 Frederick.Knight@netapp.com Thu Mar 12 08:25:08 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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:02:41 -0700 Cc: imss@ietf.org Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 18:13:51 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F05B3A6915 for ; Sat, 14 Mar 2009 18:13:51 -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 Ho-0ZQ1Y72Ho for ; Sat, 14 Mar 2009 18:13:50 -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 99DC63A6839 for ; Sat, 14 Mar 2009 18:13:50 -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 Cc: imss@ietf.org, Black_David@emc.com Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 01:13:51 -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 julian.satran@gmail.com Sun Mar 15 11:51:27 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3020D3A6960 for ; Sun, 15 Mar 2009 11:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 CIYHL6yamt+C for ; Sun, 15 Mar 2009 11:51:26 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 4D80E3A67E1 for ; Sun, 15 Mar 2009 11:51:26 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id f33so1323218fkf.5 for ; Sun, 15 Mar 2009 11:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; b=p3GbG5BnROX6jPyClvrm++K7QJuipW0iVhZW8PUpsw1NaE1nPm+HOEGSEVRm761XIR t57IzbAyHJC+qNWTDKyZnT7QcsosJg0d8qGY4BawkFIMy+bJVIILywUYEWf1LGWWev10 Cj1iZtHRpZ9pKcuhR5N+kkV9nZfZJZT+bX3og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=I/CH/sZzizMLrhcgWzQKx72gd/PAgRjWGGSrJqt0j1IhEk0lJ5rBegwR/56n3Yithm I+SGCcyho03m/yoKp8aO35Ek4oeRMdyeVHyGGReWtKkeHfHkYokrFar5rG5cEZCjZePi z54H4xjy1vfP9BmrXVA9cMU2g1+CL3GWigzXk= Received: by 10.103.189.15 with SMTP id r15mr1755665mup.126.1237143126523; Sun, 15 Mar 2009 11:52:06 -0700 (PDT) Received: from ?172.16.1.198? (bzq-84-109-49-106.red.bezeqint.net [84.109.49.106]) by mx.google.com with ESMTPS id 7sm8552008mup.49.2009.03.15.11.52.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 15 Mar 2009 11:52:06 -0700 (PDT) Message-Id: From: Julian Satran To: IPS List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 15 Mar 2009 20:51:42 +0200 X-Mailer: Apple Mail (2.930.3) Subject: [Ips] test subscription - sorry and please ignore X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2009 18:55:12 -0000 test From Jacob_Cherian@Dell.com Thu Mar 19 13:28:35 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4E13A6878 for ; Thu, 19 Mar 2009 13:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 JpV0EqU+o5v3 for ; Thu, 19 Mar 2009 13:28:34 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by core3.amsl.com (Postfix) with ESMTP id 58C383A6A61 for ; Thu, 19 Mar 2009 13:28:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9A8D1.5809E97B" Date: Thu, 19 Mar 2009 15:29:02 -0500 Message-ID: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE0255A7DA@ausx3mpc102.aus.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Valid Negotiation thread-index: Acmo0VeqNR70u5a6R0+s9cR7TbaCTg== From: To: X-OriginalArrivalTime: 19 Mar 2009 20:29:04.0646 (UTC) FILETIME=[58B1FA60:01C9A8D1] Subject: [Ips] Valid Negotiation X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 20:28:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9A8D1.5809E97B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I -> T : DefaultTime2Retain=3D2 T -> I : DefaultTime2Retain=3D5 I -> T : DefaultTime2Retain=3D5 Is this valid? ------_=_NextPart_001_01C9A8D1.5809E97B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Valid Negotiation

I   ->  T : =   DefaultTime2Retain=3D2

T  ->  I  : =   DefaultTime2Retain=3D5

I  ->  = T  :   = DefaultTime2Retain=3D5

Is this valid?

------_=_NextPart_001_01C9A8D1.5809E97B-- From kensandars@hotmail.com Thu Mar 19 17:43:29 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3540D3A690E for ; Thu, 19 Mar 2009 17:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZQ1TyAy4zNA for ; Thu, 19 Mar 2009 17:43:28 -0700 (PDT) Received: from col0-omc2-s13.col0.hotmail.com (col0-omc2-s13.col0.hotmail.com [65.55.34.87]) by core3.amsl.com (Postfix) with ESMTP id 4A3183A688C for ; Thu, 19 Mar 2009 17:43:28 -0700 (PDT) Received: from COL108-W62 ([65.55.34.73]) by col0-omc2-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Mar 2009 17:44:14 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_682ce4dc-258e-414c-861f-a3bd13bf2f96_" X-Originating-IP: [58.109.80.30] From: Ken Sandars To: , Date: Fri, 20 Mar 2009 11:44:14 +1100 Importance: Normal In-Reply-To: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE0255A7DA@ausx3mpc102.aus.amer.dell.com> References: <5DDAB7BA7BDB58439DD0EED0B8E9A3AE0255A7DA@ausx3mpc102.aus.amer.dell.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Mar 2009 00:44:14.0691 (UTC) FILETIME=[FE317330:01C9A8F4] Subject: Re: [Ips] Valid Negotiation X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 00:43:29 -0000 --_682ce4dc-258e-414c-861f-a3bd13bf2f96_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This sequence is invalid and both parties have issues. DefaultTime2Retain uses the Minimum function for negotiation=2C has admissible values 0..3600 and the default is 20 (RFC3720 section 12.16). The initiator's proposal is valid. The target MUST answer with a value in the range 0..2 since the proposed value is admissible (also refer RFC3720 section 5.2.2). Hence the answer outside this range is a protocol error. Alternatively it had the option to use "Reject" if it really wanted a value outside the proposed range. In that case the default value (20) becomes the negotiated value. The initiator is also in error. It should not have re-issued the KVP. One could wonder as to why it was only willing to accept a maximum of 2 seconds in its offer but is now happy to use 5 seconds! The correct action is to terminate the login since the target's response is a protocol error. Cheers=2C Ken Date: Thu=2C 19 Mar 2009 15:29:02 -0500 From: Jacob_Cherian@Dell.com To: ips@ietf.org Subject: [Ips] Valid Negotiation Valid Negotiation I -> T : DefaultTime2Retain=3D2 T -> I : DefaultTime2Retain=3D5 I -> T : DefaultTime2Retain=3D5 Is this valid? _________________________________________________________________ View photos of singles in your area. Click Here http://a.ninemsn.com.au/b.aspx?URL=3Dhttp%3A%2F%2Fdating%2Eninemsn%2Ecom%2E= au%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=3D773166080&_r=3DHotm= ail_Endtext&_m=3DEXT= --_682ce4dc-258e-414c-861f-a3bd13bf2f96_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This sequence is invalid and both parties have issues.

DefaultTime2R= etain uses the Minimum function for negotiation=2C
has admissible values= 0..3600 and the default is 20 (RFC3720
section 12.16). The initiator's = proposal is valid.

The target MUST answer with a value in the range = 0..2 since
the proposed value is admissible (also refer RFC3720 section<= br>5.2.2). Hence the answer outside this range is a protocol error.
Alte= rnatively it had the option to use "Reject" if it really wanted
a value = outside the proposed range. In that case the default
value (20) becomes = the negotiated value.

The initiator is also in error. It should not = have re-issued the
KVP. One could wonder as to why it was only willing t= o accept
a maximum of 2 seconds in its offer but is now happy to use
= 5 seconds! The correct action is to terminate the login since
the target= 's response is a protocol error.

Cheers=2C
Ken
Date: Thu=2C 19 Mar 2009 15:29:02 -0500
From: Jacob_Cherian@Del= l.com
To: ips@ietf.org
Subject: [Ips] Valid Negotiation

Valid Negotiation

I  =3B ->= =3B =3B<= font color=3D"#1f497d" face=3D"Calibri"> T : &= nbsp=3B =3BDefaultTime2Retain=3D2

T =3B ->= =3B =3B<= font color=3D"#1f497d" face=3D"Calibri"> I&nbs= p=3B =3B:  =3B =3BDefaultTime2Retain=3D5

I =3B ->=3B =3B T =3B : =3B =3B DefaultTime2Retain=3D5=

Is this valid?


Get what you wan= t at ebay. View photos of = singles in your area = --_682ce4dc-258e-414c-861f-a3bd13bf2f96_-- From rdr@iol.unh.edu Sun Mar 22 08:41:13 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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:27:17 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 15:58:31 -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: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM WG - draft charter X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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:04:37 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [Ips] [Junk released by Allow List] Re: [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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:04:37 -0700 Cc: "Robert D. Russell" , imss@ietf.org, ips@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: Re: [Ips] [rddp] [Junk released by Allow List] Re: Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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:04:37 -0700 Cc: imss@ietf.org, ips@ietf.org, rddp-bounces@ietf.org, Black_David@emc.com, rddp@ietf.org Subject: Re: [Ips] [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM BOF: Presentations posted X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 Paul_Koning@Dell.com Tue Mar 24 12:09:11 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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] Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [Ips] STORM WG - draft charter X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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] Cc: imss@ietf.org, ips@ietf.org, rddp@ietf.org Subject: Re: [Ips] STORM BOF: Presentations posted X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:11:29 -0000 David, On your slides: Page 7 mentions "CmdSN window size reduction". Could you elaborate? paul From Black_David@emc.com Tue Mar 24 13:27:17 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM WG - draft charter X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM BOF: Presentations posted X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 uri@broadcom.com Tue Mar 24 16:53:37 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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:28:16 -0700 Cc: "imss@ietf.org" Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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 nfd@zurich.ibm.com Wed Mar 25 09:56:51 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6BA3A6B45; Wed, 25 Mar 2009 09:56:51 -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 FnSb3UKDUKQL; Wed, 25 Mar 2009 09:56:50 -0700 (PDT) Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.17.162]) by core3.amsl.com (Postfix) with ESMTP id 390C73A67FD; Wed, 25 Mar 2009 09:56:49 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id n2PGvcsD022282; Wed, 25 Mar 2009 16:57:38 GMT Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2PGvb6J4112500; Wed, 25 Mar 2009 17:57:37 +0100 Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.13.1/8.13.3) with ESMTP id n2PGvbMX005156; Wed, 25 Mar 2009 17:57:37 +0100 Received: from d12mc302.megacenter.de.ibm.com (d12mc302.megacenter.de.ibm.com [9.149.170.82]) by d12av05.megacenter.de.ibm.com (8.13.1/8.12.11) with ESMTP id n2PGvbIT005153; Wed, 25 Mar 2009 17:57:37 +0100 In-Reply-To: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> To: Black_David@emc.com, rddp@ietf.org, ips@ietf.org MIME-Version: 1.0 X-KeepSent: E6A59B51:5C82116C-C1257584:00557D3C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 August 07, 2008 From: Fredy Neeser Message-ID: Date: Wed, 25 Mar 2009 17:57:35 +0100 X-MIMETrack: Serialize by Router on D12MC302/12/M/IBM(Release 8.0.1|February 07, 2008) at 25/03/2009 17:57:36, Serialize complete at 25/03/2009 17:57:36 Content-Type: multipart/alternative; boundary="=_alternative 005D29C5C1257584_=" X-Mailman-Approved-At: Thu, 26 Mar 2009 08:58:20 -0700 Subject: Re: [Ips] [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:56:51 -0000 This is a multipart message in MIME format. --=_alternative 005D29C5C1257584_= Content-Type: text/plain; charset="US-ASCII" David, All, While I am unfortunately unable to attend the BOF this week, I am interested in contributing to - RDDP MPA: Small startup update for MPI application support. preferably through your Option (C), the "virtual" working group. *** The interoperability of MPA-based RDMA connection management is still a concern - for MPI, NFS/RDMA and other apps. Because MPA has the (theoretically well-known) requirement that the first FPDU be sent from the RDMA initiator side, whereas InfiniBand has no such requirement, RDMA application writers tend to be caught by surprise when an application that violates this requirement works on InfiniBand but doesn't on iWARP. The so-called "peer-to-peer connection management" that was discussed in various flavours on the Linux OpenFabrics reflector for making RDMA connection management more uniform (among transports) and easier to use should be studied in detail. The solution should be flexible enough to allow an optimized application to avoid unnecessary additional round-trip delays. In addition, MPA's "delayed startup sequence" (a.k.a. delayed transition to RDMA mode or socket conversion) may need further clarification. For instance, the negotiation of connection parameters such as IRD and ORD should be clarified for cases where Private Data is not used in MPA Request/Reply. (IRD adjustment in RTS state is not mandatory according to the RDMAC Verbs, p. 74). *** Besides contributing to draft text, I am interested in early testing of the MPA startup update through a software implementation. Thanks, - Fredy ----------------------------------- Fredy Neeser, Research Staff Member IBM Zurich Research Laboratory Saeumerstrasse 4 CH-8803 Rueschlikon, Switzerland e-Mail: nfd@zurich.ibm.com Phone : +41 (0)44 724 8487 ----------------------------------- From: Black_David@emc.com To: , Cc: imss@ietf.org, Black_David@emc.com Date: 12.03.2009 00:29 Subject: [rddp] Storage Maintenance (storm) BOF reminder & requests Sent by: rddp-bounces@ietf.org 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 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www.ietf.org/mailman/listinfo/rddp --=_alternative 005D29C5C1257584_= Content-Type: text/html; charset="US-ASCII"
David, All,

While I am unfortunately unable to attend the BOF this week,
I am interested in contributing to

- RDDP MPA: Small startup update for MPI application support.

preferably through your Option (C), the "virtual" working group.

                                ***

The interoperability of MPA-based RDMA connection management
is still a concern - for MPI, NFS/RDMA and other apps.

Because MPA has the (theoretically well-known) requirement that
the first FPDU be sent from the RDMA initiator side, whereas
InfiniBand has no such requirement, RDMA application writers
tend to be caught by surprise when an application that violates
this requirement works on InfiniBand but doesn't on iWARP.

The so-called "peer-to-peer connection management" that was
discussed in various flavours on the Linux OpenFabrics
reflector for making RDMA connection management more uniform
(among transports) and easier to use should be studied in detail.
The solution should be flexible enough to allow an optimized
application to avoid unnecessary additional round-trip delays.

In addition, MPA's "delayed startup sequence" (a.k.a. delayed
transition to RDMA mode or socket conversion) may need further
clarification. For instance, the negotiation of connection
parameters such as IRD and ORD should be clarified for cases
where Private Data is not used in MPA Request/Reply.
(IRD adjustment in RTS state is not mandatory according
 to the RDMAC Verbs, p. 74).

                                ***

Besides contributing to draft text, I am interested in
early testing of the MPA startup update through a
software implementation.

Thanks,
- Fredy

-----------------------------------
Fredy Neeser, Research Staff Member
IBM Zurich Research Laboratory
Saeumerstrasse 4
CH-8803 Rueschlikon, Switzerland
e-Mail: nfd@zurich.ibm.com
Phone : +41 (0)44 724 8487
-----------------------------------



From: Black_David@emc.com
To: <ips@ietf.org>, <rddp@ietf.org>
Cc: imss@ietf.org, Black_David@emc.com
Date: 12.03.2009 00:29
Subject: [rddp] Storage Maintenance (storm) BOF reminder & requests
Sent by: rddp-bounces@ietf.org




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
----------------------------------------------------
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www.ietf.org/mailman/listinfo/rddp

--=_alternative 005D29C5C1257584_=-- From dave.b.minturn@intel.com Wed Mar 25 11:06:26 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD86328C136; Wed, 25 Mar 2009 11:06:26 -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 rHn9xk8m9OOb; Wed, 25 Mar 2009 11:06:26 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 18E5E28C135; Wed, 25 Mar 2009 11:06:25 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 25 Mar 2009 10:58:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,420,1233561600"; d="scan'208";a="675945237" Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87]) by fmsmga001.fm.intel.com with ESMTP; 25 Mar 2009 11:11:03 -0700 Received: from orsmsx001.amr.corp.intel.com (10.22.226.42) by orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 11:07:17 -0700 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx001.amr.corp.intel.com ([10.22.226.42]) with mapi; Wed, 25 Mar 2009 11:07:17 -0700 From: "Minturn, Dave B" To: "Black_David@emc.com" , "ips@ietf.org" , "rddp@ietf.org" Date: Wed, 25 Mar 2009 11:07:13 -0700 Thread-Topic: Storage Maintenance (storm) BOF reminder & requests Thread-Index: AcmioQqSkUT1te6rS+uCXVPIvobxAQK0bosw Message-ID: <4911F71203A09E4D9981D27F9D8308581CED2A15@orsmsx503.amr.corp.intel.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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 26 Mar 2009 08:58:20 -0700 Subject: Re: [Ips] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:06:27 -0000 David, Unfortunately, I will be unable to attend the BOF in person this week. I = am committing to contribute to the RDDP MPA start-up resolution for MPI bas= ed applications. The idea of doing this through a virtual working group vi= a email would be my preference. Thanks, Dave Minturn (503)712-4106 (W)=20 From felix@chelsio.com Wed Mar 25 23:46:27 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC613A6E00; Wed, 25 Mar 2009 23:46:27 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 kJrpCv3lo0AI; Wed, 25 Mar 2009 23:46:25 -0700 (PDT) Received: from stargate.chelsio.com (stargate.chelsio.com [12.22.49.110]) by core3.amsl.com (Postfix) with ESMTP id 7CB0D3A680C; Wed, 25 Mar 2009 23:46:25 -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 n2Q6lFQw030169; Wed, 25 Mar 2009 22:47:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9ADDE.D4715774" Date: Wed, 25 Mar 2009 23:45:30 -0700 Message-ID: <8A71B368A89016469F72CD08050AD33404D39FB4@maui.asicdesigners.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rddp] Storage Maintenance (storm) BOF reminder & requests Thread-Index: AcmtavVAOas6kqPjQ/O2nL1ZSuS/SAAcyO1g References: <9FA859626025B64FBC2AF149D97C944A01F736BA@CORPUSMX80A.corp.emc.com> From: "Felix Marti" To: "Fredy Neeser" , , , X-Mailman-Approved-At: Thu, 26 Mar 2009 08:58:20 -0700 Subject: Re: [Ips] [rddp] Storage Maintenance (storm) BOF reminder & requests X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:46:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9ADDE.D4715774 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 The same applies to me (unable to attend but interested in contributing). =20 Regards, felix =20 =20 From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Fredy Neeser Sent: Wednesday, March 25, 2009 9:58 AM To: Black_David@emc.com; rddp@ietf.org; ips@ietf.org Subject: [Junk released by Allow List] Re: [rddp] Storage Maintenance (storm) BOF reminder & requests =20 David, All,=20 While I am unfortunately unable to attend the BOF this week,=20 I am interested in contributing to=20 - RDDP MPA: Small startup update for MPI application support.=20 preferably through your Option (C), the "virtual" working group.=20 ***=20 The interoperability of MPA-based RDMA connection management=20 is still a concern - for MPI, NFS/RDMA and other apps.=20 Because MPA has the (theoretically well-known) requirement that=20 the first FPDU be sent from the RDMA initiator side, whereas=20 InfiniBand has no such requirement, RDMA application writers=20 tend to be caught by surprise when an application that violates=20 this requirement works on InfiniBand but doesn't on iWARP.=20 The so-called "peer-to-peer connection management" that was=20 discussed in various flavours on the Linux OpenFabrics=20 reflector for making RDMA connection management more uniform=20 (among transports) and easier to use should be studied in detail.=20 The solution should be flexible enough to allow an optimized=20 application to avoid unnecessary additional round-trip delays.=20 In addition, MPA's "delayed startup sequence" (a.k.a. delayed=20 transition to RDMA mode or socket conversion) may need further=20 clarification. For instance, the negotiation of connection=20 parameters such as IRD and ORD should be clarified for cases=20 where Private Data is not used in MPA Request/Reply.=20 (IRD adjustment in RTS state is not mandatory according=20 to the RDMAC Verbs, p. 74).=20 ***=20 Besides contributing to draft text, I am interested in=20 early testing of the MPA startup update through a=20 software implementation.=20 Thanks,=20 - Fredy=20 -----------------------------------=20 Fredy Neeser, Research Staff Member=20 IBM Zurich Research Laboratory=20 Saeumerstrasse 4=20 CH-8803 Rueschlikon, Switzerland e-Mail: nfd@zurich.ibm.com Phone : +41 (0)44 724 8487=20 -----------------------------------=20 From:=20 Black_David@emc.com=20 To:=20 , =20 Cc:=20 imss@ietf.org, Black_David@emc.com=20 Date:=20 12.03.2009 00:29=20 Subject:=20 [rddp] Storage Maintenance (storm) BOF reminder & requests=20 Sent by:=20 rddp-bounces@ietf.org =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 =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. 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 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www.ietf.org/mailman/listinfo/rddp =20 ------_=_NextPart_001_01C9ADDE.D4715774 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

The same applies to me (unable to attend but interested = in contributing).

 

Regards,

felix

 

 

From:= rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of = Fredy Neeser
Sent: Wednesday, March 25, 2009 9:58 AM
To: Black_David@emc.com; rddp@ietf.org; ips@ietf.org
Subject: [Junk released by Allow List] Re: [rddp] Storage = Maintenance (storm) BOF reminder & requests

 


David, All,

While I am unfortunately unable to = attend the BOF this week,
I am interested in contributing = to

- RDDP MPA: Small startup update = for MPI application support.

preferably through your Option (C), = the "virtual" working group.

          =                       = ***

The interoperability of MPA-based = RDMA connection management
is still a concern - for MPI, = NFS/RDMA and other apps.

Because MPA has the (theoretically well-known) requirement that
the first FPDU be sent from the = RDMA initiator side, whereas
InfiniBand has no such requirement, = RDMA application writers
tend to be caught by surprise when = an application that violates
this requirement works on = InfiniBand but doesn't on iWARP.

The so-called "peer-to-peer = connection management" that was
discussed in various flavours on = the Linux OpenFabrics
reflector for making RDMA = connection management more uniform
(among transports) and easier to = use should be studied in detail.
The solution should be flexible = enough to allow an optimized
application to avoid unnecessary = additional round-trip delays.

In addition, MPA's "delayed = startup sequence" (a.k.a. delayed
transition to RDMA mode or socket conversion) may need further
clarification. For instance, the = negotiation of connection
parameters such as IRD and ORD = should be clarified for cases
where Private Data is not used in = MPA Request/Reply.
(IRD adjustment in RTS state is not mandatory according
 to the RDMAC Verbs, p. = 74).

          =                       = ***

Besides contributing to draft text, = I am interested in
early testing of the MPA startup = update through a
software = implementation.

Thanks,
- Fredy

-----------------------------------
Fredy Neeser, Research Staff = Member
IBM Zurich Research = Laboratory
Saeumerstrasse 4
CH-8803 Rueschlikon, = Switzerland
e-Mail: nfd@zurich.ibm.com
Phone : +41 (0)44 724 8487
-----------------------------------


From:

Black_David@em= c.com

To:

<ips@ietf.o= rg>, <rddp@ietf.org>

Cc:

imss@ietf.org,= Black_David@emc.com

Date:

12.03.2009 00:29

Subject:

[rddp] Storage Maintenance (storm) BOF reminder & requests =

Sent by:

rddp-bounces@i= etf.org

 




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:
<= tt>http://www.ietf.org/mail-archive/web/ips/curre= nt/msg02669.html

The initial agenda is here:
<= tt>http://www.ietf.org/mail-archive/web/ips/curre= nt/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
----------------------------------------------------
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www.ietf.org/mailman/listinfo/rddp

------_=_NextPart_001_01C9ADDE.D4715774-- From Black_David@emc.com Thu Mar 26 21:56:59 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@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: [Ips] STORM BOF - Draft minutes X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage 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. From Black_David@emc.com Mon Mar 30 07:24:25 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFEC28C0EF for ; Mon, 30 Mar 2009 07:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 zQNdN0f53vjN for ; Mon, 30 Mar 2009 07:24:24 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7692C3A6B97 for ; Mon, 30 Mar 2009 07:24:24 -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 n2UEPL0i022597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Mar 2009 10:25: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-si01.isus.emc.com (Tablus Interceptor) for ; Mon, 30 Mar 2009 10:25:15 -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 n2UEPEHp017918 for ; Mon, 30 Mar 2009 10:25:15 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 10:25:12 -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, 30 Mar 2009 10:25:12 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A023F8427@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI-specific unit attention conditions Thread-Index: Acgq78Sj/fp6s3H2SpiLJatSdr0bxWGUT+yg To: X-OriginalArrivalTime: 30 Mar 2009 14:25:12.0574 (UTC) FILETIME=[564F69E0:01C9B143] X-EMM-EM: Active Subject: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 14:24:25 -0000 Here's another piece of "housekeeping" for the new STORM WG-to-be - I've been informed by a knowledgeable T10 participant that: > T10 proposal 05-406 (from Bill Galloway, Pivot3) added 3 > iSCSI-specific unit attention condition additional sense codes > in SPC-4: > - 3Fh/12h iSCSI IP ADDRESS ADDED > - 3Fh/13h iSCSI IP ADDRESS REMOVED > - 3Fh/14h iSCSI IP ADDRESS CHANGED >=20 > r0 used a more generic "DEVICE PORT ADDRESS" phrase, but r1 > changed that to "iSCSI IP ADDRESS" upon recommendation by the > [T10] CAP WG. >=20 > However, there is no mention in any standard of when these are > used (unlike all the other unit attention conditions, whose causes > are clearly defined). With the accepted names, that belongs in > iSCSI itself. =20 FWIW, these ASC/Q value pairs appear to have been added to SPC-4 without any cross-checking with the IETF, which would serve to explain why there is no documentation anywhere about when or how to use them. Since these ASC/Qs are iSCSI-specific, that task falls to the iSCSI specification(s), unless these ASC/Qs are removed or have their names changed to no longer be iSCSI-specific. Hence:=20 - the "new features" STORM draft should explain how to use these ASC/Qs --- AND/OR --- - discussion here and in the to-be-formed storm WG should generate a proposal to T10 about what should change and why. If these ASC/Q pairs remain and remain iSCSI-specific, they may be the first feature beyond SAM-4 that goes into the "new features" STORM draft. This situation was originally pointed out to me about a year ago, and there was some private discussion at that time. This is an opportunity for the participants in that discussion to express their views on what should be done and why (as we now have a vehicle to document their use with iSCSI *if* we choose to do so).=20 FYI, --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 Paul_Koning@Dell.com Mon Mar 30 08:38:15 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 040623A691E for ; Mon, 30 Mar 2009 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.832 X-Spam-Level: X-Spam-Status: No, score=-103.832 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_05=-1.11, 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 QByAv7upqY5a for ; Mon, 30 Mar 2009 08:38:14 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 411BC3A67B1 for ; Mon, 30 Mar 2009 08:38:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,446,1233554400"; d="scan'208";a="392774044" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 30 Mar 2009 10:39:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18896.59292.932521.584069@gargle.gargle.HOWL> Date: Mon, 30 Mar 2009 11:39:08 -0400 From: Paul Koning To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A023F8427@CORPUSMX80A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 30 Mar 2009 15:39:07.0682 (UTC) FILETIME=[A9D73020:01C9B14D] Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 15:38:15 -0000 I am somewhat puzzled by the notion of T10 defining iSCSI things. Did these things receive any discussion on the IPS list? If not, shouldn't that happen first? It seems to me that IPS should ask T10 for iSCSI related changes, not the other way around. And nothing should be added without a description of how it is supposed to be used. paul From Black_David@emc.com Mon Mar 30 09:34:57 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877ED3A6D3C for ; Mon, 30 Mar 2009 09:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 rKBE4MF3eFSm for ; Mon, 30 Mar 2009 09:34:56 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id AFC2C3A6D31 for ; Mon, 30 Mar 2009 09:34:56 -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 n2UGZqjk000977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2009 12:35:52 -0400 (EDT) From: Black_David@emc.com Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Mon, 30 Mar 2009 12:35:41 -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 n2UGZenc021633; Mon, 30 Mar 2009 12:35:40 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Mar 2009 12:35:39 -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, 30 Mar 2009 12:35:39 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A023F85CC@CORPUSMX80A.corp.emc.com> In-reply-to: <18896.59292.932521.584069@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: AcmxTbLTfeUBvOEwTwaJfQ0X6NU4UwABbZkA References: <9FA859626025B64FBC2AF149D97C944A023F8427@CORPUSMX80A.corp.emc.com> <18896.59292.932521.584069@gargle.gargle.HOWL> To: X-OriginalArrivalTime: 30 Mar 2009 16:35:39.0814 (UTC) FILETIME=[8FB57460:01C9B155] X-EMM-EM: Active Cc: ips@ietf.org, Black_David@emc.com Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 16:34:57 -0000 Paul, > I am somewhat puzzled by the notion of T10 defining iSCSI things. > Did these things receive any discussion on the IPS list? If not, > shouldn't that happen first? Not to my knowledge, and (IMHO) yes. The proposer of these ASC/Qs to T10 appears to have dropped the ball in that regard. In T10's defense, they do try to be accommodating, as there are SCSI transport-related conditions and errors that can only realistically be made visible as SCSI errors or unit attentions. =20 > It seems to me that IPS should ask T10 for iSCSI related changes, > not The other way around. And nothing should be added without a > description of how it is supposed to be used. I agree that this is how it should work, but these ASC/Qs seem to have slipped by and now need to be cleaned up one way or another. FWIW, there's one more iSCSI-specific ASC/Q: 47h 7Fh SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT This ASC/Q was added to deal with task side effects of some iSCSI error handling; use of this ASC/Q is documented in Sections 6.5 and 10.14.5 of RFC 3720. 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 Paul_Koning@Dell.com Tue Mar 31 11:55:49 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526833A6938 for ; Tue, 31 Mar 2009 11:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.104 X-Spam-Level: X-Spam-Status: No, score=-104.104 tagged_above=-999 required=5 tests=[AWL=-0.201, 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 6epF+xR34NAI for ; Tue, 31 Mar 2009 11:55:48 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 5EBCA3A6817 for ; Tue, 31 Mar 2009 11:55:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235973600"; d="scan'208";a="392931410" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 31 Mar 2009 13:56:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18898.26477.64898.577194@gargle.gargle.HOWL> Date: Tue, 31 Mar 2009 14:56:45 -0400 From: Paul Koning To: Black_David@emc.com References: <9FA859626025B64FBC2AF149D97C944A023F8427@CORPUSMX80A.corp.emc.com> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 31 Mar 2009 18:56:46.0008 (UTC) FILETIME=[705DE380:01C9B232] Cc: ips@ietf.org Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 18:55:49 -0000 >>>>> "Black" == Black David writes: Black> Here's another piece of "housekeeping" for the new STORM Black> WG-to-be - I've been informed by a knowledgeable T10 Black> participant that: >> T10 proposal 05-406 (from Bill Galloway, Pivot3) added 3 >> iSCSI-specific unit attention condition additional sense codes in >> SPC-4: - 3Fh/12h iSCSI IP ADDRESS ADDED - 3Fh/13h iSCSI IP ADDRESS >> REMOVED - 3Fh/14h iSCSI IP ADDRESS CHANGED >> >> r0 used a more generic "DEVICE PORT ADDRESS" phrase, but r1 >> changed that to "iSCSI IP ADDRESS" upon recommendation by the >> [T10] CAP WG. >> >> However, there is no mention in any standard of when these are >> used (unlike all the other unit attention conditions, whose causes >> are clearly defined). With the accepted names, that belongs in >> iSCSI itself. Black> FWIW, these ASC/Q value pairs appear to have been added to Black> SPC-4 without any cross-checking with the IETF, which would Black> serve to explain why there is no documentation anywhere about Black> when or how to use them. Since these ASC/Qs are Black> iSCSI-specific, that task falls to the iSCSI specification(s), Black> unless these ASC/Qs are removed or have their names changed to Black> no longer be iSCSI-specific. Black> Hence: - the "new features" STORM draft should explain how to Black> use these ASC/Qs --- AND/OR --- - discussion here and in the Black> to-be-formed storm WG should generate a proposal to T10 about Black> what should change and why. I would suggest the following. 1. The person advocating these ASC/Q codes should propose a new work item for STORM to add this new feature. It first needs to be added to the charter, then a new I-D needs to be generated to describe it. It doesn't belong in the other work items because it's neither cleanup nor (as far as I can tell) SAM-4 support. 2. If #1 isn't done or the proposal doesn't receive WG consensus, STORM should generate a liaison request to T10 asking for these ASC/Q codes to be removed, or deprecated, or otherwise relabeled to make it clear that they are not defined by the iSCSI standard. paul From Paul_Koning@Dell.com Tue Mar 31 12:31:33 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF763A6899 for ; Tue, 31 Mar 2009 12:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 BSX-qEMtQthX for ; Tue, 31 Mar 2009 12:31:33 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id C5D153A6817 for ; Tue, 31 Mar 2009 12:31:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,303,1235973600"; d="scan'208";a="392934856" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 31 Mar 2009 14:32:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18898.28621.87089.387064@gargle.gargle.HOWL> Date: Tue, 31 Mar 2009 15:32:29 -0400 From: Paul Koning To: Frederick.Knight@netapp.com References: <18898.26477.64898.577194@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-OriginalArrivalTime: 31 Mar 2009 19:32:30.0272 (UTC) FILETIME=[6E729C00:01C9B237] Cc: ips@ietf.org, Black_David@emc.com Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 19:31:33 -0000 >>>>> "Frederick" == Frederick Knight writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul From brown_David1@emc.com Tue Mar 31 13:11:12 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0CD3A69AE for ; Tue, 31 Mar 2009 13:11:12 -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 b96f5MfLNOEy for ; Tue, 31 Mar 2009 13:11:11 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F33993A6810 for ; Tue, 31 Mar 2009 13:11:10 -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 n2VKC7eL008612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Mar 2009 16:12:08 -0400 (EDT) From: brown_David1@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, 31 Mar 2009 16:12:04 -0400 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2VKC1ww003695; Tue, 31 Mar 2009 16:12:04 -0400 Received: from CORPUSMX60C.corp.emc.com ([10.254.64.72]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Mar 2009 16:12:01 -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, 31 Mar 2009 16:11:34 -0400 Message-ID: <11145F1B616CCD439BE1D34604A4AFEE39C889@CORPUSMX60C.corp.emc.com> In-Reply-To: <18898.28621.87089.387064@gargle.gargle.HOWL> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions thread-index: AcmyN3muVtch7cfqQ4mDSuvM/lOx5QAA7X3A References: <18898.26477.64898.577194@gargle.gargle.HOWL> <18898.28621.87089.387064@gargle.gargle.HOWL> To: , X-OriginalArrivalTime: 31 Mar 2009 20:12:01.0303 (UTC) FILETIME=[F3B13A70:01C9B23C] X-EMM-EM: Active Cc: ips@ietf.org, Black_David@emc.com Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 20:11:12 -0000 Maybe this is obvious to the T10 folks in the audience, but . . . Since these unit attentions use an ASC of 3F, they indicate a change to the operating state of the device. No commands are affected. From the concise wording of the 05-406 proposal, it's hard to be sure what the author intended, but it sounds to me like the target is telling the initiator about a change in the membership of the portal group. Might be caused by a configuration change, possibly by hot-plugging another network interface card into the target system.=20 DJ Brown -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Paul Koning Sent: Tuesday, March 31, 2009 3:32 PM To: Frederick.Knight@netapp.com Cc: ips@ietf.org; Black, David Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "Frederick" =3D=3D Frederick Knight writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips From Frederick.Knight@netapp.com Tue Mar 31 14:37:48 2009 Return-Path: X-Original-To: ips@core3.amsl.com Delivered-To: ips@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887543A676A for ; Tue, 31 Mar 2009 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 tIqKCqxlsXQx for ; Tue, 31 Mar 2009 14:37:47 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 6E4023A6997 for ; Tue, 31 Mar 2009 14:37:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,304,1235980800"; d="scan'208";a="148438000" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Mar 2009 14:38:46 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n2VLckVr028553; Tue, 31 Mar 2009 14:38:46 -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); Tue, 31 Mar 2009 14:38:46 -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); Tue, 31 Mar 2009 17:38:41 -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, 31 Mar 2009 17:38:12 -0400 Message-ID: In-Reply-To: <11145F1B616CCD439BE1D34604A4AFEE39C889@CORPUSMX60C.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI-specific unit attention conditions Thread-Index: AcmyN3muVtch7cfqQ4mDSuvM/lOx5QAA7X3AAACnQHA= From: "Knight, Frederick" To: , X-OriginalArrivalTime: 31 Mar 2009 21:38:41.0530 (UTC) FILETIME=[0F44E5A0:01C9B249] Cc: ips@ietf.org, Black_David@emc.com Subject: Re: [Ips] iSCSI-specific unit attention conditions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2009 21:37:48 -0000 "No commands are affected." The command which receives this response is NOT executed, and must be reissued by the initiator. True, no command other than the one that receives this response is affected. My guess from reading 05-406 is that the target is simply telling the initiator that it is time to reissue a SendTargets (redo discovery). My guess is that all 3 ASC/Qs would be handled by the host in the same way - something change (ala RSCN), so go find out what. I can't tell from the proposal why there needs to be 3 different reports (add/remove/change); it seems that "change" is really all that might be needed. So, it's possible my guess about the original intent is missing something. Fred=20 -----Original Message----- From: brown_David1@emc.com [mailto:brown_David1@emc.com]=20 Sent: Tuesday, March 31, 2009 4:12 PM To: Paul_Koning@dell.com; Knight, Frederick Cc: ips@ietf.org; Black_David@emc.com Subject: RE: [Ips] iSCSI-specific unit attention conditions Maybe this is obvious to the T10 folks in the audience, but . . . Since these unit attentions use an ASC of 3F, they indicate a change to the operating state of the device. No commands are affected. From the concise wording of the 05-406 proposal, it's hard to be sure what the author intended, but it sounds to me like the target is telling the initiator about a change in the membership of the portal group. Might be caused by a configuration change, possibly by hot-plugging another network interface card into the target system.=20 DJ Brown -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Paul Koning Sent: Tuesday, March 31, 2009 3:32 PM To: Frederick.Knight@netapp.com Cc: ips@ietf.org; Black, David Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "Frederick" =3D=3D Frederick Knight writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips