From ips-bounces@ietf.org Wed Feb 01 17:23:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4QNa-0007vd-40; Wed, 01 Feb 2006 17:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4QNY-0007u6-3z for ips@megatron.ietf.org; Wed, 01 Feb 2006 17:23:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18272 for ; Wed, 1 Feb 2006 17:21:28 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4QYj-0002ld-VO for ips@ietf.org; Wed, 01 Feb 2006 17:34:44 -0500 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k11MMjhQ018036 for ; Wed, 1 Feb 2006 17:22:45 -0500 (EST) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k11MMe9F025535 for ; Wed, 1 Feb 2006 17:22:41 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Feb 2006 17:22:39 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] iSCSI ACA - Implementers Guide (long, sorry) Date: Wed, 1 Feb 2006 17:22:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2006.02.01.134606 X-PerlMx-Spam: Gauge=%%XGAUGE%%, SPAM=%%PROB%%, Reasons='%%HITS%%' X-Spam-Score: 0.3 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Consolidating responses to Eddy and Bill. The most important piece of this message is the last paragraph (repeated here): ACA and multi-connection iSCSI sessions are a lousy fit. Would it be worth saying that ACA SHOULD NOT be used on multi-connection iSCSI sessions and initiators are responsible for dealing with the response ordering issues that arise when ACA is used on a multi-connection session? That would be mostly consistent with RFC 3720 and impose no ACA implementation burden on targets. Please comment. --- Eddy Quicksall wrote: > If the target is going to have wait for acknowledgement of all responses > outstanding on other connections then wouldn't it have to use a NOP-in to > solicit the next ExpStatSN? (because it can't be guaranteed that the > initiator will be sending another command). I don't see any big deal in the > but just thought it would be worth mentioning. Yes, that's definitely worth mentioning. > I would think that the delay mentioned would not be much of a concern > because this would only happen if there is a check condition followed by > recovery action in which case performance would be suffering anyway. > > Also I think that the delay we introduce with this proposal is consistent > with the sentence in SAM-2 you have mentioned. I agree with both of these thoughts. --- William Studenmund wrote: > > -- (1) The SCSI response indicating that CHECK CONDITION has > > caused establishment of ACA could get ahead of a response > > to a command completed prior to establishment of ACA. > Well, the first question that comes to my mind in these cases is what > does Fibre Channel do in these cases on a large SAN? Or what is FC > doing on SANs that are bridged over IP? :-) > > We shouldn't beat ourselves up to do stuff the FC doesn't. :-) Fibre Channel doesn't have multi-connection sessions, and hence these ACA-related reordering-across-connections problems don't arise. > I was going to suggest a bit of a tangent here by suggesting we pull in > a post-SAM-2 feature and add support for the Query Task Task Management > Function. However I think that that function only indicates if a task > is in the task set or not. Hmmm... Maybe that is enough. That's a separable item. At some point, someone will write the draft to update iSCSI to SAM-3 (backwards compatible - any incompatible behavior differences have to be negotiated), and QUERY TASK would be part of that. > I really have all of these delays we are building into the target. If > we are in a MC/S situation, shouldn't we expect the initiator > to carry some of the load? > > Put another way, if the initiator can't handle ACA cleanup, maybe it > shouldn't issue commands with NACA set. :-) The issue here is that multi-connection iSCSI sessions without target synchronization of responses add out-of-order response cases for ACA that a SCSI initiator isn't expecting. RFC 3720 says ACA is entirely a SCSI-layer issue. > I think it'd be fine for the ACA-status go through immediately as it > would tell the initiator that we have entered an error condition and it > should, for instance, immediately stop issuing commands to the target. > :-) It should also take steps to see what the outstanding status events > are on other connections. If the initiator SCSI code assumes the device is quiesced when the CHECK CONDITION arrives, the arrival of the successful completion for a command that the initiator thought was going to receive ACA ACTIVE could be confusing. The general risk here is that initiators may have catch-all cases in their logic where they resort to just resetting the misbehaving device, which is not a great idea for a tape device in the middle of a long backup. Does anyone have direct knowledge of initiators that use ACA for which this is a real concern? AIX is the usual suspect here. > The problem is that there is no way to indicate target status across > the whole session; status is a per-connection thing (which is usually > great!). > > The only other thing I can think of is to add a new async event > indicating we entered ACA and that all status messages with StatSN less > than this one were completed before the event. And issue that on every connection in the session for ACA? IMHO, it's probably better to wait for the status acks, issuing NOPs as needed to get them (as Eddy notes above). > > -- (2) An ACA ACTIVE status response could get ahead of the SCSI > > response that indicates establishment of ACA. > Is this issue really a special worry? > > As I understand SAM-2, this can always happen. In table 25, if QErr is > 00b and TST is 000b, some OTHER initiator triggering ACA can put our > port into ACA ("all enabled tasks from all SCSI initiator ports"). So > there may not even be a status event with the CHECK CONDITION on any of > our connections. Thus we can suddenly find ourselves in ACA. :-| Right, but what if they're not? Also, an initiator who reacts to this situation by retrying the task (on the assumption that the other initiator will get out of ACA eventually) is in for a surprise when the ACA turns out to be its own fault. I would hope the common case for ACA is single initiator devices or TST = 001b (task set per initiator), but I don't know. > > Between (1) and (2) it's probably a good idea to advise > > initiator implementers that the synchronous nature of ACA > > makes it a poor fit with the concurrency of multi-connection > > iSCSI sessions. > > Indeed. Consider the further wrinkle of a slow initiator (or slow > connections) in a QErr 00b/TST 000b scenario. Another initiator could > have cleared ACA and RETRIGGERED ACA before the one initiator could > have cleared it. :-) Again, I think ACA and TST = 000b (single task set for all initiators) are a lousy match for multi-initiator devices. That would also be worth saying in the implementers guide. > > -- (3) A command issued prior to establishment of ACA could > > arrive after ACA is established. > > For a command with the ACA attribute, the situation is less > > clear, courtesy of the text quoted from SAM-2 above. I talked > > with at least one other SCSI expert at T10 last week, and the > > two of us concur that this initiator behavior (initiator issues > > a command with the ACA attribute without knowing that ACA is > > in effect at the target) is questionable at best and probably > > wrong (and hence if the target unexpectedly executes the > > command because an ACA occurred, the initiator got what it > > deserved). > > I agree it's wrong and the initiator deserves to get its command > killed. :-) Good, although in this case, the ACA command is going to execute, and the initiator is at risk for a surprise when the target enters ACA for an unexpected reason, instead of reason the initiator anticipated when it issued the ACA command in advance. > > Comments? (and sorry for the length) > > I think this is a mess. For ACA to work well, it really needs the SCSI > world to be different than it is normally for iSCSI. :-( I think it's slightly more specific as noted above - ACA and multi-connection iSCSI sessions are a lousy fit. Would it be worth saying that ACA SHOULD NOT be used on multi-connection iSCSI sessions and initiators are responsible for dealing with the response ordering issues that arise when ACA is used on a multi-connection session? That would be mostly consistent with RFC 3720 and impose no ACA implementation burden on targets. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Feb 01 19:28:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4SKe-00044k-UA; Wed, 01 Feb 2006 19:28:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4SKc-00040Q-8Z for ips@megatron.ietf.org; Wed, 01 Feb 2006 19:28:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06020 for ; Wed, 1 Feb 2006 19:26:37 -0500 (EST) Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4SVt-00011M-0w for ips@ietf.org; Wed, 01 Feb 2006 19:39:53 -0500 Received: from [10.0.0.11] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 2E172870EE; Wed, 1 Feb 2006 19:28:01 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] iSCSI ACA - Implementers Guide (long, sorry) Date: Wed, 1 Feb 2006 16:27:58 -0800 To: Black_David@emc.com X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: 7bit Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org On Feb 1, 2006, at 2:22 PM, Black_David@emc.com wrote: > Consolidating responses to Eddy and Bill. The most important piece > of this message is the last paragraph (repeated here): > > ACA and multi-connection iSCSI sessions are a lousy fit. Would > it be worth saying that ACA SHOULD NOT be used on multi-connection > iSCSI sessions and initiators are responsible for dealing with > the response ordering issues that arise when ACA is used on > a multi-connection session? That would be mostly consistent > with RFC 3720 and impose no ACA implementation burden on > targets. > > Please comment. I like it. It means I don't have to do anything extreme. :-) > --- William Studenmund wrote: > >>> -- (1) The SCSI response indicating that CHECK CONDITION has >>> caused establishment of ACA could get ahead of a response >>> to a command completed prior to establishment of ACA. > >> Well, the first question that comes to my mind in these cases is what >> does Fibre Channel do in these cases on a large SAN? Or what is FC >> doing on SANs that are bridged over IP? :-) >> >> We shouldn't beat ourselves up to do stuff the FC doesn't. :-) > > Fibre Channel doesn't have multi-connection sessions, and hence these > ACA-related reordering-across-connections problems don't arise. Ok. >> I was going to suggest a bit of a tangent here by suggesting we >> pull in >> a post-SAM-2 feature and add support for the Query Task Task >> Management >> Function. However I think that that function only indicates if a task >> is in the task set or not. Hmmm... Maybe that is enough. > > That's a separable item. At some point, someone will write the > draft to > update iSCSI to SAM-3 (backwards compatible - any incompatible > behavior > differences have to be negotiated), and QUERY TASK would be part of > that. Sounds good. >> I really have all of these delays we are building into the target. If >> we are in a MC/S situation, shouldn't we expect the initiator >> to carry some of the load? >> >> Put another way, if the initiator can't handle ACA cleanup, maybe it >> shouldn't issue commands with NACA set. :-) > > The issue here is that multi-connection iSCSI sessions without > target synchronization of responses add out-of-order response cases > for ACA that a SCSI initiator isn't expecting. RFC 3720 says ACA > is entirely a SCSI-layer issue. Ahh... I was a bit sloppy. A better way to say this may be that an iSCSI initiator shouldn't accept CDBs with NACA set if it can't handle cleanup. :-) So should the (iSCSI) initiator complain if commands are issued with NACA set and we're in MC/S? >> The problem is that there is no way to indicate target status across >> the whole session; status is a per-connection thing (which is usually >> great!). >> >> The only other thing I can think of is to add a new async event >> indicating we entered ACA and that all status messages with StatSN >> less >> than this one were completed before the event. > > And issue that on every connection in the session for ACA? IMHO, it's > probably better to wait for the status acks, issuing NOPs as needed to > get them (as Eddy notes above). Yes, on every connection. My thought was that the special event would have the advantage that it immediately flags that something is going on. Also, once we get this event on all connections, we know we're done (modulo Status SNACKing). But just not using ACA in MC/S is easier. :-) >>> -- (2) An ACA ACTIVE status response could get ahead of the SCSI >>> response that indicates establishment of ACA. > >> Is this issue really a special worry? >> >> As I understand SAM-2, this can always happen. In table 25, if >> QErr is >> 00b and TST is 000b, some OTHER initiator triggering ACA can put our >> port into ACA ("all enabled tasks from all SCSI initiator ports"). So >> there may not even be a status event with the CHECK CONDITION on >> any of >> our connections. Thus we can suddenly find ourselves in ACA. :-| > > Right, but what if they're not? Also, an initiator who reacts to this > situation by retrying the task (on the assumption that the other > initiator > will get out of ACA eventually) is in for a surprise when the ACA > turns > out to be its own fault. I would hope the common case for ACA is > single > initiator devices or TST = 001b (task set per initiator), but I > don't know. I agree it really only makes sense in a single-initiator device (well, usage). At least as I understand why you want ACA, which was to be able to make tape command streams work right in face of EOT events. >>> Between (1) and (2) it's probably a good idea to advise >>> initiator implementers that the synchronous nature of ACA >>> makes it a poor fit with the concurrency of multi-connection >>> iSCSI sessions. >> >> Indeed. Consider the further wrinkle of a slow initiator (or slow >> connections) in a QErr 00b/TST 000b scenario. Another initiator could >> have cleared ACA and RETRIGGERED ACA before the one initiator could >> have cleared it. :-) > > Again, I think ACA and TST = 000b (single task set for all initiators) > are a lousy match for multi-initiator devices. That would also be > worth saying in the implementers guide. Ok. Agreed. >>> Comments? (and sorry for the length) >> >> I think this is a mess. For ACA to work well, it really needs the >> SCSI >> world to be different than it is normally for iSCSI. :-( > > I think it's slightly more specific as noted above - ACA and > multi-connection iSCSI sessions are a lousy fit. Would it be > worth saying that ACA SHOULD NOT be used on multi-connection > iSCSI sessions and initiators are responsible for dealing with > the response ordering issues that arise when ACA is used on > a multi-connection session? That would be mostly consistent > with RFC 3720 and impose no ACA implementation burden on > targets. As I make targets, I really like this idea. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Feb 01 21:40:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4UOU-0002B8-K2; Wed, 01 Feb 2006 21:40:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4UOS-00027o-70 for ips@megatron.ietf.org; Wed, 01 Feb 2006 21:40:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15719 for ; Wed, 1 Feb 2006 21:38:42 -0500 (EST) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4UZj-0005V4-NQ for ips@ietf.org; Wed, 01 Feb 2006 21:52:00 -0500 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 01 Feb 2006 18:40:06 -0800 X-IronPort-AV: i="4.01,245,1136188800"; d="txt'?scan'208"; a="355928793:sNHT27837132" Received: from [10.61.17.57] ([10.61.17.57]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k122e00C020750; Wed, 1 Feb 2006 18:40:05 -0800 (PST) Message-ID: <43E16E26.9040003@netapp.com> Date: Wed, 01 Feb 2006 21:27:50 -0500 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Content-Type: multipart/mixed; boundary="------------080503030708060908020902" X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Cc: ips@ietf.org Subject: [Ips] Submission of X#NodeArchitecture as Internet-Draft X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --------------080503030708060908020902 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi David, Per our conversation in San Jose, do you have any objections to my submitting version 00 of this document as an IPS WG Internet-Draft? I would like to submit very soon, as the March IETF meeting deadlines are quickly approaching (WG chair approval cutoff for v00 document submissions is Feb 20, and final deadline for v00 submissions is Feb 27). Thanks for your time. --------------080503030708060908020902 Content-Type: text/plain; name="draft-ietf-ips-xkey-iscsi-support-00r1.txt" Content-Disposition: inline; filename="draft-ietf-ips-xkey-iscsi-support-00r1.txt" Content-Transfer-Encoding: 7bit IP Storage Working Group Dave Wysochanski Internet-Draft Network Appliance, Inc Expires: July 1, 2006 February 1, 2006 Declarative Public Extension Key to Enhance iSCSI Supportability draft-ietf-ips-xkey-iscsi-support-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract RFC 3270 defines the iSCSI protocol and allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires July 1, 2006 [Page 1] Internet-Draft iSCSI Supportability February 2006 1. Introduction 1.1 Terminology The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 1.2 Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of RFC 3720 that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the evolving iSCSI market. The key has been modelled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of RFC 2616, with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of RFC 2616. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of RFC 3720. The following described Public Extension Key is sent during the login phase of an iSCSI normal session. It is important to note that the proper use of this key is to provide enhanced logging and support capabilities, and for better understanding of customer environments. The key MUST NOT be used by iSCSI nodes for things such as interoperability, performance, exclusion or deception of other nodes, or other uses not defined here. To enforce proper use, iSCSI nodes MUST NOT allow user modification of the key value(s), and SHOULD set the value automatically based on standard internal interfaces. Wysochanski Expires July 1, 2006 [Page 2] Internet-Draft iSCSI Supportability February 2006 2. Definition The definition of the proposed key is as follows, with example text-values conforming to section 5.1 of RFC 3720. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture="iscsi-vendor-software/1.2.3.4,os/1.2.3.4" X#NodeArchitecture="iscsi-vendor-hardware/1.2.3.4, iscsi-vendor-firmware/1.2.3.4, os/1.2.3.4,cpu-type-x,cpu-speed/2.0ghz" The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires July 1, 2006 [Page 3] Internet-Draft iSCSI Supportability February 2006 3. Security Considerations In certain environments where security is a primary concern, the use of this extension key may not be appropriate as it reveals specific details about an iSCSI node. For these environments, nodes implementing this public extension key SHOULD provide a method to disable sending the key. Wysochanski Expires July 1, 2006 [Page 4] Internet-Draft iSCSI Supportability February 2006 4. IANA Considerations This document serves as the specification for the iSCSI Extension Key NodeArchitecture. Wysochanski Expires July 1, 2006 [Page 5] Internet-Draft iSCSI Supportability February 2006 5. References 5.1 Normative References [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Wysochanski Expires July 1, 2006 [Page 6] Internet-Draft iSCSI Supportability February 2006 6. Author's Address Dave Wysochanski Network Appliance, Inc. 7301 Kit Creek Road P. O. Box 13917 Research Triangle, NC 27709 Phone: +1-919-476-5628 E-mail: davidw@netapp.com Wysochanski Expires July 1, 2006 [Page 7] Internet-Draft iSCSI Supportability February 2006 7. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, and John Forte. This document benefited from all these contributions. Wysochanski Expires July 1, 2006 [Page 8] Internet-Draft iSCSI Supportability February 2006 8. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wysochanski Expires July 1, 2006 [Page 9] Internet-Draft iSCSI Supportability February 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wysochanski Expires July 1, 2006 [Page 10] --------------080503030708060908020902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --------------080503030708060908020902-- From ips-bounces@ietf.org Thu Feb 02 14:58:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kb3-0007p9-JR; Thu, 02 Feb 2006 14:58:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kb1-0007oI-E9 for ips@megatron.ietf.org; Thu, 02 Feb 2006 14:58:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04327 for ; Thu, 2 Feb 2006 14:56:46 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4kmR-0000x1-KI for ips@ietf.org; Thu, 02 Feb 2006 15:10:12 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id k12JwAD4010013; Thu, 2 Feb 2006 14:58:10 -0500 (EST) Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k12JvvNn011720; Thu, 2 Feb 2006 14:57:59 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Feb 2006 14:57:41 -0500 Message-ID: To: davidw@netapp.com Date: Thu, 2 Feb 2006 14:57:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2006.02.02.110707 X-PerlMx-Spam: Gauge=, SPAM=4%, Reasons='EMC_BODY_1+ -1, EMC_FROM_0+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ips@ietf.org Subject: [Ips] RE: Submission of X#NodeArchitecture as Internet-Draft X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David, I prefer to see it as an individual submission that the WG can then choose to adopt or not. Please send it in as an individual submission (i.e., draft-wysochanski-...), and I'll make sure it's on the IPS agenda for March. Among the reasons for doing this is that it avoids putting the Area Director (i.e., my talking to her in her non-existent "copious spare time") in the critical path for you submitting the draft. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com] > Sent: Wednesday, February 01, 2006 9:28 PM > To: Black, David > Cc: ips@ietf.org > Subject: Submission of X#NodeArchitecture as Internet-Draft > > Hi David, > > Per our conversation in San Jose, do you have any objections to > my submitting version 00 of this document as an IPS WG > Internet-Draft? > > I would like to submit very soon, as the March IETF meeting > deadlines are quickly approaching (WG chair approval cutoff > for v00 document submissions is Feb 20, and final deadline > for v00 submissions is Feb 27). > > Thanks for your time. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Feb 02 19:34:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ouT-0008LX-HR; Thu, 02 Feb 2006 19:34:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ouS-0008I8-Nz for ips@megatron.ietf.org; Thu, 02 Feb 2006 19:34:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03910 for ; Thu, 2 Feb 2006 19:32:59 -0500 (EST) Received: from web51906.mail.yahoo.com ([206.190.48.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4p5m-0005Wq-4O for ips@ietf.org; Thu, 02 Feb 2006 19:46:28 -0500 Received: (qmail 25006 invoked by uid 60001); 3 Feb 2006 00:34:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CNrJ3oUtFrLaiFf9r42pFzc9Pt6l0q/PbWBygM57AEe3Yb41O5giyhj6RGWQQqcV5WrOBM1EFTOiSWtb6gn18yR8MF6DiaivrKDIUOlI80/menvx1MVnrqmZkPGZS7q8kTsOA0oGlpCvorGUpbDIs1OXwzRu8Bg6sDHYNkMhAbA= ; Message-ID: <20060203003423.25004.qmail@web51906.mail.yahoo.com> Received: from [156.153.255.236] by web51906.mail.yahoo.com via HTTP; Thu, 02 Feb 2006 16:34:22 PST Date: Thu, 2 Feb 2006 16:34:22 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] iSCSI ACA - Implementers Guide (long, sorry) To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e52c6009a9b39871b75233310d7f3490 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org David and all, It took me a while to think and consult with others on this topic - apologies for the delay (we are even, an almost equally long response follows). It concerns me that iSCSI layer (initiator or target) should make ordering decisions based on SCSI payload contents (e.g. ACA ACTIVE) defined outside of the iSCSI spec. I am concerned that such an approach leaves iSCSI having to continuously catch up with SCSI spec extensions, not to mention the layer-crossing issue and the unnecessary complexity in iSCSI layer. OTOH, I would like us to address the ACA issue cleanly for multi-connection iSCSI sessions from an architecture perspective so we don't have to keep coming back to this - essentially making it possible for implementations to fully support the feature. I also hope this can be minimally incremental in functionality terms relative to RFC3720 requirements. In short, I propose the following: SCSI protocol layer instructs the SCSI transport layer at the time of "Send Command Complete" protocol data service (SAM-2, clause 5.4.2) and "Task Management Function Executed" (SAM-2, clause 6.9) invocations of a "Response Fence" associated with the status in question. The Response Fence flag instructs the SCSI transport layer that the following two conditions must be met: (1) Response with Response Fence must chronologically be delivered after all the "preceding" responses on the I_T nexus whenever the preceding responses are delivered. (2) Response with Response Fence must chronologically be delivered before all the "following" responses on the I_T nexus whenever the following responses are delivered. Note that there is no new reliable delivery requirement here, nor is there a requirement to flush the transport connection - just that chronological delivery is mandatory for this status message. And how this chronological sequencing is ensured is really transport-specific - for a single channel FCP-based nexus, it is merely an uninteresting hint, whereas for a multi-connection iSCSI sesion, it triggers a flush of all connections. Why does this matter to iSCSI? iSCSI could use Response Fence when the Response Fence flag is set by the SCSI layer on the following SCSI completion messages handed down to the transport layer: (1) The first completion message carrying the UA after the multi-task abort on the issuing and third-party sessions (2) The TMF Response carrying the Abort Task Set/Clear Task Set reponse on the issuing session (3) The completion message indicating ACA establishment on the issuing session (4) The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions (5) The TMF Response carrying the Clear ACA response on the issuing session (6) Any other TBD SCSI response that SCSI architecture documents define in future. In all these cases with Response Fence, the target iSCSI layer does the following: a) If it is a single-connection session, no special processing is required. Standard SCSI Response PDU build process happens. b) If it is a multi-connection session, the target iSCSI layer takes note of last-sent and unaknowledged StatSN on each of the connections in the iSCSI session, and waits for acknowledgement (may solicit for acknowledgement by way of a Nop-In) of each such StatSN to clear the fence. All further status processing is resumed only after clearing the fence. Note that step-(b) above is already required for task set TMF responses by RFC 3720. The "Response Fence" notion genericizes such behavior for a class of messages flagged with "Response Fence" qualifier from the SCSI layer. Comments are welcome. Mallikarjun --- Black_David@emc.com wrote: > An Implementer working on ACA (Auto-Contingent > Allegiance) > has pointed out some issues that could use some > attention > in the implementers guide. The SCSI reference for > this is > Section 5.9.1 of SAM-2. NOTE: This message is not > written > in my role as WG Chair. > > A quick introduction is that ACA is an alternative > behavior > for error handling (CHECK CONDITION) to the more > familiar > behavior of CA (Contingent Allegiance) that is > immediately > exited via Autosense. ACA is requested on a per > command > basis via the NACA bit in the CDB. The Autosense > transmission > of sense data still occurs as a result of CHECK > CONDITION > (Autosense is required by iSCSI), but unlike CA, the > ACA > condition persists until it is cleared by a CLEAR > ACA task > management function. During ACA, the initiator uses > commands > with the ACA attribute (cf Section 10.3 of RFC 3720) > to > deal with the situation. One ACA command at a time > is > permitted, and non ACA commands are rejected with an > "ACA > ACTIVE" status. > > The change in command processing behavior when > entering ACA > raises a number of concurrency issues, as SAM-2 is > specified > as if the initiator and target interact > synchronously, which > is not the case for iSCSI. SAM-2 contains the > following > somewhat cryptic text in Section 5.9.1.2 whose > consequences > the implementers guide could help explain: > > If the SCSI transport protocol does not enforce > state > synchronization as described in 4.6.2, there may be > a > time delay between the occurrence of the CA or ACA > condition and the time at which the application > client > becomes aware of the condition. > > iSCSI does not enforce state synchronization. > Further, in a > multi-connection session, iSCSI does not support > status > sequencing (order of delivery of status/responses) > across > connections. So, for a multi-connection, session, > there are > (at least) 4 interesting potential concurrency > conditions: > > (1) The SCSI response indicating that CHECK > CONDITION has > caused establishment of ACA could get ahead of a > response > to a command completed prior to establishment of > ACA. > > (2) An ACA ACTIVE status response could get ahead of > the SCSI > response that indicates establishment of ACA. > > (3) A command issued prior to establishment of ACA > could > arrive after ACA is established. > > (4) The CLEAR ACA task management function could get > ahead of > a command that is dealing with the ACA condition. > > Here are some initial thoughts on how to deal with > these > situations: > > -- (1) The SCSI response indicating that CHECK > CONDITION has > caused establishment of ACA could get ahead of a > response > to a command completed prior to establishment of > ACA. > > This is only a concern in multi-connection sessions, > as in a > single-connection session, the response indicating > ACA > establishment will come after responses to all prior > commands. > This behavior can be preserved for multi-connection > sessions > by saying that the target MUST wait for > acknowledgement of all > responses outstanding on other connections at the > time of ACA > establishment before sending the response that > indicates ACA > has been established. This "MUST" would be an > additional > requirement to RFC 3720 for multi-connection > targets. > > This seems like a useful thing to require, as one of > the first > things an initiator will probably want to do on > learning > that ACA has happened is figure out what commands > completed > successfully prior to ACA (vs. are still at the > target, and > hence have been blocked by the ACA), and only the > target knows > what statuses are outstanding against the other > connections. > > OTOH, it causes delays, so the alternative is to > leave the > initiator to sort this out, which may entail issuing > NOPs > to determine command status on other connections. > That > would have the advantage of limiting the impact of > ACA > support to multi-connection initiators that actually > want > to use ACA, but the need to use the NOPs is > unpleasant, > leading me to favor having the target get this right > (initiators who don't like the resulting delay in > entering > ACA shouldn't use it). > > I don't think ignoring the issue causes any SCSI > specification > violations, but it may make ACA error handling > behave badly > as command completions will be unexpectedly received > during ACA. > > -- (2) An ACA ACTIVE status response could get ahead > of the SCSI > response that indicates establishment of ACA. > > Again, this is only a concern in multi-connection > sessions, as > in a single-connection session, ACA ACTIVE responses > will come > after the response indicating that ACA has been > entered. The > approach to this should probably match (1) - if the > target is > required to wait for outstanding responses on other > connections > in (1), we should require that the target MUST > receive > acknowledgement of the response indicating > establishment of ACA > before issuing any ACA ACTIVE status responses on > any connection > other than the one that response used. This "MUST" > would be an > additional requirement to RFC 3720 for > multi-connection targets. > > The resulting delay in issuing ACA ACTIVE responses > seems to be > less of a concern, as the initiator can figure out > what's > going to happen: > - Based on (1), the initiator has responses to the > completed > commands, > - Uncompleted commands prior to ExpCmdSN in the > response that > established ACA were delivered to SCSI and have > been > blocked by the ACA. > - All other commands will receive ACA ACTIVE status > responses, > as they were not delivered to SCSI when the ACA > occurred. > > If we don't require the wait in (1), initiator use > of NOP on > other connections will flush out delayed ACA ACTIVE > responses, > but still leave a multi-connection initiator who > wants to use > ACA with the surprise that ACA ACTIVE responses can > show up > before the response indicating that an ACA has > occurred. This > will result in a requirement on initiators to hold > ACA ACTIVE > status responses until the SCSI response indicating > that ACA > has occurred is delivered. This is an additional > requirement > to RFC 3720, and may require initiators to track > NACA on all > outstanding commands to determine whether an > Autosense response > caused ACA or not. This is probably better left to > SCSI. > > IMHO, something needs to be done here, as delivery > of an ACA > ACTIVE response to SCSI before the response > indicating ACA > establishment is pretty clearly wrong from a SCSI > perspective. > > Between (1) and (2) it's probably a good idea to > advise > initiator implementers that the synchronous nature > of ACA > makes it a poor fit with the concurrency of > multi-connection > iSCSI sessions. > > -- (3) A command issued prior to establishment of > ACA could > arrive after ACA is established. > > For a command without the ACA attribute, this is not > an issue - > such a command will be rejected with ACA ACTIVE > status if ACA > is in effect when it is due to be delivered to SCSI > at the > target. > > For a command with the ACA attribute, the situation > is less > clear, courtesy of the text quoted from SAM-2 above. > I talked > with at least one other SCSI expert at T10 last > week, and the > two of us concur that this initiator behavior > (initiator issues > a command with the ACA attribute without knowing > that ACA is > in effect at the target) is questionable at best and > probably > wrong (and hence if the target unexpectedly executes > the > command because an ACA occurred, the initiator got > what it > deserved). > > Hence I suggest guidance (for both single and > multi-connection > sessions) that an initiator SHOULD NOT issue > commands with the > ACA attribute unless it knows that ACA is in effect > at a target, > because targets will process all commands with the > ACA attribute > if they are received while ACA is in effect, > irrespective of > whether an initiator may have issued such a command > prior to > ACA being established. I believe this target > behavior is > permitted by the text quoted from SAM-2 above. This > is a > general SCSI matter, and is not a change from RFC > 3720. > > One of the reasons for taking this approach is that > determining > what ACA command to issue could well depend on what > went wrong > to cause the CHECK CONDITION in the first place, and > an > initiator that thinks it knows all the possible ways > in which a > target could get into a CHECK CONDITION is probably > kidding > itself in most cases. It's better in general to > wait for the > ACA, look at the sense data and figure out what to > do rather > than blindly fire an ACA command into the dark based > on a guess > about what will cause the ACA. > > -- (4) The CLEAR ACA task management function could > get ahead of > a command that is dealing with the ACA condition. > > The corresponding race for exiting ACA - issue CLEAR > ACA while a > command with the ACA attribute is outstanding - > seems less of a > concern. An initiator who has done this clearly > doesn't care > whether that command (and there can only be one) > executes or not. > > SAM-2 says that CLEAR ACA has the side effect of > aborting a task > with the ACA attribute. iSCSI's logical ordering of > command (and > task management function) delivery to SCSI at the > target ensures > that this abort side effect will take place, but > it's probably > worth pointing out that the ordering > responsibilities in Section > 10.5.1 apply to this situation: > - The target MUST wait for all tasks prior to the > CLEAR ACA > function to arrive in order to issue the ACA ACTIVE > response > (non ACA task) or abort them (ACA task). > - The initiator MUST NOT deliver responses from > affected > tasks (all tasks prior to the CLEAR ACA function) > to > SCSI after the response to CLEAR ACA is delivered. > An initiator that wishes to deal with ACA as > expeditiously as > possible should (lower case): > - Issue all commands with the ACA attribute as well > as the > CLEAR ACA task management function on the same > connection > as the SCSI response that indicated establishment > of ACA. > - Not issue any commands without the ACA attribute > prior to > the CLEAR ACA task management function. > > Comments? (and sorry for the length) > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Feb 02 19:48:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4p83-0003CT-ES; Thu, 02 Feb 2006 19:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4p82-0003Bu-0P for ips@megatron.ietf.org; Thu, 02 Feb 2006 19:48:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05383 for ; Thu, 2 Feb 2006 19:47:00 -0500 (EST) Received: from web51901.mail.yahoo.com ([206.190.48.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F4pJN-0006Be-GM for ips@ietf.org; Thu, 02 Feb 2006 20:00:30 -0500 Received: (qmail 68298 invoked by uid 60001); 3 Feb 2006 00:48:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0y9BMHjL9RmuO/l3dx2eLR58rVrYrhS1l0G5pkaA5zYdIgVGWeINBWRsxy40Nxld4E6QUTHEoOxLvEdDxy66WiIJQmU/4C1JLgt9dHfZ0xAPEEh4RCuCgrB9QD0vAY7cVHXUQj6KXZ1zrW4xVs4POGmeVAHv9M8tyFNRbbNOTXw= ; Message-ID: <20060203004828.68296.qmail@web51901.mail.yahoo.com> Received: from [156.153.255.243] by web51901.mail.yahoo.com via HTTP; Thu, 02 Feb 2006 16:48:28 PST Date: Thu, 2 Feb 2006 16:48:28 -0800 (PST) From: "Mallikarjun C." Subject: RE: [Ips] iSCSI ACA - Implementers Guide (long, sorry) To: ips@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Content-Transfer-Encoding: 8bit X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org >Would > it be worth saying that ACA SHOULD NOT be used on > multi-connection > iSCSI sessions and initiators are responsible for > dealing with > the response ordering issues that arise when ACA > is used on > a multi-connection session? That would be mostly > consistent > with RFC 3720 and impose no ACA implementation > burden on > targets. Agree that SHOULD NOT would be a fair requirement for RFC3720-compliant targets (because the spec never called this case out as it did for task set TMF responses). For iSCSI targets compliant with the Implementer's guide RFC though (well, when it's eventually published as an RFC), I think we should define an interface abstraction for targets to cleanly support it (please see my other long note). Once this is covered in the implementer's guide, we can simply warn initiator implementers about the slow-nature of ACA with multi-connection sessions and leave it at that. In short, IMHO, SHOULD NOT would be fine for 3720-compliant implementations, but not for "future-compliant" implementations - particularly when the response flushing/ordering mechanics are already required to be implemented per RFC 3720 for a different PDU type. BTW, I will be traveling for the next 10 days without email access - starting this Friday. So please excuse my delayed responses. Thanks. Mallikarjun --- Black_David@emc.com wrote: > Consolidating responses to Eddy and Bill. The most > important piece > of this message is the last paragraph (repeated > here): > > ACA and multi-connection iSCSI sessions are a > lousy fit. Would > it be worth saying that ACA SHOULD NOT be used on > multi-connection > iSCSI sessions and initiators are responsible for > dealing with > the response ordering issues that arise when ACA > is used on > a multi-connection session? That would be mostly > consistent > with RFC 3720 and impose no ACA implementation > burden on > targets. > > Please comment. > > --- Eddy Quicksall wrote: > > > If the target is going to have wait for > acknowledgement of all responses > > outstanding on other connections then wouldn't it > have to use a NOP-in to > > > solicit the next ExpStatSN? (because it can't be > guaranteed that the > > initiator will be sending another command). I > don't see any big deal in > the > > but just thought it would be worth mentioning. > > Yes, that's definitely worth mentioning. > > > I would think that the delay mentioned would not > be much of a concern > > because this would only happen if there is a check > condition followed by > > recovery action in which case performance would be > suffering anyway. > > > > Also I think that the delay we introduce with this > proposal is consistent > > with the sentence in SAM-2 you have mentioned. > > I agree with both of these thoughts. > > --- William Studenmund wrote: > > > > -- (1) The SCSI response indicating that CHECK > CONDITION has > > > caused establishment of ACA could get ahead of > a response > > > to a command completed prior to establishment > of ACA. > > > Well, the first question that comes to my mind in > these cases is what > > does Fibre Channel do in these cases on a large > SAN? Or what is FC > > doing on SANs that are bridged over IP? :-) > > > > We shouldn't beat ourselves up to do stuff the FC > doesn't. :-) > > Fibre Channel doesn't have multi-connection > sessions, and hence these > ACA-related reordering-across-connections problems > don't arise. > > > I was going to suggest a bit of a tangent here by > suggesting we pull in > > a post-SAM-2 feature and add support for the Query > Task Task Management > > Function. However I think that that function only > indicates if a task > > is in the task set or not. Hmmm... Maybe that is > enough. > > That's a separable item. At some point, someone > will write the draft to > update iSCSI to SAM-3 (backwards compatible - any > incompatible behavior > differences have to be negotiated), and QUERY TASK > would be part of that. > > > I really have all of these delays we are building > into the target. If > > we are in a MC/S situation, shouldn't we expect > the initiator > > to carry some of the load? > > > > Put another way, if the initiator can't handle ACA > cleanup, maybe it > > shouldn't issue commands with NACA set. :-) > > The issue here is that multi-connection iSCSI > sessions without > target synchronization of responses add out-of-order > response cases > for ACA that a SCSI initiator isn't expecting. RFC > 3720 says ACA > is entirely a SCSI-layer issue. > > > I think it'd be fine for the ACA-status go through > immediately as it > > would tell the initiator that we have entered an > error condition and it > > should, for instance, immediately stop issuing > commands to the target. > > :-) It should also take steps to see what the > outstanding status events > > are on other connections. > > If the initiator SCSI code assumes the device is > quiesced when the > CHECK CONDITION arrives, the arrival of the > successful completion for > a command that the initiator thought was going to > receive ACA ACTIVE > could be confusing. The general risk here is that > initiators may have > catch-all cases in their logic where they resort to > just resetting > the misbehaving device, which is not a great idea > for a tape device > in the middle of a long backup. Does anyone have > direct knowledge > of initiators that use ACA for which this is a real > concern? AIX > is the usual suspect here. > > > The problem is that there is no way to indicate > target status across > > the whole session; status is a per-connection > thing (which is usually > > great!). > > > > The only other thing I can think of is to add a > new async event > > indicating we entered ACA and that all status > messages with StatSN less > > than this one were completed before the event. > > And issue that on every connection in the session > for ACA? IMHO, it's > probably better to wait for the status acks, issuing > NOPs as needed to > get them (as Eddy notes above). > > > > -- (2) An ACA ACTIVE status response could get > ahead of the SCSI > > > response that indicates establishment of ACA. > > > Is this issue really a special worry? > > > > As I understand SAM-2, this can always happen. In > table 25, if QErr is > > 00b and TST is 000b, some OTHER initiator > triggering ACA can put our > > port into ACA ("all enabled tasks from all SCSI > initiator ports"). So > > there may not even be a status event with the > CHECK CONDITION on any of > > our connections. Thus we can suddenly find > ourselves in ACA. :-| > > Right, but what if they're not? Also, an initiator > who reacts to this > situation by retrying the task (on the assumption > that the other initiator > will get out of ACA eventually) is in for a surprise > when the ACA turns > out to be its own fault. I would hope the common > case for ACA is single > initiator devices or TST = 001b (task set per > initiator), but I don't know. > > > > Between (1) and (2) it's probably a good idea to > advise > > > initiator implementers that the synchronous > nature of ACA > > > makes it a poor fit with the concurrency of > multi-connection > > > iSCSI sessions. > > > > Indeed. Consider the further wrinkle of a slow > initiator (or slow > > connections) in a QErr 00b/TST 000b scenario. > Another initiator could > > have cleared ACA and RETRIGGERED ACA before the > one initiator could > > have cleared it. :-) > > Again, I think ACA and TST = 000b (single task set > for all initiators) > are a lousy match for multi-initiator devices. That > would also be > worth saying in the implementers guide. > > > > -- (3) A command issued prior to establishment > of ACA could > > > arrive after ACA is established. > > > > For a command with the ACA attribute, the > situation is less > > > clear, courtesy of the text quoted from SAM-2 > above. I talked > > > with at least one other SCSI expert at T10 last > week, and the > > > two of us concur that this initiator behavior > (initiator issues > > > a command with the ACA attribute without knowing > that ACA is > > > in effect at the target) is questionable at best > and probably > > > wrong (and hence if the target unexpectedly > executes the > > > command because an ACA occurred, the initiator > got what it > > > deserved). > > > > I agree it's wrong and the initiator deserves to > get its command > > killed. :-) > > Good, although in this case, the ACA command is > going to execute, and > the initiator is at risk for a surprise when the > target enters ACA > for an unexpected reason, instead of reason the > initiator anticipated > when it issued the ACA command in advance. > > > > Comments? (and sorry for the length) > > > > I think this is a mess. For ACA to work well, it > really needs the SCSI > > world to be different than it is normally for > iSCSI. :-( > > I think it's slightly more specific as noted above - > ACA and > multi-connection iSCSI sessions are a lousy fit. > Would it be > worth saying that ACA SHOULD NOT be used on > multi-connection > iSCSI sessions and initiators are responsible for > dealing with > the response ordering issues that arise when ACA is > used on > a multi-connection session? That would be mostly > consistent > with RFC 3720 and impose no ACA implementation > burden on > targets. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Feb 02 20:26:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4pix-0007X6-L0; Thu, 02 Feb 2006 20:26:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4piw-0007W6-E4 for ips@megatron.ietf.org; Thu, 02 Feb 2006 20:26:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08441 for ; Thu, 2 Feb 2006 20:25:06 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4puE-0007d4-Im for ips@ietf.org; Thu, 02 Feb 2006 20:38:35 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id k131QXD4005072 for ; Thu, 2 Feb 2006 20:26:33 -0500 (EST) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k131QU8l008258 for ; Thu, 2 Feb 2006 20:26:31 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Feb 2006 20:26:30 -0500 Message-ID: To: ips@ietf.org Date: Thu, 2 Feb 2006 20:26:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2006.02.02.164605 X-PerlMx-Spam: Gauge=, SPAM=4%, Reasons='EMC_BODY_1+ -1, EMC_FROM_0+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ips] ips WG *will* meet in Dallas X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IP Storage WG will meet in Dallas at the IETF meetings during the week of March 19th. The topics I know about for the agenda are: - iSCSI Implementers Guide (anything and everything) - David Wysochanski's forthcoming iSCSI X# key draft Any remaining time will be used to start a very preliminary discussion of what to do about the IETF Security Area's request that plans be made to eliminate all uses of MD5 from IETF protocols in the not-too-distant future. Anyone else who wants agenda time should to send me email with a topic, Internet-Draft name and time estimate. NOTE: Before anyone gets excited, there is no reason to believe that iSCSI has any security issues courtesy of its use of MD5 (e.g., CHAP is ok as there is no indication that anyone is close to inverting MD5), with the possible exception of MD5 in certificate signatures for IPsec (don't do that - at least use SHA-1), which is an issue for the pkix WG to address. This is about good engineering practice (MD5 has known flaws, it will only get worse, not better, so it's time to think about migrating to sounder technology). Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Feb 03 10:45:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F537x-00058t-H4; Fri, 03 Feb 2006 10:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F537q-00057p-Sn; Fri, 03 Feb 2006 10:45:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11941; Fri, 3 Feb 2006 10:43:52 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F53JS-0007dE-Pl; Fri, 03 Feb 2006 10:57:30 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F537n-0003Qt-Oc; Fri, 03 Feb 2006 10:45:27 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 03 Feb 2006 10:45:27 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Definition of Managed Objects for SCSI Entities' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Definition of Managed Objects for SCSI Entities ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-scsi-mib-09.txt Technical Summary This specification defines a set of managed objects to configure and monitor Small Computer System Interface entities (SCSI entities), i.e. SCSI Target Devices and SCSI Initiator Devices and SCSI Ports. SCSI is a client-server protocol in which application clients within a SCSI initiator device (client) issue service requests to logical units contained in a SCSI target device(server). Working Group Summary This working group was chartered to work on SCSI over TCP-IP (iSCSI), but it was determined (with reflection in the charter) that it was also the right group to work on and review the SCSI MIB. There was no controversy on this MIB. There was some active discussion and review when the WG handled the MIB, which was some time ago, due to delay in availability of a slot for a MIB Doctor Review. Protocol Quality Bert Wijnen was the MIB Doctor for the IESG. This MIB was also very carefully reviewed by the ANSI T10 Committee, which is responsible for the SCSI specifications. The Area Director has been told of implementations. Note to the RFC Editor Please delete from Section 14.1, Normative References, this one is not cited/required for implementing the MIB: [X3T10] X3T10/97-101, "IEEE Tutorial for SCSI use of IEEE company_id", X3T10 Revision 2, February 1997, . _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Feb 03 14:58:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F574o-0002Dv-FD; Fri, 03 Feb 2006 14:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F574n-0002Dd-44 for ips@megatron.ietf.org; Fri, 03 Feb 2006 14:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05129 for ; Fri, 3 Feb 2006 14:56:59 -0500 (EST) From: Black_David@emc.com Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F57GR-0001rP-2O for ips@ietf.org; Fri, 03 Feb 2006 15:10:39 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id k13JwND4021946 for ; Fri, 3 Feb 2006 14:58:23 -0500 (EST) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k13JwKbV005660 for ; Fri, 3 Feb 2006 14:58:21 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Feb 2006 14:58:19 -0500 Message-ID: To: ips@ietf.org Subject: RE: [Ips] ips WG *will* meet in Dallas Date: Fri, 3 Feb 2006 14:58:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2006.02.03.112605 X-PerlMx-Spam: Gauge=, SPAM=4%, Reasons='EMC_BODY_1+ -1, EMC_FROM_0+ -0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org Oops, forgot an agenda item for Dallas: - iSNS MIB (discussion of newly reduced functionality scope). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > Behalf Of Black, David > Sent: Thursday, February 02, 2006 8:26 PM > To: ips@ietf.org > Subject: [Ips] ips WG *will* meet in Dallas > > The IP Storage WG will meet in Dallas at the IETF meetings > during the week of March 19th. The topics I know about > for the agenda are: > - iSCSI Implementers Guide (anything and everything) > - David Wysochanski's forthcoming iSCSI X# key draft > > Any remaining time will be used to start a very preliminary > discussion of what to do about the IETF Security Area's request > that plans be made to eliminate all uses of MD5 from IETF > protocols in the not-too-distant future. Anyone else who > wants agenda time should to send me email with a topic, > Internet-Draft name and time estimate. > > NOTE: Before anyone gets excited, there is no reason to > believe that iSCSI has any security issues courtesy of > its use of MD5 (e.g., CHAP is ok as there is no indication > that anyone is close to inverting MD5), with the possible > exception of MD5 in certificate signatures for IPsec (don't > do that - at least use SHA-1), which is an issue for the > pkix WG to address. This is about good engineering practice > (MD5 has known flaws, it will only get worse, not better, > so it's time to think about migrating to sounder technology). > > Thanks, > --David (ips WG chair) > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Feb 03 17:30:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59S4-0004Iq-N6; Fri, 03 Feb 2006 17:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F59S1-0004IK-MY; Fri, 03 Feb 2006 17:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22088; Fri, 3 Feb 2006 17:29:05 -0500 (EST) Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F59de-0001gj-AI; Fri, 03 Feb 2006 17:42:47 -0500 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 03 Feb 2006 14:30:26 -0800 X-IronPort-AV: i="4.02,85,1139212800"; d="txt'?scan'208"; a="356354780:sNHT22954560" Received: from [10.61.17.57] ([10.61.17.57]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k13MUO5F011589; Fri, 3 Feb 2006 14:30:25 -0800 (PST) Message-ID: <43E3D697.70308@netapp.com> Date: Fri, 03 Feb 2006 17:17:59 -0500 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org Content-Type: multipart/mixed; boundary="------------040705060008060609070403" X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: ips@ietf.org, Black_David@emc.com Subject: [Ips] iSCSI extension key to enhance supportability X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --------------040705060008060609070403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I submit the attached Internet-Draft for the March IETF meeting in Dallas. Please note that I have already been in contact with the IP Storage WG, and WG chair David Black has put this item on the agenda for that meeting. Thanks, Dave Wysochanski --------------040705060008060609070403 Content-Type: text/plain; name="draft-wysochanski-xkey-iscsi-support-00.txt" Content-Disposition: inline; filename="draft-wysochanski-xkey-iscsi-support-00.txt" Content-Transfer-Encoding: 7bit INTERNET-DRAFT Dave Wysochanski Expires: August 3, 2006 Network Appliance, Inc February 3, 2006 Declarative Public Extension Key to Enhance iSCSI Supportability draft-wysochanski-xkey-iscsi-support-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract RFC 3270 defines the iSCSI protocol and allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Wysochanski Expires August 3, 2006 [Page 1] Internet-Draft iSCSI Supportability February 2006 1. Introduction 1.1 Terminology The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 1.2 Overview This Internet-Draft describes a declarative Public Extension Key as defined by section 12.22 of RFC 3720 that may be used to communicate additional iSCSI node information to the opposite node in a session. The information carried in the described key has been found to be valuable in real iSCSI customer environments as initiator and target vendors collaborate to resolve technical issues and better understand the evolving iSCSI market. The key has been modelled after the "Server" and "User-Agent" header fields as specified in sections 14.38 and 14.43 of RFC 2616, with the text-value(s) of the key roughly equivalent to Product Tokens in section 3.8 of RFC 2616. Note however that the text-value(s) in the keys list-of-values MUST conform to the Text Format as specified in section 5.1 of RFC 3720. The following described Public Extension Key is sent during the login phase of an iSCSI normal session. It is important to note that the proper use of this key is to provide enhanced logging and support capabilities, and for better understanding of customer environments. The key MUST NOT be used by iSCSI nodes for things such as interoperability, performance, exclusion or deception of other nodes, or other uses not defined here. To enforce proper use, iSCSI nodes MUST NOT allow user modification of the key value(s), and SHOULD set the value automatically based on standard internal interfaces. Wysochanski Expires August 3, 2006 [Page 2] Internet-Draft iSCSI Supportability February 2006 2. Definition The definition of extension the key is as follows, with example list-of-values conforming to section 5.1 of RFC 3720. X#NodeArchitecture Use: LO, Declarative Senders: Initiator and Target Scope: SW X#NodeArchitecture= Examples: X#NodeArchitecture="iscsi-vendor-software/1.2.3.4,os/1.2.3.4" X#NodeArchitecture="iscsi-vendor-hardware/1.2.3.4, iscsi-vendor-firmware/1.2.3.4, os/1.2.3.4,cpu-type-x,cpu-speed/2.0ghz" The initiator or target declares the details of its iSCSI node architecture to the remote endpoint. These details may include, but are not limited to, iSCSI vendor software, firmware, or hardware versions, the OS version, or hardware architecture. X#NodeArchitecture MUST NOT be redeclared. Wysochanski Expires August 3, 2006 [Page 3] Internet-Draft iSCSI Supportability February 2006 3. Security Considerations In certain environments where security is a primary concern, the use of this extension key may not be appropriate as it reveals specific details about an iSCSI node. For these environments, nodes implementing this public extension key SHOULD provide a method to disable sending the key. Wysochanski Expires August 3, 2006 [Page 4] Internet-Draft iSCSI Supportability February 2006 4. IANA Considerations This document defines the iSCSI Extension Key NodeArchitecture to be registered in the IANA iSCSI extended key registry. Wysochanski Expires August 3, 2006 [Page 5] Internet-Draft iSCSI Supportability February 2006 5. References 5.1 Normative References [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs.", BCP 26, RFC 2434, October 1998. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. 5.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Wysochanski Expires August 3, 2006 [Page 6] Internet-Draft iSCSI Supportability February 2006 6. Author's Address Dave Wysochanski Network Appliance, Inc. 7301 Kit Creek Road P. O. Box 13917 Research Triangle, NC 27709 Phone: +1-919-476-5628 E-mail: davidw@netapp.com Wysochanski Expires August 3, 2006 [Page 7] Internet-Draft iSCSI Supportability February 2006 7. Acknowledgements The IP Storage (ips) Working Group in the Transport Area of IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group. The following individuals directly contributed to identifying issues and/or suggesting resolutions to the issues found in this document: David Black, Paul Koning, Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, and John Forte. This document benefited from all these contributions. Wysochanski Expires August 3, 2006 [Page 8] Internet-Draft iSCSI Supportability February 2006 8. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wysochanski Expires August 3, 2006 [Page 9] Internet-Draft iSCSI Supportability February 2006 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Wysochanski Expires August 3, 2006 [Page 10] --------------040705060008060609070403 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --------------040705060008060609070403-- From ips-bounces@ietf.org Tue Feb 07 20:33:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6eDG-00023z-M2; Tue, 07 Feb 2006 20:33:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6eDC-00021J-Jg for ips@megatron.ietf.org; Tue, 07 Feb 2006 20:33:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28718 for ; Tue, 7 Feb 2006 20:31:54 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ePe-0002ad-Kx for ips@ietf.org; Tue, 07 Feb 2006 20:46:31 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k181XPsK025250; Tue, 7 Feb 2006 19:33:25 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Feb 2006 02:33:24 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509433846@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: mbakke@cisco.com, james.muchow@qlogic.com Date: Wed, 8 Feb 2006 02:33:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ips@ietf.org, "'Black_David@emc.com'" , "'mankin@psg.com'" Subject: [Ips] MIB Doctor review for: draft-ietf-ips-auth-mib-07.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org I think this doc is basically ready for IETF Last Call. I have some comments here that you can either address before an IETF Last Call, or you can consider them as initial IETF Last Call comments: - I think it would be good to explain in the IpsAuthAddress textual convention how the format of the address is to be determined. - REVISION "200510180000Z" -- October 18, 2005 DESCRIPTION "Initial version of the IP Storage Authentication MIB module" I would add: Published as RFC xxxx" --- RFCeditor pls fill in xxxx - I see that in the DESCRIPTION clauses of objects with SYNTAX StorageType there is no text about which (if any) writable columns MUST be writable for permanent objects. RFC2579 tells you that such is needed. - I see that in the DESCRIPTION clauses of objects with SYNTAX Rowstatus there is not text explaining which (if any) writable columns can be changed while the row is active. Neither do I see it specified on the writable objects themselves. - I wonder if the Security Considerations is sufficient for the Security ADs. Recently we have had some MIB documents with DISCUSSes because of a similar (all tables xxx have vulnerabilities of...) instead instead of listing each object and why it is vulnerable. I would personally also like a stronger warning that probably for both read and write operations it is best to ue encryption, no? Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Feb 08 12:45:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tNJ-000879-QM; Wed, 08 Feb 2006 12:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tN0-0007yC-CS; Wed, 08 Feb 2006 12:44:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14103; Wed, 8 Feb 2006 12:43:05 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6tZe-0005vh-8A; Wed, 08 Feb 2006 12:57:50 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6tMz-0005Gn-MA; Wed, 08 Feb 2006 12:44:45 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Feb 2006 12:44:45 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ips@ietf.org Subject: [Ips] Last Call: 'Definitions of Managed Objects for User Identity Authorization' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has received a request from the IP Storage WG to consider the following document: - 'Definitions of Managed Objects for User Identity Authorization ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-07.txt _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Feb 08 12:45:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tNp-0008CC-OJ; Wed, 08 Feb 2006 12:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6tNj-0008BD-JO; Wed, 08 Feb 2006 12:45:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14205; Wed, 8 Feb 2006 12:43:50 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6taN-0005y2-GD; Wed, 08 Feb 2006 12:58:35 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6tNj-0005cu-1E; Wed, 08 Feb 2006 12:45:31 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 08 Feb 2006 12:45:31 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ips@ietf.org Subject: [Ips] Last Call: 'Definitions of Managed Objects for iSCSI' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ips-bounces@ietf.org Errors-To: ips-bounces@ietf.org The IESG has received a request from the IP Storage WG to consider the following document: - 'Definitions of Managed Objects for iSCSI ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-11.txt _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Sun Feb 19 01:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAhsM-0004FZ-90; Sun, 19 Feb 2006 01:16:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAhsK-0004FP-Jk for ips@ietf.org; Sun, 19 Feb 2006 01:16:52 -0500 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAhsJ-0008UT-DS for ips@ietf.org; Sun, 19 Feb 2006 01:16:52 -0500 Received: by zproxy.gmail.com with SMTP id 18so718525nzp for ; Sat, 18 Feb 2006 22:16:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=YCHqoe3fvoWtNSFYx83p8OnvQUQMR1d+saXHVH1Fnt26Tjbi0yini2WbsY3pqYfjt0Ouqz1s7p/9Z/vEt6VHus4YBgO1gJYBNtstH46vF9YMI/l9WqLioOM3JGfKk7IfssaxpLK3M9o33VlcxzRo6oHXnNYEdBEUA1ZCQNquD3M= Received: by 10.36.121.14 with SMTP id t14mr3772118nzc; Sat, 18 Feb 2006 22:16:50 -0800 (PST) Received: by 10.36.247.13 with HTTP; Sat, 18 Feb 2006 22:16:50 -0800 (PST) Message-ID: <2bd90fb70602182216v20aadea2tdd04abe0b3bd52d3@mail.gmail.com> Date: Sun, 19 Feb 2006 11:46:50 +0530 From: T.Krishnanand To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ips] current multi-task abort model in RFC 3720 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Folks, I'm aware that a new multi-task model is being discussed on the mlist these days. But the following questions are based on the CURRENT RFC3720 model...and what initiators support TODAY. Consider a scenario where multiple iSCSI initiators are sharing a READ-ONLY (no SCSI reservations) access to a common LUN which has advertized TAS=3D1 control mode page setting. If LUN-reset from init-A and init-B happen on same lun then is it OK if LUN-reset response to init-B TM cmd is sent AFTER "task aborted" scsi status is sent to init-B for tasks aborted becoz of init-A's LUN-reset. IMHO after receiving the TM response wont init-B think that ALL outstanding tasks are aborted and hence MAY be surprised to recv scsi status for tasks which were outstanding when the LUN-reset was issued from init-B. IMHO think this scenario should be handled as follows, plz confirm if my understanding is correct. 1) start processing LUN-reset from init-A 2) send TM response to init-A AFTER sending out "task aborted" scsi status for tasks of init-B that were outstanding. 3) start processing LUN-reset from init-B. (At this time all init-B tasks aborted by init-A's LUN-reset have been notified to the init-B). Plz comment. -tkrishna _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 12:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbcy-0006Tg-Bt; Tue, 21 Feb 2006 12:48:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbcx-0006TX-Up for ips@ietf.org; Tue, 21 Feb 2006 12:48:43 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBbcx-0006ep-LZ for ips@ietf.org; Tue, 21 Feb 2006 12:48:43 -0500 Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2.netapp.com with ESMTP; 21 Feb 2006 09:48:43 -0800 X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="360504626:sNHT17762556" Received: from [10.61.17.57] ([10.61.17.57]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k1LHmfHl016153; Tue, 21 Feb 2006 09:48:42 -0800 (PST) Message-ID: <43FB4EFE.4060506@netapp.com> Date: Tue, 21 Feb 2006 12:33:50 -0500 From: David Wysochanski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [Ips] ips WG *will* meet in Dallas References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Does IPS have a day and/or timeslot yet? (didn't see it on the current IETF draft agenda) Thanks. Black_David@emc.com wrote: > Oops, forgot an agenda item for Dallas: > - iSNS MIB (discussion of newly reduced functionality scope). > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > > Behalf Of Black, David > > Sent: Thursday, February 02, 2006 8:26 PM > > To: ips@ietf.org > > Subject: [Ips] ips WG *will* meet in Dallas > > > > The IP Storage WG will meet in Dallas at the IETF meetings > > during the week of March 19th. The topics I know about > > for the agenda are: > > - iSCSI Implementers Guide (anything and everything) > > - David Wysochanski's forthcoming iSCSI X# key draft > > > > Any remaining time will be used to start a very preliminary > > discussion of what to do about the IETF Security Area's request > > that plans be made to eliminate all uses of MD5 from IETF > > protocols in the not-too-distant future. Anyone else who > > wants agenda time should to send me email with a topic, > > Internet-Draft name and time estimate. > > > > NOTE: Before anyone gets excited, there is no reason to > > believe that iSCSI has any security issues courtesy of > > its use of MD5 (e.g., CHAP is ok as there is no indication > > that anyone is close to inverting MD5), with the possible > > exception of MD5 in certificate signatures for IPsec (don't > > do that - at least use SHA-1), which is an issue for the > > pkix WG to address. This is about good engineering practice > > (MD5 has known flaws, it will only get worse, not better, > > so it's time to think about migrating to sounder technology). > > > > Thanks, > > --David (ips WG chair) > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 13:03:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbre-0007H9-NN; Tue, 21 Feb 2006 13:03:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBbrd-0007Gk-5U for ips@ietf.org; Tue, 21 Feb 2006 13:03:53 -0500 Received: from mailhub.lss.emc.com ([168.159.213.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBbrb-000709-SJ for ips@ietf.org; Tue, 21 Feb 2006 13:03:53 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k1LI3lcb025318; Tue, 21 Feb 2006 13:03:48 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Feb 2006 13:03:46 -0500 Message-ID: From: Black_David@emc.com To: davidw@netapp.com Subject: RE: [Ips] ips WG *will* meet in Dallas Date: Tue, 21 Feb 2006 13:03:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.02.21.092607 X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_0+ -2, EMC_BODY_1+ -1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Not yet, I did ask for a long timeslot, so it could be almost any day. --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: David Wysochanski [mailto:davidw@netapp.com] > Sent: Tuesday, February 21, 2006 12:34 PM > To: Black, David > Cc: ips@ietf.org > Subject: Re: [Ips] ips WG *will* meet in Dallas > > Does IPS have a day and/or timeslot yet? > (didn't see it on the current IETF draft agenda) > > Thanks. > > Black_David@emc.com wrote: > > Oops, forgot an agenda item for Dallas: > > - iSNS MIB (discussion of newly reduced > functionality scope). > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > -----Original Message----- > > > From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On > > > Behalf Of Black, David > > > Sent: Thursday, February 02, 2006 8:26 PM > > > To: ips@ietf.org > > > Subject: [Ips] ips WG *will* meet in Dallas > > > > > > The IP Storage WG will meet in Dallas at the IETF meetings > > > during the week of March 19th. The topics I know about > > > for the agenda are: > > > - iSCSI Implementers Guide (anything and everything) > > > - David Wysochanski's forthcoming iSCSI X# key draft > > > > > > Any remaining time will be used to start a very preliminary > > > discussion of what to do about the IETF Security Area's request > > > that plans be made to eliminate all uses of MD5 from IETF > > > protocols in the not-too-distant future. Anyone else who > > > wants agenda time should to send me email with a topic, > > > Internet-Draft name and time estimate. > > > > > > NOTE: Before anyone gets excited, there is no reason to > > > believe that iSCSI has any security issues courtesy of > > > its use of MD5 (e.g., CHAP is ok as there is no indication > > > that anyone is close to inverting MD5), with the possible > > > exception of MD5 in certificate signatures for IPsec (don't > > > do that - at least use SHA-1), which is an issue for the > > > pkix WG to address. This is about good engineering practice > > > (MD5 has known flaws, it will only get worse, not better, > > > so it's time to think about migrating to sounder technology). > > > > > > Thanks, > > > --David (ips WG chair) > > > ---------------------------------------------------- > > > David L. Black, Senior Technologist > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > > Ips mailing list > > > Ips@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ips > > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 14:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdKn-0004RV-GN; Tue, 21 Feb 2006 14:38:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdKm-0004RL-1G for ips@ietf.org; Tue, 21 Feb 2006 14:38:04 -0500 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdKk-0004qT-NX for ips@ietf.org; Tue, 21 Feb 2006 14:38:04 -0500 Received: from [10.0.0.11] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 22AE0870F3; Tue, 21 Feb 2006 14:38:00 -0500 (EST) In-Reply-To: <2bd90fb70602182216v20aadea2tdd04abe0b3bd52d3@mail.gmail.com> References: <2bd90fb70602182216v20aadea2tdd04abe0b3bd52d3@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9753C485-EE6C-4A9B-844B-76D429161E1D@wasabisystems.com> Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] current multi-task abort model in RFC 3720 Date: Tue, 21 Feb 2006 11:37:52 -0800 To: T.Krishnanand X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 18, 2006, at 10:16 PM, T.Krishnanand wrote: > Folks, > > I'm aware that a new multi-task model is being discussed on the mlist > these days. But the following questions are based on the CURRENT > RFC3720 model...and what initiators support TODAY. > > Consider a scenario where multiple iSCSI initiators are sharing a > READ-ONLY (no SCSI reservations) access to a common LUN which has > advertized TAS=1 control mode page setting. > > If LUN-reset from init-A and init-B happen on same lun then is it > OK if > LUN-reset response to init-B TM cmd is sent AFTER "task aborted" scsi > status is sent to init-B for tasks aborted becoz of init-A's > LUN-reset. > > IMHO after receiving the TM response wont init-B think that ALL > outstanding tasks are aborted and hence MAY be surprised to recv scsi > status for tasks which were outstanding when the LUN-reset was issued > from init-B. I'm not fully clear what the issue is, but I think that you are describing an initiator that does not understand TAS=1. With TAS=1, tasks don't silently disappear. So you will get abort status on all of them, regardless of which initiator triggered the abort. > IMHO think this scenario should be handled as follows, plz confirm if > my understanding is correct. > > 1) start processing LUN-reset from init-A > 2) send TM response to init-A AFTER sending out "task aborted" scsi > status for tasks of init-B that were outstanding. > 3) start processing LUN-reset from init-B. (At this time all init-B > tasks aborted by init-A's LUN-reset have been notified to the init-B). I think that is what targets will do today. One major aspect of the discussion is what exactly is meant by, "sending out," in your step 2. Does it mean that we have assigned status to the task and we have passed a SCSI Command Response to the tcp stack, or does it mean that we have done that and further that we know the initiator has responded it has received the status? On a data-center SAN with working initiators, it doesn't make much difference. Add the public internet and/or ill initiators and it becomes problematic. Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD+2wVDJT2Egh26K0RAtLdAJ4zxQUjmXYC4+ewW1fiAI7Xy+KwtwCdEjtP vC+p34JTdPPt3SQG65mAYEw= =FFyo -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 16:42:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfGw-0004IR-Os; Tue, 21 Feb 2006 16:42:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfGv-0004IM-TC for ips@ietf.org; Tue, 21 Feb 2006 16:42:13 -0500 Received: from gate01out.mcdata.com ([208.47.132.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBfGr-00032V-ER for ips@ietf.org; Tue, 21 Feb 2006 16:42:13 -0500 Received: from mc4gate01.mcdata.com ([172.16.11.205]) by gate01out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 14:42:08 -0700 Received: from MC4EXCH02.mcdata.com ([172.16.11.132]) by mc4gate01.mcdata.com with InterScan Messaging Security Suite; Tue, 21 Feb 2006 14:42:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2006 14:42:07 -0700 Message-ID: <3CCE3490660DD14ABB8BCD7D0B09925C9B3F94@MC4EXCH02.mcdata.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes to iSNS MIB Thread-Index: AcY3L6mSl2kgXJ2XSYid2D8qfFCsYg== From: "Scott Kipp" To: X-imss-version: 2.037 X-imss-result: Passed X-imss-approveListMatch: *@mcdata.com X-OriginalArrivalTime: 21 Feb 2006 21:42:08.0574 (UTC) FILETIME=[AA3CCDE0:01C6372F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: "G.D. Ramkumar" , Kevin Gibbons Subject: [Ips] Changes to iSNS MIB X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org IPS Working Group, The 8th revision of the iSNS MIB can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-08.txt This 8th revision was a major rewrite and includes the following changes to= simplify the MIB: 1) Change the MIB so that it monitors instead of configures iSNS: Starting with isnsDdsInfo, remove modify capabilities. - changed MAX-ACCESS to read-only in following objects: isnsDdsSymbolicName, isnsDdsStatus - Removed isnsDdsRowStatus object, and from IsnsDdsEntry,= isnsServerIscsiDdsDdObjGroup, isnsServerIfcpDdsDdObjGroup - Removed isnsDdsMemberRowStatus object, and from IsnsDdsMemberEntry,= isnsServerIscsiDdsDdObjGroup - changed MAX-ACCESS to read-only in following objects: isnsDdSymbolicName, isnsDdFeatures - Removed isnsDdRowStatus object, and from IsnsDdEntry,= isnsServerIscsiDdsDdObjGroup, isnsServerIfcpDdsDdObjGroup - changed MAX-ACCESS to read-only in following objects: isnsDdMemberIscsiName - Removed isnsDdMemberRowStatus object, and from IsnsDdiScsiMemberEntry,= isnsServerIscsiDdsDdObjGroup, isnsServerIfcpDdsDdObjGroup - changed MAX-ACCESS to read-only in following objects: isnsDdMemberPortalAddrType, isnsDdMemberPortalAddr,= isnsDdMemberPortalPortType, isnsDdMemberPortalPort - Removed isnsDdMemberPortalRowStatus object, and from= IsnsDdPortalMemberEntry, isnsServerIfcpDdsDdObjGroup - Removed isnsDdMemberFcRowStatus object, and from= IsnsDdFcPortMemberEntry, isnsServerIfcpDdsDdObjGroup 2) Removed Client Information: removed all client tables. a. isnsClntInfo b. isnsClntInstTable, isnsClntInstEntry, all objects in table c. isnsClntSrvrCfgTable, isnsClntSrvrCfgEntry, all objects in table d. isnsClntDscvrdSrvrTable, isnsClntDscvrdSrvrEntry, all objects in= table e. isnsClntRegEntityTable, isnsClntRegEntityEntry, all objects in= table Removed other client related objects a. Notifications: isnsClientStart, isnsClientInitialRegistration,= isnsClientLostConnection b. Groups: isnsClntAttributesGroup, isnsClientNotificationGroup= adjusted the numbering of isnsGroups c. Compliances: isnsIscsiClientComplianceV1,= isnsIfcpClientComplianceV1, adjusted the numbering of isnsCompliances - Removed isnsClntSrvrCfgRowStatus object, and from= isnsClntSrvrCfgEntry, isnsClientAttributesGroup - Removed isnsServerIfcpCntlNodeGroup, and object= isnsCntlNodeFcPortRowStatus, removed from isnsIfcpServerComplianceV1 - Removed isnsServerNextIdxGroup from isnsIscsiServerComplianceV1 and= isnsIfcpServerComplianceV1 =0D 3) Removed previous Revision History since this was a major rewrite. 4) Authors - Remove Josh Tseng and Tim McSweeney and add Scott Kipp and= G.D.Ramkumar 5) Other changes as suggested by Keith McCloghrie. Thanks, Scott Kipp SPECIAL NOTICE=0D All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that= disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of= this communication contains public information, no such restrictions apply to= that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 16:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfTs-0005Zo-1t; Tue, 21 Feb 2006 16:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfTr-0005Zb-7S for ips@ietf.org; Tue, 21 Feb 2006 16:55:35 -0500 Received: from mailhub.lss.emc.com ([168.159.213.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBfTp-0003ZS-Sd for ips@ietf.org; Tue, 21 Feb 2006 16:55:35 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k1LLtTeu010462 for ; Tue, 21 Feb 2006 16:55:30 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Feb 2006 16:55:27 -0500 Message-ID: From: Black_David@emc.com To: ips@ietf.org Subject: RE: [Ips] Changes to iSNS MIB Date: Tue, 21 Feb 2006 16:55:12 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.02.21.130610 X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_0+ -2, EMC_BODY_1+ -1, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_PRIORITY 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Everyone interested in iSNS, Please review this new draft of the iSNS MIB. Believe it or not, this draft is still in the IPS WG (it's our last MIB). I plan to issue a Working Group Last Call on this draft in the next couple of weeks, with WG Last Call to end sometime around the Dallas IETF meetings, but you don't have to wait for this Last Call to start before making comments. Also, please ignore the silly McData "may contain confidential and privileged information" footer on Scott's original message. That sort of footer does not apply to anything sent to the IPS mailing list. Thanks, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Scott Kipp [mailto:scott.kipp@mcdata.com] > Sent: Tuesday, February 21, 2006 4:42 PM > To: ips@ietf.org > Cc: G.D. Ramkumar; Kevin Gibbons > Subject: [Ips] Changes to iSNS MIB > > > IPS Working Group, > > The 8th revision of the iSNS MIB can be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-08.txt > > This 8th revision was a major rewrite and includes the > following changes to simplify the MIB: > > 1) Change the MIB so that it monitors instead of configures iSNS: > > Starting with isnsDdsInfo, remove modify capabilities. > - changed MAX-ACCESS to read-only in following objects: > isnsDdsSymbolicName, isnsDdsStatus > - Removed isnsDdsRowStatus object, and from IsnsDdsEntry, > isnsServerIscsiDdsDdObjGroup, isnsServerIfcpDdsDdObjGroup > - Removed isnsDdsMemberRowStatus object, and from > IsnsDdsMemberEntry, isnsServerIscsiDdsDdObjGroup > - changed MAX-ACCESS to read-only in following objects: > isnsDdSymbolicName, isnsDdFeatures > - Removed isnsDdRowStatus object, and from IsnsDdEntry, > isnsServerIscsiDdsDdObjGroup, isnsServerIfcpDdsDdObjGroup > - changed MAX-ACCESS to read-only in following objects: > isnsDdMemberIscsiName > - Removed isnsDdMemberRowStatus object, and from > IsnsDdiScsiMemberEntry, isnsServerIscsiDdsDdObjGroup, > isnsServerIfcpDdsDdObjGroup > - changed MAX-ACCESS to read-only in following objects: > isnsDdMemberPortalAddrType, isnsDdMemberPortalAddr, > isnsDdMemberPortalPortType, isnsDdMemberPortalPort > - Removed isnsDdMemberPortalRowStatus object, and from > IsnsDdPortalMemberEntry, isnsServerIfcpDdsDdObjGroup > - Removed isnsDdMemberFcRowStatus object, and from > IsnsDdFcPortMemberEntry, isnsServerIfcpDdsDdObjGroup > > 2) Removed Client Information: > removed all client tables. > a. isnsClntInfo > b. isnsClntInstTable, isnsClntInstEntry, all objects in table > c. isnsClntSrvrCfgTable, isnsClntSrvrCfgEntry, all objects in table > d. isnsClntDscvrdSrvrTable, isnsClntDscvrdSrvrEntry, all objects in table > e. isnsClntRegEntityTable, isnsClntRegEntityEntry, all objects in table > > Removed other client related objects > a. Notifications: isnsClientStart, > isnsClientInitialRegistration, isnsClientLostConnection > b. Groups: isnsClntAttributesGroup, > isnsClientNotificationGroup adjusted the numbering of isnsGroups > c. Compliances: isnsIscsiClientComplianceV1, > isnsIfcpClientComplianceV1, adjusted the numbering of isnsCompliances > > - Removed isnsClntSrvrCfgRowStatus object, and from > isnsClntSrvrCfgEntry, isnsClientAttributesGroup > - Removed isnsServerIfcpCntlNodeGroup, and object > isnsCntlNodeFcPortRowStatus, removed from isnsIfcpServerComplianceV1 > - Removed isnsServerNextIdxGroup from > isnsIscsiServerComplianceV1 and isnsIfcpServerComplianceV1 > > > 3) Removed previous Revision History since this was a major rewrite. > > 4) Authors > - Remove Josh Tseng and Tim McSweeney and add Scott Kipp and G.D.Ramkumar > 5) Other changes as suggested by Keith McCloghrie. > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Feb 21 23:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBlGF-0006ku-3a; Tue, 21 Feb 2006 23:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBlGD-0006kl-Rc for ips@ietf.org; Tue, 21 Feb 2006 23:05:53 -0500 Received: from zproxy.gmail.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBlGD-000483-J8 for ips@ietf.org; Tue, 21 Feb 2006 23:05:53 -0500 Received: by zproxy.gmail.com with SMTP id 18so1412404nzp for ; Tue, 21 Feb 2006 20:05:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ELBALYfddv/hgd/i+voOfzHfGRGaUgqeGUCPtaHzlCYneYkwhU6VmrUXMdLPeOcaP691cxiNVDFNRjhtgg2Jlj9JxbddHbjNpvIFZ5Q3uUy54qF8feoG0Op4BM5a8UTUtytXXrqPYeVjUWNwLjPm6O5J7YAZ7P5PVcRR54dzEOY= Received: by 10.36.100.19 with SMTP id x19mr288616nzb; Tue, 21 Feb 2006 20:05:53 -0800 (PST) Received: by 10.36.247.13 with HTTP; Tue, 21 Feb 2006 20:05:53 -0800 (PST) Message-ID: <2bd90fb70602212005y3233c823mb93496d496705e13@mail.gmail.com> Date: Wed, 22 Feb 2006 09:35:53 +0530 From: T.Krishnanand To: "William Studenmund" Subject: Re: [Ips] current multi-task abort model in RFC 3720 In-Reply-To: <9753C485-EE6C-4A9B-844B-76D429161E1D@wasabisystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <2bd90fb70602182216v20aadea2tdd04abe0b3bd52d3@mail.gmail.com> <9753C485-EE6C-4A9B-844B-76D429161E1D@wasabisystems.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org On 2/22/06, William Studenmund wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Feb 18, 2006, at 10:16 PM, T.Krishnanand wrote: > > > Folks, > > > > I'm aware that a new multi-task model is being discussed on the mlist > > these days. But the following questions are based on the CURRENT > > RFC3720 model...and what initiators support TODAY. > > > > Consider a scenario where multiple iSCSI initiators are sharing a > > READ-ONLY (no SCSI reservations) access to a common LUN which has > > advertized TAS=3D1 control mode page setting. > > > > If LUN-reset from init-A and init-B happen on same lun then is it > > OK if > > LUN-reset response to init-B TM cmd is sent AFTER "task aborted" scsi > > status is sent to init-B for tasks aborted becoz of init-A's > > LUN-reset. > > > > IMHO after receiving the TM response wont init-B think that ALL > > outstanding tasks are aborted and hence MAY be surprised to recv scsi > > status for tasks which were outstanding when the LUN-reset was issued > > from init-B. > > I'm not fully clear what the issue is, but I think that you are > describing an initiator that does not understand TAS=3D1. With TAS=3D1, > tasks don't silently disappear. So you will get abort status on all > of them, regardless of which initiator triggered the abort. > The issue that I was trying to raise was: TAS=3D1 implies tasks aborted by actions on OTHER nexus cause "TASK ABORTED" scsi status. But abort of tasks on the nexus on which TM cmd came are NOT notified to the initiator, only TM response is given. So I was trying to confirm that iSCSI target MUST ensure that ALL "task aborted" scsi statuses are sent to TCP for transmission to init-B and only AFTER THAT it can send the lun-reset task mgmt response to init-B. So that init-B will ALWAYS first see all the "task aborted" scsi statuses (due to lun-reset from init-A) and THEN it'll see the lun-reset response from it's own lun-reset task mgmt cmd. IMHO this is important since if init-B see its own lun-reset response first the followed by the "task aborted" scsi statuses......then isn't it a violation of the SCSI spec which mandates... "once task mgmt cmd response is recvd...NO responses from chronologically older tasks can be recvd by an initiator." Hope this clarifies the "confirmation of target behaviour" I'm seeking. Another related question is: Do you know if the CURRENT breed of initiators will properly handle TAS=3D1 support from a target ? > > IMHO think this scenario should be handled as follows, plz confirm if > > my understanding is correct. > > > > 1) start processing LUN-reset from init-A > > 2) send TM response to init-A AFTER sending out "task aborted" scsi > > status for tasks of init-B that were outstanding. > > 3) start processing LUN-reset from init-B. (At this time all init-B > > tasks aborted by init-A's LUN-reset have been notified to the init-B). > > I think that is what targets will do today. > > One major aspect of the discussion is what exactly is meant by, > "sending out," in your step 2. Does it mean that we have assigned > status to the task and we have passed a SCSI Command Response to the > tcp stack, or does it mean that we have done that and further that we > know the initiator has responded it has received the status? > > On a data-center SAN with working initiators, it doesn't make much > difference. Add the public internet and/or ill initiators and it > becomes problematic. > > Take care, > > Bill > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > > iD8DBQFD+2wVDJT2Egh26K0RAtLdAJ4zxQUjmXYC4+ewW1fiAI7Xy+KwtwCdEjtP > vC+p34JTdPPt3SQG65mAYEw=3D > =3DFFyo > -----END PGP SIGNATURE----- > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Feb 22 19:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4AK-0001AU-79; Wed, 22 Feb 2006 19:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4AI-0001AP-PW for ips@ietf.org; Wed, 22 Feb 2006 19:17:02 -0500 Received: from mononoke.wasabisystems.com ([66.173.145.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC4AI-0002tz-GL for ips@ietf.org; Wed, 22 Feb 2006 19:17:02 -0500 Received: from [10.0.0.11] (h-66-166-188-91.sndacagl.covad.net [66.166.188.91]) by mononoke.wasabisystems.com (Postfix) with ESMTP id 473DA87120; Wed, 22 Feb 2006 19:16:59 -0500 (EST) In-Reply-To: <2bd90fb70602212005y3233c823mb93496d496705e13@mail.gmail.com> References: <2bd90fb70602182216v20aadea2tdd04abe0b3bd52d3@mail.gmail.com> <9753C485-EE6C-4A9B-844B-76D429161E1D@wasabisystems.com> <2bd90fb70602212005y3233c823mb93496d496705e13@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: William Studenmund Subject: Re: [Ips] current multi-task abort model in RFC 3720 Date: Wed, 22 Feb 2006 16:16:53 -0800 To: T.Krishnanand X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 21, 2006, at 8:05 PM, T.Krishnanand wrote: > On 2/22/06, William Studenmund wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Feb 18, 2006, at 10:16 PM, T.Krishnanand wrote: >> >> >> I'm not fully clear what the issue is, but I think that you are >> describing an initiator that does not understand TAS=1. With TAS=1, >> tasks don't silently disappear. So you will get abort status on all >> of them, regardless of which initiator triggered the abort. >> > > The issue that I was trying to raise was: > > TAS=1 implies tasks aborted by actions on OTHER nexus cause "TASK > ABORTED" scsi status. But abort of tasks on the nexus on which TM cmd > came are NOT notified to the initiator, only TM response is given. True. > So I was trying to confirm that iSCSI target MUST ensure that ALL > "task aborted" scsi statuses are sent to TCP for transmission to > init-B and only AFTER THAT it can send the lun-reset task mgmt > response to init-B. > > So that init-B will ALWAYS first see all the "task aborted" scsi > statuses (due to lun-reset from init-A) and THEN it'll see the > lun-reset response from it's own lun-reset task mgmt cmd. > > IMHO this is important since if init-B see its own lun-reset response > first the followed by the "task aborted" scsi statuses......then isn't > it a violation of the SCSI spec which mandates... > > "once task mgmt cmd response is recvd...NO responses from > chronologically older tasks can be recvd by an initiator." > > Hope this clarifies the "confirmation of target behaviour" I'm > seeking. The way you have it phrased, I don't see why you had to ask. As outlined above, this is not an iSCSI issue, but a SCSI/SAM issue. The place where things get difficult is in how you define "received." All you are requiring above is that the responses have been posted to the TCP stack. That's what most targets do AFAIK. The problem is that in an MC/S environment, that doesn't mean that the initiator has gotten the status. Consider two connections, one of which has a task (or tasks) on it and the other which is used to send the TMR. Further let the first connection be suffering connectivity issues (say the intermediate switch and its friends are inefficiently updating a spanning-tree, so it's off line for a few tens of seconds). So the target sends the aborted response for the tasks aborted due to Intr-A, however they are stuck waiting for the switch. Now the TMF comes along, and completes. The TMF Response gets to the initiator without issue. Next the switches decide to carry traffic again, and the status messages arrive at the initiator. I'm starting to think that the real fix for a number of these issues is actually to change things at the SCSI layer, and to come up with something akin to TAS & friends on steroids. Make it so that _every_ task will receive status (unless there's an I_T Nexus Loss). Then a lot of these races disappear. I realize this isn't the best list to discuss this. :-) Take care, Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD/P76DJT2Egh26K0RArRdAJ94Z6T8T29SbQixlYI64PmJKjjNyQCePovJ 3vwTme/h8ZB816X/DmoSTTY= =KTtd -----END PGP SIGNATURE----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Feb 27 17:25:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqnt-0004nD-SG; Mon, 27 Feb 2006 17:25:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqnp-0004aq-1S; Mon, 27 Feb 2006 17:25:13 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpYD-0003zk-Td; Mon, 27 Feb 2006 16:05:01 -0500 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FDpJi-0002Pb-DU; Mon, 27 Feb 2006 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1RKo1vP023709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FDpJh-000710-UW; Mon, 27 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Feb 2006 15:50:01 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-auth-mib-08.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for IP Storage User Identity Authorization Author(s) : M. Bakke, J. Muchow Filename : draft-ietf-ips-auth-mib-08.txt Pages : 43 Date : 2006-2-27 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This draft was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-auth-mib-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-auth-mib-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-27114119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-auth-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-auth-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-27114119.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart--