From exim@www1.ietf.org Mon Feb 2 09:23:11 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14457 for ; Mon, 2 Feb 2004 09:23:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneyI-0005KY-6q for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 09:22:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12EMg6o020486 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 09:22:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AneyH-0005KL-TJ for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 09:22:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14422 for ; Mon, 2 Feb 2004 09:22:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AneyG-0005ns-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 09:22:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnexQ-0005hN-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 09:21:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anewq-0005b1-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 09:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anewi-0004hT-8r; Mon, 02 Feb 2004 09:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnewO-0004c3-0o for ips@optimus.ietf.org; Mon, 02 Feb 2004 09:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14252 for ; Mon, 2 Feb 2004 09:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnewM-0005YW-00 for ips@ietf.org; Mon, 02 Feb 2004 09:20:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnevW-0005Sa-00 for ips@ietf.org; Mon, 02 Feb 2004 09:19:51 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx with esmtp (Exim 4.12) id 1Aneum-0005I1-00 for ips@ietf.org; Mon, 02 Feb 2004 09:19:04 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i12EIPMf132380; Mon, 2 Feb 2004 14:18:25 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i12EIOh9146838; Mon, 2 Feb 2004 14:18:25 GMT In-Reply-To: To: wrstuden@wasabisystems.com Cc: "Mallikarjun C." , Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: Fw: [Ips] iSCSI: abort task set X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 2 Feb 2004 16:18:17 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/02/2004 16:18:19, Serialize complete at 02/02/2004 16:18:19 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 I might be a bit late and you might have closed on all this but here is what I think although I have to admit that I don't recall the debate in its entirety ips-admin@ietf.org wrote on 30/01/2004 21:33:55: > On Fri, 30 Jan 2004, Mallikarjun C. wrote: > > > Eddy, > > > > Sorry for not responding sooner, I was checking my old > > notes (but couldn't find relevant ones so far). > > > > The authors' advice on this is the following - > > > > The wait for affected tasks can be done (need to > > pick a point in time as the reference for determining > > the "affected" tasks, regardless of the # of sessions). > > However, an alternative that's also legal is given below. > > > > Bullet (b) should have been: > > > > b) Waits for all target transfer tags to be responded to > > and for all affected tasks in the task set to be > > received (alternatively, the target may plug the CmdSN > > gaps for unreceived commands just as if an abort request > > is received for each individual affected task, refer > > section 6.9 "SCSI timeouts") > > Abort Task Set has to plug the whole CmdSN window on each session?? That > sounds excessive. Plugging the CmdSN hole for an Abort Task seems fine, > since the initiator tells the target explicitly which CmdSN to abort (and > also knows what the highest CmdSN used so far is). But with the Task Set > commands, we _don't_ know the highest CmdSN the initiator has used, only > the highest CmdSN we've seen and MaxCmdSN. > I don't think that the plugging the holes for other initiators is required even if TST is 0. The SCSI tasks are what they are an the SCSI task set has to aborted accordingly. However plugging the holes for the specific initiator seems to fall in the realm of iSCSI and a target may wait or plug as the "bound" of CmdSN is known for that session. And yes abort task-set with TST=0 is messy! (for any transport) > Also, for the TST 000b case, what does that mean for other initiators? > Their entire CmdSN window gets filled? Consider an initiator that was > quiescent. If I'm understanding the window-filling correctly, its entire > CmdSN window gets slammed shut. Since its quescent, how will it know its > window got closed? Any non-immediate command it sends will just disapear > as the CmdSN window was filled. It will also see the CmdSN window just > move if the target sends in a PDU. It won't understand why the window > moved of its own accord until it gets a SCSI abort UA. ?? > > Finally, since iSCSI tasks don't get passed to the SCSI layer until the > CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI task > set? > > Or did I misunderstand something? Please tell me I did as the above looks > messy. :-) > > > Note that the wait on StatSN ack is however > > mandatory. > > Is there any sort of time out? > > > It is good to get this alternative/clarification into > > the final RFC. > > Take care, > > Bill > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 2 13:05:05 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26662 for ; Mon, 2 Feb 2004 13:05:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniR5-0006g7-1q for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:04:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12I4drK025671 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:04:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniR4-0006fy-Ri for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:04:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26617 for ; Mon, 2 Feb 2004 13:04:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniR3-0001mA-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniNU-00010J-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:00:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AniMK-0000oZ-01 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 12:59:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AniGu-0007MJ-HQ for ips-web-archive@ietf.org; Mon, 02 Feb 2004 12:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniGn-0005ta-Fe; Mon, 02 Feb 2004 12:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniGV-0005sw-Fq for ips@optimus.ietf.org; Mon, 02 Feb 2004 12:53:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26344 for ; Mon, 2 Feb 2004 12:53:39 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniGT-0000Pj-00 for ips@ietf.org; Mon, 02 Feb 2004 12:53:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniFl-0000KV-00 for ips@ietf.org; Mon, 02 Feb 2004 12:52:58 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1AniEy-0000DF-00; Mon, 02 Feb 2004 12:52:09 -0500 Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 736FC75BA; Mon, 2 Feb 2004 10:52:00 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos1.cos.agilent.com (Postfix) with ESMTP id 51E7F433; Mon, 2 Feb 2004 10:52:00 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 10:51:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Mon, 2 Feb 2004 10:51:59 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPnKFSSJJfKduMgRJyqkEsBAb7cTACi0b/w To: Cc: , , , X-OriginalArrivalTime: 02 Feb 2004 17:51:59.0827 (UTC) FILETIME=[41C4BA30:01C3E9B5] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If we really believe that the change would be overly painful for current = and in development implementations, I would prefer a change to make = R2TSN and DataSN independent for bidirectional commands. The logic: Bidirectional commands already need extra context so carrying an extra = SN variable is a very small burden to them. It is poor form to have one variable that is sitting under two names. It = creates confusion and is likely to cause interoperability problems in = the future.=20 Therefore, it is worth the burden of carrying an extra value in = bidirectional command context to forstall interoperability problems. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 30, 2004 3:57 AM To: THALER,PAT (A-Roseville,ex1) Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Will fix the example (thanks Pat and perhaps add the text you = suggested).=20 For pratical purposes it should be noted that the only SCSI device that=20 plans to use bidirectional data transfers to-date has different phases = for=20 input and output so that block are no mixed. However I assumed always that the space is shared and that data = placement=20 is unaffected by the order of PDU's . The SNACK identifies unambiguously = to the target what is missing and the initiator has to know only that=20 something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the=20 > combination of the behavior described in 10.4.8 and that described in=20 > 3.2.2 is broken for bidirectional commands. The reason for reporting=20 > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to=20 > send a SNACK if it didn't. >=20 > For example, one could have the following in response to a=20 > bidirectional command: >=20 > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T >=20 > If the ExpDataSN to be reported in the SCSI Response was truly the=20 > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that=20 > DataSN and R2TSN for bidirectional commands form one continuous=20 > undifferentiated series but it is not consistent with the example in=20 > B.3. The example shows a PDU with R2TSN =3D 0 followed by a PDU with=20 DataSN =3D 0. >=20 > This is broken because the initiator could not compare the value=20 > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is=20 > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the=20 > ExpDataSN value. The target would also have to keep two separate=20 > counters during processing of bidirectional commands (both named=20 > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so=20 > it can put it in the Response and one of the value of ExpDataSN=20 > indicating the DataSN to put in the next Data-In or R2T PDU it sends=20 > for the command. >=20 > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and=20 > R2TSN form one sequence for bidirectional commands is to allow the=20 > command to maintain one count for DataIn and R2T PDUs rather than=20 > having two counters. If we were willing to forgo that optimization,=20 > then DataSN and R2TSN should have been kept separate.=20 >=20 > In any case, it is incorrect to have two variables for the same=20 > context with the same name. >=20 > One can correct the problem by changing 10.4.8 to say that for=20 > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs=20 > that were sent, then one can maintain one value. One should also=20 > correct the example in B.3. >=20 > One could also correct the problem by changing 3.2.2 so that DataSN=20 > was kept separate from R2TSN in bidirectional commands. In some=20 > senses, this would have been cleaner because it avoids having one=20 > variable with two names but it would require more context per command=20 > and it is probably a bigger change for existing implementations. >=20 > The code in E.2.2 seems ambiguous - it just says if (expDataSN does=20 > not match) but it doesn't define what is considered a match. Neither=20 > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs=20 > is derived. Therefore it would be consistent with either choice. >=20 > Regards, > Pat >=20 > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for = bidirectional > commands >=20 >=20 > On Thu, 29 Jan 2004, Mallikarjun C. wrote: >=20 > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. >=20 > While I'll be honest that I don't understand _why_ R2Ts are factored=20 into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared = the > same space. >=20 > So I don't think it's supposed to be something new. >=20 > Take care, >=20 > Bill >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 2 13:12:53 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28098 for ; Mon, 2 Feb 2004 13:12:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniYc-0007nc-QK for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:12:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12ICQKZ029974 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:12:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniYc-0007nN-H1 for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:12:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28069 for ; Mon, 2 Feb 2004 13:12:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniYa-0003dz-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:12:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniXX-0003SP-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:11:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniWN-0003EK-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniWN-0007O9-CZ; Mon, 02 Feb 2004 13:10:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniVo-0007Kp-AV for ips@optimus.ietf.org; Mon, 02 Feb 2004 13:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27739 for ; Mon, 2 Feb 2004 13:09:28 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniVm-00033r-00 for ips@ietf.org; Mon, 02 Feb 2004 13:09:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniSs-0002Ga-00 for ips@ietf.org; Mon, 02 Feb 2004 13:06:33 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1AniO3-000160-00 for ips@ietf.org; Mon, 02 Feb 2004 13:01:31 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 1EFA176A0; Mon, 2 Feb 2004 11:01:31 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id ED03C3E4; Mon, 2 Feb 2004 11:01:30 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 11:01:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Mon, 2 Feb 2004 11:01:30 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPnc+7kFxpMg6LQSzmCS94RimDCegAy5sDAAF1euxA= To: , , , Cc: X-OriginalArrivalTime: 02 Feb 2004 18:01:30.0600 (UTC) FILETIME=[95F9C680:01C3E9B6] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't think "(read)" should be in there. We don't usually put read = after Data-In. Also, I would rather have it a separate sentence.=20 For read commands, the number of Data-In PDUs the target has sent for = the command. For bidirectional commands, the number of Data-In PDUs and = R2T PDUs the target has sent for the command. or=20 For bidirectional commands, the number of Data-In PDUs and R2T PDUs the = target has sent for the command. For all other commands, the number of = Data-In PDUs the target has sent for the command. The more I think about it, the more I lean toward leaving 10.4.8 as it = is and changing 3.2.2 to disentangle DataSN from R2TSN. Is it really = worth these gymnastics to reduce bidirectional command context by one = variable? -----Original Message----- From: Ramesh Mangamuri [mailto:rmangamuri@istor.com] Sent: Saturday, January 31, 2004 1:27 PM To: Ken Sandars; Julian Satran; Mallikarjun C. Cc: THALER,PAT (A-Roseville,ex1); ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Hello Ken/Julian: I have another proposal here for section 10.4.8: Suggestion --------------------------- 10.4.8 ExpDataSN The number of Data-In (read) PDUs (for bidirectional commands this is R2Ts + Data-Ins) the target has sent for the command. This field is reserved if the response code is not Command Completed at Target, or the command is Write only command. How does this sound??? -Rams =20 =09 -----Original Message----- From: Ken Sandars [mailto:ksandars@elipsan.com]=20 Sent: Friday, January 30, 2004 12:57 PM To: 'Julian Satran'; 'Mallikarjun C.' Cc: pat_thaler@agilent.com; ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Hi Julo, As requested, two alternative proposals for section 10.4.8: Suggestion 1 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target. Suggestion 2 -------------------------- 10.4.8 ExpDataSN The number of R2T and Data-In (read) PDUs the target has sent for the command. This field is reserved if the response code is not Command Completed at Target or the target sent no Data-In PDUs for the command. ---------------------------------------- I'm more than happy with any answer which clarifies when the field is reserved. Thanks, Ken Sandars Elipsan UK > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On=20 > Behalf Of Mallikarjun C. > Sent: 30 January 2004 20:29 > To: Ken Sandars > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for=20 > bidirectional commands >=20 >=20 > Ken, >=20 > I am not sure we need to restrict the wording > to commands with at least one Data-In PDU. Do > you see an issue? >=20 > In any case, if you have a specific wording suggestion, > please send it to Julian directly (he owns the pen). >=20 > Regards. >=20 > Mallikarjun >=20 >=20 >=20 > Ken Sandars wrote: >=20 > > Hi Mallikarjun, > >=20 > > One final clarification request, and I can sleep easy on=20 > this topic! > >=20 > > Will the new wording for 10.4.8 be more general to indicate that=20 > > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > >=20 > > Is this field only valid for commands which have at least=20 > one Data-In=20 > > PDU? > >=20 > >=20 > > Thanks again, > > Ken Sandars > > Elipsan UK > >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ 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 exim@www1.ietf.org Mon Feb 2 13:14:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28253 for ; Mon, 2 Feb 2004 13:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniaD-0007yT-TA for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:14:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IE5Wi030647 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniaD-0007yE-Nb for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28236 for ; Mon, 2 Feb 2004 13:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniaB-0003y0-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniZG-0003mm-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:13:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniYC-0003b6-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniYD-0007fp-TR; Mon, 02 Feb 2004 13:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniXi-0007eO-H5 for ips@optimus.ietf.org; Mon, 02 Feb 2004 13:11:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28015 for ; Mon, 2 Feb 2004 13:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniXg-0003Tb-00 for ips@ietf.org; Mon, 02 Feb 2004 13:11:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniWa-0003Gj-00 for ips@ietf.org; Mon, 02 Feb 2004 13:10:22 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AniUj-0002dd-00; Mon, 02 Feb 2004 13:08:25 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 2 Feb 2004 10:06:35 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DD1@mail1irv.inside.istor.com> Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPnKFSSJJfKduMgRJyqkEsBAb7cTACi0b/wAADRkxA= X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: , Cc: , , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable To be honest I really don't know about the resources we would be saving by combining R2TSN and DataSN into one variable in the of bidirectional . But from logical standpoint, Pat's suggestion makes perfect sense to me. More later ..., Rams -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Monday, February 02, 2004 9:52 AM To: Julian_Satran@il.ibm.com Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands If we really believe that the change would be overly painful for current and in development implementations, I would prefer a change to make R2TSN and DataSN independent for bidirectional commands. The logic: Bidirectional commands already need extra context so carrying an extra SN variable is a very small burden to them. It is poor form to have one variable that is sitting under two names. It creates confusion and is likely to cause interoperability problems in the future.=20 Therefore, it is worth the burden of carrying an extra value in bidirectional command context to forstall interoperability problems. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 30, 2004 3:57 AM To: THALER,PAT (A-Roseville,ex1) Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Will fix the example (thanks Pat and perhaps add the text you suggested).=20 For pratical purposes it should be noted that the only SCSI device that=20 plans to use bidirectional data transfers to-date has different phases for=20 input and output so that block are no mixed. However I assumed always that the space is shared and that data placement=20 is unaffected by the order of PDU's . The SNACK identifies unambiguously to the target what is missing and the initiator has to know only that=20 something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the=20 > combination of the behavior described in 10.4.8 and that described in=20 > 3.2.2 is broken for bidirectional commands. The reason for reporting=20 > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to=20 > send a SNACK if it didn't. >=20 > For example, one could have the following in response to a=20 > bidirectional command: >=20 > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T >=20 > If the ExpDataSN to be reported in the SCSI Response was truly the=20 > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that=20 > DataSN and R2TSN for bidirectional commands form one continuous=20 > undifferentiated series but it is not consistent with the example in=20 > B.3. The example shows a PDU with R2TSN =3D 0 followed by a PDU with=20 DataSN =3D 0. >=20 > This is broken because the initiator could not compare the value=20 > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is=20 > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the=20 > ExpDataSN value. The target would also have to keep two separate=20 > counters during processing of bidirectional commands (both named=20 > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so=20 > it can put it in the Response and one of the value of ExpDataSN=20 > indicating the DataSN to put in the next Data-In or R2T PDU it sends=20 > for the command. >=20 > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and=20 > R2TSN form one sequence for bidirectional commands is to allow the=20 > command to maintain one count for DataIn and R2T PDUs rather than=20 > having two counters. If we were willing to forgo that optimization,=20 > then DataSN and R2TSN should have been kept separate.=20 >=20 > In any case, it is incorrect to have two variables for the same=20 > context with the same name. >=20 > One can correct the problem by changing 10.4.8 to say that for=20 > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs=20 > that were sent, then one can maintain one value. One should also=20 > correct the example in B.3. >=20 > One could also correct the problem by changing 3.2.2 so that DataSN=20 > was kept separate from R2TSN in bidirectional commands. In some=20 > senses, this would have been cleaner because it avoids having one=20 > variable with two names but it would require more context per command=20 > and it is probably a bigger change for existing implementations. >=20 > The code in E.2.2 seems ambiguous - it just says if (expDataSN does=20 > not match) but it doesn't define what is considered a match. Neither=20 > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs=20 > is derived. Therefore it would be consistent with either choice. >=20 > Regards, > Pat >=20 > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional > commands >=20 >=20 > On Thu, 29 Jan 2004, Mallikarjun C. wrote: >=20 > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. >=20 > While I'll be honest that I don't understand _why_ R2Ts are factored=20 into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. >=20 > So I don't think it's supposed to be something new. >=20 > Take care, >=20 > Bill >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 2 13:18:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28562 for ; Mon, 2 Feb 2004 13:18:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anido-0008QE-W2 for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:17:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IHmle032368 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anido-0008Pz-P2 for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28542 for ; Mon, 2 Feb 2004 13:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anidm-0004Xs-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:17:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anics-0004RC-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:16:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anic7-0004Jx-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anic5-0008DA-9d; Mon, 02 Feb 2004 13:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnibC-000834-SE for ips@optimus.ietf.org; Mon, 02 Feb 2004 13:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28292 for ; Mon, 2 Feb 2004 13:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnibA-000492-00 for ips@ietf.org; Mon, 02 Feb 2004 13:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ania1-0003wT-00 for ips@ietf.org; Mon, 02 Feb 2004 13:13:54 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AniZB-0003lZ-00 for ips@ietf.org; Mon, 02 Feb 2004 13:13:01 -0500 Received: from [192.168.7.113] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AniXl-0004bG-00; Mon, 02 Feb 2004 18:11:33 +0000 From: "Ken Sandars" To: , , , Cc: Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Mon, 2 Feb 2004 18:12:14 -0000 Message-ID: <001101c3e9b8$2b530060$7107a8c0@winminx> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pat, > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: 02 February 2004 18:02 > To: rmangamuri@istor.com; ksandars@elipsan.com; > Julian_Satran@il.ibm.com; cbm@rose.hp.com > Cc: ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectional commands > > > I don't think "(read)" should be in there. We don't usually > put read after Data-In. Also, I would rather have it a > separate sentence. > > For read commands, the number of Data-In PDUs the target has > sent for the command. For bidirectional commands, the number > of Data-In PDUs and R2T PDUs the target has sent for the command. > > or > > For bidirectional commands, the number of Data-In PDUs and > R2T PDUs the target has sent for the command. For all other > commands, the number of Data-In PDUs the target has sent for > the command. > > The more I think about it, the more I lean toward leaving > 10.4.8 as it is and changing 3.2.2 to disentangle DataSN from > R2TSN. Is it really worth these gymnastics to reduce > bidirectional command context by one variable? > This would affect Data/R2T SNACK processing, but that's probably a good thing. Perhaps explicit Data SNACK and R2T SNACK types are All that is needed. But is this needed, or just a can-o-worms? Cheers, Ken Sandars Elipsan UK > -----Original Message----- > From: Ramesh Mangamuri [mailto:rmangamuri@istor.com] > Sent: Saturday, January 31, 2004 1:27 PM > To: Ken Sandars; Julian Satran; Mallikarjun C. > Cc: THALER,PAT (A-Roseville,ex1); ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectional commands > > > Hello Ken/Julian: > > I have another proposal here for section 10.4.8: > > Suggestion --------------------------- > > 10.4.8 ExpDataSN > > The number of Data-In (read) PDUs (for bidirectional > commands this is R2Ts + Data-Ins) the target has sent for the command. > > This field is reserved if the response code is not Command > Completed > at Target, or the command is Write only command. > > > How does this sound??? > > -Rams > > > > > -----Original Message----- > From: Ken Sandars [mailto:ksandars@elipsan.com] > Sent: Friday, January 30, 2004 12:57 PM > To: 'Julian Satran'; 'Mallikarjun C.' > Cc: pat_thaler@agilent.com; ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectional commands > > Hi Julo, > > As requested, two alternative proposals for section 10.4.8: > > Suggestion 1 -------------------------- > > 10.4.8 ExpDataSN > > The number of R2T and Data-In (read) PDUs the target has > sent for the > command. > > This field is reserved if the response code is not Command > Completed > at Target. > > > Suggestion 2 -------------------------- > > 10.4.8 ExpDataSN > > The number of R2T and Data-In (read) PDUs the target has > sent for the > command. > > This field is reserved if the response code is not Command > Completed > at Target or the target sent no Data-In PDUs for the command. > > ---------------------------------------- > > > I'm more than happy with any answer which clarifies when the > field is reserved. > > > Thanks, > Ken Sandars > Elipsan UK > > > > > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Mallikarjun C. > > Sent: 30 January 2004 20:29 > > To: Ken Sandars > > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org > > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for > > bidirectional commands > > > > > > Ken, > > > > I am not sure we need to restrict the wording > > to commands with at least one Data-In PDU. Do > > you see an issue? > > > > In any case, if you have a specific wording suggestion, > please send it > > to Julian directly (he owns the pen). > > > > Regards. > > > > Mallikarjun > > > > > > > > Ken Sandars wrote: > > > > > Hi Mallikarjun, > > > > > > One final clarification request, and I can sleep easy on > > this topic! > > > > > > Will the new wording for 10.4.8 be more general to indicate that > > > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > > > > > > Is this field only valid for commands which have at least > > one Data-In > > > PDU? > > > > > > > > > Thanks again, > > > Ken Sandars > > > Elipsan UK > > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Mon Feb 2 13:57:09 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01639 for ; Mon, 2 Feb 2004 13:57:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjFS-0004CH-3s for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 13:56:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IugvN016132 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 13:56:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjFR-0004C7-Qy for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01561 for ; Mon, 2 Feb 2004 13:56:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjFP-0003k9-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:56:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjCR-0002wx-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:53:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anj91-00028p-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 13:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj92-0003IW-3h; Mon, 02 Feb 2004 13:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj8b-0003FQ-Lz for ips@optimus.ietf.org; Mon, 02 Feb 2004 13:49:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00819 for ; Mon, 2 Feb 2004 13:49:34 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anj8Z-00021z-00 for ips@ietf.org; Mon, 02 Feb 2004 13:49:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj56-0001IS-00 for ips@ietf.org; Mon, 02 Feb 2004 13:46:02 -0500 Received: from msgbas1x.cos.agilent.com ([192.25.240.36]) by ietf-mx with esmtp (Exim 4.12) id 1Anj2Z-0000j6-00 for ips@ietf.org; Mon, 02 Feb 2004 13:43:23 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 11A0723E5A; Mon, 2 Feb 2004 11:43:23 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id DD56D14B; Mon, 2 Feb 2004 11:43:22 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 2 Feb 2004 11:43:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Date: Mon, 2 Feb 2004 11:43:21 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Thread-Index: AcPpuDWYHAlXJ9LnSaip6zoZPO4k/QAAFe0g To: , , , Cc: X-OriginalArrivalTime: 02 Feb 2004 18:43:22.0078 (UTC) FILETIME=[6EEEE7E0:01C3E9BC] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ken, Good point. I had missed that the DataIn and R2T are one SNACK type. = Changing that would affect current implementations even if they don't do = bidirectional. While I don't like the one variable, two names thing, = changing it isn't worth that turmoil. Given that, I think we need to keep target DataSN and R2TSN as one = sequence for bidirectional. There is another way to clean things up which is editorially = significantly more radical but which should be less tramatic for = implementations. DataSN (for DataIn PDUs) and R2TSN are really two names for one counter = variable -=20 Write only commands use the counter for R2T PDUs and call it R2TSN Read only commands use the counter for DataIn PDUs and call it DataInSN Bidirectional commands use the counter for both kinds of PDUs and both = names are applied to it depending on the PDU type. The obvious way to clean this up is to give the SNs generated for DataIn = and R2T PDUs a single name such as: DataR2TSN DRSN or even just the current DataSN=20 The justification for DataSN is that both R2T and DataIn are concerned = with the movement of data. (See also iSER which classifies both PDUs as = iSCSI data type PDUs.) Keeping this name would minimize the amount of = editorial change. I know this editorial change would have to be carefully made (there are = 35 instances of R2TSN in the draft most of which would be pretty = straight forward to convert), but in the long run that is probably = significantly less effort than we will expend explaining to people that = DataSN and R2TSN form one sequence. Regards, Pat =20 -----Original Message----- From: Ken Sandars [mailto:ksandars@elipsan.com] Sent: Monday, February 02, 2004 10:12 AM To: THALER,PAT (A-Roseville,ex1); rmangamuri@istor.com; Julian_Satran@il.ibm.com; cbm@rose.hp.com Cc: ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Hi Pat, > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 > Sent: 02 February 2004 18:02 > To: rmangamuri@istor.com; ksandars@elipsan.com;=20 > Julian_Satran@il.ibm.com; cbm@rose.hp.com > Cc: ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for=20 > bidirectional commands >=20 >=20 > I don't think "(read)" should be in there. We don't usually=20 > put read after Data-In. Also, I would rather have it a=20 > separate sentence.=20 >=20 > For read commands, the number of Data-In PDUs the target has=20 > sent for the command. For bidirectional commands, the number=20 > of Data-In PDUs and R2T PDUs the target has sent for the command. >=20 > or=20 >=20 > For bidirectional commands, the number of Data-In PDUs and=20 > R2T PDUs the target has sent for the command. For all other=20 > commands, the number of Data-In PDUs the target has sent for=20 > the command. >=20 > The more I think about it, the more I lean toward leaving=20 > 10.4.8 as it is and changing 3.2.2 to disentangle DataSN from=20 > R2TSN. Is it really worth these gymnastics to reduce=20 > bidirectional command context by one variable? >=20 This would affect Data/R2T SNACK processing, but that's probably a good thing. Perhaps explicit Data SNACK and R2T SNACK types are All that is needed. But is this needed, or just a can-o-worms? Cheers, Ken Sandars Elipsan UK > -----Original Message----- > From: Ramesh Mangamuri [mailto:rmangamuri@istor.com] > Sent: Saturday, January 31, 2004 1:27 PM > To: Ken Sandars; Julian Satran; Mallikarjun C. > Cc: THALER,PAT (A-Roseville,ex1); ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for=20 > bidirectional commands >=20 >=20 > Hello Ken/Julian: >=20 > I have another proposal here for section 10.4.8: >=20 > Suggestion --------------------------- >=20 > 10.4.8 ExpDataSN >=20 > The number of Data-In (read) PDUs (for bidirectional=20 > commands this is R2Ts + Data-Ins) the target has sent for the command. >=20 > This field is reserved if the response code is not Command=20 > Completed > at Target, or the command is Write only command. >=20 >=20 > How does this sound??? >=20 > -Rams > =20 > =09 >=20 >=20 > -----Original Message----- > From: Ken Sandars [mailto:ksandars@elipsan.com]=20 > Sent: Friday, January 30, 2004 12:57 PM > To: 'Julian Satran'; 'Mallikarjun C.' > Cc: pat_thaler@agilent.com; ips@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for=20 > bidirectional commands >=20 > Hi Julo, >=20 > As requested, two alternative proposals for section 10.4.8: >=20 > Suggestion 1 -------------------------- >=20 > 10.4.8 ExpDataSN >=20 > The number of R2T and Data-In (read) PDUs the target has=20 > sent for the > command. >=20 > This field is reserved if the response code is not Command=20 > Completed > at Target. >=20 >=20 > Suggestion 2 -------------------------- >=20 > 10.4.8 ExpDataSN >=20 > The number of R2T and Data-In (read) PDUs the target has=20 > sent for the > command. >=20 > This field is reserved if the response code is not Command=20 > Completed > at Target or the target sent no Data-In PDUs for the command. >=20 > ---------------------------------------- >=20 >=20 > I'm more than happy with any answer which clarifies when the=20 > field is reserved. >=20 >=20 > Thanks, > Ken Sandars > Elipsan UK >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Mallikarjun C. > > Sent: 30 January 2004 20:29 > > To: Ken Sandars > > Cc: 'Julian Satran'; pat_thaler@agilent.com; ips@ietf.org > > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for=20 > > bidirectional commands > >=20 > >=20 > > Ken, > >=20 > > I am not sure we need to restrict the wording > > to commands with at least one Data-In PDU. Do > > you see an issue? > >=20 > > In any case, if you have a specific wording suggestion,=20 > please send it=20 > > to Julian directly (he owns the pen). > >=20 > > Regards. > >=20 > > Mallikarjun > >=20 > >=20 > >=20 > > Ken Sandars wrote: > >=20 > > > Hi Mallikarjun, > > >=20 > > > One final clarification request, and I can sleep easy on > > this topic! > > >=20 > > > Will the new wording for 10.4.8 be more general to indicate that > > > ExpDataSN is the number of DataIn and R2T PDUs that were sent? > > >=20 > > > Is this field only valid for commands which have at least > > one Data-In > > > PDU? > > >=20 > > >=20 > > > Thanks again, > > > Ken Sandars > > > Elipsan UK > > >=20 > >=20 > >=20 > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 2 15:10:18 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06104 for ; Mon, 2 Feb 2004 15:10:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkOF-0008Oz-4h for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 15:09:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12K9p48032291 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 15:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkOE-0008Ok-R7 for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:09:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06058 for ; Mon, 2 Feb 2004 15:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkOB-0003it-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:09:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkNG-0003eE-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:08:51 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnkMV-0003Yr-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkMT-0007YW-Lx; Mon, 02 Feb 2004 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkMK-0007Sg-89 for ips@optimus.ietf.org; Mon, 02 Feb 2004 15:07:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05832 for ; Mon, 2 Feb 2004 15:07:48 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnkMH-0003Xr-00 for ips@ietf.org; Mon, 02 Feb 2004 15:07:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnkLN-0003TE-00 for ips@ietf.org; Mon, 02 Feb 2004 15:06:54 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AnkKg-0003Nr-00; Mon, 02 Feb 2004 15:06:10 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id E4BA340167; Mon, 2 Feb 2004 15:06:09 -0500 (EST) Date: Mon, 2 Feb 2004 12:05:56 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF290570DD1@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF290570DD1@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > To be honest I really don't know about the resources we would be saving > by combining R2TSN and DataSN into one variable in the of bidirectional > . But from logical standpoint, Pat's suggestion makes perfect sense to > me. I think the reason they are the same variable is that they (R2T numbers and DataSN) are in the same number space, due to how SNACK Requests work. To request a given DataSN or a given R2T be retransmitted, the initiator sends a SNACK Request of Type 0. That's a Type 0 for _either_ a R2T or DataSN retransmit. So for the target to keep things clear, it has to use the same number space for both. I think separating the number spaces would be ok, but it means changing SNACK requests so that BiDi commands can tell what's being asked for. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 2 15:48:19 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08196 for ; Mon, 2 Feb 2004 15:48:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ankz0-0005WX-SC for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 15:47:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12KloEE021227 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 15:47:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ankz0-0005WG-3X for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:47:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08190 for ; Mon, 2 Feb 2004 15:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ankyy-0007FT-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:47:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anky6-0007Ay-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:46:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnkxP-00075t-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:46:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkxG-0005Jj-0O; Mon, 02 Feb 2004 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ankx2-0005IR-Om for ips@optimus.ietf.org; Mon, 02 Feb 2004 15:45:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08151 for ; Mon, 2 Feb 2004 15:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ankx1-00074K-00 for ips@ietf.org; Mon, 02 Feb 2004 15:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ankw2-0006yo-00 for ips@ietf.org; Mon, 02 Feb 2004 15:44:46 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1Ankv5-0006o5-00; Mon, 02 Feb 2004 15:43:47 -0500 content-class: urn:content-classes:message Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands Date: Mon, 2 Feb 2004 12:41:46 -0800 MIME-Version: 1.0 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A4@mail1irv.inside.istor.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands Thread-Index: AcPpx+ADs8/GbKkdRtemwkccElLd1QAA/GIg X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: Cc: , , , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >From the discussion so far, I am interested to know Julian's plans on about the below approaches in the case of a bidirectional commands.=20 Implementation 1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Keep the same variable for both so that there is no need to introduce another new SNACK type for R2TSN. Or, Implementation 2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Use different variables for R2TSNs and DataInSN and introduce new SNACK type for R2TSNs. More later..., Rams -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Monday, February 02, 2004 12:06 PM To: Ramesh Mangamuri Cc: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > To be honest I really don't know about the resources we would be saving > by combining R2TSN and DataSN into one variable in the of bidirectional > . But from logical standpoint, Pat's suggestion makes perfect sense to > me. I think the reason they are the same variable is that they (R2T numbers and DataSN) are in the same number space, due to how SNACK Requests work. To request a given DataSN or a given R2T be retransmitted, the initiator sends a SNACK Request of Type 0. That's a Type 0 for _either_ a R2T or DataSN retransmit. So for the target to keep things clear, it has to use the same number space for both. I think separating the number spaces would be ok, but it means changing SNACK requests so that BiDi commands can tell what's being asked for. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 2 15:50:21 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08265 for ; Mon, 2 Feb 2004 15:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl0y-0005gS-CC for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 15:49:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12KnqqL021842 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 15:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl0y-0005gD-6W for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 15:49:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08247 for ; Mon, 2 Feb 2004 15:49:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anl0w-0007Re-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:49:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anl03-0007MG-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:48:56 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnkzA-0007Ga-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 15:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnkzA-0005Wz-Ua; Mon, 02 Feb 2004 15:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ankyy-0005W1-FX for ips@optimus.ietf.org; Mon, 02 Feb 2004 15:47:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08187 for ; Mon, 2 Feb 2004 15:47:45 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ankyw-0007FG-00 for ips@ietf.org; Mon, 02 Feb 2004 15:47:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anky0-0007A3-00 for ips@ietf.org; Mon, 02 Feb 2004 15:46:48 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ankx5-00074w-00 for ips@ietf.org; Mon, 02 Feb 2004 15:45:51 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id DCEF24014A; Mon, 2 Feb 2004 15:45:51 -0500 (EST) Date: Mon, 2 Feb 2004 12:45:39 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: pat_thaler@agilent.com Cc: ksandars@elipsan.com, rmangamuri@istor.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 2 Feb 2004 pat_thaler@agilent.com wrote: > Ken, > > Good point. I had missed that the DataIn and R2T are one SNACK type. > Changing that would affect current implementations even if they don't do > bidirectional. While I don't like the one variable, two names thing, > changing it isn't worth that turmoil. > > Given that, I think we need to keep target DataSN and R2TSN as one > sequence for bidirectional. Not necessarily. We could add a new SNACK type for BiDi commands, say for R2Ts for a BiDi. If we make the new type used only for BiDi commands, we do not impact implementations that do not handle BiDi commands (for which there is no such ambiguity). This would, though, impact existing implementations that do support BiDi commands. I'm not sure if we want to be that tramatic. > There is another way to clean things up which is editorially > significantly more radical but which should be less tramatic for > implementations. This option also would work. > DataSN (for DataIn PDUs) and R2TSN are really two names for one counter > variable - > Write only commands use the counter for R2T PDUs and call it R2TSN > Read only commands use the counter for DataIn PDUs and call it DataInSN > Bidirectional commands use the counter for both kinds of PDUs and both > names are applied to it depending on the PDU type. > > The obvious way to clean this up is to give the SNs generated for DataIn > and R2T PDUs a single name such as: > DataR2TSN > DRSN > or even just the current DataSN > The justification for DataSN is that both R2T and DataIn are concerned > with the movement of data. (See also iSER which classifies both PDUs as > iSCSI data type PDUs.) Keeping this name would minimize the amount of > editorial change. > > I know this editorial change would have to be carefully made (there are > 35 instances of R2TSN in the draft most of which would be pretty > straight forward to convert), but in the long run that is probably > significantly less effort than we will expend explaining to people that > DataSN and R2TSN form one sequence. Indeed. If we decide to keep it one sequence, we should do something like this. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 2 16:16:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11433 for ; Mon, 2 Feb 2004 16:16:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlQ3-0000Ps-O3 for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 16:15:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12LFlqZ001594 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 16:15:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlQ3-0000Pd-HY for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 16:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11409 for ; Mon, 2 Feb 2004 16:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlQ1-0002es-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 16:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlOC-0002Gj-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 16:13:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnlMO-0001oZ-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 16:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlMP-00008M-5v; Mon, 02 Feb 2004 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlLV-0008VD-VM for ips@optimus.ietf.org; Mon, 02 Feb 2004 16:11:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10707 for ; Mon, 2 Feb 2004 16:11:02 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnlLT-0001eO-00 for ips@ietf.org; Mon, 02 Feb 2004 16:11:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnlKP-0001T9-00 for ips@ietf.org; Mon, 02 Feb 2004 16:09:58 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AnlJV-0001LD-00; Mon, 02 Feb 2004 16:09:01 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 2ED614014A; Mon, 2 Feb 2004 16:09:02 -0500 (EST) Date: Mon, 2 Feb 2004 13:08:49 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A4@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A4@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > >From the discussion so far, I am interested to know Julian's plans on > about the below approaches in the case of a bidirectional commands. > > Implementation 1: > ================= > Keep the same variable for both so that there is no > need to introduce another new SNACK type for R2TSN. > > Or, > > Implementation 2: > ================= > Use different variables for R2TSNs and DataInSN and introduce new SNACK > type for R2TSNs. As noted in my other note, I'd like to propose we consider this new SNACK type as applying only for BiDi commands. Otherwise we impact all existing implementations. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 2 20:55:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00323 for ; Mon, 2 Feb 2004 20:55:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpmI-0007oc-OT for ips-archive@odin.ietf.org; Mon, 02 Feb 2004 20:55:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i131t1pC030020 for ips-archive@odin.ietf.org; Mon, 2 Feb 2004 20:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpmG-0007o1-R9 for ips-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 20:55:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00303 for ; Mon, 2 Feb 2004 20:54:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpmE-0006vo-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 20:54:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnplI-0006qE-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 20:54:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnpkN-0006l2-00 for ips-web-archive@ietf.org; Mon, 02 Feb 2004 20:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpkM-0007UU-2H; Mon, 02 Feb 2004 20:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnpkK-0007Ty-1a for ips@optimus.ietf.org; Mon, 02 Feb 2004 20:53:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00270 for ; Mon, 2 Feb 2004 20:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnpkH-0006kL-00 for ips@ietf.org; Mon, 02 Feb 2004 20:52:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnpjL-0006f7-00 for ips@ietf.org; Mon, 02 Feb 2004 20:52:00 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AnpiP-0006V8-00; Mon, 02 Feb 2004 20:51:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: Fw: [Ips] iSCSI: abort task set MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Feb 2004 17:49:13 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A5@mail1irv.inside.istor.com> Thread-Topic: Fw: [Ips] iSCSI: abort task set Thread-Index: AcPpnWQcXYuIl44zQ2C/2MF4MWSV+wAWfgvQ X-Priority: 1 Priority: Urgent Importance: high From: "Ramesh Mangamuri" To: "Julian Satran" , Cc: "Mallikarjun C." , "Eddy Quicksall" , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,PRIORITY_NO_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If I understood this discussion correctly and 10.5.1, I didn't understand why we consider about Commands from other sessions from different initiators. 10.5.1 mentioned clearly that "ABORT TASK SET" only aborts tasks issued via this session. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20 Sent: Monday, February 02, 2004 6:18 AM To: wrstuden@wasabisystems.com Cc: Mallikarjun C.; Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: Re: Fw: [Ips] iSCSI: abort task set I might be a bit late and you might have closed on all this but here is=20 what I think although I have to admit that I don't recall the debate in=20 its entirety ips-admin@ietf.org wrote on 30/01/2004 21:33:55: > On Fri, 30 Jan 2004, Mallikarjun C. wrote: >=20 > > Eddy, > > > > Sorry for not responding sooner, I was checking my old > > notes (but couldn't find relevant ones so far). > > > > The authors' advice on this is the following - > > > > The wait for affected tasks can be done (need to > > pick a point in time as the reference for determining > > the "affected" tasks, regardless of the # of sessions). > > However, an alternative that's also legal is given below. > > > > Bullet (b) should have been: > > > > b) Waits for all target transfer tags to be responded to > > and for all affected tasks in the task set to be > > received (alternatively, the target may plug the CmdSN > > gaps for unreceived commands just as if an abort request > > is received for each individual affected task, refer > > section 6.9 "SCSI timeouts") >=20 > Abort Task Set has to plug the whole CmdSN window on each session?? That > sounds excessive. Plugging the CmdSN hole for an Abort Task seems fine, > since the initiator tells the target explicitly which CmdSN to abort=20 (and > also knows what the highest CmdSN used so far is). But with the Task Set > commands, we _don't_ know the highest CmdSN the initiator has used, only > the highest CmdSN we've seen and MaxCmdSN. >=20 I don't think that the plugging the holes for other initiators is required=20 even if TST is 0. The SCSI tasks are what they are an the SCSI task set has to aborted=20 accordingly. However plugging the holes for the specific initiator seems to fall in the=20 realm of iSCSI and a target may wait or plug as the "bound" of CmdSN is known for that=20 session. And yes abort task-set with TST=3D0 is messy! (for any transport) > Also, for the TST 000b case, what does that mean for other initiators? > Their entire CmdSN window gets filled? Consider an initiator that was > quiescent. If I'm understanding the window-filling correctly, its entire > CmdSN window gets slammed shut. Since its quescent, how will it know its > window got closed? Any non-immediate command it sends will just disapear > as the CmdSN window was filled. It will also see the CmdSN window just > move if the target sends in a PDU. It won't understand why the window > moved of its own accord until it gets a SCSI abort UA. ?? >=20 > Finally, since iSCSI tasks don't get passed to the SCSI layer until the > CmdSN window is satisfied, are CmdSN-pending tasks really in the SCSI=20 task > set? >=20 > Or did I misunderstand something? Please tell me I did as the above=20 looks > messy. :-) >=20 > > Note that the wait on StatSN ack is however > > mandatory. >=20 > Is there any sort of time out? >=20 > > It is good to get this alternative/clarification into > > the final RFC. >=20 > Take care, >=20 > Bill >=20 > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 3 00:54:34 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09779 for ; Tue, 3 Feb 2004 00:54:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AntVf-0007uJ-Kh for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 00:54:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i135s7Te030384 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 00:54:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AntVf-0007tZ-9f for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 00:54:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09750 for ; Tue, 3 Feb 2004 00:54:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AntVc-0001Ox-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 00:54:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AntUf-0001Hg-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 00:53:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AntTg-0001Ax-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 00:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AntTe-0007bG-0y; Tue, 03 Feb 2004 00:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AntSq-0007a9-E4 for ips@optimus.ietf.org; Tue, 03 Feb 2004 00:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09627 for ; Tue, 3 Feb 2004 00:51:08 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AntSn-00015Y-00 for ips@ietf.org; Tue, 03 Feb 2004 00:51:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AntRw-000106-00 for ips@ietf.org; Tue, 03 Feb 2004 00:50:17 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AntR3-0000uI-00; Tue, 03 Feb 2004 00:49:22 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 8CA7D40140; Tue, 3 Feb 2004 00:49:22 -0500 (EST) Date: Mon, 2 Feb 2004 21:49:09 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: Julian Satran , "Mallikarjun C." , Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A5@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A5@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > If I understood this discussion correctly and 10.5.1, I didn't > understand why we consider about Commands from other sessions from > different initiators. 10.5.1 mentioned clearly that "ABORT TASK SET" > only aborts tasks issued via this session. CLEAR TASK SET when TST is 000b does abort tasks from other initiators. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 02:06:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19279 for ; Tue, 3 Feb 2004 02:06:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnudT-0001C9-HZ for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 02:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1376Fim004587 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 02:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnudT-0001Bq-4F for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 02:06:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18667 for ; Tue, 3 Feb 2004 02:06:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnudP-0000XQ-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 02:06:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnucU-0000SS-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 02:05:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnucJ-0000NO-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 02:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnucI-0000T7-QJ; Tue, 03 Feb 2004 02:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnubW-00009n-Kr for ips@optimus.ietf.org; Tue, 03 Feb 2004 02:04:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16484 for ; Tue, 3 Feb 2004 02:04:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnubT-0000Mf-00 for ips@ietf.org; Tue, 03 Feb 2004 02:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnuaX-0000Gy-00 for ips@ietf.org; Tue, 03 Feb 2004 02:03:14 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx with esmtp (Exim 4.12) id 1Anua2-0000AP-00 for ips@ietf.org; Tue, 03 Feb 2004 02:02:42 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate6.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i13728ZP107132; Tue, 3 Feb 2004 07:02:08 GMT Received: from d10ml001.telaviv.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i13726xE093070; Tue, 3 Feb 2004 07:02:07 GMT In-Reply-To: To: Cc: cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 3 Feb 2004 09:02:00 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/02/2004 09:02:01, Serialize complete at 03/02/2004 09:02:01 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Pat, Regardless of the name - the two types of PDUs share the same space and if one is missing it has to be recovered. The target knows exactly what each one was and the initiator asks for both the same way. I don't see a point in changing something that is not broken. Regards, Julo 02/02/2004 19:51 To Julian Satran/Haifa/IBM@IBMIL cc , , , Subject RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands If we really believe that the change would be overly painful for current and in development implementations, I would prefer a change to make R2TSN and DataSN independent for bidirectional commands. The logic: Bidirectional commands already need extra context so carrying an extra SN variable is a very small burden to them. It is poor form to have one variable that is sitting under two names. It creates confusion and is likely to cause interoperability problems in the future. Therefore, it is worth the burden of carrying an extra value in bidirectional command context to forstall interoperability problems. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 30, 2004 3:57 AM To: THALER,PAT (A-Roseville,ex1) Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Will fix the example (thanks Pat and perhaps add the text you suggested). For pratical purposes it should be noted that the only SCSI device that plans to use bidirectional data transfers to-date has different phases for input and output so that block are no mixed. However I assumed always that the space is shared and that data placement is unaffected by the order of PDU's . The SNACK identifies unambiguously to the target what is missing and the initiator has to know only that something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the > combination of the behavior described in 10.4.8 and that described in > 3.2.2 is broken for bidirectional commands. The reason for reporting > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to > send a SNACK if it didn't. > > For example, one could have the following in response to a > bidirectional command: > > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T > > If the ExpDataSN to be reported in the SCSI Response was truly the > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that > DataSN and R2TSN for bidirectional commands form one continuous > undifferentiated series but it is not consistent with the example in > B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with DataSN = 0. > > This is broken because the initiator could not compare the value > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the > ExpDataSN value. The target would also have to keep two separate > counters during processing of bidirectional commands (both named > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so > it can put it in the Response and one of the value of ExpDataSN > indicating the DataSN to put in the next Data-In or R2T PDU it sends > for the command. > > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and > R2TSN form one sequence for bidirectional commands is to allow the > command to maintain one count for DataIn and R2T PDUs rather than > having two counters. If we were willing to forgo that optimization, > then DataSN and R2TSN should have been kept separate. > > In any case, it is incorrect to have two variables for the same > context with the same name. > > One can correct the problem by changing 10.4.8 to say that for > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs > that were sent, then one can maintain one value. One should also > correct the example in B.3. > > One could also correct the problem by changing 3.2.2 so that DataSN > was kept separate from R2TSN in bidirectional commands. In some > senses, this would have been cleaner because it avoids having one > variable with two names but it would require more context per command > and it is probably a bigger change for existing implementations. > > The code in E.2.2 seems ambiguous - it just says if (expDataSN does > not match) but it doesn't define what is considered a match. Neither > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs > is derived. Therefore it would be consistent with either choice. > > Regards, > Pat > > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional > commands > > > On Thu, 29 Jan 2004, Mallikarjun C. wrote: > > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. > > While I'll be honest that I don't understand _why_ R2Ts are factored into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. > > So I don't think it's supposed to be something new. > > Take care, > > Bill > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 3 06:14:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03149 for ; Tue, 3 Feb 2004 06:14:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnyVb-0000tT-3v for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 06:14:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13BENNT003429 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 06:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnyVa-0000tE-Tm for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 06:14:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03144 for ; Tue, 3 Feb 2004 06:14:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnyVX-0001WT-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 06:14:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnyUb-0001Qi-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 06:13:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnyUH-0001LZ-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 06:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnyUG-0000lX-S7; Tue, 03 Feb 2004 06:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnyTf-0000l6-S2 for ips@optimus.ietf.org; Tue, 03 Feb 2004 06:12:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03068 for ; Tue, 3 Feb 2004 06:12:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnyTc-0001KP-00 for ips@ietf.org; Tue, 03 Feb 2004 06:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnySk-0001Ei-00 for ips@ietf.org; Tue, 03 Feb 2004 06:11:26 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1AnyS7-00016U-00; Tue, 03 Feb 2004 06:10:47 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i13BAHZ3104766; Tue, 3 Feb 2004 11:10:17 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i13BAFxE120610; Tue, 3 Feb 2004 11:10:16 GMT In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A4@mail1irv.inside.istor.com> To: "Ramesh Mangamuri" Cc: cbm@rose.hp.com, ips@ietf.org, ips-admin@ietf.org, pat_thaler@agilent.com, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 3 Feb 2004 13:10:13 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 03/02/2004 13:10:16, Serialize complete at 03/02/2004 13:10:16 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 As I stated I think we might have an editorial issue (two names for the same thing) but since this has also some history I would be really reluctant to make any change (except fixing the example and adding a statement explaining that they share the space). Julo "Ramesh Mangamuri" 02/02/2004 22:41 To cc , Julian Satran , , , Subject RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands >From the discussion so far, I am interested to know Julian's plans on about the below approaches in the case of a bidirectional commands. Implementation 1: ================= Keep the same variable for both so that there is no need to introduce another new SNACK type for R2TSN. Or, Implementation 2: ================= Use different variables for R2TSNs and DataInSN and introduce new SNACK type for R2TSNs. More later..., Rams -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] Sent: Monday, February 02, 2004 12:06 PM To: Ramesh Mangamuri Cc: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > To be honest I really don't know about the resources we would be saving > by combining R2TSN and DataSN into one variable in the of bidirectional > . But from logical standpoint, Pat's suggestion makes perfect sense to > me. I think the reason they are the same variable is that they (R2T numbers and DataSN) are in the same number space, due to how SNACK Requests work. To request a given DataSN or a given R2T be retransmitted, the initiator sends a SNACK Request of Type 0. That's a Type 0 for _either_ a R2T or DataSN retransmit. So for the target to keep things clear, it has to use the same number space for both. I think separating the number spaces would be ok, but it means changing SNACK requests so that BiDi commands can tell what's being asked for. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 12:04:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18350 for ; Tue, 3 Feb 2004 12:04:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3xi-0008VM-Ka for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 12:03:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13H3kmM032686 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 12:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3xi-0008V7-BZ for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:03:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18325 for ; Tue, 3 Feb 2004 12:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3xh-0000RE-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:03:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3wf-0000K7-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:02:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3vi-0000E7-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:01:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3vE-0007vA-Ow; Tue, 03 Feb 2004 12:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao3uX-0007k9-AN for ips@optimus.ietf.org; Tue, 03 Feb 2004 12:00:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18162 for ; Tue, 3 Feb 2004 12:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao3uW-00006f-00 for ips@ietf.org; Tue, 03 Feb 2004 12:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao3tb-00001U-00 for ips@ietf.org; Tue, 03 Feb 2004 11:59:32 -0500 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 1Ao3sq-0007ep-00 for ips@ietf.org; Tue, 03 Feb 2004 11:58:48 -0500 Message-ID: <20040203165810.9570.qmail@web41510.mail.yahoo.com> Received: from [200.189.76.132] by web41510.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 08:58:10 PST Date: Tue, 3 Feb 2004 08:58:10 -0800 (PST) From: Antonio Jose Rodrigues Neto To: ips@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-908127225-1075827490=:8764" Subject: [Ips] iSCSI versus FCP Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --0-908127225-1075827490=:8764 Content-Type: text/plain; charset=us-ascii Hi All, Could you help me? Does anyone know any paper that compare SCSI vs FCP? Thanks in advanced Best Regards neto --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --0-908127225-1075827490=:8764 Content-Type: text/html; charset=us-ascii
Hi All,
 
Could you help me?
 
Does anyone know any paper that compare SCSI vs FCP?
 
Thanks in advanced
 
Best Regards
 
neto

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it! --0-908127225-1075827490=:8764-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 12:10:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18868 for ; Tue, 3 Feb 2004 12:10:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao43O-0000ve-VV for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 12:09:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13H9cBC003564 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 12:09:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao43O-0000vP-Rg for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:09:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18805 for ; Tue, 3 Feb 2004 12:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao43N-0001Fn-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:09:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao42Q-00016n-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:08:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao41q-00010J-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao41q-0000cy-92; Tue, 03 Feb 2004 12:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao41K-0000UP-64 for ips@optimus.ietf.org; Tue, 03 Feb 2004 12:07:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18668 for ; Tue, 3 Feb 2004 12:07:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao41I-0000xv-00 for ips@ietf.org; Tue, 03 Feb 2004 12:07:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao40P-0000rF-00 for ips@ietf.org; Tue, 03 Feb 2004 12:06:33 -0500 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 1Ao3zc-0000dg-00 for ips@ietf.org; Tue, 03 Feb 2004 12:05:44 -0500 Message-ID: <20040203170510.12334.qmail@web41510.mail.yahoo.com> Received: from [200.189.76.132] by web41510.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 09:05:10 PST Date: Tue, 3 Feb 2004 09:05:10 -0800 (PST) From: Antonio Jose Rodrigues Neto Subject: Re: [Ips] iSCSI versus FCP To: ips@ietf.org In-Reply-To: <20040203165810.9570.qmail@web41510.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1172150876-1075827910=:12110" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 --0-1172150876-1075827910=:12110 Content-Type: text/plain; charset=us-ascii Sorry, iSCSI vs FCP TIA Best Regards neto Antonio Jose Rodrigues Neto wrote: Hi All, Could you help me? Does anyone know any paper that compare SCSI vs FCP? Thanks in advanced Best Regards neto --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! --0-1172150876-1075827910=:12110 Content-Type: text/html; charset=us-ascii
Sorry,
 
iSCSI vs FCP
 
TIA
 
Best Regards
neto
Antonio Jose Rodrigues Neto <antonio_jose_rodrigues_neto@yahoo.com> wrote:
Hi All,
 
Could you help me?
 
Does anyone know any paper that compare SCSI vs FCP?
 
Thanks in advanced
 
Best Regards
 
neto

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!

Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it! --0-1172150876-1075827910=:12110-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 12:50:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21033 for ; Tue, 3 Feb 2004 12:50:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4g0-0006OK-VQ for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 12:49:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13HnWk1024562 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 12:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4g0-0006O5-P1 for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 12:49:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21019 for ; Tue, 3 Feb 2004 12:49:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4fz-00062J-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:49:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4f6-0005xC-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:48:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4eW-0005ry-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 12:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4eW-0006F9-RA; Tue, 03 Feb 2004 12:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao4e4-0006Da-5s for ips@optimus.ietf.org; Tue, 03 Feb 2004 12:47:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20896 for ; Tue, 3 Feb 2004 12:47:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao4e2-0005qS-00 for ips@ietf.org; Tue, 03 Feb 2004 12:47:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao4d7-0005lJ-00 for ips@ietf.org; Tue, 03 Feb 2004 12:46:34 -0500 Received: from mail4.nsc.com ([12.151.32.19] helo=SCNTRDCSS5.nsc.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao4cT-0005aK-00 for ips@ietf.org; Tue, 03 Feb 2004 12:45:53 -0500 Received: from 139.187.179.130 by SCNTRDCSS5.nsc.com with ESMTP (-Hi-); Tue, 03 Feb 2004 09:45:10 -0800 X-Server-Uuid: 7C23B877-2DEF-4040-80B8-CC46A9B05345 Received: from mailhost1.ia.nsc.com by scmh1.nsc.com with ESMTP; Tue, 3 Feb 2004 09:45:06 -0800 Received: from nsc.com (richardm.ia.nsc.com [147.5.204.105]) by mailhost1.ia.nsc.com (Postfix) with ESMTP id 18B867BC0B; Tue, 3 Feb 2004 10:45:06 -0700 (MST) Message-ID: <401FDEF8.2050907@nsc.com> Date: Tue, 03 Feb 2004 10:48:40 -0700 From: "Richard Masoner" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Antonio Jose Rodrigues Neto" cc: ips@ietf.org Subject: Re: [Ips] iSCSI versus FCP References: <20040203170510.12334.qmail@web41510.mail.yahoo.com> In-Reply-To: <20040203170510.12334.qmail@web41510.mail.yahoo.com> MIME-Version: 1.0 X-WSS-ID: 6C0101991GS159839-10-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Antonio Jose Rodrigues Neto asked about papers comparing iSCSI with FCP: > iSCSI vs FCP You can find a handful of cites here: http://citeseer.nj.nec.com/context/1836960/0 These are all at least a couple of years old. RFM _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 13:19:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22808 for ; Tue, 3 Feb 2004 13:19:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao588-0002Hu-OP for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 13:18:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13IIanT008788 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 13:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao588-0002Hf-Hf for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 13:18:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22794 for ; Tue, 3 Feb 2004 13:18:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao586-0001va-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 13:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao579-0001qJ-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 13:17:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao56b-0001lE-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 13:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao56a-00029n-PS; Tue, 03 Feb 2004 13:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao569-00028S-Gi for ips@optimus.ietf.org; Tue, 03 Feb 2004 13:16:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22745 for ; Tue, 3 Feb 2004 13:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao567-0001kV-00 for ips@ietf.org; Tue, 03 Feb 2004 13:16:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao55C-0001fl-00 for ips@ietf.org; Tue, 03 Feb 2004 13:15:35 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao54U-0001W4-00; Tue, 03 Feb 2004 13:14:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Tue, 3 Feb 2004 10:12:33 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DD9@mail1irv.inside.istor.com> Thread-Topic: Fw: [Ips] iSCSI: abort task set Thread-Index: AcPqGVl7sbeTVYQEREmgM0HxrshldAAZ4OoQ From: "Ramesh Mangamuri" To: Cc: "Julian Satran" , "Mallikarjun C." , "Eddy Quicksall" , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hence we only need to consider this multiple session stuff for CLEAR TASK SET only. I have got confused by the subject of this mail -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Monday, February 02, 2004 9:49 PM To: Ramesh Mangamuri Cc: Julian Satran; Mallikarjun C.; Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > If I understood this discussion correctly and 10.5.1, I didn't > understand why we consider about Commands from other sessions from > different initiators. 10.5.1 mentioned clearly that "ABORT TASK SET" > only aborts tasks issued via this session. CLEAR TASK SET when TST is 000b does abort tasks from other initiators. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 14:03:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24811 for ; Tue, 3 Feb 2004 14:03:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5op-0004ba-6D for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 14:02:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13J2huU017696 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 14:02:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5oo-0004bL-TT for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 14:02:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24800 for ; Tue, 3 Feb 2004 14:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5om-00071S-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 14:02:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5nm-0006va-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 14:01:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5nE-0006q0-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 14:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5nD-0004U1-I2; Tue, 03 Feb 2004 14:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5mm-0004S1-MW for ips@optimus.ietf.org; Tue, 03 Feb 2004 14:00:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24735 for ; Tue, 3 Feb 2004 14:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5mk-0006on-00 for ips@ietf.org; Tue, 03 Feb 2004 14:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5lr-0006ip-00 for ips@ietf.org; Tue, 03 Feb 2004 13:59:40 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao5ks-0006Wj-00; Tue, 03 Feb 2004 13:58:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Tue, 3 Feb 2004 10:56:55 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A6@mail1irv.inside.istor.com> Thread-Topic: Fw: [Ips] iSCSI: abort task set Thread-Index: AcPqGVl7sbeTVYQEREmgM0HxrshldAAZ4OoQAAFG5+A= From: "Ramesh Mangamuri" To: "Ramesh Mangamuri" , Cc: "Julian Satran" , "Mallikarjun C." , "Eddy Quicksall" , , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I wanted to hold on my previous mail regarding ABORT TASK SET because of the following information that I run across.=20 As per SCSI Spec if TST =3D 000b, then SCSI Target maintains task set = per LUN for all initiators. So if there are two iSCSI initiators that have different sessions opened to the same LUN on a target, then all tasks (from both initiators) will be entered into the same SCSI TASK SET(assuming TST=3D000b).If one of the initiators issues ABORT TASK SET, don't the tasks from other initiator get affected???????( because they are in the same task set) Can some one please clarify this one???? -----Original Message----- From: Ramesh Mangamuri=20 Sent: Tuesday, February 03, 2004 10:13 AM To: wrstuden@wasabisystems.com Cc: Julian Satran; Mallikarjun C.; Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set Hence we only need to consider this multiple session stuff for CLEAR TASK SET only. I have got confused by the subject of this mail -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Monday, February 02, 2004 9:49 PM To: Ramesh Mangamuri Cc: Julian Satran; Mallikarjun C.; Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > If I understood this discussion correctly and 10.5.1, I didn't > understand why we consider about Commands from other sessions from > different initiators. 10.5.1 mentioned clearly that "ABORT TASK SET" > only aborts tasks issued via this session. CLEAR TASK SET when TST is 000b does abort tasks from other initiators. Take care, Bill _______________________________________________ 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 exim@www1.ietf.org Tue Feb 3 15:52:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00644 for ; Tue, 3 Feb 2004 15:52:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7WB-0000eA-Ol for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 15:51:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13KpZV3002485 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 15:51:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7WB-0000e0-LG for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 15:51:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00605 for ; Tue, 3 Feb 2004 15:51:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7WA-0001yi-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 15:51:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao7VH-0001tX-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao7Ui-0001ok-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 15:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Ug-00007O-M5; Tue, 03 Feb 2004 15:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7U7-000052-NK for ips@optimus.ietf.org; Tue, 03 Feb 2004 15:49:27 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00369; Tue, 3 Feb 2004 15:49:25 -0500 (EST) Message-Id: <200402032049.PAA00369@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 03 Feb 2004 15:49:25 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-fcip-slp-08.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Finding FCIP Entities Using SLPv2 Author(s) : D. Peterson Filename : draft-ietf-ips-fcip-slp-08.txt Pages : 12 Date : 2004-2-3 This document defines the use of Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP Entities [FCIP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fcip-slp-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-fcip-slp-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: <2004-2-3150107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-slp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-slp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3150107.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 16:55:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07436 for ; Tue, 3 Feb 2004 16:55:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8VJ-0005Ca-R2 for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 16:54:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13LsjXH019996 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 16:54:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8VJ-0005CR-Jq for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 16:54:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07417 for ; Tue, 3 Feb 2004 16:54:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8VH-0004cH-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:54:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8UJ-0004WD-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:53:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8Te-0004R5-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8Td-0004yw-B6; Tue, 03 Feb 2004 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8TI-0004yc-DE for ips@optimus.ietf.org; Tue, 03 Feb 2004 16:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07340 for ; Tue, 3 Feb 2004 16:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8TG-0004PL-00 for ips@ietf.org; Tue, 03 Feb 2004 16:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8SI-0004HV-00 for ips@ietf.org; Tue, 03 Feb 2004 16:51:38 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8RS-00041c-00 for ips@ietf.org; Tue, 03 Feb 2004 16:50:46 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 13:50:17 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 13:50:16 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Feb 2004 13:50:16 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 13:50:15 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 13:50:23 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 13:49:25 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [IPS] iSCSI: Text Command with F Bit set to 0 Date: Tue, 3 Feb 2004 13:50:13 -0800 Message-ID: Thread-Topic: [IPS] iSCSI: Text Command with F Bit set to 0 Thread-Index: AcPqRtOvxV8XwYB7QomxUQ4LqE/4QwAWEgZg From: "Lakshmi Ramasubramanian" To: "Julian Satran" , X-OriginalArrivalTime: 03 Feb 2004 21:49:26.0091 (UTC) FILETIME=[979DD9B0:01C3EA9F] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 10.10.4 Target Transfer Tag says that if the target sets F bit to 0, and C Bit to 1 in Text Response, initiator MUST send an emptry Text Request with the same Target Transfer Tag given by the target in the response. Is the Command Sequence Number (CmdSN) incremented each time the initiator sends the empty text request? Or, should it use the same CmdSN it had specified in the initial Text Request? thanks! -lakshmi _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 16:56:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07548 for ; Tue, 3 Feb 2004 16:56:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8WR-0005HK-NS for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 16:55:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Ltt9m020282 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 16:55:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8WR-0005Gw-HL for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 16:55:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07502 for ; Tue, 3 Feb 2004 16:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8WP-0004me-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:55:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8VX-0004eP-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:54:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8Ua-0004Wv-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 16:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8Ub-00055y-Df; Tue, 03 Feb 2004 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8UF-00055H-GC for ips@optimus.ietf.org; Tue, 03 Feb 2004 16:53:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07380 for ; Tue, 3 Feb 2004 16:53:36 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8UD-0004VK-00 for ips@ietf.org; Tue, 03 Feb 2004 16:53:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8TF-0004PD-00 for ips@ietf.org; Tue, 03 Feb 2004 16:52:37 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8SF-0004Fd-00; Tue, 03 Feb 2004 16:51:35 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 287104014A; Tue, 3 Feb 2004 16:51:35 -0500 (EST) Date: Tue, 3 Feb 2004 13:51:21 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: Julian Satran , "Mallikarjun C." , Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A6@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A6@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 3 Feb 2004, Ramesh Mangamuri wrote: > I wanted to hold on my previous mail regarding ABORT TASK SET because of > the following information that I run across. > > As per SCSI Spec if TST = 000b, then SCSI Target maintains task set per > LUN for all initiators. So if there are two iSCSI initiators that have > different sessions opened to the same LUN on a target, then all tasks > (from both initiators) will be entered into the same SCSI TASK > SET(assuming TST=000b).If one of the initiators issues ABORT TASK SET, > don't the tasks from other initiator get affected???????( because they > are in the same task set) > > Can some one please clarify this one???? >From SAM-2 about ABORT TASK SET: All tasks from that initiator in the task set serviced by the logical unit shall be aborted. Tasks from other initiators or in other task sets shall not be aborted. ABORT TASK SET always only effects tasks from the initiator requesting it. CLEAR TASK SET always effects all tasks in the task set. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 17:24:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09039 for ; Tue, 3 Feb 2004 17:24:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8xh-0006ya-Mp for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 17:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13MO5Di026815 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 17:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8xh-0006yQ-GK for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 17:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08971 for ; Tue, 3 Feb 2004 17:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8xf-0000Fm-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:24:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8wa-00000X-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:22:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8vg-0007fG-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8vh-0006lH-Er; Tue, 03 Feb 2004 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao8va-0006kd-I9 for ips@optimus.ietf.org; Tue, 03 Feb 2004 17:21:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08789 for ; Tue, 3 Feb 2004 17:21:51 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8vY-0007dh-00 for ips@ietf.org; Tue, 03 Feb 2004 17:21:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao8uV-0007WD-00 for ips@ietf.org; Tue, 03 Feb 2004 17:20:47 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ao8ts-0007Pw-00 for ips@ietf.org; Tue, 03 Feb 2004 17:20:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id E18CB4013A; Tue, 3 Feb 2004 17:20:06 -0500 (EST) Date: Tue, 3 Feb 2004 14:19:53 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Lakshmi Ramasubramanian Cc: Julian Satran , ips@ietf.org Subject: Re: [IPS] iSCSI: Text Command with F Bit set to 0 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 3 Feb 2004, Lakshmi Ramasubramanian wrote: > Section 10.10.4 Target Transfer Tag says that if the target sets F bit > to 0, > and C Bit to 1 in Text Response, initiator MUST send an emptry Text > Request > with the same Target Transfer Tag given by the target in the response. > > Is the Command Sequence Number (CmdSN) incremented each time the > initiator > sends the empty text request? Or, should it use the same CmdSN it had > specified in the initial Text Request? It certainly should not use the same CmdSN as the initial request. The CmdSN window will keep moving, and if the follow-up PDU's CmdSN is outside of the CmdSN window it will get dropped. The initiator has two choices here, and they are the same ones as for a SCSI command. Either send the PDU non-immediate and then incriment CmdSN, or send the command immediate and use the next-command CmdSN. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 17:45:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10174 for ; Tue, 3 Feb 2004 17:45:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9Hj-0000Zq-KZ for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 17:44:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Mil75002212 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 17:44:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9Hj-0000Zb-FW for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 17:44:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10055 for ; Tue, 3 Feb 2004 17:44:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9Hg-0002xY-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:44:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9Fl-0002V4-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:42:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao9Eh-0002HA-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:41:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ao98R-0007RU-Bh for ips-web-archive@ietf.org; Tue, 03 Feb 2004 17:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao98H-0008Bn-MX; Tue, 03 Feb 2004 17:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao97x-0008BQ-GD for ips@optimus.ietf.org; Tue, 03 Feb 2004 17:34:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09866 for ; Tue, 3 Feb 2004 17:34:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao97v-0001nF-00 for ips@ietf.org; Tue, 03 Feb 2004 17:34:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao971-0001i7-00 for ips@ietf.org; Tue, 03 Feb 2004 17:33:44 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao96D-0001XA-00 for ips@ietf.org; Tue, 03 Feb 2004 17:32:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fw: [Ips] iSCSI: abort task set Date: Tue, 3 Feb 2004 14:31:22 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A7@mail1irv.inside.istor.com> Thread-Topic: Fw: [Ips] iSCSI: abort task set Thread-Index: AcPqn8Qk0cX6s7SiREK9rzTNa2QvVgABT1Cw From: "Ramesh Mangamuri" To: Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ultimately the iSCSI TMF(ABORT TASK SET) will be handed over to SCSI Layer. How the SCSI layer differentiates between different initiator tasks that present in the same task set???=20 -----Original Message----- Julian Satran From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Tuesday, February 03, 2004 1:51 PM To: Ramesh Mangamuri Cc: Julian Satran; Mallikarjun C.; Eddy Quicksall; ips@ietf.org; ips-admin@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set On Tue, 3 Feb 2004, Ramesh Mangamuri wrote: > I wanted to hold on my previous mail regarding ABORT TASK SET because of > the following information that I run across. > > As per SCSI Spec if TST =3D 000b, then SCSI Target maintains task set per > LUN for all initiators. So if there are two iSCSI initiators that have > different sessions opened to the same LUN on a target, then all tasks > (from both initiators) will be entered into the same SCSI TASK > SET(assuming TST=3D000b).If one of the initiators issues ABORT TASK = SET, > don't the tasks from other initiator get affected???????( because they > are in the same task set) > > Can some one please clarify this one???? >From SAM-2 about ABORT TASK SET: All tasks from that initiator in the task set serviced by the logical unit shall be aborted. Tasks from other initiators or in other task sets shall not be aborted. ABORT TASK SET always only effects tasks from the initiator requesting it. CLEAR TASK SET always effects all tasks in the task set. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 18:28:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12917 for ; Tue, 3 Feb 2004 18:28:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9xI-000139-Dk for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 18:27:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13NRiGI004029 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 18:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9xH-00012u-Mw for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12914 for ; Tue, 3 Feb 2004 18:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9xE-0007G1-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9wH-0007BV-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:26:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9vc-00077B-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9vc-0000te-KS; Tue, 03 Feb 2004 18:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao9vN-0000sK-Ew for ips@optimus.ietf.org; Tue, 03 Feb 2004 18:25:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12873 for ; Tue, 3 Feb 2004 18:25:41 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9vK-00076V-00 for ips@ietf.org; Tue, 03 Feb 2004 18:25:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao9uN-00071V-00 for ips@ietf.org; Tue, 03 Feb 2004 18:24:43 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ao9to-0006wd-00 for ips@ietf.org; Tue, 03 Feb 2004 18:24:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3074140138; Tue, 3 Feb 2004 18:24:09 -0500 (EST) Date: Tue, 3 Feb 2004 15:23:55 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Ramesh Mangamuri Cc: ips@ietf.org Subject: RE: Fw: [Ips] iSCSI: abort task set In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A7@mail1irv.inside.istor.com> Message-ID: References: <7D036BD3216A084DB1BD9D62BCEAF2905717A7@mail1irv.inside.istor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 3 Feb 2004, Ramesh Mangamuri wrote: > Ultimately the iSCSI TMF(ABORT TASK SET) will be handed over to SCSI > Layer. How the SCSI layer differentiates between different initiator > tasks that present in the same task set??? The SCSI layer has to have some linkage so that it can send data back to the initiator. So for ABORT TASK SET, all it has to do is identify the I_T nexus for the TMF(ATS) and then find all tasks that have that linkage. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 18:59:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13792 for ; Tue, 3 Feb 2004 18:59:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoARJ-00035f-Vs for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 18:58:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Nwj5Q011878 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 18:58:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoARJ-00035V-Q7 for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 18:58:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13781 for ; Tue, 3 Feb 2004 18:58:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoARG-0002RS-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:58:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAQL-0002MP-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:57:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoAPc-0002HQ-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 18:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAPd-00031Z-7g; Tue, 03 Feb 2004 18:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAPQ-00030u-1L for ips@optimus.ietf.org; Tue, 03 Feb 2004 18:56:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13745 for ; Tue, 3 Feb 2004 18:56:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAPM-0002GR-00 for ips@ietf.org; Tue, 03 Feb 2004 18:56:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAOP-0002Ak-00 for ips@ietf.org; Tue, 03 Feb 2004 18:55:46 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AoANa-00020K-00 for ips@ietf.org; Tue, 03 Feb 2004 18:54:55 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13NsL709829 for ; Tue, 3 Feb 2004 17:54:21 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 00:54:19 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC500@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipswg (E-mail)" Cc: "Mike MacFaden (E-mail)" , "Allison Mankin (E-mail)" Date: Wed, 4 Feb 2004 00:54:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ips] MIB Doctors starting review Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I have to appology that it took so (far too) long before we got MIB doctor review started. Mike MacFaden and I are doing the reviews. We hope to be posting our findings soon. Thanks, Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 19:15:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14196 for ; Tue, 3 Feb 2004 19:15:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAh1-0004JA-69 for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 19:14:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i140Exoh016554 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 19:14:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAh0-0004Iv-Vf for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 19:14:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14183 for ; Tue, 3 Feb 2004 19:14:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAgz-0003zl-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 19:14:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAfw-0003u7-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 19:13:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoAfT-0003oE-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 19:13:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAfS-0004Bq-SX; Tue, 03 Feb 2004 19:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoASJ-00037E-70 for ips@optimus.ietf.org; Tue, 03 Feb 2004 18:59:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13828 for ; Tue, 3 Feb 2004 18:59:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoASG-0002X7-00 for ips@ietf.org; Tue, 03 Feb 2004 18:59:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoARL-0002SD-00 for ips@ietf.org; Tue, 03 Feb 2004 18:58:48 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AoAQy-0002Mn-00 for ips@ietf.org; Tue, 03 Feb 2004 18:58:24 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13Nvp712139 for ; Tue, 3 Feb 2004 17:57:51 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 00:57:50 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC501@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'ips@ietf.org'" Cc: "Allison Mankin (E-mail)" , "Mike MacFaden (E-mail)" Date: Wed, 4 Feb 2004 00:57:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ips] MIB Doctor review of: draft-ietf-ips-scsi-mib-06.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Compiles clean with SMICng. Smilint causes soem warnings, see below. More or less serious: - I see in ScsiIdentifier DESCRIPTION clause: The format depends on the transport used: - SPI: only bits:0-3 for a port identifier (MSB is 0 and LSB is 3). Other bits must be zero. - SPI: identifier of a device is a zero-length octet string. So how does one know if it is one or the other? Same for the other transports - I see HrSWInstalledIndexOrZero TC. This runs the risk of name clash in the future. Would it be so bad to name it ScsiHrSWInstalledIndexOrZero - I see: scsiObjects OBJECT IDENTIFIER ::= { scsiModule 1 } scsiNotifications OBJECT IDENTIFIER ::= { scsiModule 2 } scsiConformance OBJECT IDENTIFIER ::= { scsiModule 3 } scsiTransportTypes OBJECT IDENTIFIER ::= { scsiObjects 1 } scsiGeneral OBJECT IDENTIFIER ::= { scsiObjects 2 } scsiInitiator OBJECT IDENTIFIER ::= { scsiObjects 3 } scsiTarget OBJECT IDENTIFIER ::= { scsiObjects 4 } scsiLogicalUnit OBJECT IDENTIFIER ::= { scsiObjects 5 } I think I would put the transportTypes under an ADMIN tree, so I would define it somethink aka: scsiAdmin OBJECT IDENTIFIER ::= { scsiModule 1 } scsiObjects OBJECT IDENTIFIER ::= { scsiModule 2 } scsiNotifications OBJECT IDENTIFIER ::= { scsiModule 3 } scsiConformance OBJECT IDENTIFIER ::= { scsiModule 4 } scsiTransportTypes OBJECT IDENTIFIER ::= { scsiAdmin 1 } scsiGeneral OBJECT IDENTIFIER ::= { scsiObjects 1 } scsiInitiator OBJECT IDENTIFIER ::= { scsiObjects 2 } scsiTarget OBJECT IDENTIFIER ::= { scsiObjects 3 } scsiLogicalUnit OBJECT IDENTIFIER ::= { scsiObjects 4 } Maybe it is just me. - scsiInstanceTable I do not see any text that specifies persistency behaviour over a restart or reboot. We need to specify that. Same for scsiDeviceTable... and possibly other tables, pls check! - scsiInstScsiNotificationsEnable DESCRIPTION clause claims: " This object indicates whether notifications defined in this MIB will be sent." which is not true. The actual sending is under control of the MIB modules in RFC3413. This object indicates (I think) if notifications get generated. - scsiDeviceRole and scsiPortRole WOuld it make sense to define a TC for ScsiRole ?? - scsiIntrPortOutCommands and scsiIntrPortHSOutCommands If I understood the introductory text correctly, then the first one will always be the low order 32 bit of the second one. If so, pls specify so in the DESCRIPTION clause. Same question for other such combinations - For all Counter32 and Counter64 objects I do not see any mention of a discontinuity timer as required/recommended by RFC2578. - scsiDscTgtRowStatus DESCRIPTION clause should express if any columns can be changed while row is active. It should also describe which objects MUST have valid values before a row can be made active All as per RowStatus TC in RFC2579 No discussion of persistency after restart/reboot for this table Same question for (at least some) other RowStatus objects, for example scsiAuthIntrRowStatus - For scsiAuthIntrTgtPortIndex What if there is a entry/row with this index as zero and one or more with a non-zero index. Do the counters than get incremented in both the zero-indexed enrty and in the specific entry? May want to add some words on the fact if this situation is valid and if so what the behaviour is. - scsiLuPeripheralType not having quick access to the ANSI spec, does it make sense to enumerate the values? - Did you do this consciously: -- scsiNotifications OBJECT IDENTIFIER ::= { scsiModule 2 } scsiNotificationsPrefix OBJECT IDENTIFIER ::= { scsiNotifications 0 } I myslef probably would have used scsiNotifications OBJECT IDENTIFIER ::= { scsiModule 0 } and then the notifications can go underneath that right away. Not a showstopper. Just asking. - I think that this is a typical MIB Module where I would specify two MODULE-COMPLIANCE statements, one for FullCompliance amd one for ReadOnlyCompliance (RFC3289 is a good example of how to do it). Kind of nit picking, yet for consistency in MIB documents it would be really good to address these: - In the abstract: This memo defines a Management Information Base (MIB) for Small should read: This memo defines a portion of the Management Information Base (MIB), namely managed objects for Small - In various places where you speak of "The SCSI MIB" it is better to speak of "The SCSI MIB Module". There is only one MIB which consists of many MIB Modules. - Section 5, s/the SNMP tables/the MIB tables/ !? - I would add DISPLAY-HINTS for the TEXTUAL CONVENTIONs In fact smilint gives these warnings because of them being absent: .\SCSI-MIB:87: [5] {type-without-format} warning: type `ScsiIndexValue' has no format specification .\SCSI-MIB:94: [5] {type-without-format} warning: type `ScsiPortIndexValueOrZero' has no format specification .\SCSI-MIB:108: [5] {type-without-format} warning: type `ScsiIndexValueOrZero' has no format specification .\SCSI-MIB:194: [5] {type-without-format} warning: type `ScsiIdCodeSet' has no format specification .\SCSI-MIB:208: [5] {type-without-format} warning: type `ScsiIdAssociation' has no format specification .\SCSI-MIB:223: [5] {type-without-format} warning: type `ScsiIdType' has no format specification .\SCSI-MIB:254: [5] {type-without-format} warning: type `HrSWInstalledIndexOrZero' has no format specification Real nits: - I think I would change scsiModule MODULE-IDENTITY into scsiMIB MODULE-IDENTITY it much more common practice. - I see: SYNTAX Unsigned32(1..4294967295) we normally leave space before the open parenthesis - I see the use of "octets" and "bytes" used, even in the same DESCRIPTION clause. I can live with it, but it seems inconsistent does it not? Admin issues - I see references to RFC2573, RFC2575... These have been obsoleted by RFC3413 and 3415 respectively Actually I do not see that you have a citation to these. To 3413, you probably SHOULD have a citation near text that explains that the ultimate control on sending of notifications is controled by the MIB modules in that RFC. - I think you must add RFC3411 as a normative reference, you IMPORT from it Last ... I have not (yet) checked if sect 11 is correct. Thanks, Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 3 21:04:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17064 for ; Tue, 3 Feb 2004 21:04:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCOT-0001MH-4H for ips-archive@odin.ietf.org; Tue, 03 Feb 2004 21:03:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1423vJS005218 for ips-archive@odin.ietf.org; Tue, 3 Feb 2004 21:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCOS-0001M5-UD for ips-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 21:03:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17061 for ; Tue, 3 Feb 2004 21:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoCOQ-0006J3-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 21:03:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCNP-0006Dv-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 21:02:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoCMh-00068f-00 for ips-web-archive@ietf.org; Tue, 03 Feb 2004 21:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCMb-0001IB-GK; Tue, 03 Feb 2004 21:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCMS-0001Hn-Om for ips@optimus.ietf.org; Tue, 03 Feb 2004 21:01:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17003 for ; Tue, 3 Feb 2004 21:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoCMQ-00067Z-00 for ips@ietf.org; Tue, 03 Feb 2004 21:01:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCLV-000629-00 for ips@ietf.org; Tue, 03 Feb 2004 21:00:54 -0500 Received: from p11.n-lapop01.stsn.com ([12.129.240.11] helo=s-utl01-lanoc.stsn.com) by ietf-mx with smtp (Exim 4.12) id 1AoCLA-0005wR-00; Tue, 03 Feb 2004 21:00:32 -0500 Received: (from ivvt2dxrc11 [10.1.167.17]) by s-utl01-lanoc.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004020317522913696 ; Tue, 03 Feb 2004 17:52:30 -0800 Message-ID: <002401c3eac1$97cfc6b0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: , "Ramesh Mangamuri" Cc: "Julian Satran" , "Mallikarjun C." , , References: <7D036BD3216A084DB1BD9D62BCEAF2905717A6@mail1irv.inside.istor.com> Subject: Re: Fw: [Ips] iSCSI: abort task set Date: Tue, 3 Feb 2004 20:52:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Regarding TST==0, that was my error, it is as Bill says. I was thinking CLEAR TASK SET when I said that but I put it under ABORT TASK SET. Eddy ----- Original Message ----- From: To: "Ramesh Mangamuri" Cc: "Julian Satran" ; "Mallikarjun C." ; "Eddy Quicksall" ; ; Sent: Tuesday, February 03, 2004 4:51 PM Subject: RE: Fw: [Ips] iSCSI: abort task set > On Tue, 3 Feb 2004, Ramesh Mangamuri wrote: > > > I wanted to hold on my previous mail regarding ABORT TASK SET because of > > the following information that I run across. > > > > As per SCSI Spec if TST = 000b, then SCSI Target maintains task set per > > LUN for all initiators. So if there are two iSCSI initiators that have > > different sessions opened to the same LUN on a target, then all tasks > > (from both initiators) will be entered into the same SCSI TASK > > SET(assuming TST=000b).If one of the initiators issues ABORT TASK SET, > > don't the tasks from other initiator get affected???????( because they > > are in the same task set) > > > > Can some one please clarify this one???? > > From SAM-2 about ABORT TASK SET: > > All tasks from that initiator in the task set serviced by the logical unit > shall be aborted. Tasks from other initiators or in other task sets shall > not be aborted. > > > > ABORT TASK SET always only effects tasks from the initiator requesting it. > CLEAR TASK SET always effects all tasks in the task set. > > Take care, > > Bill > > _______________________________________________ > 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 exim@www1.ietf.org Wed Feb 4 05:46:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29868 for ; Wed, 4 Feb 2004 05:46:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKXQ-0002XO-80 for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 05:45:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14AjigA009754 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 05:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKXP-0002XF-TC for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 05:45:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29758 for ; Wed, 4 Feb 2004 05:45:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoKXM-00038l-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 05:45:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoKWE-0002vl-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 05:44:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AoKVT-0002m2-04 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 05:43:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AoKO9-0005jF-V9 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 05:36:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKO3-0001P9-On; Wed, 04 Feb 2004 05:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoKNA-0001Gg-Qv for ips@optimus.ietf.org; Wed, 04 Feb 2004 05:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29464 for ; Wed, 4 Feb 2004 05:35:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoKN7-00023y-00 for ips@ietf.org; Wed, 04 Feb 2004 05:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoKM8-0001yR-00 for ips@ietf.org; Wed, 04 Feb 2004 05:34:04 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AoKLx-0001tH-00 for ips@ietf.org; Wed, 04 Feb 2004 05:33:53 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i14AXL325908 for ; Wed, 4 Feb 2004 04:33:22 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 4 Feb 2004 11:33:20 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC50A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipswg (E-mail)" Cc: "Mike MacFaden (E-mail)" , "Allison Mankin (E-mail)" Date: Wed, 4 Feb 2004 11:33:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Ips] FW: Initial review of http://www.ietf.org/internet-drafts/draft-i etf-ips-fcmgmt-mib-04.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Thanks Mike for the first MIB Doctor review. authors/wg members, Pls copy Mike on any responses, cause I suspect he is not subscribed to IPS mailinglist (Mike tell us if you are, in which case people do not specifically have to copy you). Thanks, Bert -----Original Message----- From: Michael MacFaden [mailto:mrm@kazeon.com] Sent: woensdag 4 februari 2004 7:02 To: Wijnen, Bert (Bert) Cc: Anurag Maunder Subject: Initial review of http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt Hi Bert, My review of the fiber channel management MIB module: http://www.macfaden.com/ietf/fc-mgmt-mib-4-reviewed.txt Regards, Mike _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 4 07:20:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03174 for ; Wed, 4 Feb 2004 07:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoM0k-00082n-NP for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 07:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14CK6PY030918 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 07:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoM0j-00082b-DQ for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 07:20:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03159 for ; Wed, 4 Feb 2004 07:20:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoM0i-0004t7-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 07:20:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLzl-0004nK-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 07:19:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoLyn-0004ha-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 07:18:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLyi-0007tc-Mv; Wed, 04 Feb 2004 07:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoLxt-0007rU-B7 for ips@optimus.ietf.org; Wed, 04 Feb 2004 07:17:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03073 for ; Wed, 4 Feb 2004 07:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoLxs-0004c4-00 for ips@ietf.org; Wed, 04 Feb 2004 07:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoLwy-0004X3-00 for ips@ietf.org; Wed, 04 Feb 2004 07:16:13 -0500 Received: from [80.74.102.50] (helo=SANSRV1.SAN-RAD.CO.IL) by ietf-mx with esmtp (Exim 4.12) id 1AoLwE-0004Qs-00 for ips@ietf.org; Wed, 04 Feb 2004 07:15:27 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 4 Feb 2004 14:17:43 +0200 Message-ID: <6CD55BEE318E0D45B89043D74720E22A09534A@sansrv1.san-rad.co.il> Thread-Topic: iSCSI MIB compliance with iSCSI draft 20 Thread-Index: AcPrGOQOW8nefm4lThy6+hM6JVnPAA== From: "Michele Hallak - Stamler" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] iSCSI MIB compliance with iSCSI draft 20 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Working on an implementation of the iSCSI MIB, we encountered the = following problems: 1. Minor Issue: What is the meaning of Initiator Portal Tag? It seems = that it's there for historical reason. If confirmed, the object: = iscsiIntrPortalTag and therefore the all table: = iscsiIntrPortalAttributesTable should be removed. 2. Target Portal Group Tag: The scope of the tag is per target device = (node) and not per iSCSI instance. The actual MIB allows to define = several target portals whithin one entity without any relation to the = target device node.=20 Therefore, if I want to define a portal (IP address + TCP Port) with a = tag "x" (for one target device) and with a tag "y" (for a different = target device), I have to set two identical rows with just the object = "tag" different.(And no direct connection between the portal and the = target node device, just via the SCSI target port name of the SCSI MIB). = It is generally not the usage. I suggest to add an index to the portal table. This index will be: - "0" for all nodes within the iSCSI instance. or - the index of the node (preceding the index of the portal). So, all the = portals depending on one node will be nicely organized whithin an iSCSI = instance. I'll be very glad to get any clarifications concerning those two issues. Michele Visit the SANRAD Live Demo of a complete IP Based SAN and Virtualization = Solution at CeBIT 2004 (Hannover, Germany 16-24 March, 2004), at the = eSeSIX stand, in Hall 6, Stand G36=20 SANRAD - access, share, manage =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Tel: +972 (3) 767 4809 Fax: +972 (3) 647 4104 E-mail: michele@sanrad.com =20 Web: www.sanrad.com =20 Address: 32 Habarzel St. Tel-Aviv 69710, Israel _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 4 12:45:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17166 for ; Wed, 4 Feb 2004 12:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoR5g-0006dG-Eh for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 12:45:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14HjWs0025490 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 12:45:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoR5g-0006d3-AT for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 12:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17159 for ; Wed, 4 Feb 2004 12:45:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoR5e-0007cd-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 12:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoR4s-0007Vd-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 12:44:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoR4J-0007Ne-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 12:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoR4D-0006Tv-O9; Wed, 04 Feb 2004 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoR3c-0006SO-4H for ips@optimus.ietf.org; Wed, 04 Feb 2004 12:43:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17032 for ; Wed, 4 Feb 2004 12:43:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoR3a-0007LJ-00 for ips@ietf.org; Wed, 04 Feb 2004 12:43:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoR2m-0007Fi-00 for ips@ietf.org; Wed, 04 Feb 2004 12:42:33 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AoR29-00077N-00 for ips@ietf.org; Wed, 04 Feb 2004 12:41:53 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 4 Feb 2004 09:40:22 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717A8@mail1irv.inside.istor.com> Thread-Topic: TMF Response of "Function Auth Failed" Thread-Index: AcPrRfcx1PSQ6eHuS6eC6JL5DUt0ig== From: "Ramesh Mangamuri" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] TMF Response of "Function Auth Failed" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable What case triggers the target to reply with response of "Function Authorization Failed" in reply to TMF request from Initiator??? Is it SCSI Access controls??? -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]=20 Sent: Monday, February 02, 2004 9:52 AM To: Julian_Satran@il.ibm.com Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands If we really believe that the change would be overly painful for current and in development implementations, I would prefer a change to make R2TSN and DataSN independent for bidirectional commands. The logic: Bidirectional commands already need extra context so carrying an extra SN variable is a very small burden to them. It is poor form to have one variable that is sitting under two names. It creates confusion and is likely to cause interoperability problems in the future.=20 Therefore, it is worth the burden of carrying an extra value in bidirectional command context to forstall interoperability problems. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 30, 2004 3:57 AM To: THALER,PAT (A-Roseville,ex1) Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Will fix the example (thanks Pat and perhaps add the text you suggested).=20 For pratical purposes it should be noted that the only SCSI device that=20 plans to use bidirectional data transfers to-date has different phases for=20 input and output so that block are no mixed. However I assumed always that the space is shared and that data placement=20 is unaffected by the order of PDU's . The SNACK identifies unambiguously to the target what is missing and the initiator has to know only that=20 something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the=20 > combination of the behavior described in 10.4.8 and that described in=20 > 3.2.2 is broken for bidirectional commands. The reason for reporting=20 > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to=20 > send a SNACK if it didn't. >=20 > For example, one could have the following in response to a=20 > bidirectional command: >=20 > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T >=20 > If the ExpDataSN to be reported in the SCSI Response was truly the=20 > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that=20 > DataSN and R2TSN for bidirectional commands form one continuous=20 > undifferentiated series but it is not consistent with the example in=20 > B.3. The example shows a PDU with R2TSN =3D 0 followed by a PDU with=20 DataSN =3D 0. >=20 > This is broken because the initiator could not compare the value=20 > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is=20 > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the=20 > ExpDataSN value. The target would also have to keep two separate=20 > counters during processing of bidirectional commands (both named=20 > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so=20 > it can put it in the Response and one of the value of ExpDataSN=20 > indicating the DataSN to put in the next Data-In or R2T PDU it sends=20 > for the command. >=20 > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and=20 > R2TSN form one sequence for bidirectional commands is to allow the=20 > command to maintain one count for DataIn and R2T PDUs rather than=20 > having two counters. If we were willing to forgo that optimization,=20 > then DataSN and R2TSN should have been kept separate.=20 >=20 > In any case, it is incorrect to have two variables for the same=20 > context with the same name. >=20 > One can correct the problem by changing 10.4.8 to say that for=20 > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs=20 > that were sent, then one can maintain one value. One should also=20 > correct the example in B.3. >=20 > One could also correct the problem by changing 3.2.2 so that DataSN=20 > was kept separate from R2TSN in bidirectional commands. In some=20 > senses, this would have been cleaner because it avoids having one=20 > variable with two names but it would require more context per command=20 > and it is probably a bigger change for existing implementations. >=20 > The code in E.2.2 seems ambiguous - it just says if (expDataSN does=20 > not match) but it doesn't define what is considered a match. Neither=20 > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs=20 > is derived. Therefore it would be consistent with either choice. >=20 > Regards, > Pat >=20 > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional > commands >=20 >=20 > On Thu, 29 Jan 2004, Mallikarjun C. wrote: >=20 > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. >=20 > While I'll be honest that I don't understand _why_ R2Ts are factored=20 into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. >=20 > So I don't think it's supposed to be something new. >=20 > Take care, >=20 > Bill >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Feb 4 14:59:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22628 for ; Wed, 4 Feb 2004 14:59:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTBJ-0008LC-L7 for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 14:59:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14JxTHC032052 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 14:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTBJ-0008Kt-E2 for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 14:59:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22583 for ; Wed, 4 Feb 2004 14:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTBG-0005bu-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 14:59:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTAJ-0005Wm-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 14:58:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTA3-0005Rg-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 14:58:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoT9t-000841-E3; Wed, 04 Feb 2004 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoT9O-0007zI-17 for ips@optimus.ietf.org; Wed, 04 Feb 2004 14:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22481 for ; Wed, 4 Feb 2004 14:57:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoT9L-0005Pf-00 for ips@ietf.org; Wed, 04 Feb 2004 14:57:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoT8Q-0005IR-00 for ips@ietf.org; Wed, 04 Feb 2004 14:56:31 -0500 Received: from [209.172.74.34] (helo=kazeon.com) by ietf-mx with esmtp (Exim 4.12) id 1AoT7k-0005CW-00 for ips@ietf.org; Wed, 04 Feb 2004 14:55:48 -0500 Content-class: urn:content-classes:message Date: Wed, 4 Feb 2004 11:53:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <4E022DDAB8F45741914ACD6EDFE2309B2B36@BIGFOOT.kazeon.local> X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Initial review of http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt Thread-Index: AcPrCiBPhgYAfflKQ5qg2OX6DYzE6QATflHA From: "Michael MacFaden" To: Content-Transfer-Encoding: quoted-printable Subject: [Ips] Initial review of http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, My review of the fiber channel management MIB module: http://www.macfaden.com/ietf/fc-mgmt-mib-4-reviewed.txt Would prefer to have comments or questions sent to this list please. Regards, Mike MacFaden _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 4 15:46:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25883 for ; Wed, 4 Feb 2004 15:46:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtw-0005Lp-Eq for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 15:45:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KjaX3020563 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 15:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtw-0005La-AO for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:45:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25862 for ; Wed, 4 Feb 2004 15:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTtu-0001tg-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 15:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTsv-0001mn-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTsR-0001ga-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTsP-0004nu-N7; Wed, 04 Feb 2004 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTrV-0004hr-VE for ips@optimus.ietf.org; Wed, 04 Feb 2004 15:43:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25639; Wed, 4 Feb 2004 15:43:03 -0500 (EST) Message-Id: <200402042043.PAA25639@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Feb 2004 15:43:03 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-fcip-slp-09.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Finding FCIP Entities Using SLPv2 Author(s) : D. Peterson Filename : draft-ietf-ips-fcip-slp-09.txt Pages : 12 Date : 2004-2-4 This document defines the use of Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP Entities [FCIP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-fcip-slp-09.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-fcip-slp-09.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: <2004-2-4160207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-slp-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-slp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4160207.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 4 22:53:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17008 for ; Wed, 4 Feb 2004 22:53:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaZE-0000CT-4r for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 22:52:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153qevB000768 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 22:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaZD-0000CJ-Td for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:52:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17000 for ; Wed, 4 Feb 2004 22:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaZA-0001l2-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:52:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaYG-0001fz-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:51:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoaXh-0001bG-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaXe-0008Pd-Lh; Wed, 04 Feb 2004 22:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaXK-0008Ok-Jm for ips@optimus.ietf.org; Wed, 04 Feb 2004 22:50:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16954 for ; Wed, 4 Feb 2004 22:50:38 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaXH-0001Zn-00 for ips@ietf.org; Wed, 04 Feb 2004 22:50:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaWJ-0001Tg-00 for ips@ietf.org; Wed, 04 Feb 2004 22:49:40 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AoaVN-0001Jt-00 for ips@ietf.org; Wed, 04 Feb 2004 22:48:41 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id DWR1GV0L; Wed, 4 Feb 2004 22:48:12 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 22:48:12 -0500 Message-ID: X-Sybari-Trust: 077d1cc6 b1a25add 2ab5bd83 0000013d To: ips@ietf.org Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcom mands Date: Wed, 4 Feb 2004 22:48:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Let me reinforce what Julian said. A technical change such as separation of the variables and introduction of a new SNACK type *CANNOT* be done at this juncture, unless something is really and truly broken. Editorial cleanup is what's in order - i.e., "Implementation 1" below. 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-owner@ietf.org [mailto:ips-owner@ietf.org] On > Behalf Of Julian Satran > Sent: Tuesday, February 03, 2004 6:10 AM > To: Ramesh Mangamuri > Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; > pat_thaler@agilent.com; wrstuden@wasabisystems.com > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectionalcommands > > > As I stated I think we might have an editorial issue (two > names for the > same thing) but since this has also some history I would be really > reluctant to make any change (except fixing the example and adding a > statement explaining that they share the space). > > Julo > > > > "Ramesh Mangamuri" > 02/02/2004 22:41 > > To > > cc > , Julian Satran , > , , > Subject > RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectionalcommands > > > > > > > From the discussion so far, I am interested to know Julian's plans on > about the below approaches in the case of a bidirectional commands. > > Implementation 1: > ================= > Keep the same variable for both so that > there is no > need to introduce another new SNACK type for R2TSN. > > Or, > > Implementation 2: > ================= > Use different variables for R2TSNs and DataInSN and introduce > new SNACK > type for R2TSNs. > > More later..., > Rams > > -----Original Message----- > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > Sent: Monday, February 02, 2004 12:06 PM > To: Ramesh Mangamuri > Cc: pat_thaler@agilent.com; Julian_Satran@il.ibm.com; cbm@rose.hp.com; > ips@ietf.org; ips-admin@ietf.org > Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for > bidirectionalcommands > > On Mon, 2 Feb 2004, Ramesh Mangamuri wrote: > > > To be honest I really don't know about the resources we would be > saving > > by combining R2TSN and DataSN into one variable in the of > bidirectional > > . But from logical standpoint, Pat's suggestion makes > perfect sense to > > me. > > I think the reason they are the same variable is that they > (R2T numbers > and DataSN) are in the same number space, due to how SNACK Requests > work. > To request a given DataSN or a given R2T be retransmitted, > the initiator > sends a SNACK Request of Type 0. That's a Type 0 for _either_ a R2T or > DataSN retransmit. So for the target to keep things clear, it > has to use > the same number space for both. > > I think separating the number spaces would be ok, but it > means changing > SNACK requests so that BiDi commands can tell what's being asked for. > > Take care, > > Bill > > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 4 22:53:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17026 for ; Wed, 4 Feb 2004 22:53:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaZF-0000Cu-ME for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 22:52:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i153qfvr000790 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 22:52:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaZF-0000Cf-I8 for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 22:52:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17004 for ; Wed, 4 Feb 2004 22:52:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaZC-0001lH-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:52:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaYH-0001g9-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:51:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoaXh-0001bH-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 22:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaXf-0008Pp-Ax; Wed, 04 Feb 2004 22:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoaXL-0008Op-9P for ips@optimus.ietf.org; Wed, 04 Feb 2004 22:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16957 for ; Wed, 4 Feb 2004 22:50:39 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoaXH-0001Zs-00 for ips@ietf.org; Wed, 04 Feb 2004 22:50:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoaWL-0001Ty-00 for ips@ietf.org; Wed, 04 Feb 2004 22:49:42 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AoaVP-0001Ju-00 for ips@ietf.org; Wed, 04 Feb 2004 22:48:43 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id DWR1GV0N; Wed, 4 Feb 2004 22:48:14 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Feb 2004 22:48:14 -0500 Message-ID: X-Sybari-Trust: 2f3b1856 b1a25add 2ab5bd83 0000013d To: cbm@rose.hp.com Cc: ips@ietf.org Subject: RE: CSM [Ips] iSCSI: ErrorRecoveryLevel=2 Interoperability Issue Date: Wed, 4 Feb 2004 22:48:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I want to close out this thread because the words "Interoperability Issue" appeared in its subject line. I agree with Mallikarjun that: > > The net is that I do not see an interoperability problem, > > nor anything that needs changing in the spec. The only ill effect I've seen described is that if the SHOULD is ignored, error recovery gets messier in that a blunter mechanism (Session Reinstatement) has to be used as a fall-back when the connection recovery fails. While having to fall-back in this fashion is not pleasant, this is already an error-recovery (exceptional case), and having to use a blunter mechanism that is more disruptive is well within reason as a consequence of ignoring a "SHOULD". 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 exim@www1.ietf.org Wed Feb 4 23:52:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18284 for ; Wed, 4 Feb 2004 23:52:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AobUM-0005j1-MO for ips-archive@odin.ietf.org; Wed, 04 Feb 2004 23:51:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i154pgiL022003 for ips-archive@odin.ietf.org; Wed, 4 Feb 2004 23:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AobUL-0005io-RG for ips-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 23:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18268 for ; Wed, 4 Feb 2004 23:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AobUJ-0006oy-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 23:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AobTO-0006j6-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 23:50:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AobSo-0006e4-00 for ips-web-archive@ietf.org; Wed, 04 Feb 2004 23:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AobSl-0005X0-6T; Wed, 04 Feb 2004 23:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AobSO-0005Vg-HY for ips@optimus.ietf.org; Wed, 04 Feb 2004 23:49:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18210 for ; Wed, 4 Feb 2004 23:49:37 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AobSM-0006d6-00 for ips@ietf.org; Wed, 04 Feb 2004 23:49:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AobRR-0006YI-00 for ips@ietf.org; Wed, 04 Feb 2004 23:48:42 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AobQc-0006TK-00 for ips@ietf.org; Wed, 04 Feb 2004 23:47:50 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id CE3404013E; Wed, 4 Feb 2004 23:47:51 -0500 (EST) Date: Wed, 4 Feb 2004 20:47:35 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Michele Hallak - Stamler Cc: ips@ietf.org Subject: Re: [Ips] iSCSI MIB compliance with iSCSI draft 20 In-Reply-To: <6CD55BEE318E0D45B89043D74720E22A09534A@sansrv1.san-rad.co.il> Message-ID: References: <6CD55BEE318E0D45B89043D74720E22A09534A@sansrv1.san-rad.co.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Wed, 4 Feb 2004, Michele Hallak - Stamler wrote: > Hello, > Working on an implementation of the iSCSI MIB, we encountered the > following problems: > 1. Minor Issue: What is the meaning of Initiator Portal Tag? It seems > that it's there for historical reason. If confirmed, the object: > iscsiIntrPortalTag and therefore the all table: > iscsiIntrPortalAttributesTable should be removed. I don't think so. While the initiator portal tag does not have the same protocol significance that TPGT has, it's useful in that it can indicate which initiator ports can participate in multi-connection sessions. iSCSI sessions can't span initiator portals with differing IPTs. I agree that initiator software has to respect the IPT concept; iSCSI won't really care about it and if all the connections have the same initiator name and ISID, the session will span all of them. If the initiators behind the different portals can't share a session yet are all logged into the same target portal group, things will get messy. > 2. Target Portal Group Tag: The scope of the tag is per target device > (node) and not per iSCSI instance. The actual MIB allows to define > several target portals whithin one entity without any relation to the > target device node. > Therefore, if I want to define a portal (IP address + TCP Port) with a > tag "x" (for one target device) and with a tag "y" (for a different > target device), I have to set two identical rows with just the object > "tag" different.(And no direct connection between the portal and the > target node device, just via the SCSI target port name of the SCSI MIB). > It is generally not the usage. Right now, if you use the MIB, you really can't have different TPGTs for a portal. I think your work-around will really confuse some clients. I agree it should be different. > I suggest to add an index to the portal table. This index will be: > - "0" for all nodes within the iSCSI instance. > or > - the index of the node (preceding the index of the portal). So, all the > portals depending on one node will be nicely organized whithin an iSCSI > instance. I think it would be better to have a table that ties nodes to portals with an explicit portal tag. Like how iSNS does it. > I'll be very glad to get any clarifications concerning those two issues. > > Michele > > > Visit the SANRAD Live Demo of a complete IP Based SAN and Virtualization Solution at CeBIT 2004 (Hannover, Germany 16-24 March, 2004), at the eSeSIX stand, in Hall 6, Stand G36 > SANRAD - access, share, manage > ================================= > Tel: +972 (3) 767 4809 > Fax: +972 (3) 647 4104 > E-mail: michele@sanrad.com > Web: www.sanrad.com > Address: 32 Habarzel St. Tel-Aviv 69710, Israel > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Feb 5 02:47:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05713 for ; Thu, 5 Feb 2004 02:47:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeDp-0007TE-MS for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 02:46:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i157knxG028715 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 02:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeDp-0007T4-1w for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 02:46:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05674 for ; Thu, 5 Feb 2004 02:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeDl-0006IT-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 02:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeCo-0006DW-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 02:45:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoeCA-00068k-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 02:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeC9-0007Fi-IW; Thu, 05 Feb 2004 02:45:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoeBv-0007EG-3c for ips@optimus.ietf.org; Thu, 05 Feb 2004 02:44:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05563 for ; Thu, 5 Feb 2004 02:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoeBr-000689-00 for ips@ietf.org; Thu, 05 Feb 2004 02:44:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeBB-000638-00 for ips@ietf.org; Thu, 05 Feb 2004 02:44:05 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1AoeAX-0005u0-00 for ips@ietf.org; Thu, 05 Feb 2004 02:43:25 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Feb 2004 23:42:56 -0800 Message-ID: From: Jane Liu To: ips@ietf.org Date: Wed, 4 Feb 2004 23:42:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EBBB.AAD7E84D" Subject: [Ips] Recovery R2T for unsolicited data Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EBBB.AAD7E84D Content-Type: text/plain; charset="iso-8859-1" Hi, I'm wondering if an R2T sent to recover unsolicited data should be allowed to use a Target Transfer Tag of 0xffffffff. I understand that the spec clearly says that 0xffffffff is reserved and must not be used in an R2T, but can't it be considered as the TTT for the implicit Initial R2T? If that is the case, what's the harm in reusing the original TTT in the recovery R2T? Of course its use would have to be restricted to firstburst recovery only, and it wouldn't work when the requested data range crosses the unsolicited/solicited data boundary. This brings up another question, is a recovery R2T allowed to request data across multiple sequences (i.e. sequences established by prior R2Ts)? Here's what the spec says on recovery R2Ts: "A Recovery-R2T carries the next unused R2TSN, but requests part of or the entire data burst that an earlier R2T (with a lower R2TSN) had already requested." Thanks in advance for all replies. Jane Liu ------_=_NextPart_001_01C3EBBB.AAD7E84D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Recovery R2T for unsolicited data

Hi,

I'm wondering if an R2T sent to recover unsolicited = data should be allowed to use a Target Transfer Tag of 0xffffffff. I = understand that the spec clearly says that 0xffffffff is reserved and = must not be used in an R2T, but can't it be considered as the TTT for = the implicit Initial R2T? If that is the case, what's the harm in = reusing the original TTT in the recovery R2T? Of course its use would = have to be restricted to firstburst recovery only, and it wouldn't work = when the requested data range crosses the unsolicited/solicited data = boundary.

This brings up another question, is a recovery R2T = allowed to request data across multiple sequences (i.e. sequences = established by prior R2Ts)? Here's what the spec says on recovery R2Ts: = "A Recovery-R2T carries the next unused R2TSN, but requests part = of

or the entire data burst that an earlier R2T (with a = lower R2TSN)
had already requested."

Thanks in advance for all replies.

Jane Liu
 

------_=_NextPart_001_01C3EBBB.AAD7E84D-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 10:16:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18950 for ; Thu, 5 Feb 2004 10:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolEZ-0000y6-Bx for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 10:16:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15FG3EI003718 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 10:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolEZ-0000xt-6G for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 10:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18890 for ; Thu, 5 Feb 2004 10:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolEX-0001QY-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 10:16:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolDa-0001IY-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 10:15:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AolCg-0001Be-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 10:14:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolCb-00005e-MS; Thu, 05 Feb 2004 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolCZ-00004s-A2 for ips@optimus.ietf.org; Thu, 05 Feb 2004 10:13:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18697 for ; Thu, 5 Feb 2004 10:13:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolCW-0001A9-00 for ips@ietf.org; Thu, 05 Feb 2004 10:13:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolBY-000140-00 for ips@ietf.org; Thu, 05 Feb 2004 10:12:57 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1AolAZ-0000to-00 for ips@ietf.org; Thu, 05 Feb 2004 10:11:55 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Thu, 5 Feb 2004 07:11:22 -0800 Message-ID: From: Andy Currid To: "'wrstuden@wasabisystems.com'" , ips@ietf.org Subject: RE: [Ips] iSNS failover and multi-server configurations Date: Thu, 5 Feb 2004 07:11:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EBFA.4FEE419A" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EBFA.4FEE419A Content-Type: text/plain; charset="iso-8859-1" > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > ... > 2) I see that DHCP can indicate multiple servers. But what > about SLP in face of multiple servers? Andy Currid suggested > that SLP should only have the most-senior operational server > registered. That's more than I recall saying :-) I agree with your suggestion that the SLP storage management service template should include some form of precedence attribute. Andy -- > But what happens when either a formerly-off-line server comes > back on line or an on-line server goes off-line? SLP does not > seem well-suited for "server moved" notifications. Also, with > SLP, if a server fails, what are the security considerations > for the backup server to be able to de-register the server? > > Would it be easier for SLP to add a "precedence" attribute > and have each server register with SLP, then have the client > perform the same failover as DHCP and heartbeat do? -- Andy Currid Phone: 408 330 4507 iReady Corporation Fax: 408 330 4521 andy@iready.com http://www.iready.com ------_=_NextPart_001_01C3EBFA.4FEE419A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ips] iSNS failover and multi-server configurations

> From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems= .com]
> ...
> 2) I see that DHCP can indicate multiple = servers. But what
> about SLP in face of multiple servers? Andy = Currid suggested
> that SLP should only have the most-senior = operational server
> registered.

That's more than I recall saying :-)

I agree with your suggestion that the SLP storage = management
service template should include some form of = precedence attribute.

Andy
--

> But what happens when either a formerly-off-line = server comes
> back on line or an on-line server goes = off-line? SLP does not
> seem well-suited for "server moved" = notifications. Also, with
> SLP, if a server fails, what are the security = considerations
> for the backup server to be able to de-register = the server?
>
> Would it be easier for SLP to add a = "precedence" attribute
> and have each server register with SLP, then = have the client
> perform the same failover as DHCP and heartbeat = do?

--
Andy = Currid           =       Phone: 408 330 4507
iReady = Corporation          &= nbsp; Fax: 408 330 4521
andy@iready.com        =    http://www.iready.com

------_=_NextPart_001_01C3EBFA.4FEE419A-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 11:33:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22561 for ; Thu, 5 Feb 2004 11:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR4-0002Cc-Ah for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 11:33:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GX2BO008462 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 11:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR3-0002CP-VD for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:33:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22541 for ; Thu, 5 Feb 2004 11:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomR3-0001GR-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:33:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomQ9-0001Au-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:32:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomPG-00015q-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomP9-0001oN-0V; Thu, 05 Feb 2004 11:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomOH-0001lG-Ab for ips@optimus.ietf.org; Thu, 05 Feb 2004 11:30:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22424 for ; Thu, 5 Feb 2004 11:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomOG-0000ym-00 for ips@ietf.org; Thu, 05 Feb 2004 11:30:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomNH-0000sT-00 for ips@ietf.org; Thu, 05 Feb 2004 11:29:08 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1AomMv-0000ml-00; Thu, 05 Feb 2004 11:28:45 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i15GSBZ3121260; Thu, 5 Feb 2004 16:28:11 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i15GSAVZ175212; Thu, 5 Feb 2004 16:28:11 GMT In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF2905717A8@mail1irv.inside.istor.com> To: "Ramesh Mangamuri" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] TMF Response of "Function Auth Failed" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 5 Feb 2004 18:28:09 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/02/2004 18:28:10, Serialize complete at 05/02/2004 18:28:10 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Yes - some TMF functions can have painful results (e.g., clear task set or reset) and the target may let only some initiators do them. Julo "Ramesh Mangamuri" Sent by: ips-admin@ietf.org 04/02/2004 19:40 To cc Subject [Ips] TMF Response of "Function Auth Failed" What case triggers the target to reply with response of "Function Authorization Failed" in reply to TMF request from Initiator??? Is it SCSI Access controls??? -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Monday, February 02, 2004 9:52 AM To: Julian_Satran@il.ibm.com Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands If we really believe that the change would be overly painful for current and in development implementations, I would prefer a change to make R2TSN and DataSN independent for bidirectional commands. The logic: Bidirectional commands already need extra context so carrying an extra SN variable is a very small burden to them. It is poor form to have one variable that is sitting under two names. It creates confusion and is likely to cause interoperability problems in the future. Therefore, it is worth the burden of carrying an extra value in bidirectional command context to forstall interoperability problems. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 30, 2004 3:57 AM To: THALER,PAT (A-Roseville,ex1) Cc: cbm@rose.hp.com; ips@ietf.org; ips-admin@ietf.org; wrstuden@wasabisystems.com Subject: RE: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional commands Will fix the example (thanks Pat and perhaps add the text you suggested). For pratical purposes it should be noted that the only SCSI device that plans to use bidirectional data transfers to-date has different phases for input and output so that block are no mixed. However I assumed always that the space is shared and that data placement is unaffected by the order of PDU's . The SNACK identifies unambiguously to the target what is missing and the initiator has to know only that something is missing in order to start a recovery action. Other than the example the spec is fine. ips-admin@ietf.org wrote on 30/01/2004 03:25:58: > I also don't think the current spec is clear and I think the > combination of the behavior described in 10.4.8 and that described in > 3.2.2 is broken for bidirectional commands. The reason for reporting > ExpDataSN in the SCSI Response is to allow the initiator to check that > it received all the Data-In PDUs associated with the command and to > send a SNACK if it didn't. > > For example, one could have the following in response to a > bidirectional command: > > DataSN PDU > 0 1st Data-In > 1 1st R2T > 2 2nd R2T > 3 2nd Data-In > 4 3rd Data-In > 5 4th Data-In > 6 3rd R2T > > If the ExpDataSN to be reported in the SCSI Response was truly the > number of Data-In PDUs as 10.4.8 says, its value would be 4. Note that > the above is consistent with the text of 3.2.2.3 which says that > DataSN and R2TSN for bidirectional commands form one continuous > undifferentiated series but it is not consistent with the example in > B.3. The example shows a PDU with R2TSN = 0 followed by a PDU with DataSN = 0. > > This is broken because the initiator could not compare the value > received in ExpDataSN to its copy of ExpDataSN to determine whether it > had gotten all the Data-In PDUs. If the behavior in 10.4.8 is > maintained, an initiator will have to keep a count of the Data-In PDUs > it has received for bidirectional commands in addition to keeping the > ExpDataSN value. The target would also have to keep two separate > counters during processing of bidirectional commands (both named > ExpDataSN by the draft) - one of how many Data-In PDUs it has sent so > it can put it in the Response and one of the value of ExpDataSN > indicating the DataSN to put in the next Data-In or R2T PDU it sends > for the command. > > There is no reason to define the protocol such that keeping two values > is necessary here. It appears that the reason to say that DataSN and > R2TSN form one sequence for bidirectional commands is to allow the > command to maintain one count for DataIn and R2T PDUs rather than > having two counters. If we were willing to forgo that optimization, > then DataSN and R2TSN should have been kept separate. > > In any case, it is incorrect to have two variables for the same > context with the same name. > > One can correct the problem by changing 10.4.8 to say that for > bidirectional commands ExpDataSN is the number of DataIn and R2T PDUs > that were sent, then one can maintain one value. One should also > correct the example in B.3. > > One could also correct the problem by changing 3.2.2 so that DataSN > was kept separate from R2TSN in bidirectional commands. In some > senses, this would have been cleaner because it avoids having one > variable with two names but it would require more context per command > and it is probably a bigger change for existing implementations. > > The code in E.2.2 seems ambiguous - it just says if (expDataSN does > not match) but it doesn't define what is considered a match. Neither > the target code nor the initiator code in E.2 seems to address how the > value of ExpDataSN for response PDUs and the compare to response PDUs > is derived. Therefore it would be consistent with either choice. > > Regards, > Pat > > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org]On Behalf Of > wrstuden@wasabisystems.com > Sent: Thursday, January 29, 2004 2:46 PM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: Correct value for ExpDataSN for bidirectional > commands > > > On Thu, 29 Jan 2004, Mallikarjun C. wrote: > > > Not sure why the initiator needs to be reported on the > > total # of R2Ts in the final response....I presume > > any mismatch in R2Ts is already factored into the status. > > > > _If_ we indeed want to include R2Ts, I think it would be > > necessary to make changes (10.4.8, E.2.2, and perhaps 6) > > because I believe the current spec semantics are clear > > that R2Ts are not included. > > While I'll be honest that I don't understand _why_ R2Ts are factored into > the DataSN space along with Data-In PDUs, I've understood they were > comingled for over a year. I think it was about 16 months ago I asked > about this (before draft 20), and Julian explained that they shared the > same space. > > So I don't think it's supposed to be something new. > > Take care, > > Bill > > _______________________________________________ > 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 _______________________________________________ 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 exim@www1.ietf.org Thu Feb 5 11:33:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22578 for ; Thu, 5 Feb 2004 11:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR5-0002Cx-NN for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 11:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GX3e6008481 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 11:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR5-0002Ci-J9 for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:33:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22545 for ; Thu, 5 Feb 2004 11:33:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomR4-0001Gh-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:33:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomQA-0001B5-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:32:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomPG-00015s-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomPA-0001p8-NX; Thu, 05 Feb 2004 11:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomOL-0001mH-0Q for ips@optimus.ietf.org; Thu, 05 Feb 2004 11:30:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22430 for ; Thu, 5 Feb 2004 11:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomOJ-0000zM-00 for ips@ietf.org; Thu, 05 Feb 2004 11:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomNJ-0000sp-00 for ips@ietf.org; Thu, 05 Feb 2004 11:29:10 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1AomMv-0000mm-00 for ips@ietf.org; Thu, 05 Feb 2004 11:28:45 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i15GSAZ3015990; Thu, 5 Feb 2004 16:28:10 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i15GS9VZ164084; Thu, 5 Feb 2004 16:28:09 GMT In-Reply-To: To: "Lakshmi Ramasubramanian" Cc: ips@ietf.org MIME-Version: 1.0 Subject: Re: [IPS] iSCSI: Text Command with F Bit set to 0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 5 Feb 2004 18:28:08 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/02/2004 18:28:09, Serialize complete at 05/02/2004 18:28:09 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Lakshmi, Sorry for the delay. There is no exception from the CmDSN increment rule in this case unless the I bit is 1. Julo "Lakshmi Ramasubramanian" 03/02/2004 23:50 To "Julian Satran" , cc Subject [IPS] iSCSI: Text Command with F Bit set to 0 Section 10.10.4 Target Transfer Tag says that if the target sets F bit to 0, and C Bit to 1 in Text Response, initiator MUST send an emptry Text Request with the same Target Transfer Tag given by the target in the response. Is the Command Sequence Number (CmdSN) incremented each time the initiator sends the empty text request? Or, should it use the same CmdSN it had specified in the initial Text Request? thanks! -lakshmi _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 11:33:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22583 for ; Thu, 5 Feb 2004 11:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR6-0002DF-Dq for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 11:33:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GX4mt008499 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 11:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomR6-0002D0-9b for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:33:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22548 for ; Thu, 5 Feb 2004 11:33:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomR5-0001Go-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomQB-0001BD-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:32:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomPG-00015t-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 11:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomPB-0001pe-IU; Thu, 05 Feb 2004 11:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomOL-0001mM-JR for ips@optimus.ietf.org; Thu, 05 Feb 2004 11:30:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22433 for ; Thu, 5 Feb 2004 11:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomOK-0000zR-00 for ips@ietf.org; Thu, 05 Feb 2004 11:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomNK-0000sx-00 for ips@ietf.org; Thu, 05 Feb 2004 11:29:10 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx with esmtp (Exim 4.12) id 1AomMv-0000mn-00; Thu, 05 Feb 2004 11:28:45 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i15GSBBT081464; Thu, 5 Feb 2004 16:28:11 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i15GSAVZ145916; Thu, 5 Feb 2004 16:28:11 GMT In-Reply-To: To: Jane Liu Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Recovery R2T for unsolicited data X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 5 Feb 2004 18:28:08 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 05/02/2004 18:28:11, Serialize complete at 05/02/2004 18:28:11 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jane, ips-admin@ietf.org wrote on 05/02/2004 09:42:55: > Hi, > I'm wondering if an R2T sent to recover unsolicited data should be > allowed to use a Target Transfer Tag of 0xffffffff. I understand that > the spec clearly says that 0xffffffff is reserved and must not be used > in an R2T, but can't it be considered as the TTT for the implicit > Initial R2T? If that is the case, what's the harm in reusing the > original TTT in the recovery R2T? Of course its use would have to be > restricted to firstburst recovery only, and it wouldn't work when the > requested data range crosses the unsolicited/solicited data boundary. 0xffffffff is reserved and should not be used by any R2T > This brings up another question, is a recovery R2T allowed to request > data across multiple sequences (i.e. sequences established by prior > R2Ts)? Here's what the spec says on recovery R2Ts: "A Recovery-R2T > carries the next unused R2TSN, but requests part of > or the entire data burst that an earlier R2T (with a lower R2TSN) > had already requested." R2Ts can request as much data as it wants (including data from former R2Ts)if recovery is supported (data sequencing rules do not get violated). > Thanks in advance for all replies. > Jane Liu > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 13:50:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28533 for ; Thu, 5 Feb 2004 13:50:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooZt-0006xn-SZ for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 13:50:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15IoHYf026763 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 13:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooZt-0006xa-NI for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 13:50:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28476 for ; Thu, 5 Feb 2004 13:50:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AooZr-0000L8-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 13:50:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AooYo-0000EF-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 13:49:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AooXu-00007g-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 13:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooXk-0006QG-If; Thu, 05 Feb 2004 13:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AooWt-0006Jb-BI for ips@optimus.ietf.org; Thu, 05 Feb 2004 13:47:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28276 for ; Thu, 5 Feb 2004 13:47:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AooWr-000005-00 for ips@ietf.org; Thu, 05 Feb 2004 13:47:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AooVz-0007iS-00 for ips@ietf.org; Thu, 05 Feb 2004 13:46:16 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AooVF-0007WK-00 for ips@ietf.org; Thu, 05 Feb 2004 13:45:29 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 11:44:54 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Thu, 05 Feb 2004 11:44:53 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.12]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 11:44:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Ips] iSNS failover and multi-server configurations Date: Thu, 5 Feb 2004 10:44:52 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480D4BB102@SNEXCH01.mcdata.com> Thread-Topic: [Ips] iSNS failover and multi-server configurations Thread-Index: AcPr+tbdchGxrFhhSpmoGfUew0rdHwAHSIzs From: "Joshua Tseng" To: "Andy Currid" , , X-OriginalArrivalTime: 05 Feb 2004 18:44:53.0445 (UTC) FILETIME=[24A1A750:01C3EC18] Content-Transfer-Encoding: base64 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpJIHdvdWxkIGFncmVlLCBhbmQgd291bGQgcmVxdWVzdCB0aGF0IHRoZSBpU0NTSS1TTFAgZHJh ZnQgYXV0aG9yIChNYXJrIEJha2tlLCB5b3Ugc3RpbGwgdGhlcmU/KSB0byBpbmNvcnBvcmF0ZSBh IHByZWNlZGVuY2UgYXR0cmlidXRlIGludG8gdGhlIHNtcyB0ZW1wbGF0ZS4NCiANCkpvc2ggVHNl bmcNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206IEFuZHkgQ3VycmlkIFtt YWlsdG86YWN1cnJpZEBjb3JwLmlyZWFkeS5jb21dIA0KCVNlbnQ6IFRodSAyLzUvMjAwNCA3OjEx IEFNIA0KCVRvOiAnd3JzdHVkZW5Ad2FzYWJpc3lzdGVtcy5jb20nOyBpcHNAaWV0Zi5vcmcgDQoJ Q2M6IA0KCVN1YmplY3Q6IFJFOiBbSXBzXSBpU05TIGZhaWxvdmVyIGFuZCBtdWx0aS1zZXJ2ZXIg Y29uZmlndXJhdGlvbnMNCgkNCgkNCg0KDQoJPiBGcm9tOiB3cnN0dWRlbkB3YXNhYmlzeXN0ZW1z LmNvbSBbbWFpbHRvOndyc3R1ZGVuQHdhc2FiaXN5c3RlbXMuY29tXSANCgk+IC4uLiANCgk+IDIp IEkgc2VlIHRoYXQgREhDUCBjYW4gaW5kaWNhdGUgbXVsdGlwbGUgc2VydmVycy4gQnV0IHdoYXQg DQoJPiBhYm91dCBTTFAgaW4gZmFjZSBvZiBtdWx0aXBsZSBzZXJ2ZXJzPyBBbmR5IEN1cnJpZCBz dWdnZXN0ZWQgDQoJPiB0aGF0IFNMUCBzaG91bGQgb25seSBoYXZlIHRoZSBtb3N0LXNlbmlvciBv cGVyYXRpb25hbCBzZXJ2ZXIgDQoJPiByZWdpc3RlcmVkLiANCg0KCVRoYXQncyBtb3JlIHRoYW4g SSByZWNhbGwgc2F5aW5nIDotKSANCg0KCUkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24gdGhh dCB0aGUgU0xQIHN0b3JhZ2UgbWFuYWdlbWVudCANCglzZXJ2aWNlIHRlbXBsYXRlIHNob3VsZCBp bmNsdWRlIHNvbWUgZm9ybSBvZiBwcmVjZWRlbmNlIGF0dHJpYnV0ZS4gDQoNCglBbmR5IA0KCS0t IA0KDQoJPiBCdXQgd2hhdCBoYXBwZW5zIHdoZW4gZWl0aGVyIGEgZm9ybWVybHktb2ZmLWxpbmUg c2VydmVyIGNvbWVzIA0KCT4gYmFjayBvbiBsaW5lIG9yIGFuIG9uLWxpbmUgc2VydmVyIGdvZXMg b2ZmLWxpbmU/IFNMUCBkb2VzIG5vdCANCgk+IHNlZW0gd2VsbC1zdWl0ZWQgZm9yICJzZXJ2ZXIg bW92ZWQiIG5vdGlmaWNhdGlvbnMuIEFsc28sIHdpdGggDQoJPiBTTFAsIGlmIGEgc2VydmVyIGZh aWxzLCB3aGF0IGFyZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgDQoJPiBmb3IgdGhlIGJh Y2t1cCBzZXJ2ZXIgdG8gYmUgYWJsZSB0byBkZS1yZWdpc3RlciB0aGUgc2VydmVyPyANCgk+IA0K CT4gV291bGQgaXQgYmUgZWFzaWVyIGZvciBTTFAgdG8gYWRkIGEgInByZWNlZGVuY2UiIGF0dHJp YnV0ZSANCgk+IGFuZCBoYXZlIGVhY2ggc2VydmVyIHJlZ2lzdGVyIHdpdGggU0xQLCB0aGVuIGhh dmUgdGhlIGNsaWVudCANCgk+IHBlcmZvcm0gdGhlIHNhbWUgZmFpbG92ZXIgYXMgREhDUCBhbmQg aGVhcnRiZWF0IGRvPyANCg0KCS0tIA0KCUFuZHkgQ3VycmlkICAgICAgICAgICAgICAgICBQaG9u ZTogNDA4IDMzMCA0NTA3IA0KCWlSZWFkeSBDb3Jwb3JhdGlvbiAgICAgICAgICAgIEZheDogNDA4 IDMzMCA0NTIxIA0KCWFuZHlAaXJlYWR5LmNvbSAgICAgICAgICAgaHR0cDovL3d3dy5pcmVhZHku Y29tIA0KDQoNClNQRUNJQUwgTk9USUNFIA0KDQpBbGwgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQg aGVyZWJ5IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIA0KYWRkcmVzc2VlKHMp IG5hbWVkICBhYm92ZSBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2Vk IA0KaW5mb3JtYXRpb24uIEFueSB1bmF1dGhvcml6ZWQgIHJldmlldywgdXNlLCBkaXNjbG9zdXJl IG9yIGRpc3RyaWJ1dGlvbg0Kb2YgY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIElmIHRoZSByZWFkZXIgb2YNCnRoaXMgbWVzc2FnZSBpcyBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBvciB0aGUgZW1wbG95ZWUgb3IgYWdlbnQgDQpyZXNw b25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGUgbWVzc2FnZSB0byB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UNCmFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCB5b3UgbXVzdCBub3QgcmVhZCB0aGlz IHRyYW5zbWlzc2lvbiBhbmQgdGhhdA0KZGlzY2xvc3VyZSwgY29weWluZywgcHJpbnRpbmcsIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IG9yIGF0dGFjaGVkIHRvIHRoaXMgdHJhbnNtaXNzaW9uIGlzIFNUUklDVExZIA0KUFJPSElCSVRF RC4NCg0KQW55b25lIHdobyByZWNlaXZlcyBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gaW4gZXJyb3Igc2hvdWxkIA0Kbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHRlbGVw aG9uZSBhbmQgbWFpbCB0aGUgb3JpZ2luYWwgbWVzc2FnZSB0byB1cyBhdCB0aGUNCmFib3ZlIGFk ZHJlc3MgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcy4gIFRvIHRoZSBleHRlbnQgYW55IHBvcnRpb24g b2YgdGhpcw0KY29tbXVuaWNhdGlvbiBjb250YWlucyBwdWJsaWMgaW5mb3JtYXRpb24sIG5vIHN1 Y2ggcmVzdHJpY3Rpb25zIA0KYXBwbHkgdG8gdGhhdCBpbmZvcm1hdGlvbi4gKGdhdGUwMSkNCg== _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 14:19:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29912 for ; Thu, 5 Feb 2004 14:19:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aop26-0008Bu-Vn for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 14:19:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15JJQXi031480 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 14:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aop26-0008Bf-QZ for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 14:19:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29873 for ; Thu, 5 Feb 2004 14:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aop23-0003HW-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:19:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aop0x-0003Ay-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:18:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoozm-00031i-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:17:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoozl-000827-Ol; Thu, 05 Feb 2004 14:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aooyw-0007za-TK for ips@optimus.ietf.org; Thu, 05 Feb 2004 14:16:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29709 for ; Thu, 5 Feb 2004 14:16:08 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aooyu-0002zX-00 for ips@ietf.org; Thu, 05 Feb 2004 14:16:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aooxv-0002rq-00 for ips@ietf.org; Thu, 05 Feb 2004 14:15:07 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aoowx-0002kJ-00 for ips@ietf.org; Thu, 05 Feb 2004 14:14:07 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 0C4B140152; Thu, 5 Feb 2004 14:14:05 -0500 (EST) Date: Thu, 5 Feb 2004 11:13:48 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Andy Currid Cc: ips@ietf.org Subject: RE: [Ips] iSNS failover and multi-server configurations In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 5 Feb 2004, Andy Currid wrote: > > about SLP in face of multiple servers? Andy Currid suggested > > that SLP should only have the most-senior operational server > > registered. > > That's more than I recall saying :-) Sorry, turns out that was Josh Tseng. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 14:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01550 for ; Thu, 5 Feb 2004 14:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopbd-0001xh-13 for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 14:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Ju8pd007535 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 14:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aopbc-0001xS-RF for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 14:56:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01529 for ; Thu, 5 Feb 2004 14:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aopba-000758-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aopab-0006zx-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:55:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AopZd-0006uz-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 14:54:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopZZ-0001ov-7F; Thu, 05 Feb 2004 14:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AopYj-0001m4-6W for ips@optimus.ietf.org; Thu, 05 Feb 2004 14:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01486 for ; Thu, 5 Feb 2004 14:53:06 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AopYg-0006py-00 for ips@ietf.org; Thu, 05 Feb 2004 14:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AopXj-0006kU-00 for ips@ietf.org; Thu, 05 Feb 2004 14:52:07 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AopWn-0006fV-00 for ips@ietf.org; Thu, 05 Feb 2004 14:51:09 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 69F6040139; Thu, 5 Feb 2004 14:51:09 -0500 (EST) Date: Thu, 5 Feb 2004 11:50:53 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Joshua Tseng , Elizabeth.Rodriguez@DotHill.com, Black_David@emc.com Cc: Andy Currid , ips@ietf.org Subject: RE: [Ips] iSNS failover and multi-server configurations In-Reply-To: <501EA67E9359C645A10C42EB5B52480D4BB102@SNEXCH01.mcdata.com> Message-ID: References: <501EA67E9359C645A10C42EB5B52480D4BB102@SNEXCH01.mcdata.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Thu, 5 Feb 2004, Joshua Tseng wrote: > I would agree, and would request that the iSCSI-SLP draft author (Mark > Bakke, you still there?) to incorporate a precedence attribute into the > sms template. That's now two outstanding requests against the iSCSI-SLP draft. The other (repeated for clarity) is that we add a transport attribute for iSNS servers so that a client knows if it should use tcp or udp to reach the server. I second Josh's request that we make these changes. :-) Elizabeth & David, where do we stand on this draft? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 5 17:55:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17474 for ; Thu, 5 Feb 2004 17:55:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosOw-0001vE-UN for ips-archive@odin.ietf.org; Thu, 05 Feb 2004 17:55:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15MtEPp007384 for ips-archive@odin.ietf.org; Thu, 5 Feb 2004 17:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosOw-0001v1-PP for ips-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 17:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17461 for ; Thu, 5 Feb 2004 17:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AosOu-0003Wg-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 17:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AosNw-0003Vd-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 17:54:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AosNb-0003Un-00 for ips-web-archive@ietf.org; Thu, 05 Feb 2004 17:53:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosMn-0001pZ-4D; Thu, 05 Feb 2004 17:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AosM4-0001oV-RV for ips@optimus.ietf.org; Thu, 05 Feb 2004 17:52:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17387 for ; Thu, 5 Feb 2004 17:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AosM2-0003TN-00 for ips@ietf.org; Thu, 05 Feb 2004 17:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AosLF-0003SF-00 for ips@ietf.org; Thu, 05 Feb 2004 17:51:26 -0500 Received: from mcjekyll.mcdata.com ([144.49.6.25] helo=380GATE01out.mcdata.com) by ietf-mx with esmtp (Exim 4.12) id 1AosKM-0003Ou-00 for ips@ietf.org; Thu, 05 Feb 2004 17:50:30 -0500 Received: from 380GATE01.mcdata.com ([172.18.1.72]) by 380GATE01out.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 15:50:00 -0700 Received: from MC4EXCH03.mcdata.com ([172.16.11.122]) by 380GATE01 with InterScan Messaging Security Suite; Thu, 05 Feb 2004 15:49:58 -0700 Received: from SNEXCH01.mcdata.com ([172.19.161.12]) by MC4EXCH03.mcdata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 15:49:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSNS failover and multi-server configurations Date: Thu, 5 Feb 2004 14:49:57 -0800 Message-ID: <501EA67E9359C645A10C42EB5B52480D361342@SNEXCH01.mcdata.com> Thread-Topic: [Ips] iSNS failover and multi-server configurations Thread-Index: AcPrkV9Hc2ZDvQ+jS5+NMu7ZzUFhwwAor5DA From: "Kevin Gibbons" To: , X-OriginalArrivalTime: 05 Feb 2004 22:49:58.0781 (UTC) FILETIME=[61B1DAD0:01C3EC3A] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable All, please see below for comments. Regards, Kevin -----Original Message----- From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com]=20 Sent: Wednesday, February 04, 2004 6:37 PM To: ips@ietf.org Subject: [Ips] iSNS failover and multi-server configurations The iSNS draft (draft-ietf-ips-isns-21.txt) mentions the concept of backup servers (especially in the heartbeat PDU) and says it will describe client interatctions with multiple servers (Section 2.8). However I can't find any discussion of client interactions in that section. KAG> Yes, section 2.8, "Backup iSNS Servers", primarily talks about iSNS server interaction. It does not discuss how a client interacts with them. It only says that a client can interact with multiple iSNS servers, some of which are backup servers. So can we either have some more text, or some sort of suplimental document that gives guidelines on how to deal with these concepts? I have a few questions, and while I can answer them, I want to make sure my answers agree with everyone else's. :-) KAG> If I understand the IETF WG process correctly, it should be possible to add some text at this stage - if it is agreed that the text is not changing the technical operation of the protocol. Questions: 1) Say a device is using iSNS heartbeats to find the server. Say it starts up and can't connect to the primary server (or specifically it is only hearing messages from a backup server). Say it registers with the backup server. Now say the primary server comes back on line. What does the device need to do? KAG> As described in Section 2.7, "Transfer of iSNS Database Records between iSNS Servers", and Section 2.8, "Backup iSNS Servers", the primary and backup servers must have a coordinated database. It states: "If the primary backup server or other higher-precedence backup server returns, then the existing active server is responsible for ensuring that the new active server's database is up-to-date before demoting itself to its original status as backup." How the coordination is done is beyond the scope of the current iSNS specification. 1a) does it re-register its configuration with the new primary server, or does it assume that the new server synchronized itself before resuming being hte primary server? KAG> since the iSNS server database is coordinated between the primary and backup servers, no re-registration by an iSNS Client is required. KAG> I agree that adding some text to clarify this in Section 2.8 would be helpful. Perhaps the following: "Since the primary and backup iSNS servers maintain a coordinated database, no re-registration by an iSNS Client is required when a secondary server takes the active server role. Likewise, no re-registration by an iSNS Client is required when the previous primary server returns to the active server role." 1b) does it need to register SCN requests with the new server? Does it need to de-register its old SCN registrations? KAG> no re-registration should be required. 2) I see that DHCP can indicate multiple servers. But what about SLP in face of multiple servers? Andy Currid suggested that SLP should only have the most-senior operational server registered. But what happens when either a formerly-off-line server comes back on line or an on-line server goes off-line? SLP does not seem well-suited for "server moved" notifications. Also, with SLP, if a server fails, what are the security considerations for the backup server to be able to de-register the server? Would it be easier for SLP to add a "precedence" attribute and have each server register with SLP, then have the client perform the same failover as DHCP and heartbeat do? KAG> It may be best for SLP template to also indicate the iSNS server precedence in some manner. Thanks! Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips SPECIAL NOTICE=20 All information transmitted hereby is intended only for the use of the=20 addressee(s) named above and may contain confidential and privileged=20 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=20 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=20 PROHIBITED. Anyone who receives confidential and privileged information in error should= =20 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=20 apply to that information. (gate01) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 6 18:00:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27386 for ; Fri, 6 Feb 2004 18:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApExB-0007cc-Vs for ips-archive@odin.ietf.org; Fri, 06 Feb 2004 18:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16N04Xw029284 for ips-archive@odin.ietf.org; Fri, 6 Feb 2004 18:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEx9-0007cC-PG for ips-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 18:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27351 for ; Fri, 6 Feb 2004 17:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEx7-0002Cz-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 18:00:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEwA-00029x-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 17:59:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApEvM-00027I-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 17:58:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEvB-0007OW-Jq; Fri, 06 Feb 2004 17:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEuE-0007MP-En for ips@optimus.ietf.org; Fri, 06 Feb 2004 17:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27273 for ; Fri, 6 Feb 2004 17:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEuB-00022C-00 for ips@ietf.org; Fri, 06 Feb 2004 17:56:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEtF-0001yu-00 for ips@ietf.org; Fri, 06 Feb 2004 17:56:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ApEsK-0001t2-00 for ips@ietf.org; Fri, 06 Feb 2004 17:55:04 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2004 14:55:09 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i16MsVGq025387; Fri, 6 Feb 2004 14:54:32 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA13010; Fri, 6 Feb 2004 14:54:31 -0800 (PST) From: Keith McCloghrie Message-Id: <200402062254.OAA13010@cisco.com> Subject: Re: [Ips] FW: Initial review of http://www.ietf.org/internet-drafts/draft-i To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Fri, 6 Feb 2004 14:54:31 -0800 (PST) Cc: ips@ietf.org ("Ipswg (E-mail)"), mrm@kazeon.com ("Mike MacFaden (E-mail)"), mankin@psg.com ("Allison Mankin (E-mail)") In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC50A@nl0006exch001u.nl.lucent.com> from "Wijnen, Bert (Bert)" at Feb 04, 2004 11:33:19 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bert/Mike, Thanks for the review. Below, please find : a) my respones to the comments, and b) the changes that I plan to make as a result of the review. Thanks, Keith. > Thanks Mike for the first MIB Doctor review. > > authors/wg members, > Pls copy Mike on any responses, cause I suspect he is not > subscribed to IPS mailinglist (Mike tell us if you are, > in which case people do not specifically have to copy you). > > Thanks, > Bert > > -----Original Message----- > From: Michael MacFaden [mailto:mrm@kazeon.com] > Sent: woensdag 4 februari 2004 7:02 > To: Wijnen, Bert (Bert) > Cc: Anurag Maunder > Subject: Initial review of > http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > > Hi Bert, > > My review of the fiber channel management MIB module: > > http://www.macfaden.com/ietf/fc-mgmt-mib-4-reviewed.txt > > Regards, > Mike > ------------------------------------------------------------------------------ > Feb 3, 2004 MIB DOCTOR Review: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcmgmt-mib-04.txt > > Performed by Michael R. MacFaden, Kazeon Systems, Inc > according to draft-ietf-ops-mib-review-guidelines-02.txt > > A. Documentation Guidelines > 3.1 o MIB boilerplate section -> present > current version? -> YES > o Narrative sections -> present > Scope described? -> YES > Spelling? -> No obvious mistakes > Module structure described? -> YES > Dependent on other modules? -> YES > If so, which ones? -> IF-MIB > Relates to other modules? -> YES > If so, which ones? -> HOST-RESOURCES-MIB, ENTITY-MIB, > References ([XXX])? -> Yes, they are correct and resolve properly > > Reviewer Comments: > 1. "high performance capability" isn't further defined so first > sentence is so much fluff. This sentence which appears in the first sentence of the "Short Intro to Fibre Channel" section, was copied from the Introduction section of Fibre Channel standards documents. The intent is to give a high-level indication of what Fibre Channel is aimed at, and to phrase it so as to remain valid in the future as and when the specific bandwidth supported by Fibre Channel is higher than it is today. It is too early in the into to be definitive. Thus, it isn't "fluff". > 2. Text describing the MIB module's structure (Sect 4.1-11) is better than the GROUP DESCRIPTION > clauses in the compliance section. > 3. IF-MIB description was superbly done. > o Definitions section present -> present > Written to SMIv2 standards? -> YES > Issues with compilation? -> YES > o Intellectual Property section -> present > Matches current boilerplate? -> YES > Any proprietary rights claimed? -> NO > o References section -> present > Matches current boilerplate (2578-80,3410)? -> YES > Normative/informative sections separate? -> YES > MIB modules listed in IMPORTS included? -> > o Security section -> present > Matches current boilerplate? -> YES > Specific Read/write objects listed? -> YES > Security risk spelled out? -> YES > Specific Read only objects listed? > > Reviewer Comments: > There was only one specific security risk described. More could be "spelled out." > For instance, setting fcmSwitchDomainId to an invalid value could lead to > denial of service in some configurations. No matter how much one writes in this section, it is always true that "more could be spelled out". > o IANA Considerations section -> not present > Was a namespace defined? -> NO > > o Copyright Notices section -> present > Correct year specified? -> NO > Copyright found in MODULE-IDENTITY? -> NO Noted. > o Definitions section detail > > Here are the diagnostics from certain mib syntax checkers: > > Diagnostics from Version 0.4.2 smilint -l9 > C:\local\smi\mibs\ietf>smilint -m -s -l 9 ./FC-MGMT-MIB > ./FC-MGMT-MIB:2213: [5] {group-unref} warning: current group `fcmLinkBasicGroup' is not referenced in this module OK, I will add a GROUP clause to "make it clear that the optional status is intended". > ./FC-MGMT-MIB:62: [5] {type-without-format} warning: type `DomainIdOrZero' has no format specification > ./FC-MGMT-MIB:94: [5] {type-without-format} warning: type `FcBbCredit' has no format specification > ./FC-MGMT-MIB:106: [5] {type-without-format} warning: type `FcDataFieldSize' has no format specification > ./FC-MGMT-MIB:171: [5] {type-without-format} warning: type `PhysicalIndexOrZero' has no format specification > ./FC-MGMT-MIB:181: [5] {type-without-format} warning: type `HrSWInstalledIndexOrZero' has no format specification > ./FC-MGMT-MIB:192: [5] {type-without-format} warning: type `MilliSeconds' has no format specification > ./FC-MGMT-MIB:198: [5] {type-without-format} warning: type `MicroSeconds' has no format specification It seems to me like the compiler has a bug here, since all of these are, or have a TC as their syntax and for all but two of them, the TC is defined with a range, e.g., DomainIdOrZero is defined as: DomainIdOrZero ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The Domain Id (of a FC switch), or zero if the no Domain Id has been assigned." SYNTAX Integer32 (0..239) The two exceptions are MilliSeconds and MicroSeconds which are both Unsigned32 and the inherent (0..4294967295) is correct for both. > Diagnostics from MIB Smithy 2.4.2 > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstanceSoftwareIndex] : warning : SYNTAX in variation and OBJECT-TYPE differ in type names 'Integer32' and 'HrSWInstalledIndexOrZero'. > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstancePhysicalIndex] : warning : SYNTAX in variation and OBJECT-TYPE differ in type names 'Integer32' and 'PhysicalIndexOrZero'. Yes, but both HrSWInstalledIndexOrZero and PhysicalIndexOrZero are TCs which have Integer32 as their underlying syntax. > [FC-MGMT-MIB:fcmLinkEnd2UnitType] : warning : BITS named-number list values should start at zero. > [FC-MGMT-MIB:fcmFLoginClassesAgreed] : warning : BITS named-number list values should start at zero. Another bug in the compiler. Both objects have a TC as their syntax where the TC has a named-number list which does start at zero. > [FC-MGMT-MIB:fcmISPortEntry] : warning : All INDEX objects in this table are auxiliary (i.e., from other tables). > [FC-MGMT-MIB:fcmFxPortEntry] : warning : All INDEX objects in this table are auxiliary (i.e., from other tables). Eh? The compiler has another bug, since: a) auxiliary does NOT mean "i.e., from other tables", rather RFC 2758 section 7.7 defines "auxiliary" as follows: Objects which are both specified in the INDEX clause of a conceptual row and also columnar objects of the same conceptual row are termed auxiliary objects. Thus, the error message as stated is actually wrong. b) It is common practice for media-specific MIBs which extend the IF-MIB to define a table which is INDEX-ed only by ifIndex. > [FC-MGMT-MIB:fcmPortFcOperClass] : warning : BITS named-number list values should start at zero. > [FC-MGMT-MIB:fcmPortFcCapClass] : warning : BITS named-number list values should start at zero. > [FC-MGMT-MIB:fcmPortEntry] : warning : All INDEX objects in this table are auxiliary (i.e., from other tables). > [FC-MGMT-MIB:fcmInstanceFunctions] : warning : BITS named-number list values should start at zero. > Validation complete - 0 error(s), 10 warning(s) See above. > Reviewer Comments: > 1. The TC's could possibly go into a separate TC document for fiber channel: FcNameIdOrZero, DomainIdOrZero, FcAddressId > as it is mentioned there might be multiple Fiber channel mib modules in the future. While your "could" and "possibly" are correct, but we have already written several of these follow-on FC MIB modules, and they are IMPORT-ing TCs from this MIB without any problems. So, this would be a disruptive change for no benefit. > 2. FcAddressId doesn't have an *OrZero version, which might be needed at a later date. It's syntax is "OCTET STRING (SIZE(0 | 3))" and the zero-length value is already used (see fcmLinkEnd2FcAddressId). > 3. FcPortType enumeration "dynamic(3), -- determined dynamically" seems redundant, prefer comment point to underlying spec No, it's not redundant because "dynamic" could also mean that the value is constantly changing, and saying "determined dynamically" removes that possibility. > 4. PhysicalIndexOrZero, HrSWInstalledIndexOrZero are very useful and generally applicable to many mib modules. > They look strangly wrong being defined here and should be defined in another TC, like Entity-MIB, or some common TC-MIB. But they aren't, and thus, the best that this MIB module can do is to define the TC's itself. > 5. MicroSeconds, MilliSeconds should also be in some generic tc-mib... But they aren't, and thus, the best that this MIB module can do is to define the TC's itself. > 6. fcmInstanceIndex DESCRIPTION is problematic for me. Either it stays static or it doesn't. > Having something "desireable" is worthless to those writing mangement applications, they have to assume worst case always. Not worthless, because if agent implementors heed the advice, then mgmt apps can coded to check whether the index values have been retained over the last restart, and only if not, do they need to re-synchronize their database. That is, it is an optimization for the common case of index values being retained, but the fallback still works in the case (hopefully less common) when all knowledge of index values is lost. > There are problems with the description. Sentences start without capitalization. "Sentences" ?? I see only one such sentence-break, for which the fix is to delete the the period before "but" (because it's bad grammar to start a sentence with "But".) > fcmInstanceTable has very critical data. Would like to have a LastChange entry per row to know when values were changed or > a "configuration change" notification if lastChange object is too much overhead. But the data is not, in general, both critial and dynamic. Specifically, the only things in this table that change are: - the FabricId if it's based on the WWN of the Principal switch; -- a notification of a Principal switch change is being proposed as an extension to this MIB. - the read-write objects (but only when an app changes them); -- changes in these values are not critical to the operation of the network, and the synchronization of mgmt apps should not have to rely on notifications from agents for such non-critical data. - the Status object, -- to monitor this object for changes, set an RMON threshold on it. Note that the typical situation is to have just one instance; even if there are multiple instances, there will not be many. Having an RMON threshold will be more effective than having a LastChange object. > 7. fcmInstanceWwn, but does it matter which WWN is selected? Will managment stations expect one vendor implemetnation over another? The ability to have multiple instances is defined as a flexibility to allow for many/any different choices by vendors. Vendors are free to choose to have one, or more, instances using whatever methodology they wish. Thus, we cannot prescribe how the WWN is selected. This flexibility is necessary because otherwise there is a genuine risk that a vendor will implement a set of Fibre Channel interfaces in a manner which cannot be represented by this MIB. > Wouldn't it be the same as fcmSwitchDomainId if fcmSwitchPrincipal is True? It could be but it needn't be, and the circumstance you ask about is a corner case which for example never applies to HBAs. > 8. fcmInstanceStatus could use an associated object to get timestamp of the last state change While implementation feedback might tell us that, I think it's too soon to be sure. So, let's save this comment until we update the MIB from Proposed to Draft Standard. > 9. fcmInstanceStatus doesn't seem to be implementable in a consistent way across vendors. Needs better definition > ideally this state is defined in the underlying technology specifications. On the contrary, a) there is no one underlying technology, and b) the underlying technology specifications are the subject of future MIBs, not this one. This object serves as a generic summary of the underlying specifics (e.g., somewhat like ifOperStatus does for an interface.) > 10. fcmInstanceTextName/fcmInstanceDescr, are there any DEFAULT values for these? Suspect vendor implementations will > provide something. Better to define the intended purpose of these objects better. > "A textual name for this management instance and the Fibre > Channel entity/entities that it is managing." > might be > "A textual name for this management instance and the Fibre > Channel entity/entities that it is managing set by the operator or to a default string "XXXX" by the device." "XXXX" can not be specified in this MIB without restricting the necessary flexibility, anything that could be specified in this MIB would not be specific enough. The whole idea of this object is to be the name specified by the operator/NM-app, to have a default value changes the semantics. > 11. fcmPortAdminType - Assuming a valid value change can't be done for some device resource specific case, how can > the error be reported? A generic snmp error to the set is necessary but not sufficient I think. Why would it not be sufficient ?? > 12. Not sure why these object's syntax wasn't a TC? They will probably be added to in time as well. > fcmPortCapProtocols > fcmPortTransmitterType > fcmPortConnectorType -- this should probably follow the MAU-MIB convention or we need to standardize 'JackType' > in a new TC mib as there is now overlap... Actually, not for the latter two because they are not generic definitions. Rather they are the specific enumerations listed for the function in T11's GS-3 speciofication. Sicne a future revision of the GS-3 spec could revise them individually, they cannot be defined as common TCs. The first one could, but I don't see any rule that it violates which would justify a change at this time. > 13. fcmPortStatsTable doesn't have an explicitly specified discontinuity object -- is ifXTable entry the one that applies? Yes. > Also, the counters described here should have REFERNCE clauses to counters defined in the underlying technology > specs. While the descriptions are generally good, they do not cover all possible cases when > one should be incremented or not -- that leads to incompatible implementations. Many of them are not specifically defined in any Fibre Channel specification. If any are ambiguous, please suggest alternative wording. Otherwise, I suggest we wait for implementation feedback. > 14. fcmPortLcStatsTable doesn't have split counters? Is a SNMPv1 agent then really useful when running high speed interfaces? No, but at the time (several years ago now) when this was discussed in the WG, many Storage vendors only had SNMPv1 agents, and as a result, this table was defined at the explicit direction of the WG. > DESCRIPTION > "A list of Counter32-based statistics which are a shadow of > the Counter64 statistics in the fcmPortStatsTable, for > systems which do not support Counter64." > I suggest the text mention it should "shadow" the lower 32 bits? If that isn't what "shadow" means, then I don't know what it does mean, and we shouldn't use the term at all. > 15. If errors are not so common an occurance across instances, the fcmPortErrorsTable might benefit from a *LastChange object > so not all objects have to be polled to determine any error state change. Alternately provide a summary counter that > is a simple sum of the number of errors. That should allow for better scaling of this table for mgmt polling using SNMP/UDP. The summary counter for many of these is already available: ifInErrors. > 16. Error table should have REFERENCE clauses to point out where in the underlying spec these counters are defined. > This appears to be done, but is inconsistent. fcmPortLinkFailures has a REFERENCE but fcmPortLinkResets wasn't? As I recall, it is consistent; specifically, all those for which there is an appropriate section to reference have a REFERENCE clause. > 17. fcmFxPortTable needs a discontinutity object. if fcmPortOperType is changed from Fx to some other then back within > a given polling interval, the data collected from this table will be incorrect. No, because there are no Counter-based objects in this table. > 18. Objects in fcmFxPortTable, fcmFLoginTable could use REFERENCE clauses. Sigh !! I will look again to see what I can find. > 19. fcmFLoginNxPortIndex doesn't specify what behaviors should be across SNMP agent reset or system reboots like > fcmInstanceIndex is required to do. So I'm a bit concerned what the indexing looks like for all the tables on > system reset or agent reset. I will add a sentence saying that after a value of fcmFLoginNxPortIndex is assigned to a particular Nx_Port, it can be re-used when and only when it is assigned to the same Nx_Port, or, after a reset of the value of the relevant instance of ifCounterDiscontinuityTime. > 20. fcmLinkEnd2AgentAddress OBJECT-TYPE is SYNTAX SnmpAdminString, not InetAddressType? Why? Because the value is received from the otrher end of the link, and if the other end supplies a bogus value,m then that bpgus value needs to be stored in the MIB. > 21. > > End of Report > ------------------------------------------------------------------------------ - fix the Copyright dates, and insert a Copyright statement in the MODULE-IDENTITY. - add GROUP fcmLinkBasicGroup DESCRIPTION "This group is optional." - delete the period in "... across restarts. (but note, it is ..." - add an explicit statement that discontinuities in the counters in the fcmPortStatsTable can only occur when the value of the relevant isntance of ifCounterDiscontinuityTime is zero. - look again to see what references I can find to put in REFERENCE clauses of objects in fcmFxPortTable, fcmFLoginTable. - add a sentence saying that after a value of fcmFLoginNxPortIndex is assigned to a particular Nx_Port, it can be re-used when and only when it is assigned to the same Nx_Port, or, after a reset of the value of the relevant instance of ifCounterDiscontinuityTime. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 6 18:09:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28192 for ; Fri, 6 Feb 2004 18:09:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApF5p-0003L8-NY for ips-archive@odin.ietf.org; Fri, 06 Feb 2004 18:09:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16N91BF012826 for ips-archive@odin.ietf.org; Fri, 6 Feb 2004 18:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApF5p-0003Kn-Cb for ips-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 18:09:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28110 for ; Fri, 6 Feb 2004 18:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApF5m-0002q0-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 18:08:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApF4p-0002kV-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 18:08:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApF3s-0002fK-00 for ips-web-archive@ietf.org; Fri, 06 Feb 2004 18:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApF3u-0002VW-Fj; Fri, 06 Feb 2004 18:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApF32-0002FC-HB for ips@optimus.ietf.org; Fri, 06 Feb 2004 18:06:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27748 for ; Fri, 6 Feb 2004 18:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApF2z-0002bR-00 for ips@ietf.org; Fri, 06 Feb 2004 18:06:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApF24-0002X9-00 for ips@ietf.org; Fri, 06 Feb 2004 18:05:09 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ApF1C-0002Pr-00 for ips@ietf.org; Fri, 06 Feb 2004 18:04:14 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i16N3f329941 for ; Fri, 6 Feb 2004 17:03:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 7 Feb 2004 00:03:40 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC558@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Keith McCloghrie'" , "Wijnen, Bert (Bert)" Cc: ips@ietf.org, mrm@kazeon.com, mankin@psg.com Subject: RE: [Ips] FW: Initial review of http://www.ietf.org/internet-draf ts/draft-i Date: Sat, 7 Feb 2004 00:03:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 > > ./FC-MGMT-MIB:62: [5] {type-without-format} warning: type > `DomainIdOrZero' has no format specification > > ./FC-MGMT-MIB:94: [5] {type-without-format} warning: type > `FcBbCredit' has no format specification > > ./FC-MGMT-MIB:106: [5] {type-without-format} warning: type > `FcDataFieldSize' has no format specification > > ./FC-MGMT-MIB:171: [5] {type-without-format} warning: type > `PhysicalIndexOrZero' has no format specification > > ./FC-MGMT-MIB:181: [5] {type-without-format} warning: type > `HrSWInstalledIndexOrZero' has no format specification > > ./FC-MGMT-MIB:192: [5] {type-without-format} warning: type > `MilliSeconds' has no format specification > > ./FC-MGMT-MIB:198: [5] {type-without-format} warning: type > `MicroSeconds' has no format specification > > It seems to me like the compiler has a bug here, since all of these are, or > have a TC as their syntax and for all but two of them, the TC is defined > with a range, e.g., DomainIdOrZero is defined as: > > DomainIdOrZero ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The Domain Id (of a FC switch), or zero if the no Domain Id > has been assigned." > SYNTAX Integer32 (0..239) > > The two exceptions are MilliSeconds and MicroSeconds which are both > Unsigned32 and the inherent (0..4294967295) is correct for both. > I think that the warning means that a DISPLAY-HINT is missing ! Let me add, that I find the name DomaiainIdOrZero a pretty generic name and that the description clause seems to limit it to an FC switch. Maybe all (or most) of your TCs should have a name (descriptor) that starts with FcXxxx > > Diagnostics from MIB Smithy 2.4.2 > > > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstanceSoftwareI > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > in type names 'Integer32' and 'HrSWInstalledIndexOrZero'. > > > [FC-MGMT-MIB:fcmgmtCompliance:FC-MGMT-MIB:fcmInstancePhysicalI > ndex] : warning : SYNTAX in variation and OBJECT-TYPE differ > in type names 'Integer32' and 'PhysicalIndexOrZero'. > > Yes, but both HrSWInstalledIndexOrZero and PhysicalIndexOrZero are TCs > which have Integer32 as their underlying syntax. > But I think you know very well that we do not want this, do we? WHy not be explicit. By the way, I am not sure it is wise to name it HrSWInstalledIndexOrZero If we start down this path, collisions with TCs in the Hr-MIB can easily occur in the future. Why not FcHr.... more later Bert _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 10:43:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24533 for ; Mon, 9 Feb 2004 10:43:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDZ0-0007fQ-Ue for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 10:43:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19FhAb8029468 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 10:43:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDZ0-0007fD-Ox for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24485 for ; Mon, 9 Feb 2004 10:43:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDYy-0001L0-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 10:43:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDY5-0001FU-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 10:42:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDX9-0001AG-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 10:41:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDWx-0007RL-U0; Mon, 09 Feb 2004 10:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDRD-0006b4-2S for ips@optimus.ietf.org; Mon, 09 Feb 2004 10:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24124 for ; Mon, 9 Feb 2004 10:35:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDRA-0000da-00 for ips@ietf.org; Mon, 09 Feb 2004 10:35:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDQD-0000ZV-00 for ips@ietf.org; Mon, 09 Feb 2004 10:34:07 -0500 Received: from mail0.lsil.com ([147.145.40.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqDPi-0000S1-00 for ips@ietf.org; Mon, 09 Feb 2004 10:33:34 -0500 Received: from new-mhbs.co.lsil.com (mhbs.lsil.com [172.21.20.49]) by mail0.lsil.com (8.12.8/8.12.8) with ESMTP id i19FTa1K011216 for ; Mon, 9 Feb 2004 07:29:36 -0800 (PST) Received: from exw-ks.ks.lsil.com (wic1.ks.lsil.com [153.79.12.11]) by new-mhbs.co.lsil.com (8.12.11/8.12.10) with ESMTP id i19FWq0H028494 for ; Mon, 9 Feb 2004 08:32:52 -0700 Received: by exw-ks.ks.lsil.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Feb 2004 09:31:15 -0600 Message-ID: <53CF1076699CD711B7DD0002A51363F1019BBC31@exw-ks.ks.lsil.com> From: "Spry, Andy" To: ips@ietf.org Date: Mon, 9 Feb 2004 09:31:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF21.BEC44980" X-Scanned-By: MIMEDefang 2.39 Subject: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d LUN Reset Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF21.BEC44980 Content-Type: text/plain; charset="iso-8859-1" All, The recent discussion on which tasks are affected by a clear task set was informative but did not address this issue. I need some clarification on the ordering of responses or unit attention for tasks on sessions other than the session issuing a Clear Task Set or LUN Reset TMF. When TST is 000b, the task set for a LUN includes tasks from all initiators. When a Clear Task Set (or LUN Reset) is received the set of tasks already present in the SCSI layer for the LUN must be aborted. The behavior for the initiator that issued the TMF is clearly defined. All I/O sequences in progress are completed or terminated before the TMF response is returned to the initiator. However, the timing of notification to other initiators is not as clear. According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on the setting of the TAS bit in the Control mode page. When TAS is 0, the method of notification is a Unit Attention condition. The additional sense code dependent on the action that caused the task(s) to be aborted. When TAS is 1, each task is aborted with a TASK ABORTED status. A unit attention with the sense code "COMMAND CLEARED BY ANOTHER INITIATOR" is NOT sent to the initiator. The section further states that: "When a logical unit is aborting one or more tasks from a SCSI initiator port with the TASK ABORTED status it should complete all those tasks before entering additional tasks from that SCSI initiator port into the task set" Assuming the "point in time" method is used to define the tasks sets for initiators, how can a race condition between the Unit Attention and the completion of I/O for tasks being aborted be avoided when the TAS bit is set to 0? Any commands being aborted that are in an I/O phase must be terminated gracefully if possible. However, the Unit Attention occurs immediately for the next command arriving from the initiator. The Unit Attention response can be sent back to the initiator while there is still I/O being completed on the commands being aborted. Even if the arrival of the next command which would return the Unit Attention condition is delayed (as done for the case when TAS is set to 1), the response and final I/O operations for the last command being aborted may be traveling on different connections in a session. In the pathological case, the unit attention can arrive at the initiator before the final I/O phase has completed. In both these cases, the initiator may free all resources used for I/O operations that are still not completed by the target. When TAS is 1, these issues are resolved because each individual I/O is explicitly terminated with a TASK ABORTED status. Should the iSCSI specification include a clause that encourages or mandates the use of the TAS=1 setting to resolve this potential race condition between Unit Attention and the I/O cleanup during task abort? Does anyone see some error in my reasoning or a different way of resolving this issue. Thanks, Dr. Andrew J. Spry LSI Logic Storage Systems, INC ------_=_NextPart_001_01C3EF21.BEC44980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sequencing of UA and I/O from aborted tasks in Clear Task Set, = and LUN Reset

All,

The recent discussion on which tasks are affected by = a clear task set was informative but did not address this issue.  =

I need some clarification on the ordering of = responses or unit attention for tasks on sessions other than the = session issuing a Clear Task Set or LUN Reset TMF. 

When TST is 000b, the task set for a LUN includes = tasks from all initiators.  When a Clear Task Set (or LUN Reset) = is received the set of tasks already present in the SCSI layer for the = LUN must be aborted. 

The behavior for the initiator that issued the TMF is = clearly defined.  All I/O sequences in progress are completed or = terminated before the TMF response is returned to the initiator.  =

However, the timing of notification to other = initiators is not as clear.  According to SAM-2 and SAM-3 (5.7.3) = the method of notification depends on the setting of the TAS bit in the = Control mode page. 

 
    When TAS is 0, the method of = notification is a Unit Attention condition. 
        The = additional sense code dependent on the action that caused the task(s) = to be aborted. 

    When TAS is 1, each task is = aborted with a TASK ABORTED status. 
        A unit = attention with the sense code "COMMAND CLEARED BY ANOTHER = INITIATOR" is NOT sent to the initiator. 

The section further states that: 

   "When a logical unit is aborting = one or more tasks from a SCSI initiator port with
    the TASK ABORTED status it should = complete all those tasks before entering additional
    tasks from that SCSI initiator = port into the task set" 

Assuming the "point in time" method is used = to define the tasks sets for initiators, how can a race condition = between the Unit Attention and the completion of I/O for tasks being = aborted be avoided when the TAS bit is set to 0?    =

Any commands being aborted that are in an I/O phase = must be terminated gracefully if possible.  However, the Unit = Attention occurs immediately for the next command arriving from the = initiator.  The Unit Attention response can be sent back to the = initiator while there is still I/O being completed on the commands = being aborted. 

Even if the arrival of the next command which would = return the Unit Attention condition is delayed (as done for the case = when TAS is set to 1), the response and final I/O operations for the = last command being aborted may be traveling on different connections in = a session.  In the pathological case, the unit attention can = arrive at the initiator before the final I/O phase has completed.  =

In both these cases, the initiator may free all = resources used for I/O operations that are still not completed by the = target. 

When TAS is 1, these issues are resolved because each = individual I/O is explicitly terminated with a TASK ABORTED status. = ;

Should the iSCSI specification include a clause that = encourages or mandates the use of the TAS=3D1 setting to resolve this = potential race condition between Unit Attention and the I/O cleanup = during task abort?

Does anyone see some error in my reasoning or a = different way of resolving this issue. 

Thanks,
Dr. Andrew J. Spry
LSI Logic Storage Systems, INC

------_=_NextPart_001_01C3EF21.BEC44980-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 13:29:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02668 for ; Mon, 9 Feb 2004 13:29:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG9m-00056t-3p for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 13:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19ITI2g019637 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 13:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG9l-00056e-VH for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:29:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02625 for ; Mon, 9 Feb 2004 13:29:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqG9j-0002cm-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:29:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqG8n-0002Td-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:28:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqG7c-0002DC-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG7Y-0004jC-W5; Mon, 09 Feb 2004 13:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqG7N-0004iu-DJ for ips@optimus.ietf.org; Mon, 09 Feb 2004 13:26:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02184 for ; Mon, 9 Feb 2004 13:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqG7L-0002Ax-00 for ips@ietf.org; Mon, 09 Feb 2004 13:26:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqG62-0001vK-00 for ips@ietf.org; Mon, 09 Feb 2004 13:25:27 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqG4l-0001Xl-00 for ips@ietf.org; Mon, 09 Feb 2004 13:24:07 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004020918233701600f5eb2e> (Authid: esquicksall); Mon, 9 Feb 2004 18:23:37 +0000 Message-ID: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Mon, 9 Feb 2004 13:23:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C3EF0F.E6104640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: intent of MaxCmdSN Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C3EF0F.E6104640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding MaxCmdSN, is the intent to regulate the flow of commands to = the SCSI layer or to regulate the flow to iSCSI for multiple = connections? It seems that it must be for multiple connections to reduce the number = of commands that are waiting to be ordered to SCSI. And that the SCSI = layer should be responsible for its own queue depth. But, I just wanted to see if I'm missing something. Eddy ------=_NextPart_000_0007_01C3EF0F.E6104640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Regarding MaxCmdSN, is the intent to regulate the = flow of=20 commands to the SCSI layer or to regulate the flow to iSCSI for multiple = connections?
 
It seems that it must be for multiple connections to = reduce=20 the number of commands that are waiting to be ordered to SCSI. And that = the SCSI=20 layer should be responsible for its own queue depth.
 
But, I just wanted to see if I'm missing=20 something.
 
Eddy
------=_NextPart_000_0007_01C3EF0F.E6104640-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 13:32:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02986 for ; Mon, 9 Feb 2004 13:32:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGCo-0005Yr-Nn for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 13:32:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IWQBo021371 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 13:32:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGCo-0005Yc-Jd for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:32:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02980 for ; Mon, 9 Feb 2004 13:32:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGCm-00032o-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:32:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGBt-0002x4-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:31:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGBR-0002qY-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGBS-0005PE-G5; Mon, 09 Feb 2004 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGB5-0005N7-Ew for ips@optimus.ietf.org; Mon, 09 Feb 2004 13:30:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02843 for ; Mon, 9 Feb 2004 13:30:37 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGB3-0002py-00 for ips@ietf.org; Mon, 09 Feb 2004 13:30:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGAE-0002i3-00 for ips@ietf.org; Mon, 09 Feb 2004 13:29:46 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqG9Y-0002YS-00 for ips@ietf.org; Mon, 09 Feb 2004 13:29:04 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id A4D0A40147; Mon, 9 Feb 2004 13:28:59 -0500 (EST) Date: Mon, 9 Feb 2004 10:28:40 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Spry, Andy" Cc: ips@ietf.org Subject: Re: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d LUN Reset In-Reply-To: <53CF1076699CD711B7DD0002A51363F1019BBC31@exw-ks.ks.lsil.com> Message-ID: References: <53CF1076699CD711B7DD0002A51363F1019BBC31@exw-ks.ks.lsil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Spry, Andy wrote: > I need some clarification on the ordering of responses or unit attention for > tasks on sessions other than the session issuing a Clear Task Set or LUN > Reset TMF. > > When TST is 000b, the task set for a LUN includes tasks from all initiators. > When a Clear Task Set (or LUN Reset) is received the set of tasks already > present in the SCSI layer for the LUN must be aborted. > > The behavior for the initiator that issued the TMF is clearly defined. All > I/O sequences in progress are completed or terminated before the TMF > response is returned to the initiator. > > However, the timing of notification to other initiators is not as clear. > According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on > the setting of the TAS bit in the Control mode page. > > When TAS is 0, the method of notification is a Unit Attention condition. > > The additional sense code dependent on the action that caused the > task(s) to be aborted. > > When TAS is 1, each task is aborted with a TASK ABORTED status. > A unit attention with the sense code "COMMAND CLEARED BY ANOTHER > INITIATOR" is NOT sent to the initiator. > > The section further states that: > > "When a logical unit is aborting one or more tasks from a SCSI initiator > port with > the TASK ABORTED status it should complete all those tasks before > entering additional > tasks from that SCSI initiator port into the task set" > > Assuming the "point in time" method is used to define the tasks sets for > initiators, how can a race condition between the Unit Attention and the > completion of I/O for tasks being aborted be avoided when the TAS bit is set > to 0? Note: "before entering additional tasks ... into the task set" does not mean before sending back the UA, it means that no tasks shall enter the "enabled" state in that time. In SAM-3 this is covered in section 8.4, and my recolection is it was covered the same in SAM-2. So you can (and probalby should) have tasks piling up in the "dormant" state while the abort is happening. And as a task can't return status until it has entered the "enabled" state (AFAICT), you won't get a command-related UA until after the aborting has ended. > Any commands being aborted that are in an I/O phase must be terminated > gracefully if possible. However, the Unit Attention occurs immediately for > the next command arriving from the initiator. The Unit Attention response > can be sent back to the initiator while there is still I/O being completed > on the commands being aborted. As above, I think that's where you're wrong. The UA does NOT occur immediately for the next command, as status is returned when the task ends, which is after the task starts (is "enabled"), which is after the aborting/clearing happens. > Even if the arrival of the next command which would return the Unit > Attention condition is delayed (as done for the case when TAS is set to 1), > the response and final I/O operations for the last command being aborted may > be traveling on different connections in a session. In the pathological > case, the unit attention can arrive at the initiator before the final I/O > phase has completed. I thought that tasks were allegiant to a connection, and thus the status travels on the same connection as the I/O ops for a command. If that were not the case, we'd have this problem for ALL commands, not just aborted ones. :-) > In both these cases, the initiator may free all resources used for I/O > operations that are still not completed by the target. > > When TAS is 1, these issues are resolved because each individual I/O is > explicitly terminated with a TASK ABORTED status. > > Should the iSCSI specification include a clause that encourages or mandates > the use of the TAS=1 setting to resolve this potential race condition > between Unit Attention and the I/O cleanup during task abort? > > Does anyone see some error in my reasoning or a different way of resolving > this issue. See above. I think exact task semantics enter in and resolve your concern. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 13:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03990 for ; Mon, 9 Feb 2004 13:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGPy-0006hz-MR for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 13:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Ik2lV025781 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 13:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGPy-0006hY-0M for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:46:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03913 for ; Mon, 9 Feb 2004 13:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGPv-0004jJ-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:45:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGOw-0004Yz-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:44:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGO0-0004Ni-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGO1-0006XR-8Y; Mon, 09 Feb 2004 13:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGNk-0006X1-7N for ips@optimus.ietf.org; Mon, 09 Feb 2004 13:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03623 for ; Mon, 9 Feb 2004 13:43:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGNh-0004Kw-00 for ips@ietf.org; Mon, 09 Feb 2004 13:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGMb-00048W-00 for ips@ietf.org; Mon, 09 Feb 2004 13:42:34 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqGLX-0003t9-00 for ips@ietf.org; Mon, 09 Feb 2004 13:41:27 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004020918405701600f8anee> (Authid: esquicksall); Mon, 9 Feb 2004 18:40:57 +0000 Message-ID: <002701c3ef3c$39e2ffc0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Mon, 9 Feb 2004 13:40:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C3EF12.50B49E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] iSCSI: reinstatement Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C3EF12.50B49E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When an initiator reinstates a connection/session, it will supply the = ExpStatSN and CmdSN in the new login. =20 I would like to confirm my understanding (ERL 0) ...=20 Should the target remember the last StatSN for the lost connection or = should it use the initiator's new ExpStatSN for the next StatSN? I am = expecting that the target uses the ExpStatSN. =20 Should the target remember the last ExpCmdSN for the lost session (last = lost connection of a session) or should it use the initiator's new CmdSN = for the next ExpCmdSN? I am expecting that the target uses the CmdSN. =20 Eddy ------=_NextPart_000_0024_01C3EF12.50B49E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

When an = initiator reinstates a=20 connection/session, it will supply the ExpStatSN and CmdSN in the = new=20 login.

 

I would like to confirm my = understanding=20 (ERL 0) ... 

 

Should the = target remember the=20 last StatSN for the lost connection or should it use the = initiator's new=20 ExpStatSN for the next StatSN? I am expecting that the target = uses the=20 ExpStatSN.

 

Should the = target remember the=20 last ExpCmdSN for the lost session (last lost connection of a=20 session) or should it use the initiator's new CmdSN for the next = ExpCmdSN?=20 I am expecting that the target uses the CmdSN.

 

Eddy

------=_NextPart_000_0024_01C3EF12.50B49E90-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 14:00:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04497 for ; Mon, 9 Feb 2004 14:00:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGdr-0007le-ES for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 14:00:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19J0MgJ029852 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 14:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGdp-0007lN-Uq for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:00:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04484 for ; Mon, 9 Feb 2004 14:00:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGdn-00063X-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:00:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGcu-0005yo-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:59:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGcV-0005ta-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 13:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGcW-0007cu-8r; Mon, 09 Feb 2004 13:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGbn-0007bC-E7 for ips@optimus.ietf.org; Mon, 09 Feb 2004 13:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04369 for ; Mon, 9 Feb 2004 13:58:12 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGbl-0005sn-00 for ips@ietf.org; Mon, 09 Feb 2004 13:58:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGap-0005oh-00 for ips@ietf.org; Mon, 09 Feb 2004 13:57:16 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqGaW-0005kX-00 for ips@ietf.org; Mon, 09 Feb 2004 13:56:56 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3C07B40142; Mon, 9 Feb 2004 13:56:57 -0500 (EST) Date: Mon, 9 Feb 2004 10:56:38 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: intent of MaxCmdSN In-Reply-To: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> Message-ID: References: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Eddy Quicksall wrote: > Regarding MaxCmdSN, is the intent to regulate the flow of commands to > the SCSI layer or to regulate the flow to iSCSI for multiple > connections? MaxCmdSN doesn't regulate flow for multiple connections, it regulates how many new commands can be in-flight at once. It comes into play even in single-connection sessions. > It seems that it must be for multiple connections to reduce the number > of commands that are waiting to be ordered to SCSI. And that the SCSI > layer should be responsible for its own queue depth. I don't think so. It represents how many commands the target iSCSI layer has promised it can receive. This does impact multi-connection re-ordering prevention, but it can also be used to apply back-pressure if the SCSI layer is running low on resources. The latter is important as the target's promising it can receive that many commands. It should be careful about promising what it can't deliver. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 14:16:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05231 for ; Mon, 9 Feb 2004 14:16:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGtG-0000gF-6b for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 14:16:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JGIw7002609 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 14:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGtG-0000g0-1q for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:16:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05179 for ; Mon, 9 Feb 2004 14:16:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGtD-0007aS-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:16:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGsL-0007Vo-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:15:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGs3-0007Qm-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGs3-0000YP-Bh; Mon, 09 Feb 2004 14:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGiZ-0007zc-9k for ips@optimus.ietf.org; Mon, 09 Feb 2004 14:05:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04642 for ; Mon, 9 Feb 2004 14:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGiW-0006TL-00 for ips@ietf.org; Mon, 09 Feb 2004 14:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGhV-0006Ml-00 for ips@ietf.org; Mon, 09 Feb 2004 14:04:11 -0500 Received: from mail0.lsil.com ([147.145.40.20]) by ietf-mx with esmtp (Exim 4.12) id 1AqGgW-0006EG-00 for ips@ietf.org; Mon, 09 Feb 2004 14:03:08 -0500 Received: from new-mhbs.co.lsil.com (mhbs.lsil.com [172.21.20.49]) by mail0.lsil.com (8.12.8/8.12.8) with ESMTP id i19IxFXU017615; Mon, 9 Feb 2004 10:59:15 -0800 (PST) Received: from exw-ks.ks.lsil.com (wic1.ks.lsil.com [153.79.12.11]) by new-mhbs.co.lsil.com (8.12.11/8.12.10) with ESMTP id i19J2VpH015364; Mon, 9 Feb 2004 12:02:31 -0700 Received: by exw-ks.ks.lsil.com with Internet Mail Service (5.5.2657.72) id ; Mon, 9 Feb 2004 13:00:54 -0600 Message-ID: <53CF1076699CD711B7DD0002A51363F1019BBC33@exw-ks.ks.lsil.com> From: "Spry, Andy" To: ips@ietf.org Cc: "'wrstuden@wasabisystems.com'" Subject: RE: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Ta sk Set, an d LUN Reset Date: Mon, 9 Feb 2004 13:00:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EF3F.09307B7A" X-Scanned-By: MIMEDefang 2.39 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EF3F.09307B7A Content-Type: text/plain; charset="iso-8859-1" Bill, Thanks for your reply. I added a couple of clarification points below. Andy > -----Original Message----- > From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems.com] > Sent: Monday, February 09, 2004 12:29 PM > To: Spry, Andy > Cc: ips@ietf.org > Subject: Re: [Ips] Sequencing of UA and I/O from aborted > tasks in Clear > Task Set, an d LUN Reset > > > On Mon, 9 Feb 2004, Spry, Andy wrote: > > > I need some clarification on the ordering of responses or unit attention for > > tasks on sessions other than the session issuing a Clear Task Set or LUN > > Reset TMF. > > > > When TST is 000b, the task set for a LUN includes tasks from all initiators. > > When a Clear Task Set (or LUN Reset) is received the set of tasks already > > present in the SCSI layer for the LUN must be aborted. > > > > The behavior for the initiator that issued the TMF is clearly defined. All > > I/O sequences in progress are completed or terminated before the TMF > > response is returned to the initiator. > > > > However, the timing of notification to other initiators is not as clear. > > According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on > > the setting of the TAS bit in the Control mode page. > > > > When TAS is 0, the method of notification is a Unit Attention condition. > > > > The additional sense code dependent on the action that caused the > > task(s) to be aborted. > > > > When TAS is 1, each task is aborted with a TASK ABORTED status. > > A unit attention with the sense code "COMMAND CLEARED BY ANOTHER > > INITIATOR" is NOT sent to the initiator. > > > > The section further states that: > > > > "When a logical unit is aborting one or more tasks from a SCSI initiator > > port with > > the TASK ABORTED status it should complete all those tasks before > > entering additional > > tasks from that SCSI initiator port into the task set" > > > > Assuming the "point in time" method is used to define the tasks sets for > > initiators, how can a race condition between the Unit Attention and the > > completion of I/O for tasks being aborted be avoided when the TAS bit is set > > to 0? > > Note: "before entering additional tasks ... into the task set" does not > mean before sending back the UA, it means that no tasks shall enter the > "enabled" state in that time. In SAM-3 this is covered in section 8.4, and > my recolection is it was covered the same in SAM-2. > > So you can (and probalby should) have tasks piling up in the "dormant" > state while the abort is happening. And as a task can't return status > until it has entered the "enabled" state (AFAICT), you won't get a > command-related UA until after the aborting has ended. > This is what we were considering to help with the sequence issue. I'll check the referenced section for relavence. However, doesn't this only apply to the case where TAS=1? The wording in section 5.7.3 would seem to indicate that holding the commands in abayance as "dormant" only applies to that option. > > Any commands being aborted that are in an I/O phase must be terminated > > gracefully if possible. However, the Unit Attention occurs immediately for > > the next command arriving from the initiator. The Unit > Attention response > > can be sent back to the initiator while there is still I/O being completed > > on the commands being aborted. > > As above, I think that's where you're wrong. The UA does NOT occur > immediately for the next command, as status is returned when the task > ends, which is after the task starts (is "enabled"), which is after the > aborting/clearing happens. > > > Even if the arrival of the next command which would return the Unit > > Attention condition is delayed (as done for the case when TAS is set to 1), > > the response and final I/O operations for the last command being aborted may > > be traveling on different connections in a session. In the pathological > > case, the unit attention can arrive at the initiator before the final I/O > > phase has completed. > > I thought that tasks were allegiant to a connection, and thus the status > travels on the same connection as the I/O ops for a command. If that were > not the case, we'd have this problem for ALL commands, not > just aborted ones. :-) > I think that there could still be an issue. Yes the last I/O on the task being aborted is allegiant to the connection on which that task arrived. However, the unit attention is being returned as a response to the first command arriving after all commands in the task set have been cleaned up. This task does not need to arrive on the same connection as the last task being aborted from that initiator. If the aborted task arrived on a slow connection but the subsequent task which receives the UA arrives on a faster connection, there is not guarentee that the UA response won't get back to the initiator first. For normal I/O this would not be a problem. But for a UA indicating that the target has cleared a task set or performed a LUN reset, all resources for that command and its preceeding commands can be released. If the last I/O is still completing on the slower connection, does the initaitor pull the resources before the I/O had completed. Or is this race condition aleviated by the fact that the I/O phase is completed by agreement between the iniator and target before the command is enabled on the target? > > In both these cases, the initiator may free all resources used for I/O > > operations that are still not completed by the target. > > > > When TAS is 1, these issues are resolved because each individual I/O is > > explicitly terminated with a TASK ABORTED status. > > > > Should the iSCSI specification include a clause that encourages or mandates > > the use of the TAS=1 setting to resolve this potential race condition > > between Unit Attention and the I/O cleanup during task abort? > > > > Does anyone see some error in my reasoning or a different way of resolving > > this issue. > > See above. I think exact task semantics enter in and resolve > your concern. > > Take care, > > Bill > ------_=_NextPart_001_01C3EF3F.09307B7A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ips] Sequencing of UA and I/O from aborted tasks in Clear = Task Set, an d LUN Reset

Bill,

Thanks for your reply.  I added a couple of = clarification points below.

Andy

> -----Original Message-----
> From: wrstuden@wasabisystems.com [mailto:wrstuden@wasabisystems= .com]
> Sent: Monday, February 09, 2004 12:29 PM
> To: Spry, Andy
> Cc: ips@ietf.org
> Subject: Re: [Ips] Sequencing of UA and I/O = from aborted
> tasks in Clear
> Task Set, an d LUN Reset
>
>
> On Mon, 9 Feb 2004, Spry, Andy wrote:
>
> > I need some clarification on the ordering = of responses or unit attention for
> > tasks on sessions other than the session = issuing a Clear Task Set or LUN
> > Reset TMF.
> >
> > When TST is 000b, the task set for a LUN = includes tasks from all initiators.
> > When a Clear Task Set (or LUN Reset) is = received the set of tasks already
> > present in the SCSI layer for the LUN must = be aborted.
> >
> > The behavior for the initiator that issued = the TMF is clearly defined.  All
> > I/O sequences in progress are completed or = terminated before the TMF
> > response is returned to the = initiator.
> >
> > However, the timing of notification to = other initiators is not as clear.
> > According to SAM-2 and SAM-3 (5.7.3) the = method of notification depends on
> > the setting of the TAS bit in the Control = mode page.
> >
> >     When TAS is 0, the = method of notification is a Unit Attention condition.
> >
> = >         The additional = sense code dependent on the action that caused the
> > task(s) to be aborted.
> >
> >     When TAS is 1, = each task is aborted with a TASK ABORTED status.
> = >         A unit attention = with the sense code "COMMAND CLEARED BY ANOTHER
> > INITIATOR" is NOT sent to the = initiator.
> >
> > The section further states that:
> >
> >    "When a logical = unit is aborting one or more tasks from a SCSI initiator
> > port with
> >     the TASK ABORTED = status it should complete all those tasks before
> > entering additional
> >     tasks from that = SCSI initiator port into the task set"
> >
> > Assuming the "point in time" = method is used to define the tasks sets for
> > initiators, how can a race condition = between the Unit Attention and the
> > completion of I/O for tasks being aborted = be avoided when the TAS bit is set
> > to 0?
>
> Note: "before entering additional tasks = ... into the task set" does not
> mean before sending back the UA, it means that = no tasks shall enter the
> "enabled" state in that time. In = SAM-3 this is covered in section 8.4, and
> my recolection is it was covered the same in = SAM-2.
>
> So you can (and probalby should) have tasks = piling up in the "dormant"
> state while the abort is happening. And as a = task can't return status
> until it has entered the "enabled" = state (AFAICT), you won't get a
> command-related UA until after the aborting has = ended.
>

This is what we were considering to help with the = sequence issue.  I'll check the referenced section for = relavence.  However, doesn't this only apply to the case where = TAS=3D1?  The wording in section 5.7.3 would seem to indicate that = holding the commands in abayance as "dormant" only applies to = that option. 

> > Any commands being aborted that are in an = I/O phase must be terminated
> > gracefully if possible.  However, the = Unit Attention occurs immediately for
> > the next command arriving from the = initiator.  The Unit
> Attention response
> > can be sent back to the initiator while = there is still I/O being completed
> > on the commands being aborted.
>
> As above, I think that's where you're wrong. = The UA does NOT occur
> immediately for the next command, as status is = returned when the task
> ends, which is after the task starts (is = "enabled"), which is after the
> aborting/clearing happens.
>
> > Even if the arrival of the next command = which would return the Unit
> > Attention condition is delayed (as done = for the case when TAS is set to 1),
> > the response and final I/O operations for = the last command being aborted may
> > be traveling on different connections in a = session.  In the pathological
> > case, the unit attention can arrive at the = initiator before the final I/O
> > phase has completed.
>
> I thought that tasks were allegiant to a = connection, and thus the status
> travels on the same connection as the I/O ops = for a command. If that were
> not the case, we'd have this problem for ALL = commands, not
> just aborted ones. :-)
>

I think that there could still be an issue.  Yes = the last I/O on the task being aborted is allegiant to the connection = on which that task arrived.  However, the unit attention is being = returned as a response to the first command arriving after all commands = in the task set have been cleaned up.  This task does not need to = arrive on the same connection as the last task being aborted from that = initiator.  If the aborted task arrived on a slow connection but = the subsequent task which receives the UA arrives on a faster = connection, there is not guarentee that the UA response won't get back = to the initiator first. 

For normal I/O this would not be a problem.  But = for a UA indicating that the target has cleared a task set or performed = a LUN reset, all resources for that command and its preceeding commands = can be released.  If the last I/O is still completing on the = slower connection, does the initaitor pull the resources before the I/O = had completed.

Or is this race condition aleviated by the fact that = the I/O phase is completed by agreement between the iniator and = target  before the command is enabled on the target?

> > In both these cases, the initiator may free = all resources used for I/O
> > operations that are still not completed by = the target.
> >
> > When TAS is 1, these issues are resolved = because each individual I/O is
> > explicitly terminated with a TASK ABORTED = status.
> >
> > Should the iSCSI specification include a = clause that encourages or mandates
> > the use of the TAS=3D1 setting to resolve = this potential race condition
> > between Unit Attention and the I/O cleanup = during task abort?
> >
> > Does anyone see some error in my reasoning = or a different way of resolving
> > this issue.
>
> See above. I think exact task semantics enter = in and resolve
> your concern.
>
> Take care,
>
> Bill
>

------_=_NextPart_001_01C3EF3F.09307B7A-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 14:19:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05397 for ; Mon, 9 Feb 2004 14:19:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGwC-00013g-KW for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 14:19:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JJK55004062 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 14:19:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGwC-00013R-FW for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:19:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05393 for ; Mon, 9 Feb 2004 14:19:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGwA-000049-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:19:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGvH-0007n0-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:18:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGuu-0007hn-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGuv-0000jR-KA; Mon, 09 Feb 2004 14:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGuJ-0000hw-Dj for ips@optimus.ietf.org; Mon, 09 Feb 2004 14:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05305 for ; Mon, 9 Feb 2004 14:17:20 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGuG-0007gM-00 for ips@ietf.org; Mon, 09 Feb 2004 14:17:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGtM-0007bW-00 for ips@ietf.org; Mon, 09 Feb 2004 14:16:25 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqGt6-0007WR-00 for ips@ietf.org; Mon, 09 Feb 2004 14:16:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 74ED240142; Mon, 9 Feb 2004 14:16:08 -0500 (EST) Date: Mon, 9 Feb 2004 11:15:49 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: reinstatement In-Reply-To: <002701c3ef3c$39e2ffc0$0303a8c0@ivvt2dxrc11> Message-ID: References: <002701c3ef3c$39e2ffc0$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Eddy Quicksall wrote: > When an initiator reinstates a connection/session, it will supply the > ExpStatSN and CmdSN in the new login. > > I would like to confirm my understanding (ERL 0) ... > > Should the target remember the last StatSN for the lost connection or > should it use the initiator's new ExpStatSN for the next StatSN? I am > expecting that the target uses the ExpStatSN. >From Login Request: 10.12.9 ExpStatSN For the first Login Request on a connection this is ExpStatSN for the old connection and this field is only valid if the Login request restarts a connection (see Section 5.3.4 Connection Reinstatement). For subsequent Login Requests it is used to acknowledge the Login Responses with their increasing StatSN values. And from Login Response: 10.13.4 StatSN For the first Login Response (the response to the first Login Request), this is the starting status Sequence Number for the connection. The next response of any kind, including the next login response, if any, in the same Login Phase, will carry this number + 1. This field is only valid if the Status-Class is 0. Thus where the StatSN sequence starts is the purvue of the target. Once it's started (first Login Response on a connection), the StatSN rules dictate how it changes through the connection. The target can start each connection with a totally-random number, and that'd be ok. > Should the target remember the last ExpCmdSN for the lost session (last > lost connection of a session) or should it use the initiator's new CmdSN > for the next ExpCmdSN? I am expecting that the target uses the CmdSN. I think "10.12.8 CmdSN" covers CmdSN for all cases other than session reinstatement. I'm a bit confused about session reinstatement. I _think_ a session reinstatement connection should be treated as a leading connection, in which case the target should respect the supplied CmdSN. The reason I think this is in thinking about what happens if the initiator suddenly reboots. When it comes up, it won't know it has a session with the target(*). So it will be performing an "initial login" which looks like session reinstatement to the target. If this connection isn't treated as "leading", then the initiator may get confused when it tries to negotiate some "leading-only" parameters with the target. (*) Unless we are requiring the initiator remember it had a session, so then it could know it was doing session-reinstatement. Am I understanding this correctly? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 14:26:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05739 for ; Mon, 9 Feb 2004 14:26:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH2x-0001f6-Qg for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 14:26:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19JQJnb006382 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 14:26:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH2x-0001er-Ml for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 14:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05733 for ; Mon, 9 Feb 2004 14:26:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH2v-0000kp-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:26:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqH21-0000gU-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:25:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqH1g-0000bi-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 14:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH1i-0001T1-9T; Mon, 09 Feb 2004 14:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqH0v-0001Re-6H for ips@optimus.ietf.org; Mon, 09 Feb 2004 14:24:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05592 for ; Mon, 9 Feb 2004 14:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqH0s-0000Yb-00 for ips@ietf.org; Mon, 09 Feb 2004 14:24:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGzu-0000Rb-00 for ips@ietf.org; Mon, 09 Feb 2004 14:23:10 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqGyx-0000I7-00 for ips@ietf.org; Mon, 09 Feb 2004 14:22:11 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004020919214101600f95ate> (Authid: esquicksall); Mon, 9 Feb 2004 19:21:41 +0000 Message-ID: <003601c3ef41$e70cbbf0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: intent of MaxCmdSN Date: Mon, 9 Feb 2004 14:21:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems that this is actually an implementation issue and I was wondering what the intent was. Does SAM-2 mention transport flow control? It seems that the transport should be unaware of the SCSI resources. Regarding SCSI, I thought it it would return the TASK SET FULL status (or maybe BUSY status in some cases). MaxCmdSN could be used for that purpose but I wonder if that was really the intent. Regarding commands in-flight, doesn't that fit into the re-ordering category? i.e., they are in-flight to the SCSI layer. I suppose it could also mean on-the-wire depending on implementation. Am I missing something? Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Monday, February 09, 2004 1:56 PM Subject: Re: [Ips] iSCSI: intent of MaxCmdSN > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > Regarding MaxCmdSN, is the intent to regulate the flow of commands to > > the SCSI layer or to regulate the flow to iSCSI for multiple > > connections? > > MaxCmdSN doesn't regulate flow for multiple connections, it regulates how > many new commands can be in-flight at once. It comes into play even in > single-connection sessions. > > > It seems that it must be for multiple connections to reduce the number > > of commands that are waiting to be ordered to SCSI. And that the SCSI > > layer should be responsible for its own queue depth. > > I don't think so. It represents how many commands the target iSCSI layer > has promised it can receive. This does impact multi-connection re-ordering > prevention, but it can also be used to apply back-pressure if the SCSI > layer is running low on resources. > > The latter is important as the target's promising it can receive that many > commands. It should be careful about promising what it can't deliver. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 16:18:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13163 for ; Mon, 9 Feb 2004 16:18:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIma-0002Lr-8U for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 16:17:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LHWet009034 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 16:17:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIma-0002Ld-32 for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:17:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13107 for ; Mon, 9 Feb 2004 16:17:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqImY-0002fa-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:17:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIlv-0002Zl-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:16:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIlF-0002Rh-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIl7-00029m-Jz; Mon, 09 Feb 2004 16:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIkR-000283-AE for ips@optimus.ietf.org; Mon, 09 Feb 2004 16:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12656 for ; Mon, 9 Feb 2004 16:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIkP-0002Mu-00 for ips@ietf.org; Mon, 09 Feb 2004 16:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIjR-0002GC-00 for ips@ietf.org; Mon, 09 Feb 2004 16:14:18 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AqIib-00027g-00 for ips@ietf.org; Mon, 09 Feb 2004 16:13:25 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <200402092112550120080pu9e> (Authid: esquicksall); Mon, 9 Feb 2004 21:12:55 +0000 Message-ID: <003d01c3ef51$7c88dec0$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <002701c3ef3c$39e2ffc0$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: reinstatement Date: Mon, 9 Feb 2004 16:12:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, I think you are understanding it and I just want to see if everyone agrees. Consider ERL 2 session reinstatement. According to 10.12.8, the initiator would have to keep track of the CmdSN (since the ExpCmdSN will be the leading login's CmdSN+1). Otherwise the following would be broken. Right? If the correct CmdSN is not used, the out-of-order commands already in the target will get stuck and/or new commands will appear "out of the command window". ----Connection 0 T->I CmdSN=5 I->T ExpCmdSN=6 ----Connection 1 T->I CmdSN=7 I->T ExpCmdSN=6 ----Both connections are lost ----The initiator would have to use CmdSN=5 for the new leading login. Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Monday, February 09, 2004 2:15 PM Subject: Re: [Ips] iSCSI: reinstatement > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > When an initiator reinstates a connection/session, it will supply the > > ExpStatSN and CmdSN in the new login. > > > > I would like to confirm my understanding (ERL 0) ... > > > > Should the target remember the last StatSN for the lost connection or > > should it use the initiator's new ExpStatSN for the next StatSN? I am > > expecting that the target uses the ExpStatSN. > > From Login Request: > > 10.12.9 ExpStatSN > > For the first Login Request on a connection this is ExpStatSN for > the old connection and this field is only valid if the Login request > restarts a connection (see Section 5.3.4 Connection Reinstatement). > > For subsequent Login Requests it is used to acknowledge the Login > Responses with their increasing StatSN values. > > And from Login Response: > > 10.13.4 StatSN > > For the first Login Response (the response to the first Login > Request), this is the starting status Sequence Number for the > connection. The next response of any kind, including the next login > response, if any, in the same Login Phase, will carry this number + > 1. This field is only valid if the Status-Class is 0. > > Thus where the StatSN sequence starts is the purvue of the target. Once > it's started (first Login Response on a connection), the StatSN rules > dictate how it changes through the connection. > > The target can start each connection with a totally-random number, and > that'd be ok. > > > Should the target remember the last ExpCmdSN for the lost session (last > > lost connection of a session) or should it use the initiator's new CmdSN > > for the next ExpCmdSN? I am expecting that the target uses the CmdSN. > > I think "10.12.8 CmdSN" covers CmdSN for all cases other than session > reinstatement. > > I'm a bit confused about session reinstatement. I _think_ a session > reinstatement connection should be treated as a leading connection, in > which case the target should respect the supplied CmdSN. > > The reason I think this is in thinking about what happens if the initiator > suddenly reboots. When it comes up, it won't know it has a session with > the target(*). So it will be performing an "initial login" which looks > like session reinstatement to the target. If this connection isn't treated > as "leading", then the initiator may get confused when it tries to > negotiate some "leading-only" parameters with the target. > > (*) Unless we are requiring the initiator remember it had a session, so > then it could know it was doing session-reinstatement. > > Am I understanding this correctly? > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 16:23:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14197 for ; Mon, 9 Feb 2004 16:23:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIsL-0003Fb-Qt for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 16:23:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LNTYu012494 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 16:23:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIsL-0003FR-Kl for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:23:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14087 for ; Mon, 9 Feb 2004 16:23:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIsJ-0003mg-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:23:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIqb-0003Nf-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:21:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIp0-00032J-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 16:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIp0-0002b3-Bv; Mon, 09 Feb 2004 16:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIoM-0002Ue-9F for ips@optimus.ietf.org; Mon, 09 Feb 2004 16:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13374 for ; Mon, 9 Feb 2004 16:19:19 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIoK-0002w7-00 for ips@ietf.org; Mon, 09 Feb 2004 16:19:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqInJ-0002lI-00 for ips@ietf.org; Mon, 09 Feb 2004 16:18:18 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqImI-0002dK-00 for ips@ietf.org; Mon, 09 Feb 2004 16:17:14 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7D59A40141; Mon, 9 Feb 2004 16:17:14 -0500 (EST) Date: Mon, 9 Feb 2004 13:16:54 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Spry, Andy" Cc: ips@ietf.org Subject: RE: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Ta sk Set, an d LUN Reset In-Reply-To: <53CF1076699CD711B7DD0002A51363F1019BBC33@exw-ks.ks.lsil.com> Message-ID: References: <53CF1076699CD711B7DD0002A51363F1019BBC33@exw-ks.ks.lsil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Spry, Andy wrote: > > On Mon, 9 Feb 2004, Spry, Andy wrote: > > > > > I need some clarification on the ordering of responses or unit attention > for > > > tasks on sessions other than the session issuing a Clear Task Set or LUN > > > Reset TMF. > > > > > > When TST is 000b, the task set for a LUN includes tasks from all > initiators. > > > When a Clear Task Set (or LUN Reset) is received the set of tasks > already > > > present in the SCSI layer for the LUN must be aborted. > > > > > > The behavior for the initiator that issued the TMF is clearly defined. > All > > > I/O sequences in progress are completed or terminated before the TMF > > > response is returned to the initiator. > > > > > > However, the timing of notification to other initiators is not as clear. > > > According to SAM-2 and SAM-3 (5.7.3) the method of notification depends > on > > > the setting of the TAS bit in the Control mode page. > > > > > > When TAS is 0, the method of notification is a Unit Attention > condition. > > > > > > The additional sense code dependent on the action that caused > the > > > task(s) to be aborted. > > > > > > When TAS is 1, each task is aborted with a TASK ABORTED status. > > > A unit attention with the sense code "COMMAND CLEARED BY ANOTHER > > > INITIATOR" is NOT sent to the initiator. > > > > > > The section further states that: > > > > > > "When a logical unit is aborting one or more tasks from a SCSI > initiator > > > port with > > > the TASK ABORTED status it should complete all those tasks before > > > entering additional > > > tasks from that SCSI initiator port into the task set" > > > > > > Assuming the "point in time" method is used to define the tasks sets for > > > initiators, how can a race condition between the Unit Attention and the > > > completion of I/O for tasks being aborted be avoided when the TAS bit is > set > > > to 0? > > > > Note: "before entering additional tasks ... into the task set" does not > > mean before sending back the UA, it means that no tasks shall enter the > > "enabled" state in that time. In SAM-3 this is covered in section 8.4, and > > my recolection is it was covered the same in SAM-2. > > > > So you can (and probalby should) have tasks piling up in the "dormant" > > state while the abort is happening. And as a task can't return status > > until it has entered the "enabled" state (AFAICT), you won't get a > > command-related UA until after the aborting has ended. > > This is what we were considering to help with the sequence issue. I'll > check the referenced section for relavence. However, doesn't this only > apply to the case where TAS=1? The wording in section 5.7.3 would seem to > indicate that holding the commands in abayance as "dormant" only applies to > that option. I think you can always hold tasks in "dormant" state if it helps you perform a CLEAR TASK SET. More importantly, I think with TST=0, when you clear the task set, the other tasks are GONE. No orderly command shutdown, no status reporting. I think that because if a task is aborted and status is returned, regardless of TST's value, I'd expect to get a task aborted status. We should never permit the case of non-abort status if the task was aborted, no? Does the list agree with the above? Or in the TST=0 case, should a command be completed with GOOD status and just report an underrun? > > As above, I think that's where you're wrong. The UA does NOT occur > > immediately for the next command, as status is returned when the task > > ends, which is after the task starts (is "enabled"), which is after the > > aborting/clearing happens. > > > > > Even if the arrival of the next command which would return the Unit > > > Attention condition is delayed (as done for the case when TAS is set to > 1), > > > the response and final I/O operations for the last command being aborted > may > > > be traveling on different connections in a session. In the pathological > > > case, the unit attention can arrive at the initiator before the final > I/O > > > phase has completed. > > > > I thought that tasks were allegiant to a connection, and thus the status > > travels on the same connection as the I/O ops for a command. If that were > > not the case, we'd have this problem for ALL commands, not > > just aborted ones. :-) > > > > I think that there could still be an issue. Yes the last I/O on the task > being aborted is allegiant to the connection on which that task arrived. > However, the unit attention is being returned as a response to the first > command arriving after all commands in the task set have been cleaned up. > This task does not need to arrive on the same connection as the last task > being aborted from that initiator. If the aborted task arrived on a slow > connection but the subsequent task which receives the UA arrives on a faster > connection, there is not guarentee that the UA response won't get back to > the initiator first. I think something Julian stated comes into play here. Not only does the target have to await sending status, but it has to await receiving status comfirmation. Thus the abort won't be over until the commands are done. > For normal I/O this would not be a problem. But for a UA indicating that > the target has cleared a task set or performed a LUN reset, all resources > for that command and its preceeding commands can be released. If the last > I/O is still completing on the slower connection, does the initaitor pull > the resources before the I/O had completed. > > Or is this race condition aleviated by the fact that the I/O phase is > completed by agreement between the iniator and target before the command is > enabled on the target? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 17:12:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21231 for ; Mon, 9 Feb 2004 17:12:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJcz-0000Yy-5d for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 17:11:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MBfci002165 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 17:11:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJcz-0000Yq-0b for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:11:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21220 for ; Mon, 9 Feb 2004 17:11:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJcw-0004zr-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:11:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJcE-0004sR-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:10:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqJbP-0004hw-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJbP-0000Jo-R0; Mon, 09 Feb 2004 17:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJbD-0000Iv-3O for ips@optimus.ietf.org; Mon, 09 Feb 2004 17:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20911 for ; Mon, 9 Feb 2004 17:09:47 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJbA-0004fg-00 for ips@ietf.org; Mon, 09 Feb 2004 17:09:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJZy-0004TE-00 for ips@ietf.org; Mon, 09 Feb 2004 17:08:34 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqJYq-0004FM-00 for ips@ietf.org; Mon, 09 Feb 2004 17:07:24 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 8191240141; Mon, 9 Feb 2004 17:07:24 -0500 (EST) Date: Mon, 9 Feb 2004 14:07:04 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: intent of MaxCmdSN In-Reply-To: <003601c3ef41$e70cbbf0$0303a8c0@ivvt2dxrc11> Message-ID: References: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> <003601c3ef41$e70cbbf0$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Eddy Quicksall wrote: > It seems that this is actually an implementation issue and I was wondering > what the intent was. > > Does SAM-2 mention transport flow control? It seems that the transport > should be unaware of the SCSI resources. Regarding SCSI, I thought it it > would return the TASK SET FULL status (or maybe BUSY status in some cases). > MaxCmdSN could be used for that purpose but I wonder if that was really the > intent. Well, while SCSI can return TASK SET FULL, the iSCSI layer certainly could use it for backpressure. > Regarding commands in-flight, doesn't that fit into the re-ordering > category? i.e., they are in-flight to the SCSI layer. I suppose it could > also mean on-the-wire depending on implementation. > > Am I missing something? Yes. How long it takes for a packet to go to and from the target. Including processing delays. Consider a session with only one connection. If ExpCmdSN == MaxCmdSN, then the initiator has to receive acknowledgement of a command (receive a PDU) before it can send the next one. Now say the initiator wants to send a stream of writes. The natural thing for the target to do is send a PDU when the write is over. Now say that the writes are all the same size as FirstBurstLength (default of 64k and an OS that performs 64k writes) and InitialR2T=NO. All of the Data-Out PDUs will be sent right after the command request. Unless something happens, the initiator won't be able to start another command until the transmitted one is completed. With MaxCmdSN > ExpCmdSN, the initiator can start a second (or 3rd or 4th or ...) write while the first one is being processed. Yes, there are tricks that could be played in the ExpCmdSN == MaxCmdSN case (like say a NOP-OUT with echo right after the SCSI command), but it's simpler, at least to me, to just let MaxCmdSN == ExpCmdSN + some small constant. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 17:30:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23754 for ; Mon, 9 Feb 2004 17:30:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJuY-0001rP-H1 for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 17:29:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MTo0B007151 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 17:29:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJuY-0001rG-CL for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23738 for ; Mon, 9 Feb 2004 17:29:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJuW-0000MX-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:29:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJtX-0000E9-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:28:47 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJsv-000061-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:28:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJsu-00024k-Vk for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:28:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJsn-0001gt-AE; Mon, 09 Feb 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJsJ-0001bu-Gj for ips@optimus.ietf.org; Mon, 09 Feb 2004 17:27:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23506 for ; Mon, 9 Feb 2004 17:27:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJsH-00001K-00 for ips@ietf.org; Mon, 09 Feb 2004 17:27:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJr8-0007Zc-00 for ips@ietf.org; Mon, 09 Feb 2004 17:26:18 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AqJpg-0007A8-00 for ips@ietf.org; Mon, 09 Feb 2004 17:24:48 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <200402092224180110001m5te> (Authid: esquicksall); Mon, 9 Feb 2004 22:24:18 +0000 Message-ID: <004a01c3ef5b$75706b30$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> <003601c3ef41$e70cbbf0$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: intent of MaxCmdSN Date: Mon, 9 Feb 2004 17:24:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree on all points. That is why it is a bit of a dilemma for me. If it is used to throttle the commands on the wire (including the commands out of order) then it can cause extra traffic to advertise the new MaxCmdSN when there are no responses ready. But if it is used to throttle SCSI and the diff is large enough for SCSI then it can mean queuing of incoming out-of-order commands and it is very expensive to hit memory. That is why I was wondering what the original intent was. Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Monday, February 09, 2004 5:07 PM Subject: Re: [Ips] iSCSI: intent of MaxCmdSN > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > It seems that this is actually an implementation issue and I was wondering > > what the intent was. > > > > Does SAM-2 mention transport flow control? It seems that the transport > > should be unaware of the SCSI resources. Regarding SCSI, I thought it it > > would return the TASK SET FULL status (or maybe BUSY status in some cases). > > MaxCmdSN could be used for that purpose but I wonder if that was really the > > intent. > > Well, while SCSI can return TASK SET FULL, the iSCSI layer certainly could > use it for backpressure. > > > Regarding commands in-flight, doesn't that fit into the re-ordering > > category? i.e., they are in-flight to the SCSI layer. I suppose it could > > also mean on-the-wire depending on implementation. > > > > Am I missing something? > > Yes. How long it takes for a packet to go to and from the target. > Including processing delays. > > Consider a session with only one connection. If ExpCmdSN == MaxCmdSN, then > the initiator has to receive acknowledgement of a command (receive a PDU) > before it can send the next one. Now say the initiator wants to send a > stream of writes. The natural thing for the target to do is send a PDU > when the write is over. Now say that the writes are all the same size as > FirstBurstLength (default of 64k and an OS that performs 64k writes) and > InitialR2T=NO. All of the Data-Out PDUs will be sent right after the > command request. Unless something happens, the initiator won't be able to > start another command until the transmitted one is completed. > > With MaxCmdSN > ExpCmdSN, the initiator can start a second (or 3rd or 4th > or ...) write while the first one is being processed. > > Yes, there are tricks that could be played in the ExpCmdSN == MaxCmdSN > case (like say a NOP-OUT with echo right after the SCSI command), but it's > simpler, at least to me, to just let MaxCmdSN == ExpCmdSN + some small > constant. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 9 17:46:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25418 for ; Mon, 9 Feb 2004 17:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK9t-0002y0-6h for ips-archive@odin.ietf.org; Mon, 09 Feb 2004 17:45:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MjfYF011398 for ips-archive@odin.ietf.org; Mon, 9 Feb 2004 17:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK9t-0002xl-1r for ips-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:45:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25369 for ; Mon, 9 Feb 2004 17:45:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqK9q-0002bm-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:45:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqK9M-0002UJ-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:45:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqK8K-0002I6-00 for ips-web-archive@ietf.org; Mon, 09 Feb 2004 17:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK8H-0002hH-GH; Mon, 09 Feb 2004 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK7U-0002eC-JE for ips@optimus.ietf.org; Mon, 09 Feb 2004 17:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24908 for ; Mon, 9 Feb 2004 17:43:08 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqK7S-00026G-00 for ips@ietf.org; Mon, 09 Feb 2004 17:43:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqK5x-0001nj-00 for ips@ietf.org; Mon, 09 Feb 2004 17:41:37 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqK4f-0001V8-00 for ips@ietf.org; Mon, 09 Feb 2004 17:40:17 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 9629540141; Mon, 9 Feb 2004 17:40:17 -0500 (EST) Date: Mon, 9 Feb 2004 14:39:58 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: intent of MaxCmdSN In-Reply-To: <004a01c3ef5b$75706b30$0303a8c0@ivvt2dxrc11> Message-ID: References: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> <003601c3ef41$e70cbbf0$0303a8c0@ivvt2dxrc11> <004a01c3ef5b$75706b30$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Mon, 9 Feb 2004, Eddy Quicksall wrote: > I agree on all points. That is why it is a bit of a dilemma for me. > > If it is used to throttle the commands on the wire (including the commands > out of order) then it can cause extra traffic to advertise the new MaxCmdSN > when there are no responses ready. I think it _can_ be used to throttle commands on the wire. That doesn't mean it has to be. I'd expect a target to pick a value, like say 4 or 8, and stick with that value in all but the most dire of circumstances. If changing the value is hard and you can handle over-commit in other ways, do that. > But if it is used to throttle SCSI and the diff is large enough for SCSI > then it can mean queuing of incoming out-of-order commands and it is very > expensive to hit memory. Sounds like an implementation issue. Since you get to pick the number, pick something that makes your life easy. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 11:08:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25298 for ; Tue, 10 Feb 2004 11:08:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaQs-0002eu-7p for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 11:08:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AG8Ian010211 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 11:08:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaQr-0002eb-Uy for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 11:08:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25276 for ; Tue, 10 Feb 2004 11:08:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaQp-0007bG-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 11:08:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaPw-0007Se-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 11:07:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqaOx-0007IC-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 11:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaOi-000234-35; Tue, 10 Feb 2004 11:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqaNu-0001rq-PG for ips@optimus.ietf.org; Tue, 10 Feb 2004 11:05:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24863 for ; Tue, 10 Feb 2004 11:05:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqaNs-00073V-00 for ips@ietf.org; Tue, 10 Feb 2004 11:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqaM6-0006i0-00 for ips@ietf.org; Tue, 10 Feb 2004 11:03:22 -0500 Received: from mailgate.elipsan.com ([80.177.61.146] helo=hammer.elipsan.com) by ietf-mx with esmtp (Exim 4.12) id 1AqaKg-0006PS-00 for ips@ietf.org; Tue, 10 Feb 2004 11:01:54 -0500 Received: from [192.168.7.107] (helo=winminx) by hammer.elipsan.com with esmtp (Exim 4.12) id 1AqaJG-0007iD-00; Tue, 10 Feb 2004 16:00:26 +0000 From: "Ken Sandars" To: "'Eddy Quicksall'" , Cc: Subject: RE: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 16:01:14 -0000 Message-ID: <001c01c3efef$2e428740$6b07a8c0@winminx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <003d01c3ef51$7c88dec0$0303a8c0@ivvt2dxrc11> Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eddy & Bill I reckon Bill has hit the nail on the head. The connection which causes session reinstatement must have been negotiated as a leading login (TSID is 0) to a NEW session - it's a fresh start in life. There is a convenient side-effect where any previous session (from the target's point of view) on that I-T-nexus gets nuked from outer space (regardless of ERL). Cheers, Kens Sandars Elipsan UK > -----Original Message----- > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Eddy Quicksall > Sent: 09 February 2004 21:13 > To: wrstuden@wasabisystems.com > Cc: ips@ietf.org > Subject: Re: [Ips] iSCSI: reinstatement > > > Yes, I think you are understanding it and I just want to see > if everyone agrees. > > Consider ERL 2 session reinstatement. According to 10.12.8, > the initiator would have to keep track of the CmdSN (since > the ExpCmdSN will be the leading login's CmdSN+1). Otherwise > the following would be broken. Right? If the correct CmdSN is > not used, the out-of-order commands already in the target > will get stuck and/or new commands will appear "out of the > command window". > > ----Connection 0 > T->I CmdSN=5 > I->T ExpCmdSN=6 > ----Connection 1 > T->I CmdSN=7 > I->T ExpCmdSN=6 > ----Both connections are lost > ----The initiator would have to use CmdSN=5 for the new leading login. > > Eddy > > ----- Original Message ----- > From: > To: "Eddy Quicksall" > Cc: > Sent: Monday, February 09, 2004 2:15 PM > Subject: Re: [Ips] iSCSI: reinstatement > > > > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > > > When an initiator reinstates a connection/session, it will supply > > > the ExpStatSN and CmdSN in the new login. > > > > > > I would like to confirm my understanding (ERL 0) ... > > > > > > Should the target remember the last StatSN for the lost > connection > > > or should it use the initiator's new ExpStatSN for the > next StatSN? > > > I am expecting that the target uses the ExpStatSN. > > > > From Login Request: > > > > 10.12.9 ExpStatSN > > > > For the first Login Request on a connection this is ExpStatSN for > > the old connection and this field is only valid if the > Login request > > restarts a connection (see Section 5.3.4 Connection > Reinstatement). > > > > For subsequent Login Requests it is used to acknowledge the Login > > Responses with their increasing StatSN values. > > > > And from Login Response: > > > > 10.13.4 StatSN > > > > For the first Login Response (the response to the first Login > > Request), this is the starting status Sequence Number for the > > connection. The next response of any kind, including the > next login > > response, if any, in the same Login Phase, will carry > this number + > > 1. This field is only valid if the Status-Class is 0. > > > > Thus where the StatSN sequence starts is the purvue of the target. > > Once it's started (first Login Response on a connection), > the StatSN > > rules dictate how it changes through the connection. > > > > The target can start each connection with a totally-random > number, and > > that'd be ok. > > > > > Should the target remember the last ExpCmdSN for the lost session > > > (last lost connection of a session) or should it use the > initiator's > > > new CmdSN for the next ExpCmdSN? I am expecting that the > target uses > > > the CmdSN. > > > > I think "10.12.8 CmdSN" covers CmdSN for all cases other > than session > > reinstatement. > > > > I'm a bit confused about session reinstatement. I _think_ a session > > reinstatement connection should be treated as a leading > connection, in > > which case the target should respect the supplied CmdSN. > > > > The reason I think this is in thinking about what happens if the > > initiator suddenly reboots. When it comes up, it won't know > it has a > > session with the target(*). So it will be performing an "initial > > login" which looks like session reinstatement to the > target. If this > > connection isn't treated as "leading", then the initiator may get > > confused when it tries to negotiate some "leading-only" parameters > > with the target. > > > > (*) Unless we are requiring the initiator remember it had a > session, > > so then it could know it was doing session-reinstatement. > > > > Am I understanding this correctly? > > > > Take care, > > > > Bill > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 10 12:38:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29262 for ; Tue, 10 Feb 2004 12:38:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbpd-0001Pt-0z for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 12:37:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AHbu3E005431 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 12:37:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbpc-0001PW-Gz for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 12:37:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29094 for ; Tue, 10 Feb 2004 12:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqbpa-0001Y7-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 12:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqbnl-00018q-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 12:36:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqbmG-0000n4-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 12:34:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqbXW-0002HI-Mj for ips-web-archive@ietf.org; Tue, 10 Feb 2004 12:19:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbXO-00080z-31; Tue, 10 Feb 2004 12:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqbXH-0007xz-P6 for ips@optimus.ietf.org; Tue, 10 Feb 2004 12:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28349 for ; Tue, 10 Feb 2004 12:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqbXG-0007Eq-00 for ips@ietf.org; Tue, 10 Feb 2004 12:18:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqbWK-00074b-00 for ips@ietf.org; Tue, 10 Feb 2004 12:18:01 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx with esmtp (Exim 4.12) id 1AqbVU-0006oY-00; Tue, 10 Feb 2004 12:17:08 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1AHGY7a048430; Tue, 10 Feb 2004 17:16:34 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1AHGXps162770; Tue, 10 Feb 2004 17:16:33 GMT In-Reply-To: <53CF1076699CD711B7DD0002A51363F1019BBC31@exw-ks.ks.lsil.com> To: "Spry, Andy" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d LUN Reset X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 09:18:23 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/02/2004 19:18:27, Serialize complete at 10/02/2004 19:18:27 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 If the race is to be avoided FCP is in a similar position with iSCSI and so is any other networked transport. (connections to different initiators follow different paths) I do not see why iSCSI should say something special when the problem is the same for all transports. Julo "Spry, Andy" Sent by: ips-admin@ietf.org 09/02/2004 07:31 To ips@ietf.org cc Subject [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, an d LUN Reset All, The recent discussion on which tasks are affected by a clear task set was informative but did not address this issue. I need some clarification on the ordering of responses or unit attention for tasks on sessions other than the session issuing a Clear Task Set or LUN Reset TMF. When TST is 000b, the task set for a LUN includes tasks from all initiators. When a Clear Task Set (or LUN Reset) is received the set of tasks already present in the SCSI layer for the LUN must be aborted. The behavior for the initiator that issued the TMF is clearly defined. All I/O sequences in progress are completed or terminated before the TMF response is returned to the initiator. However, the timing of notification to other initiators is not as clear. According to SAM-2 and SAM-3 (5.7.3) the method of notification depends on the setting of the TAS bit in the Control mode page. When TAS is 0, the method of notification is a Unit Attention condition. The additional sense code dependent on the action that caused the task(s) to be aborted. When TAS is 1, each task is aborted with a TASK ABORTED status. A unit attention with the sense code "COMMAND CLEARED BY ANOTHER INITIATOR" is NOT sent to the initiator. The section further states that: "When a logical unit is aborting one or more tasks from a SCSI initiator port with the TASK ABORTED status it should complete all those tasks before entering additional tasks from that SCSI initiator port into the task set" Assuming the "point in time" method is used to define the tasks sets for initiators, how can a race condition between the Unit Attention and the completion of I/O for tasks being aborted be avoided when the TAS bit is set to 0? Any commands being aborted that are in an I/O phase must be terminated gracefully if possible. However, the Unit Attention occurs immediately for the next command arriving from the initiator. The Unit Attention response can be sent back to the initiator while there is still I/O being completed on the commands being aborted. Even if the arrival of the next command which would return the Unit Attention condition is delayed (as done for the case when TAS is set to 1), the response and final I/O operations for the last command being aborted may be traveling on different connections in a session. In the pathological case, the unit attention can arrive at the initiator before the final I/O phase has completed. In both these cases, the initiator may free all resources used for I/O operations that are still not completed by the target. When TAS is 1, these issues are resolved because each individual I/O is explicitly terminated with a TASK ABORTED status. Should the iSCSI specification include a clause that encourages or mandates the use of the TAS=1 setting to resolve this potential race condition between Unit Attention and the I/O cleanup during task abort? Does anyone see some error in my reasoning or a different way of resolving this issue. Thanks, Dr. Andrew J. Spry LSI Logic Storage Systems, INC _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 13:25:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01159 for ; Tue, 10 Feb 2004 13:25:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcZA-0005kr-Pk for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 13:25:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIP0SR022115 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 13:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcZA-0005kc-JX for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:25:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01133 for ; Tue, 10 Feb 2004 13:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcZ8-0006QP-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcYD-0006Jv-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:24:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqcXJ-0006Dn-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcXF-0005Xn-4C; Tue, 10 Feb 2004 13:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcWP-0005WU-Sr for ips@optimus.ietf.org; Tue, 10 Feb 2004 13:22:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01090 for ; Tue, 10 Feb 2004 13:22:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcWN-00068H-00 for ips@ietf.org; Tue, 10 Feb 2004 13:22:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcVX-00062Y-00 for ips@ietf.org; Tue, 10 Feb 2004 13:21:16 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx with esmtp (Exim 4.12) id 1AqcV1-0005w9-00; Tue, 10 Feb 2004 13:20:43 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1AIKBMf095678; Tue, 10 Feb 2004 18:20:12 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1AIKAn6186902; Tue, 10 Feb 2004 18:20:11 GMT In-Reply-To: <000a01c3ef39$cfb11850$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: intent of MaxCmdSN X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 10:21:58 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/02/2004 20:22:04, Serialize complete at 10/02/2004 20:22:04 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Bassically to limit what you are keeping for reordering but obviously there is nothing to prevent an implementation to use it as a mechanism to limit the SCSI queue depth. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 09/02/2004 10:23 To cc Subject [Ips] iSCSI: intent of MaxCmdSN Regarding MaxCmdSN, is the intent to regulate the flow of commands to the SCSI layer or to regulate the flow to iSCSI for multiple connections? It seems that it must be for multiple connections to reduce the number of commands that are waiting to be ordered to SCSI. And that the SCSI layer should be responsible for its own queue depth. But, I just wanted to see if I'm missing something. Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 13:46:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02004 for ; Tue, 10 Feb 2004 13:46:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqctW-0007hr-Bd for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 13:46:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIk2HG029608 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 13:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqctV-0007hN-Bv for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:46:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01946 for ; Tue, 10 Feb 2004 13:45:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqctT-0000m8-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:45:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcsW-0000ez-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:45:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqcrZ-0000Yd-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 13:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcrZ-0007Uy-0v; Tue, 10 Feb 2004 13:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcqd-0007Md-Bp for ips@optimus.ietf.org; Tue, 10 Feb 2004 13:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01837 for ; Tue, 10 Feb 2004 13:43:01 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcqb-0000SS-00 for ips@ietf.org; Tue, 10 Feb 2004 13:43:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqcpe-0000NM-00 for ips@ietf.org; Tue, 10 Feb 2004 13:42:03 -0500 Received: from msgbas2x.cos.agilent.com ([192.25.240.37]) by ietf-mx with esmtp (Exim 4.12) id 1AqcpA-0000IX-00; Tue, 10 Feb 2004 13:41:32 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 3EDA36EAE; Tue, 10 Feb 2004 11:41:30 -0700 (MST) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id A2B7F252; Tue, 10 Feb 2004 11:41:27 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 11:41:27 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ips] iSCSI: intent of MaxCmdSN Date: Tue, 10 Feb 2004 11:41:26 -0700 Message-ID: Thread-Topic: [Ips] iSCSI: intent of MaxCmdSN Thread-Index: AcPwAwgHP0od8PKdSCKmxcGGLX8JJgAAb0xw To: , Cc: , X-OriginalArrivalTime: 10 Feb 2004 18:41:27.0154 (UTC) FILETIME=[7DBCE520:01C3F005] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Eddy, Your view seems to assume that iSCSI only has to worry about queuing for = reordering out of order command arrivals. Even if MaxCmdSN isn't used to = regulate flow to the SCSI layer, iSCSI still has an interest in the = command after it has passed it to SCSI. There are iSCSI resources tied up in a command until the status has been = received (initiator) or the status has been acknowledged (target). = MaxCmdSN is a way to regulate the demand on those resources throughout = the life of the command. Pat "Eddy Quicksall" =20 Sent by: ips-admin@ietf.org 09/02/2004 10:23 To cc Subject [Ips] iSCSI: intent of MaxCmdSN Regarding MaxCmdSN, is the intent to regulate the flow of commands to = the=20 SCSI layer or to regulate the flow to iSCSI for multiple connections? =20 It seems that it must be for multiple connections to reduce the number = of=20 commands that are waiting to be ordered to SCSI. And that the SCSI layer = should be responsible for its own queue depth. =20 But, I just wanted to see if I'm missing something. =20 Eddy _______________________________________________ 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 exim@www1.ietf.org Tue Feb 10 14:34:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04638 for ; Tue, 10 Feb 2004 14:34:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqddz-0003Es-MQ for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 14:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AJY30m012450 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 14:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqddz-0003Ej-GO for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 14:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04617 for ; Tue, 10 Feb 2004 14:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqddw-0006EP-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 14:34:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqdcz-000694-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 14:33:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdc4-00063k-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 14:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdc1-000367-8p; Tue, 10 Feb 2004 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqdb8-00034x-Av for ips@optimus.ietf.org; Tue, 10 Feb 2004 14:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04544 for ; Tue, 10 Feb 2004 14:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqdb5-0005yM-00 for ips@ietf.org; Tue, 10 Feb 2004 14:31:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdaF-0005tc-00 for ips@ietf.org; Tue, 10 Feb 2004 14:30:12 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AqdZu-0005ob-00 for ips@ietf.org; Tue, 10 Feb 2004 14:29:50 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc11) with SMTP id <2004021019292001100t8l7oe> (Authid: esquicksall); Tue, 10 Feb 2004 19:29:20 +0000 Message-ID: <001c01c3f00c$2e5ac400$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Ken Sandars" , Cc: References: <001c01c3efef$2e428740$6b07a8c0@winminx> Subject: Re: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 14:29:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Are the commands always terminated at ERL 2? 3.2.7 Persistent State Commands persist beyond connection termination if the session persists and command recovery within the session is supported. However, when a connection is dropped, command execution, as perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the affected task), is suspended until a new allegiance is established by the 'task reassign' task management function. (See Section 10.5 Task Management Function Request.) Eddy ----- Original Message ----- From: "Ken Sandars" To: "'Eddy Quicksall'" ; Cc: Sent: Tuesday, February 10, 2004 11:01 AM Subject: RE: [Ips] iSCSI: reinstatement > Hi Eddy & Bill > > I reckon Bill has hit the nail on the head. The connection which causes > session reinstatement must have been negotiated as a leading login (TSID > is 0) to a NEW session - it's a fresh start in life. There is a > convenient side-effect where any previous session (from the target's > point of view) on that I-T-nexus gets nuked from outer space (regardless > of ERL). > > > Cheers, > Kens Sandars > Elipsan UK > > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Eddy Quicksall > > Sent: 09 February 2004 21:13 > > To: wrstuden@wasabisystems.com > > Cc: ips@ietf.org > > Subject: Re: [Ips] iSCSI: reinstatement > > > > > > Yes, I think you are understanding it and I just want to see > > if everyone agrees. > > > > Consider ERL 2 session reinstatement. According to 10.12.8, > > the initiator would have to keep track of the CmdSN (since > > the ExpCmdSN will be the leading login's CmdSN+1). Otherwise > > the following would be broken. Right? If the correct CmdSN is > > not used, the out-of-order commands already in the target > > will get stuck and/or new commands will appear "out of the > > command window". > > > > ----Connection 0 > > T->I CmdSN=5 > > I->T ExpCmdSN=6 > > ----Connection 1 > > T->I CmdSN=7 > > I->T ExpCmdSN=6 > > ----Both connections are lost > > ----The initiator would have to use CmdSN=5 for the new leading login. > > > > Eddy > > > > ----- Original Message ----- > > From: > > To: "Eddy Quicksall" > > Cc: > > Sent: Monday, February 09, 2004 2:15 PM > > Subject: Re: [Ips] iSCSI: reinstatement > > > > > > > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > > > > > When an initiator reinstates a connection/session, it will supply > > > > the ExpStatSN and CmdSN in the new login. > > > > > > > > I would like to confirm my understanding (ERL 0) ... > > > > > > > > Should the target remember the last StatSN for the lost > > connection > > > > or should it use the initiator's new ExpStatSN for the > > next StatSN? > > > > I am expecting that the target uses the ExpStatSN. > > > > > > From Login Request: > > > > > > 10.12.9 ExpStatSN > > > > > > For the first Login Request on a connection this is ExpStatSN for > > > the old connection and this field is only valid if the > > Login request > > > restarts a connection (see Section 5.3.4 Connection > > Reinstatement). > > > > > > For subsequent Login Requests it is used to acknowledge the Login > > > Responses with their increasing StatSN values. > > > > > > And from Login Response: > > > > > > 10.13.4 StatSN > > > > > > For the first Login Response (the response to the first Login > > > Request), this is the starting status Sequence Number for the > > > connection. The next response of any kind, including the > > next login > > > response, if any, in the same Login Phase, will carry > > this number + > > > 1. This field is only valid if the Status-Class is 0. > > > > > > Thus where the StatSN sequence starts is the purvue of the target. > > > Once it's started (first Login Response on a connection), > > the StatSN > > > rules dictate how it changes through the connection. > > > > > > The target can start each connection with a totally-random > > number, and > > > that'd be ok. > > > > > > > Should the target remember the last ExpCmdSN for the lost session > > > > (last lost connection of a session) or should it use the > > initiator's > > > > new CmdSN for the next ExpCmdSN? I am expecting that the > > target uses > > > > the CmdSN. > > > > > > I think "10.12.8 CmdSN" covers CmdSN for all cases other > > than session > > > reinstatement. > > > > > > I'm a bit confused about session reinstatement. I _think_ a session > > > reinstatement connection should be treated as a leading > > connection, in > > > which case the target should respect the supplied CmdSN. > > > > > > The reason I think this is in thinking about what happens if the > > > initiator suddenly reboots. When it comes up, it won't know > > it has a > > > session with the target(*). So it will be performing an "initial > > > login" which looks like session reinstatement to the > > target. If this > > > connection isn't treated as "leading", then the initiator may get > > > confused when it tries to negotiate some "leading-only" parameters > > > with the target. > > > > > > (*) Unless we are requiring the initiator remember it had a > > session, > > > so then it could know it was doing session-reinstatement. > > > > > > Am I understanding this correctly? > > > > > > Take care, > > > > > > Bill > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Feb 10 15:41:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12726 for ; Tue, 10 Feb 2004 15:41:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqegL-0003OZ-QC for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:40:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKeXYT013045 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:40:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqegL-0003OK-HW for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:40:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12683 for ; Tue, 10 Feb 2004 15:40:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqegK-0005ph-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:40:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqefZ-0005gg-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:39:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqeem-0005WP-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:38:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeVB-0001oX-Ae; Tue, 10 Feb 2004 15:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeUE-0001mm-Oq for ips@optimus.ietf.org; Tue, 10 Feb 2004 15:28:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12229 for ; Tue, 10 Feb 2004 15:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqeUD-0004cU-00 for ips@ietf.org; Tue, 10 Feb 2004 15:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeTG-0004YP-00 for ips@ietf.org; Tue, 10 Feb 2004 15:27:03 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx with esmtp (Exim 4.12) id 1AqeSI-0004Pi-00 for ips@ietf.org; Tue, 10 Feb 2004 15:26:02 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1AKPH7a058374; Tue, 10 Feb 2004 20:25:17 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1AKPGps179856; Tue, 10 Feb 2004 20:25:16 GMT In-Reply-To: <001c01c3f00c$2e5ac400$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org, "Ken Sandars" , wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: reinstatement X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 12:27:07 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/02/2004 22:27:10, Serialize complete at 10/02/2004 22:27:10 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On the contrary - the assumption is that you will reassign within the time bounds specified and terminate only if not. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 10/02/2004 11:29 To "Ken Sandars" , cc Subject Re: [Ips] iSCSI: reinstatement Are the commands always terminated at ERL 2? 3.2.7 Persistent State Commands persist beyond connection termination if the session persists and command recovery within the session is supported. However, when a connection is dropped, command execution, as perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the affected task), is suspended until a new allegiance is established by the 'task reassign' task management function. (See Section 10.5 Task Management Function Request.) Eddy ----- Original Message ----- From: "Ken Sandars" To: "'Eddy Quicksall'" ; Cc: Sent: Tuesday, February 10, 2004 11:01 AM Subject: RE: [Ips] iSCSI: reinstatement > Hi Eddy & Bill > > I reckon Bill has hit the nail on the head. The connection which causes > session reinstatement must have been negotiated as a leading login (TSID > is 0) to a NEW session - it's a fresh start in life. There is a > convenient side-effect where any previous session (from the target's > point of view) on that I-T-nexus gets nuked from outer space (regardless > of ERL). > > > Cheers, > Kens Sandars > Elipsan UK > > > > -----Original Message----- > > From: ips-admin@ietf.org [mailto:ips-admin@ietf.org] On > > Behalf Of Eddy Quicksall > > Sent: 09 February 2004 21:13 > > To: wrstuden@wasabisystems.com > > Cc: ips@ietf.org > > Subject: Re: [Ips] iSCSI: reinstatement > > > > > > Yes, I think you are understanding it and I just want to see > > if everyone agrees. > > > > Consider ERL 2 session reinstatement. According to 10.12.8, > > the initiator would have to keep track of the CmdSN (since > > the ExpCmdSN will be the leading login's CmdSN+1). Otherwise > > the following would be broken. Right? If the correct CmdSN is > > not used, the out-of-order commands already in the target > > will get stuck and/or new commands will appear "out of the > > command window". > > > > ----Connection 0 > > T->I CmdSN=5 > > I->T ExpCmdSN=6 > > ----Connection 1 > > T->I CmdSN=7 > > I->T ExpCmdSN=6 > > ----Both connections are lost > > ----The initiator would have to use CmdSN=5 for the new leading login. > > > > Eddy > > > > ----- Original Message ----- > > From: > > To: "Eddy Quicksall" > > Cc: > > Sent: Monday, February 09, 2004 2:15 PM > > Subject: Re: [Ips] iSCSI: reinstatement > > > > > > > On Mon, 9 Feb 2004, Eddy Quicksall wrote: > > > > > > > When an initiator reinstates a connection/session, it will supply > > > > the ExpStatSN and CmdSN in the new login. > > > > > > > > I would like to confirm my understanding (ERL 0) ... > > > > > > > > Should the target remember the last StatSN for the lost > > connection > > > > or should it use the initiator's new ExpStatSN for the > > next StatSN? > > > > I am expecting that the target uses the ExpStatSN. > > > > > > From Login Request: > > > > > > 10.12.9 ExpStatSN > > > > > > For the first Login Request on a connection this is ExpStatSN for > > > the old connection and this field is only valid if the > > Login request > > > restarts a connection (see Section 5.3.4 Connection > > Reinstatement). > > > > > > For subsequent Login Requests it is used to acknowledge the Login > > > Responses with their increasing StatSN values. > > > > > > And from Login Response: > > > > > > 10.13.4 StatSN > > > > > > For the first Login Response (the response to the first Login > > > Request), this is the starting status Sequence Number for the > > > connection. The next response of any kind, including the > > next login > > > response, if any, in the same Login Phase, will carry > > this number + > > > 1. This field is only valid if the Status-Class is 0. > > > > > > Thus where the StatSN sequence starts is the purvue of the target. > > > Once it's started (first Login Response on a connection), > > the StatSN > > > rules dictate how it changes through the connection. > > > > > > The target can start each connection with a totally-random > > number, and > > > that'd be ok. > > > > > > > Should the target remember the last ExpCmdSN for the lost session > > > > (last lost connection of a session) or should it use the > > initiator's > > > > new CmdSN for the next ExpCmdSN? I am expecting that the > > target uses > > > > the CmdSN. > > > > > > I think "10.12.8 CmdSN" covers CmdSN for all cases other > > than session > > > reinstatement. > > > > > > I'm a bit confused about session reinstatement. I _think_ a session > > > reinstatement connection should be treated as a leading > > connection, in > > > which case the target should respect the supplied CmdSN. > > > > > > The reason I think this is in thinking about what happens if the > > > initiator suddenly reboots. When it comes up, it won't know > > it has a > > > session with the target(*). So it will be performing an "initial > > > login" which looks like session reinstatement to the > > target. If this > > > connection isn't treated as "leading", then the initiator may get > > > confused when it tries to negotiate some "leading-only" parameters > > > with the target. > > > > > > (*) Unless we are requiring the initiator remember it had a > > session, > > > so then it could know it was doing session-reinstatement. > > > > > > Am I understanding this correctly? > > > > > > Take care, > > > > > > Bill > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Feb 10 15:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13045 for ; Tue, 10 Feb 2004 15:50:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqepa-0003yP-Dp for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKo6wF015267 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqepa-0003yA-9W for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13026 for ; Tue, 10 Feb 2004 15:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqepY-0006o9-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:50:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqeoZ-0006hM-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:49:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqene-0006ai-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqenZ-0003jW-BY; Tue, 10 Feb 2004 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqemp-0003i9-1i for ips@optimus.ietf.org; Tue, 10 Feb 2004 15:47:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12927 for ; Tue, 10 Feb 2004 15:47:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqemn-0006VK-00 for ips@ietf.org; Tue, 10 Feb 2004 15:47:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqelr-0006P5-00 for ips@ietf.org; Tue, 10 Feb 2004 15:46:16 -0500 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 1Aqela-0006It-00 for ips@ietf.org; Tue, 10 Feb 2004 15:45:58 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 61D6D1C037B6 for ; Tue, 10 Feb 2004 12:45:54 -0800 (PST) Received: from rose.hp.com (pal2nai171041.nsr.hp.com [15.244.171.41]) by rosemail.rose.hp.com (Postfix) with ESMTP id B2AB88001 for ; Tue, 10 Feb 2004 12:40:31 -0800 (PST) Message-ID: <402942EE.3060501@rose.hp.com> Date: Tue, 10 Feb 2004 12:45:34 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] iSCSI: reinstatement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eddy, The critical phrase in the quoted text from 3.2.7 is "if the session persists". A session reinstatement wipes out the old session context in its entirety, i.e. the old instance does not "persist" any longer, please see 5.3.5. M Julian Satran wrote: > On the contrary - the assumption is that you will reassign within the time > bounds specified and terminate only if not. > > Julo > > > > "Eddy Quicksall" > Sent by: ips-admin@ietf.org > 10/02/2004 11:29 > > To > "Ken Sandars" , > cc > > Subject > Re: [Ips] iSCSI: reinstatement > > > > > > > Are the commands always terminated at ERL 2? > > 3.2.7 Persistent State > > Commands persist beyond connection termination if the session > persists and command recovery within the session is supported. > However, when a connection is dropped, command execution, as > perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the > affected task), is suspended until a new allegiance is established > by the 'task reassign' task management function. (See Section 10.5 > Task Management Function Request.) > > Eddy > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 15:57:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13932 for ; Tue, 10 Feb 2004 15:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqewL-0004Uj-FV for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:57:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AKv5Cc017271 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 15:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqewL-0004UU-88 for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 15:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13845 for ; Tue, 10 Feb 2004 15:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqewJ-0007hi-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:57:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqevL-0007YB-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:56:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqeuM-0007Oq-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 15:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqeuM-0004Fv-7O; Tue, 10 Feb 2004 15:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqetY-0004E8-In for ips@optimus.ietf.org; Tue, 10 Feb 2004 15:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13505 for ; Tue, 10 Feb 2004 15:54:10 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqetX-0007Il-00 for ips@ietf.org; Tue, 10 Feb 2004 15:54:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqesi-0007Cg-00 for ips@ietf.org; Tue, 10 Feb 2004 15:53:20 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aqerx-00076K-00 for ips@ietf.org; Tue, 10 Feb 2004 15:52:33 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 6F9D94013A; Tue, 10 Feb 2004 15:52:33 -0500 (EST) Date: Tue, 10 Feb 2004 12:52:12 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Julian Satran Cc: Eddy Quicksall , ips@ietf.org, Ken Sandars Subject: Re: [Ips] iSCSI: reinstatement In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 10 Feb 2004, Julian Satran wrote: > On the contrary - the assumption is that you will reassign within the time > bounds specified and terminate only if not. Just to make sure we're all on the same page: If we're operating at ERL 2, and we perform session reinstatement, tasks from the old commands stick around waiting to get re-attached? I'd have expected that if we're doing session reinstatement, we would just kill all the old tasks. Also, since the session-reinstatement connection should be leading, what happens if ERL gets negotiated to a different value? Say it was ERL 0 before, and now it's ERL 2? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 16:29:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18642 for ; Tue, 10 Feb 2004 16:29:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfRf-0000RX-TZ for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALTR4L001702 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfRf-0000RN-Jn for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:29:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18507 for ; Tue, 10 Feb 2004 16:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfRd-0005Zd-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:29:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfPS-00054x-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:27:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfOQ-0004tD-01 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqfNQ-0002dN-Nm for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:25:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfNP-0008OZ-Iw; Tue, 10 Feb 2004 16:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfMq-0008Na-WE for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:24:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18175 for ; Tue, 10 Feb 2004 16:24:26 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfMp-0004hl-00 for ips@ietf.org; Tue, 10 Feb 2004 16:24:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfLu-0004aC-00 for ips@ietf.org; Tue, 10 Feb 2004 16:23:30 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqfLP-0004SQ-00 for ips@ietf.org; Tue, 10 Feb 2004 16:22:59 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 2AA0F4013A; Tue, 10 Feb 2004 16:22:59 -0500 (EST) Date: Tue, 10 Feb 2004 13:22:38 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Julian Satran Cc: Eddy Quicksall , ips@ietf.org, Ken Sandars Subject: Re: [Ips] iSCSI: reinstatement In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 10 Feb 2004 wrstuden@wasabisystems.com wrote: > On Tue, 10 Feb 2004, Julian Satran wrote: > > > On the contrary - the assumption is that you will reassign within the time > > bounds specified and terminate only if not. > > Just to make sure we're all on the same page: If we're operating at ERL 2, > and we perform session reinstatement, tasks from the old commands stick > around waiting to get re-attached? > > I'd have expected that if we're doing session reinstatement, we would just > kill all the old tasks. Ahhh... Mallikarjun cleared this point up. The session doesn't persist across session reinstatement, thus my concerns are invalid. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 16:30:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18696 for ; Tue, 10 Feb 2004 16:30:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfRq-0000SS-MR for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALTcHD001754 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfRq-0000SD-IO for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:29:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18553 for ; Tue, 10 Feb 2004 16:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfRo-0005by-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:29:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfPX-00056J-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:27:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfOS-0004vI-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:26:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqfOR-0002eI-He for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfOM-00004w-1J; Tue, 10 Feb 2004 16:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfNd-0008SG-4F for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:25:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18211 for ; Tue, 10 Feb 2004 16:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfNb-0004na-00 for ips@ietf.org; Tue, 10 Feb 2004 16:25:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfMa-0004ff-00 for ips@ietf.org; Tue, 10 Feb 2004 16:24:12 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqfLW-0004SG-00 for ips@ietf.org; Tue, 10 Feb 2004 16:23:06 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004021021223601600f32a5e> (Authid: esquicksall); Tue, 10 Feb 2004 21:22:36 +0000 Message-ID: <002701c3f01c$00ef5020$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: "Mallikarjun C." , References: <402942EE.3060501@rose.hp.com> Subject: Re: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 16:22:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, I have seen the statement that says "Session reinstatement causes all tasks that were active on the old session to be immediately terminated ...". But that seems to be contradictory to the first sentence of 3.2.7. It seems 3.2.7 is allowing the session to persist; and I'm assuming that means across a connection failure where the connection is the only one in the session. Are you simply saying that a session does not persist across a connection failure? Also if session reinstatement wipes out the old session context, how can task reassignment occur under 5.3.4 without session context since that contains may contain out of order commands that are waiting for ordering? I am really confused here and may just need an example. Suppose I have two connections in a session and both connections fail? Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Tuesday, February 10, 2004 3:45 PM Subject: Re: [Ips] iSCSI: reinstatement > Eddy, > > The critical phrase in the quoted text from 3.2.7 > is "if the session persists". A session reinstatement > wipes out the old session context in its entirety, > i.e. the old instance does not "persist" any longer, > please see 5.3.5. > > > M > > > Julian Satran wrote: > > > On the contrary - the assumption is that you will reassign within the time > > bounds specified and terminate only if not. > > > > Julo > > > > > > > > "Eddy Quicksall" > > Sent by: ips-admin@ietf.org > > 10/02/2004 11:29 > > > > To > > "Ken Sandars" , > > cc > > > > Subject > > Re: [Ips] iSCSI: reinstatement > > > > > > > > > > > > > > Are the commands always terminated at ERL 2? > > > > 3.2.7 Persistent State > > > > Commands persist beyond connection termination if the session > > persists and command recovery within the session is supported. > > However, when a connection is dropped, command execution, as > > perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the > > affected task), is suspended until a new allegiance is established > > by the 'task reassign' task management function. (See Section 10.5 > > Task Management Function Request.) > > > > Eddy > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 10 16:38:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20058 for ; Tue, 10 Feb 2004 16:38:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfZc-0001Wi-R7 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:37:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALbeXG005859 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfZc-0001WL-GD for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:37:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19969 for ; Tue, 10 Feb 2004 16:37:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfZa-0007UO-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:37:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfYU-0007Fe-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:36:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqfX6-0006uD-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfX4-00017T-Et; Tue, 10 Feb 2004 16:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfWI-00016I-6q for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:34:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19328 for ; Tue, 10 Feb 2004 16:34:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfWG-0006k2-00 for ips@ietf.org; Tue, 10 Feb 2004 16:34:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfUa-0006K7-00 for ips@ietf.org; Tue, 10 Feb 2004 16:32:30 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AqfSi-0005hW-00 for ips@ietf.org; Tue, 10 Feb 2004 16:30:32 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <20040210213002012008525ge> (Authid: esquicksall); Tue, 10 Feb 2004 21:30:02 +0000 Message-ID: <003201c3f01d$0abca980$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: Subject: Re: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 16:30:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Maybe I'm reading too much into this... are you really just saying that a session can't be reinstated? If they can, what about them is reinstated? Eddy ----- Original Message ----- From: To: "Julian Satran" Cc: "Eddy Quicksall" ; ; "Ken Sandars" Sent: Tuesday, February 10, 2004 4:22 PM Subject: Re: [Ips] iSCSI: reinstatement > On Tue, 10 Feb 2004 wrstuden@wasabisystems.com wrote: > > > On Tue, 10 Feb 2004, Julian Satran wrote: > > > > > On the contrary - the assumption is that you will reassign within the time > > > bounds specified and terminate only if not. > > > > Just to make sure we're all on the same page: If we're operating at ERL 2, > > and we perform session reinstatement, tasks from the old commands stick > > around waiting to get re-attached? > > > > I'd have expected that if we're doing session reinstatement, we would just > > kill all the old tasks. > > Ahhh... Mallikarjun cleared this point up. The session doesn't persist > across session reinstatement, thus my concerns are invalid. :-) > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 16:44:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20681 for ; Tue, 10 Feb 2004 16:44:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqffS-0004u9-JH for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:43:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALhgY3018847 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqffS-0004tu-Ej for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20653 for ; Tue, 10 Feb 2004 16:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqffQ-0000k5-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfeY-0000aV-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:42:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfdo-0000Pm-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfdp-0004ki-FH; Tue, 10 Feb 2004 16:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfdC-0004jF-Qa for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:41:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20460 for ; Tue, 10 Feb 2004 16:41:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfdA-0000MQ-00 for ips@ietf.org; Tue, 10 Feb 2004 16:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfcR-0000EB-00 for ips@ietf.org; Tue, 10 Feb 2004 16:40:36 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfba-0007n6-00 for ips@ietf.org; Tue, 10 Feb 2004 16:39:42 -0500 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate7.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1ALd84n119568; Tue, 10 Feb 2004 21:39:08 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1ALd7bH188948; Tue, 10 Feb 2004 21:39:08 GMT In-Reply-To: <002701c3f01c$00ef5020$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: "Mallikarjun C." , ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: reinstatement X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 13:41:00 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/02/2004 23:41:01, Serialize complete at 10/02/2004 23:41:01 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Eddy, A session persists even across the last connection failure - if you are at ERL 2 and you are not exceeding the time limit to reconnect. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 10-02-2004 13:22 To "Mallikarjun C." , cc Subject Re: [Ips] iSCSI: reinstatement Yes, I have seen the statement that says "Session reinstatement causes all tasks that were active on the old session to be immediately terminated ...". But that seems to be contradictory to the first sentence of 3.2.7. It seems 3.2.7 is allowing the session to persist; and I'm assuming that means across a connection failure where the connection is the only one in the session. Are you simply saying that a session does not persist across a connection failure? Also if session reinstatement wipes out the old session context, how can task reassignment occur under 5.3.4 without session context since that contains may contain out of order commands that are waiting for ordering? I am really confused here and may just need an example. Suppose I have two connections in a session and both connections fail? Eddy ----- Original Message ----- From: "Mallikarjun C." To: Sent: Tuesday, February 10, 2004 3:45 PM Subject: Re: [Ips] iSCSI: reinstatement > Eddy, > > The critical phrase in the quoted text from 3.2.7 > is "if the session persists". A session reinstatement > wipes out the old session context in its entirety, > i.e. the old instance does not "persist" any longer, > please see 5.3.5. > > > M > > > Julian Satran wrote: > > > On the contrary - the assumption is that you will reassign within the time > > bounds specified and terminate only if not. > > > > Julo > > > > > > > > "Eddy Quicksall" > > Sent by: ips-admin@ietf.org > > 10/02/2004 11:29 > > > > To > > "Ken Sandars" , > > cc > > > > Subject > > Re: [Ips] iSCSI: reinstatement > > > > > > > > > > > > > > Are the commands always terminated at ERL 2? > > > > 3.2.7 Persistent State > > > > Commands persist beyond connection termination if the session > > persists and command recovery within the session is supported. > > However, when a connection is dropped, command execution, as > > perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the > > affected task), is suspended until a new allegiance is established > > by the 'task reassign' task management function. (See Section 10.5 > > Task Management Function Request.) > > > > Eddy > > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 10 16:55:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21885 for ; Tue, 10 Feb 2004 16:55:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfq8-0005Ln-8E for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:54:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALsitq020561 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 16:54:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfq8-0005LY-3g for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21830 for ; Tue, 10 Feb 2004 16:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfq6-0002ll-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:54:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfoh-0002Tu-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:53:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfnc-0002FE-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfnW-00059V-Qq; Tue, 10 Feb 2004 16:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfnG-00058B-GH for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:51:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21573 for ; Tue, 10 Feb 2004 16:51:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfnE-00028z-00 for ips@ietf.org; Tue, 10 Feb 2004 16:51:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfmS-0001xB-00 for ips@ietf.org; Tue, 10 Feb 2004 16:50:57 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1AqflK-0001bu-00 for ips@ietf.org; Tue, 10 Feb 2004 16:49:46 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1ALnDZ3160274; Tue, 10 Feb 2004 21:49:13 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1ALnCQc184290; Tue, 10 Feb 2004 21:49:12 GMT In-Reply-To: To: wrstuden@wasabisystems.com Cc: Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: reinstatement X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 13:51:03 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/02/2004 23:51:06, Serialize complete at 10/02/2004 23:51:06 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 An old session disappears after timeout or if a new session with the same name is created (explicitly new session). Otherwise a new connection (perhaps even the only one!) is added to the old session. Julo wrstuden@wasabisystems.com Sent by: ips-admin@ietf.org 10-02-2004 13:36 To Eddy Quicksall cc ips@ietf.org Subject Re: [Ips] iSCSI: reinstatement On Tue, 10 Feb 2004, Eddy Quicksall wrote: > Maybe I'm reading too much into this... are you really just saying that a > session can't be reinstated? If they can, what about them is reinstated? My understanding is that the session does not "persist" across the session reinstatement action. Yes, there is still a session with the same ID (initiator name + ISID, target name + TSIH), but the I_T nexus was broken by the reinstatement event. So the old tasks die. Take care, Bill _______________________________________________ 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 exim@www1.ietf.org Tue Feb 10 17:00:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22740 for ; Tue, 10 Feb 2004 17:00:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfvW-00061t-SN for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:00:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AM0IcN023107 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:00:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfvQ-0005zy-RP for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22664 for ; Tue, 10 Feb 2004 17:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfvO-0003s5-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:00:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfug-0003m5-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:59:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqfuH-0003f0-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 16:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfuH-0005fW-RK; Tue, 10 Feb 2004 16:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqftp-0005dZ-VC for ips@optimus.ietf.org; Tue, 10 Feb 2004 16:58:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22409 for ; Tue, 10 Feb 2004 16:58:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqftn-0003bD-00 for ips@ietf.org; Tue, 10 Feb 2004 16:58:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfsa-0003NI-00 for ips@ietf.org; Tue, 10 Feb 2004 16:57:19 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqfrM-0002xa-00; Tue, 10 Feb 2004 16:56:00 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004021021552701600f574ae> (Authid: esquicksall); Tue, 10 Feb 2004 21:55:27 +0000 Message-ID: <004f01c3f020$983a4080$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: , "Julian Satran" Cc: , References: Subject: Re: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 16:55:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So, this is what I think you are saying: If the connection is lost and there is only one connection in the session, the session persists until the timeout or session reinstatement. If the initiator wants to continue commands, the initiator does connection reinstatement (not session reinstatement) by using the same ISID-TSIH-CID. But if the initiator logs on with the ISID and TSIH==0, then the session dies along with the commands and the initiator therefore has "reset" the session (and the session does not persist). If so, then logically it is really a "session reset" and not a "session reinstatement". Eddy ----- Original Message ----- From: "Julian Satran" To: Cc: "Eddy Quicksall" ; ; Sent: Tuesday, February 10, 2004 4:51 PM Subject: Re: [Ips] iSCSI: reinstatement > An old session disappears after timeout or if a new session with the same > name is created (explicitly new session). Otherwise a new connection > (perhaps even the only one!) is added to the old session. > > Julo > > > > wrstuden@wasabisystems.com > Sent by: ips-admin@ietf.org > 10-02-2004 13:36 > > To > Eddy Quicksall > cc > ips@ietf.org > Subject > Re: [Ips] iSCSI: reinstatement > > > > > > > On Tue, 10 Feb 2004, Eddy Quicksall wrote: > > > Maybe I'm reading too much into this... are you really just saying that > a > > session can't be reinstated? If they can, what about them is reinstated? > > My understanding is that the session does not "persist" across the session > reinstatement action. Yes, there is still a session with the same ID > (initiator name + ISID, target name + TSIH), but the I_T nexus was broken > by the reinstatement event. So the old tasks die. > > Take care, > > Bill > > _______________________________________________ > 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 exim@www1.ietf.org Tue Feb 10 17:15:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24354 for ; Tue, 10 Feb 2004 17:15:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg9Z-0007n0-Mf for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:14:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMEnN5029939 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:14:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg9Z-0007mo-CT for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:14:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24323 for ; Tue, 10 Feb 2004 17:14:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg9X-0006TN-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:14:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqg8K-0006Dj-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:13:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg6r-0005t1-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg6r-00074l-8E; Tue, 10 Feb 2004 17:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqg64-000746-2T for ips@optimus.ietf.org; Tue, 10 Feb 2004 17:11:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23942 for ; Tue, 10 Feb 2004 17:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg61-0005ra-00 for ips@ietf.org; Tue, 10 Feb 2004 17:11:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqg5D-0005mb-00 for ips@ietf.org; Tue, 10 Feb 2004 17:10:20 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx with esmtp (Exim 4.12) id 1Aqg4q-0005dk-00 for ips@ietf.org; Tue, 10 Feb 2004 17:09:56 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1AM9GZP083856; Tue, 10 Feb 2004 22:09:16 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1AM9FQc173868; Tue, 10 Feb 2004 22:09:16 GMT In-Reply-To: <004f01c3f020$983a4080$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: Re: [Ips] iSCSI: reinstatement X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 10 Feb 2004 14:11:07 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 11/02/2004 00:11:09, Serialize complete at 11/02/2004 00:11:09 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 "Eddy Quicksall" wrote on 10-02-2004 13:55:27: > So, this is what I think you are saying: > > If the connection is lost and there is only one connection in the session, > the session persists until the timeout or session reinstatement. If the > initiator wants to continue commands, the initiator does connection > reinstatement (not session reinstatement) by using the same ISID-TSIH-CID. > Yes. You can even use a different CID - logout the old one and reassign commands. > But if the initiator logs on with the ISID and TSIH==0, then the session > dies along with the commands and the initiator therefore has "reset" the > session (and the session does not persist). If so, then logically it is > really a "session reset" and not a "session reinstatement". Correct. That is the effect although different people use different names for the operation. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Cc: "Eddy Quicksall" ; > ; > Sent: Tuesday, February 10, 2004 4:51 PM > Subject: Re: [Ips] iSCSI: reinstatement > > > > An old session disappears after timeout or if a new session with the same > > name is created (explicitly new session). Otherwise a new connection > > (perhaps even the only one!) is added to the old session. > > > > Julo > > > > > > > > wrstuden@wasabisystems.com > > Sent by: ips-admin@ietf.org > > 10-02-2004 13:36 > > > > To > > Eddy Quicksall > > cc > > ips@ietf.org > > Subject > > Re: [Ips] iSCSI: reinstatement > > > > > > > > > > > > > > On Tue, 10 Feb 2004, Eddy Quicksall wrote: > > > > > Maybe I'm reading too much into this... are you really just saying that > > a > > > session can't be reinstated? If they can, what about them is reinstated? > > > > My understanding is that the session does not "persist" across the session > > reinstatement action. Yes, there is still a session with the same ID > > (initiator name + ISID, target name + TSIH), but the I_T nexus was broken > > by the reinstatement event. So the old tasks die. > > > > Take care, > > > > Bill > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Feb 10 17:40:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26834 for ; Tue, 10 Feb 2004 17:40:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgY9-00022A-Kg for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:40:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMeCqk007812 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgY7-00021l-0j for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:40:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26788 for ; Tue, 10 Feb 2004 17:40:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgY4-0002SK-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:40:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgX9-0002La-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:39:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgW8-0002Eh-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgW3-0001fm-9z; Tue, 10 Feb 2004 17:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgVF-0001Sy-54 for ips@optimus.ietf.org; Tue, 10 Feb 2004 17:37:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26656 for ; Tue, 10 Feb 2004 17:37:09 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgVC-00028G-00 for ips@ietf.org; Tue, 10 Feb 2004 17:37:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgUN-00022v-00 for ips@ietf.org; Tue, 10 Feb 2004 17:36:20 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AqgTn-0001wo-00; Tue, 10 Feb 2004 17:35:43 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 3634A40151; Tue, 10 Feb 2004 17:35:44 -0500 (EST) Date: Tue, 10 Feb 2004 14:35:23 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Julian Satran Cc: Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: reinstatement In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Tue, 10 Feb 2004, Julian Satran wrote: > An old session disappears after timeout or if a new session with the same > name is created (explicitly new session). Otherwise a new connection > (perhaps even the only one!) is added to the old session. Please note we are talking specifically about session reinstatement only. Adding extra connections to the session will, I fear, cloud the discussion. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 10 17:48:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27220 for ; Tue, 10 Feb 2004 17:48:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgfw-0002ZR-6i for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:48:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMmGZZ009875 for ips-archive@odin.ietf.org; Tue, 10 Feb 2004 17:48:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgfw-0002ZC-1G for ips-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:48:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27217 for ; Tue, 10 Feb 2004 17:48:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgft-0003Du-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:48:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgf0-00038F-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:47:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgej-00032V-00 for ips-web-archive@ietf.org; Tue, 10 Feb 2004 17:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgej-0002Qp-J1; Tue, 10 Feb 2004 17:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgdv-0002Lw-Cf for ips@optimus.ietf.org; Tue, 10 Feb 2004 17:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27035 for ; Tue, 10 Feb 2004 17:46:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgds-00030b-00 for ips@ietf.org; Tue, 10 Feb 2004 17:46:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgcw-0002vS-00 for ips@ietf.org; Tue, 10 Feb 2004 17:45:11 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AqgcO-0002q4-00; Tue, 10 Feb 2004 17:44:37 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc13) with SMTP id <2004021022440601600fdhi4e> (Authid: esquicksall); Tue, 10 Feb 2004 22:44:07 +0000 Message-ID: <006a01c3f027$6444ff20$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: , "Julian Satran" , "Mallikarjun C." , "Ken Sandars" Cc: , References: Subject: Re: [Ips] iSCSI: reinstatement Date: Tue, 10 Feb 2004 17:44:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Its all clear now ... I was putting my own meaning on "reinstatement". Thanks for all your help. Eddy ----- Original Message ----- From: To: "Julian Satran" Cc: "Eddy Quicksall" ; ; Sent: Tuesday, February 10, 2004 5:35 PM Subject: Re: [Ips] iSCSI: reinstatement > On Tue, 10 Feb 2004, Julian Satran wrote: > > > An old session disappears after timeout or if a new session with the same > > name is created (explicitly new session). Otherwise a new connection > > (perhaps even the only one!) is added to the old session. > > Please note we are talking specifically about session reinstatement only. > Adding extra connections to the session will, I fear, cloud the > discussion. :-) > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 11 17:34:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04487 for ; Wed, 11 Feb 2004 17:34:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2vX-0008PP-25 for ips-archive@odin.ietf.org; Wed, 11 Feb 2004 17:33:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMXoYP032322 for ips-archive@odin.ietf.org; Wed, 11 Feb 2004 17:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2vW-0008PF-Pv for ips-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:33:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04461 for ; Wed, 11 Feb 2004 17:33:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2vU-0004aW-00 for ips-web-archive@ietf.org; Wed, 11 Feb 2004 17:33:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2ua-0004T1-00 for ips-web-archive@ietf.org; Wed, 11 Feb 2004 17:32:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2u0-0004MF-00 for ips-web-archive@ietf.org; Wed, 11 Feb 2004 17:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2tl-0007vH-K8; Wed, 11 Feb 2004 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2tW-0007uZ-Tf for ips@optimus.ietf.org; Wed, 11 Feb 2004 17:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04344 for ; Wed, 11 Feb 2004 17:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2tU-0004KU-00 for ips@ietf.org; Wed, 11 Feb 2004 17:31:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2sa-0004Dq-00 for ips@ietf.org; Wed, 11 Feb 2004 17:30:49 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2ri-00041E-00 for ips@ietf.org; Wed, 11 Feb 2004 17:29:54 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1BMTJZ3136988; Wed, 11 Feb 2004 22:29:19 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1BMTIIf132656; Wed, 11 Feb 2004 22:29:18 GMT To: ips@ietf.org Cc: cbm@rose.hp.com MIME-Version: 1.0 Subject: RE: [Ips] Sequencing of UA and I/O from aborted tasks in Clear Task Set, and LUN Reset X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Wed, 11 Feb 2004 14:31:11 -0800 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 12/02/2004 00:31:12, Serialize complete at 12/02/2004 00:31:12 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Dear all, As alluded earlier the text for the Clear Task set TM function needs at least a change (to plural for session) to make it more precise. Also if we want to consider the fact taht some of the "sessions" may be non-iSCSI (e.g., FCP) we may want to be "softer" on how the target assures ordering. The current text on page 128 says: ---------------------------------- The target: a) Receives the ABORT TASK SET/CLEAR TASK SET request. b) Waits for all target transfer tags to be responded to and for all affected tasks in the task set to be received. c) Propagates the command to and receives the response from the target SCSI layer. d) Takes note of last-sent StatSN on each of the connections in the session, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). e) Sends the task set management response. __________________________ Mallikarjun and I suggest we change d & e to: d) Takes note of last-sent StatSN on each of the connections in the iSCSI sessions (one or more) sharing the affected task set, and waits for acknowledgement of each StatSN (may solicit for acknowledgement by way of a NOP-In). If some tasks originate from non-iSCSI I_T_L nexi then the means by which the target insures that all affected tasks have returned to the initiator their status are defined by the specific protocol. e) Sends the task set management response to the issuing initiator. -------------------- Please observe that the change is purely editorial. Julo _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Feb 14 15:19:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29948 for ; Sat, 14 Feb 2004 15:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As6Fa-00086y-H2 for ips-archive@odin.ietf.org; Sat, 14 Feb 2004 15:18:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EKIsb0031176 for ips-archive@odin.ietf.org; Sat, 14 Feb 2004 15:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As6Fa-00086l-Cq for ips-web-archive@optimus.ietf.org; Sat, 14 Feb 2004 15:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29894 for ; Sat, 14 Feb 2004 15:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As6FZ-0007Fe-00 for ips-web-archive@ietf.org; Sat, 14 Feb 2004 15:18:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As6Ec-0007Cq-00 for ips-web-archive@ietf.org; Sat, 14 Feb 2004 15:17:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1As6Dp-0007AR-00 for ips-web-archive@ietf.org; Sat, 14 Feb 2004 15:17:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As6Dk-0007YP-Mz; Sat, 14 Feb 2004 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As6Df-0007Wx-0j for ips@optimus.ietf.org; Sat, 14 Feb 2004 15:16:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29719 for ; Sat, 14 Feb 2004 15:16:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As6Dd-00079h-00 for ips@ietf.org; Sat, 14 Feb 2004 15:16:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As6Ci-000778-00 for ips@ietf.org; Sat, 14 Feb 2004 15:15:57 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1As6C8-00070m-00 for ips@ietf.org; Sat, 14 Feb 2004 15:15:20 -0500 Received: from ivvt2dxrc11 (c-66-177-57-55.se.client2.attbi.com[66.177.57.55]) by comcast.net (sccrmhc12) with SMTP id <2004021420145001200mkuuhe> (Authid: esquicksall); Sat, 14 Feb 2004 20:14:50 +0000 Message-ID: <000e01c3f337$33171f10$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Sat, 14 Feb 2004 15:14:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C3F30D.49DC3AC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Ips] Use of I bit in Nop-out Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C3F30D.49DC3AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the I bit is not set in a Nop-out, is there a good case for = sequencing the NOP? Eddy ------=_NextPart_000_000B_01C3F30D.49DC3AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If the I bit is not set in a Nop-out, is there a = good case for=20 sequencing the NOP?
 
Eddy
------=_NextPart_000_000B_01C3F30D.49DC3AC0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Feb 15 07:25:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06574 for ; Sun, 15 Feb 2004 07:25:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLKy-0004gH-AY for ips-archive@odin.ietf.org; Sun, 15 Feb 2004 07:25:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FCPSCh017987 for ips-archive@odin.ietf.org; Sun, 15 Feb 2004 07:25:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLKx-0004g2-Ty for ips-web-archive@optimus.ietf.org; Sun, 15 Feb 2004 07:25:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06568 for ; Sun, 15 Feb 2004 07:25:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsLKx-0000CC-00 for ips-web-archive@ietf.org; Sun, 15 Feb 2004 07:25:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsLK0-00009d-00 for ips-web-archive@ietf.org; Sun, 15 Feb 2004 07:24:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AsLJd-00006z-00 for ips-web-archive@ietf.org; Sun, 15 Feb 2004 07:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLJZ-0004Z9-2K; Sun, 15 Feb 2004 07:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLJ3-0004YW-14 for ips@optimus.ietf.org; Sun, 15 Feb 2004 07:23:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06524 for ; Sun, 15 Feb 2004 07:23:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsLJ2-00006B-00 for ips@ietf.org; Sun, 15 Feb 2004 07:23:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsLI4-00002N-00 for ips@ietf.org; Sun, 15 Feb 2004 07:22:28 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx with esmtp (Exim 4.12) id 1AsLHX-0007mP-00; Sun, 15 Feb 2004 07:21:55 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1FCLMBT167932; Sun, 15 Feb 2004 12:21:22 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1FCLLZw172774; Sun, 15 Feb 2004 12:21:22 GMT In-Reply-To: <000e01c3f337$33171f10$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Use of I bit in Nop-out X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sun, 15 Feb 2004 14:23:14 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 15/02/2004 14:23:17, Serialize complete at 15/02/2004 14:23:17 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Good sequencing is useful as it tells the target what (if any) it is missing. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 14/02/2004 22:14 To cc Subject [Ips] Use of I bit in Nop-out If the I bit is not set in a Nop-out, is there a good case for sequencing the NOP? Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 16 10:34:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25450 for ; Mon, 16 Feb 2004 10:34:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsklH-0005Ee-BK for ips-archive@odin.ietf.org; Mon, 16 Feb 2004 10:34:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GFYJEc020124 for ips-archive@odin.ietf.org; Mon, 16 Feb 2004 10:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsklH-0005EV-4L for ips-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 10:34:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25361 for ; Mon, 16 Feb 2004 10:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsklE-0004cn-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 10:34:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AskkG-0004Xf-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 10:33:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AskjH-0004ST-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 10:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askj4-0004ZX-VH; Mon, 16 Feb 2004 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Askj0-0004YP-Ta for ips@optimus.ietf.org; Mon, 16 Feb 2004 10:31:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24944; Mon, 16 Feb 2004 10:31:53 -0500 (EST) Message-Id: <200402161531.KAA24944@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Feb 2004 10:31:53 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-isns-22.txt Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons Filename : draft-ietf-ips-isns-22.txt Pages : 111 Date : 2004-2-13 This document specifies the Internet Storage Name Service (iSNS) protocol, which is used for interaction between iSNS servers and iSNS clients in order to facilitate automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. iSNS also facilitates a seamless integration of IP and Fibre Channel networks, due to its ability to emulate Fibre Channel fabric services, and manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-22.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-isns-22.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-isns-22.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: <2004-2-16104458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16104458.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 16 14:07:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11914 for ; Mon, 16 Feb 2004 14:07:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso4d-00066h-QQ for ips-archive@odin.ietf.org; Mon, 16 Feb 2004 14:06:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GJ6V4J023471 for ips-archive@odin.ietf.org; Mon, 16 Feb 2004 14:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso4d-00066U-Je for ips-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 14:06:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11872 for ; Mon, 16 Feb 2004 14:06:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aso4b-0002Mc-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 14:06:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aso3f-0002Jg-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 14:05:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aso3L-0002Gn-00 for ips-web-archive@ietf.org; Mon, 16 Feb 2004 14:05:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso3C-0005r5-El; Mon, 16 Feb 2004 14:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aso2f-0005oW-Ky for ips@optimus.ietf.org; Mon, 16 Feb 2004 14:04:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11806 for ; Mon, 16 Feb 2004 14:04:26 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aso2d-0002FR-00 for ips@ietf.org; Mon, 16 Feb 2004 14:04:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aso1g-0002C8-00 for ips@ietf.org; Mon, 16 Feb 2004 14:03:29 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aso0y-00027N-00 for ips@ietf.org; Mon, 16 Feb 2004 14:02:45 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id AC05040137; Mon, 16 Feb 2004 14:02:38 -0500 (EST) Date: Mon, 16 Feb 2004 11:02:12 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] Use of I bit in Nop-out In-Reply-To: <000e01c3f337$33171f10$0303a8c0@ivvt2dxrc11> Message-ID: References: <000e01c3f337$33171f10$0303a8c0@ivvt2dxrc11> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Sat, 14 Feb 2004, Eddy Quicksall wrote: > If the I bit is not set in a Nop-out, is there a good case for > sequencing the NOP? What do you mean? If the 'I' bit is not set, the NOP-out must follow the standard CmdSN sequencing rules. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 18 18:07:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29294 for ; Wed, 18 Feb 2004 18:07:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtamD-0004qC-5n for ips-archive@odin.ietf.org; Wed, 18 Feb 2004 18:06:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IN6jsD018602 for ips-archive@odin.ietf.org; Wed, 18 Feb 2004 18:06:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtamD-0004px-0s for ips-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 18:06:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29235 for ; Wed, 18 Feb 2004 18:06:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtamA-0000Zh-00 for ips-web-archive@ietf.org; Wed, 18 Feb 2004 18:06:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtalG-0000XZ-00 for ips-web-archive@ietf.org; Wed, 18 Feb 2004 18:05:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atakf-0000Vb-00 for ips-web-archive@ietf.org; Wed, 18 Feb 2004 18:05:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtakY-0004Ky-QB; Wed, 18 Feb 2004 18:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atajj-00047t-JB for ips@optimus.ietf.org; Wed, 18 Feb 2004 18:04:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28891 for ; Wed, 18 Feb 2004 18:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atajg-0000Qx-00 for ips@ietf.org; Wed, 18 Feb 2004 18:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atair-0000K8-00 for ips@ietf.org; Wed, 18 Feb 2004 18:03:18 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1Ataht-0000A1-00 for ips@ietf.org; Wed, 18 Feb 2004 18:02:17 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Wed, 18 Feb 2004 15:01:47 -0800 Message-ID: From: Jane Liu To: ips@ietf.org Date: Wed, 18 Feb 2004 15:01:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F673.2EB24E65" Subject: [Ips] Abort/error handling for task with pending data sequence Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F673.2EB24E65 Content-Type: text/plain; charset="iso-8859-1" Hi, What should the target do when it gets an Abort Task request for a SCSI write command that has an unterminated data sequence? Is it safe to assume that the initiator will not send any more data PDUs for the task to be aborted? When the target detects a payload digest error on the command PDU for a SCSI write command, what should it do if the offending PDU does not have the F-bit set (unsolicited data PDUs are expected). Section 6.7 of the spec says that the target must reject and discard the offending PDU, and "no further action is necessary". Should the target do just that and then reject the unsolicited data PDUs with "Invalid PDU Field"? Thanks in advance for all replies. Jane Liu ------_=_NextPart_001_01C3F673.2EB24E65 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Abort/error handling for task with pending data sequence

Hi,

What should the target do when it gets = an Abort Task request for a SCSI write command that has an unterminated = data sequence? Is it safe to assume that the initiator will not send = any more data PDUs for the task to be aborted?

When the target detects a payload = digest error on the command PDU for a SCSI write command, what should = it do if the offending PDU does not have the F-bit set (unsolicited = data PDUs are expected). Section 6.7 of the spec says that the target = must reject and discard the offending PDU, and "no further action = is necessary". Should the target do just that and then reject the = unsolicited data PDUs with "Invalid PDU Field"?

Thanks in advance for all = replies.

Jane Liu

------_=_NextPart_001_01C3F673.2EB24E65-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 19 07:43:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16540 for ; Thu, 19 Feb 2004 07:43:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnWD-0006Sq-3b for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 07:43:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JCh5o8024841 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 07:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnWC-0006Sa-Uu for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 07:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16510 for ; Thu, 19 Feb 2004 07:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnWC-0002KZ-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 07:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnVH-0002IT-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 07:42:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtnUR-0002Ge-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 07:41:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnUF-0006F8-0o; Thu, 19 Feb 2004 07:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtnTO-0006D0-A3 for ips@optimus.ietf.org; Thu, 19 Feb 2004 07:40:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16432 for ; Thu, 19 Feb 2004 07:40:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtnTN-0002EA-00 for ips@ietf.org; Thu, 19 Feb 2004 07:40:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtnSQ-0002Bn-00 for ips@ietf.org; Thu, 19 Feb 2004 07:39:11 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AtnRx-00027r-00; Thu, 19 Feb 2004 07:38:41 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i1JCbvpS126148; Thu, 19 Feb 2004 12:37:57 GMT Received: from d12ml102.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1JCbtP1265750; Thu, 19 Feb 2004 13:37:57 +0100 In-Reply-To: To: Jane Liu Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Abort/error handling for task with pending data sequence X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 19 Feb 2004 14:39:50 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 19/02/2004 14:39:53, Serialize complete at 19/02/2004 14:39:53 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Jane, ips-admin@ietf.org wrote on 19/02/2004 01:01:46: > Hi, > What should the target do when it gets an Abort Task request for a > SCSI write command that has an unterminated data sequence? Is it safe > to assume that the initiator will not send any more data PDUs for the > task to be aborted? No it is not safe. The target should send it's response to TM only after receiving all the data (unsolicited and expected). The data may be arriving on a different connection than the TM or may be generate by a different thread at the initiator (there is no guaranteed sequence). > When the target detects a payload digest error on the command PDU for > a SCSI write command, what should it do if the offending PDU does not > have the F-bit set (unsolicited data PDUs are expected). Section 6.7 > of the spec says that the target must reject and discard the offending > PDU, and "no further action is necessary". Should the target do just > that and then reject the unsolicited data PDUs with "Invalid PDU Field"? The target may want to delay the reject until it gets all the data. Otherwise if the initiator reuses the ITT some races may result. > Thanks in advance for all replies. > Jane Liu _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 19 19:26:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06540 for ; Thu, 19 Feb 2004 19:26:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyU9-00065X-HM for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:25:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K0Pf1r023399 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyU9-00065K-9X for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:25:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06531 for ; Thu, 19 Feb 2004 19:25:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyU7-0006nR-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:25:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyTT-0006jH-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:24:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtySd-0006cJ-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtySX-0005g1-Lr; Thu, 19 Feb 2004 19:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtySL-0005eW-By for ips@optimus.ietf.org; Thu, 19 Feb 2004 19:23:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06324 for ; Thu, 19 Feb 2004 19:23:46 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtySJ-0006ZN-00 for ips@ietf.org; Thu, 19 Feb 2004 19:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyRd-0006Qo-00 for ips@ietf.org; Thu, 19 Feb 2004 19:23:05 -0500 Received: from srexchimc2.lss.emc.com ([168.159.100.11] helo=srexchimc2.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AtyQT-00069P-00 for ips@ietf.org; Thu, 19 Feb 2004 19:21:53 -0500 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by srexchimc2.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZQJ3SK9; Thu, 19 Feb 2004 19:21:24 -0500 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1YVFG24S>; Thu, 19 Feb 2004 19:21:24 -0500 Message-ID: X-Sybari-Trust: ced9522b 1d8c424f cc4dbb5e 0000013d To: ips@ietf.org Subject: RE: [Ips] IPS WG last call on iSCSI Name Extension Draft Date: Thu, 19 Feb 2004 19:21:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 A bit later than I had hoped, I've reviewed this draft, and turned up what I believe to be a serious issue. Section 2 of the draft motivates NAA naming for iSCSI by discussing the naming formats used by four SCSI transports: iSCSI, Fibre Channel (FC), Serial Attach SCSI (SAS), and SCSI RDMA Protocol (SRP). At first blush, it says that iSCSI should support NAA naming so that it has at least one naming format in common with each of the other three SCSI transports. Probing deeper, it appears that: - SRP provides no motivation for NAA because SRP already uses EUI-64. Mentioning SRP could lead the less than expert reader to the incorrect conclusion that iSCSI is being modified to accommodate InfiniBand. I think the SRP material is extraneous and should be deleted for this reason. - The Fibre Channel motivation seems to be based on a hope that T10 will do something in the future about using NAA for SCSI device names (the Note in square brackets). That's questionable for a standards track RFC. If the FC motivation for NAA usage in iSCSI requires that T10 do something, then we should wait until T10 does that so that we have a stable T10 doc (FCP-3 draft?) to refer to. So, Section 2 appears to boil down to introducing the new NAA naming format to iSCSI to accommodate SAS (Serial Attach SCSI) in a multi-protocol SCSI device, but that's not an easy conclusion to draw from the text as it is currently written. If what I've written above is essentially correct, Section 2 needs to be rewritten to clearly state that SAS is the primary motivation for adding NAA names to iSCSI or to provide the stable T10 reference for FC NAA device naming to use FC as a motivation. Given the difficulty in figuring out the technical case for NAA naming as the draft is currently written, another WG Last Call may be needed on a version of the draft with a rewritten Section 2. Elizabeth and I have sent a number of other editorial comments to the authors. I apologize for the delay in getting to this. --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 exim@www1.ietf.org Thu Feb 19 19:40:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06985 for ; Thu, 19 Feb 2004 19:40:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyiU-00078W-Mp for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:40:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K0eUSi027426 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyiU-00078H-Gr for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:40:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06888 for ; Thu, 19 Feb 2004 19:40:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyiS-0007V0-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:40:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyhY-0007S6-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:39:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atyh3-0007Pa-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atyh3-0006wz-RV; Thu, 19 Feb 2004 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtygV-0006wa-Q4 for ips@optimus.ietf.org; Thu, 19 Feb 2004 19:38:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06829 for ; Thu, 19 Feb 2004 19:38:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtygU-0007OZ-00 for ips@ietf.org; Thu, 19 Feb 2004 19:38:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtyfX-0007N6-00 for ips@ietf.org; Thu, 19 Feb 2004 19:37:28 -0500 Received: from mailhost.intnet.net ([198.252.32.150] helo=mailsys01.intnet.net) by ietf-mx with esmtp (Exim 4.12) id 1AtyfE-0007Lf-00 for ips@ietf.org; Thu, 19 Feb 2004 19:37:08 -0500 Received: from [207.90.20.22] (HELO intnet.net) by mailsys01.intnet.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 65040789 for ips@ietf.org; Thu, 19 Feb 2004 19:39:13 -0500 Message-ID: <4035564A.2040200@intnet.net> Date: Thu, 19 Feb 2004 19:35:22 -0500 From: Jon Toigo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] SCSI to iSCSI Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Off Topic for a second... Does anyone know of a parallel SCSI-to-iSCSI router or bridge either in the market or on the drawing boards anywhere? Is there a standard for performing such a bridge function? Thanks. JWT _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 19 19:53:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07881 for ; Thu, 19 Feb 2004 19:53:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyuD-000892-7s for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:52:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K0qbBN031307 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 19:52:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtyuD-00088s-3H for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 19:52:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07861 for ; Thu, 19 Feb 2004 19:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtyuB-0000mg-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:52:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtytK-0000jy-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:51:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atysf-0000gf-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 19:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atysf-0007qw-Mx; Thu, 19 Feb 2004 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atys8-0007lx-KM for ips@optimus.ietf.org; Thu, 19 Feb 2004 19:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07708 for ; Thu, 19 Feb 2004 19:50:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atys6-0000eG-00 for ips@ietf.org; Thu, 19 Feb 2004 19:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atyr8-0000am-00 for ips@ietf.org; Thu, 19 Feb 2004 19:49:26 -0500 Received: from mailhost.intnet.net ([198.252.32.150] helo=mailsys01.intnet.net) by ietf-mx with esmtp (Exim 4.12) id 1AtyqC-0000Xg-00 for ips@ietf.org; Thu, 19 Feb 2004 19:48:28 -0500 Received: from [207.90.20.22] (HELO intnet.net) by mailsys01.intnet.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 65041176 for ips@ietf.org; Thu, 19 Feb 2004 19:50:48 -0500 Message-ID: <40355901.6080807@intnet.net> Date: Thu, 19 Feb 2004 19:46:57 -0500 From: Jon Toigo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Ips] Follow on Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Is SAS to iSCSI bridging part of an evolving standard to which Mr. Black referred? It would seem that iSCSI could be of enormous value as a means to connect legacy SCSI and or SAS implementations together -- particularly in smaller shops. JWT _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 19 20:22:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09451 for ; Thu, 19 Feb 2004 20:22:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzMR-0002Ox-5A for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 20:21:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K1Ll0e009229 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 20:21:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzMQ-0002Om-Vx for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 20:21:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09443 for ; Thu, 19 Feb 2004 20:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzMO-0003Cg-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 20:21:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzLT-00038e-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 20:20:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtzKm-00034B-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 20:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzKn-0002EK-52; Thu, 19 Feb 2004 20:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtzKd-0002DR-Sj for ips@optimus.ietf.org; Thu, 19 Feb 2004 20:19:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09402 for ; Thu, 19 Feb 2004 20:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtzKb-00033z-00 for ips@ietf.org; Thu, 19 Feb 2004 20:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtzJq-0002y5-00 for ips@ietf.org; Thu, 19 Feb 2004 20:19:07 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1AtzIo-0002nQ-00 for ips@ietf.org; Thu, 19 Feb 2004 20:18:03 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Thu, 19 Feb 2004 17:17:33 -0800 Message-ID: From: Jane Liu To: "'Julian Satran'" Cc: ips@ietf.org Subject: RE: [Ips] Abort/error handling for task with pending data sequenc e Date: Thu, 19 Feb 2004 17:17:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F74F.50A7AC55" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F74F.50A7AC55 Content-Type: text/plain; charset="iso-8859-1" Please see comments below. >> Hi, >> What should the target do when it gets an Abort Task request for a >> SCSI write command that has an unterminated data sequence? Is it safe >> to assume that the initiator will not send any more data PDUs for the >> task to be aborted? > No it is not safe. The target should send it's response to TM only after > receiving all the data (unsolicited and expected). > The data may be arriving on a different connection than the TM or may be > generate by a different thread at the initiator (there is no guaranteed > sequence). I'm still not very clear on this. What should the target do in the following scenario: ("I->T CID 0" means "initiator to target on connection with CID 0") I->T CID 0: SCSI write command with ITT = X, F-bit = 0 I->T CID 0: Data-Out with ITT = X, F-bit = 1 Connection 0 fails after the initiator sends out the Data-Out but before the target receives it. Connection 0 gets logged out. I->T CID 1: Abort Task TM to abort ITT X Should the target wait for the event [I->T CID 1: Data-Out with ITT = X, F-bit = 1]? It seems that such an event can only occur after a succesful reassignment of the write command to connection 1. Section 10.5.1 of the spec says that the TM will "establish a new allegiance for the command to be aborted as well as abort it" and "the task to be aborted will not have to be retried or reassigned". I'm not exactly sure what these requirements entail in such a scenario. Again, all help appreciated. Jane Liu ------_=_NextPart_001_01C3F74F.50A7AC55 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ips] Abort/error handling for task with pending data = sequence

Please see comments below.

>> Hi,
>> What should the target do when it gets an = Abort Task request for a
>> SCSI write command that has an unterminated = data sequence? Is it safe
>> to assume that the initiator will not send = any more data PDUs for the
>> task to be aborted?

> No it is not safe. The target should send it's = response to TM only after
> receiving all the data (unsolicited and = expected).
> The data may be arriving on a different = connection than the TM or may be
> generate by a different thread at the initiator = (there is no guaranteed
> sequence).

I'm still not very clear on this. What should the = target do in the following scenario:
("I->T CID 0" means "initiator to = target on connection with CID 0")

 I->T CID 0: SCSI write command with ITT =3D = X, F-bit =3D 0
 I->T CID 0: Data-Out with ITT =3D X, F-bit = =3D 1
 Connection 0 fails after the initiator sends = out the Data-Out but before the target receives it.
 Connection 0 gets logged out.
 I->T CID 1: Abort Task TM to abort ITT = X

Should the target wait for the event [I->T CID 1: = Data-Out with ITT =3D X, F-bit =3D 1]?
It seems that such an event can only occur after a = succesful reassignment of the write command to connection 1. Section = 10.5.1 of the spec says that the TM will "establish a new = allegiance for the command to be aborted as well as abort it" and = "the task to be aborted will not have to be retried or = reassigned". I'm not exactly sure what these requirements entail = in such a scenario.

Again, all help appreciated. 
 
Jane Liu

------_=_NextPart_001_01C3F74F.50A7AC55-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 19 21:17:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11837 for ; Thu, 19 Feb 2004 21:17:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0Da-0006rv-MI for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 21:16:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K2Ggbp026397 for ips-archive@odin.ietf.org; Thu, 19 Feb 2004 21:16:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0Da-0006rg-G1 for ips-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 21:16:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11831 for ; Thu, 19 Feb 2004 21:16:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0DY-0006sG-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 21:16:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0Cb-0006p6-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 21:15:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au0C0-0006lt-00 for ips-web-archive@ietf.org; Thu, 19 Feb 2004 21:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0By-0006f4-UK; Thu, 19 Feb 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au0BU-0006e8-Ca for ips@optimus.ietf.org; Thu, 19 Feb 2004 21:14:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11749 for ; Thu, 19 Feb 2004 21:14:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au0BR-0006kY-00 for ips@ietf.org; Thu, 19 Feb 2004 21:14:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au0Aa-0006iP-00 for ips@ietf.org; Thu, 19 Feb 2004 21:13:37 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1Au0AQ-0006fw-00 for ips@ietf.org; Thu, 19 Feb 2004 21:13:26 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:12:36 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 19 Feb 2004 18:12:55 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:12:40 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Feb 2004 18:13:20 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 19 Feb 2004 18:11:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Thu, 19 Feb 2004 18:12:46 -0800 Message-ID: Thread-Topic: [iSCSI] Usage of ISID in discovery session Thread-Index: AcP3VwgjJlan2c1+SFu5bbSKVooXNw== From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 20 Feb 2004 02:11:39.0147 (UTC) FILETIME=[DFDBADB0:01C3F756] Subject: [Ips] [iSCSI] Usage of ISID in discovery session Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F757.0B761812" ------_=_NextPart_001_01C3F757.0B761812 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the rule for picking ISIDs for discovery sessions? Since there is no target can any ISID be used? Or do we need to be aware of other discovery sessions and not reuse the ISID ? thanks! -lakshmi ------_=_NextPart_001_01C3F757.0B761812 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What is=20 the rule for picking ISIDs = for=20 discovery sessions?  Since there is no target can any ISID be used? =  Or do we need to be aware of other discovery sessions and not = reuse the=20 ISID ?

thanks!
 -lakshmi<= /FONT>

------_=_NextPart_001_01C3F757.0B761812-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 20 16:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13544 for ; Fri, 20 Feb 2004 16:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHnf-00010C-Aw for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 16:03:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KL37tb003846 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 16:03:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHnf-0000zx-4B for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 16:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13525 for ; Fri, 20 Feb 2004 16:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHnd-0001DB-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 16:03:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHmf-00019V-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 16:02:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuHlj-00015n-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 16:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHle-0000pt-IW; Fri, 20 Feb 2004 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuHks-0000nu-1o for ips@optimus.ietf.org; Fri, 20 Feb 2004 16:00:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13444 for ; Fri, 20 Feb 2004 16:00:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuHkq-00012a-00 for ips@ietf.org; Fri, 20 Feb 2004 16:00:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuHjx-0000z2-00 for ips@ietf.org; Fri, 20 Feb 2004 15:59:17 -0500 Received: from atlrel6.hp.com ([156.153.255.205]) by ietf-mx with esmtp (Exim 4.12) id 1AuHjH-0000vW-00 for ips@ietf.org; Fri, 20 Feb 2004 15:58:36 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel6.hp.com (Postfix) with ESMTP id E3E071C03E66 for ; Fri, 20 Feb 2004 15:58:30 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 7C0118349 for ; Fri, 20 Feb 2004 12:52:12 -0800 (PST) Message-ID: <403674CC.9060802@rose.hp.com> Date: Fri, 20 Feb 2004 12:57:48 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] Abort/error handling for task with pending data sequence References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jane, I remember an earlier discussion on your first question, I thought we had added a "SHOULD NOT" prohibition on the initiator (don't send anymore data after issuing an abort), but I can't find it now. In any case, if your question is about a single Abort Task TMF (not the task set, which Julian may be referring to), I think it's fairly safe to return the response to the TMF after doing the necessary cleanup on the target. The assumptions/rules are: a) initiator sends the Abort Task TMF only on the allegiant connection, or when there's no allegiant connection (section 10.5.1, top of page 123), b) target discards the data-out PDUs on that task, if any, with Rejects (required behavior per 10.17.1), and (c) initiator will not blindly start retransmitting the data PDUs on seeing the rejects (it should be really broken to do that on an aborted task....). On your second question: it's very close to the scenario described in 10.17.1, bottom of page 168, but not quite the same. You're asking about a payload digest error on the command PDU, so the task isn't even instantiated (per section 6.3). So I don't believe your scenario is technically bound by the "MUST wait" rule in 10.17.1, but it's still a good idea to do what Julian suggests to avoid running into needless exception handling and Rejects down the road. Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > Jane, > > ips-admin@ietf.org wrote on 19/02/2004 01:01:46: > > >>Hi, >>What should the target do when it gets an Abort Task request for a >>SCSI write command that has an unterminated data sequence? Is it safe >>to assume that the initiator will not send any more data PDUs for the >>task to be aborted? > > > No it is not safe. The target should send it's response to TM only after > receiving all the data (unsolicited and expected). > The data may be arriving on a different connection than the TM or may be > generate by a different thread at the initiator (there is no guaranteed > sequence). > > >>When the target detects a payload digest error on the command PDU for >>a SCSI write command, what should it do if the offending PDU does not >>have the F-bit set (unsolicited data PDUs are expected). Section 6.7 >>of the spec says that the target must reject and discard the offending >>PDU, and "no further action is necessary". Should the target do just >>that and then reject the unsolicited data PDUs with "Invalid PDU Field"? > > > > The target may want to delay the reject until it gets all the data. > Otherwise if the initiator reuses the ITT some races may result. > > > >>Thanks in advance for all replies. >>Jane Liu > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Feb 20 19:20:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24300 for ; Fri, 20 Feb 2004 19:20:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKsX-0001mm-NX for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 19:20:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L0KLqk006857 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 19:20:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKsX-0001mW-IQ for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 19:20:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24296 for ; Fri, 20 Feb 2004 19:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKsW-0001Pi-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 19:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKrf-0001MP-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 19:19:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuKrI-0001IA-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 19:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKrF-0001cy-4T; Fri, 20 Feb 2004 19:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKqZ-0001cB-Kh for ips@optimus.ietf.org; Fri, 20 Feb 2004 19:18:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24224 for ; Fri, 20 Feb 2004 19:18:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKqY-0001Ga-00 for ips@ietf.org; Fri, 20 Feb 2004 19:18:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKpV-0001Cv-00 for ips@ietf.org; Fri, 20 Feb 2004 19:17:14 -0500 Received: from [65.174.117.136] (helo=morpheus.corp.iready.com) by ietf-mx with esmtp (Exim 4.12) id 1AuKoZ-00017q-00 for ips@ietf.org; Fri, 20 Feb 2004 19:16:15 -0500 Received: by morpheus.corp.iready.com with Internet Mail Service (5.5.2655.55) id ; Fri, 20 Feb 2004 16:15:45 -0800 Message-ID: From: Jane Liu To: "'Mallikarjun C.'" , ips@ietf.org Subject: RE: [Ips] Abort/error handling for task with pending data sequenc e Date: Fri, 20 Feb 2004 16:15:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F80F.9577D0EF" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F80F.9577D0EF Content-Type: text/plain; charset="iso-8859-1" Mallikarjun and Julian, thanks for the clarification. -Jane -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Friday, February 20, 2004 12:58 PM To: ips@ietf.org Subject: Re: [Ips] Abort/error handling for task with pending data sequence Jane, I remember an earlier discussion on your first question, I thought we had added a "SHOULD NOT" prohibition on the initiator (don't send anymore data after issuing an abort), but I can't find it now. In any case, if your question is about a single Abort Task TMF (not the task set, which Julian may be referring to), I think it's fairly safe to return the response to the TMF after doing the necessary cleanup on the target. The assumptions/rules are: a) initiator sends the Abort Task TMF only on the allegiant connection, or when there's no allegiant connection (section 10.5.1, top of page 123), b) target discards the data-out PDUs on that task, if any, with Rejects (required behavior per 10.17.1), and (c) initiator will not blindly start retransmitting the data PDUs on seeing the rejects (it should be really broken to do that on an aborted task....). On your second question: it's very close to the scenario described in 10.17.1, bottom of page 168, but not quite the same. You're asking about a payload digest error on the command PDU, so the task isn't even instantiated (per section 6.3). So I don't believe your scenario is technically bound by the "MUST wait" rule in 10.17.1, but it's still a good idea to do what Julian suggests to avoid running into needless exception handling and Rejects down the road. Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com Julian Satran wrote: > Jane, > > ips-admin@ietf.org wrote on 19/02/2004 01:01:46: > > >>Hi, >>What should the target do when it gets an Abort Task request for a >>SCSI write command that has an unterminated data sequence? Is it safe >>to assume that the initiator will not send any more data PDUs for the >>task to be aborted? > > > No it is not safe. The target should send it's response to TM only after > receiving all the data (unsolicited and expected). > The data may be arriving on a different connection than the TM or may be > generate by a different thread at the initiator (there is no guaranteed > sequence). > > >>When the target detects a payload digest error on the command PDU for >>a SCSI write command, what should it do if the offending PDU does not >>have the F-bit set (unsolicited data PDUs are expected). Section 6.7 >>of the spec says that the target must reject and discard the offending >>PDU, and "no further action is necessary". Should the target do just >>that and then reject the unsolicited data PDUs with "Invalid PDU Field"? > > > > The target may want to delay the reject until it gets all the data. > Otherwise if the initiator reuses the ITT some races may result. > > > >>Thanks in advance for all replies. >>Jane Liu > > > _______________________________________________ > 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 ------_=_NextPart_001_01C3F80F.9577D0EF Content-Type: text/html; charset="iso-8859-1" RE: [Ips] Abort/error handling for task with pending data sequence

Mallikarjun and Julian, thanks for the clarification.   -Jane

-----Original Message-----
From: Mallikarjun C. [mailto:cbm@rose.hp.com]
Sent: Friday, February 20, 2004 12:58 PM
To: ips@ietf.org
Subject: Re: [Ips] Abort/error handling for task with pending data
sequence


Jane,

I remember an earlier discussion on your first question,
I thought we had added a "SHOULD NOT" prohibition on the
initiator (don't send anymore data after issuing an abort),
but I can't find it now.  In any case, if your question
is about a single Abort Task TMF (not the task set, which
Julian may be referring to), I think it's fairly safe to
return the response to the TMF after doing the necessary
cleanup on the target.  The assumptions/rules are: a) initiator
sends the Abort Task TMF only on the allegiant connection,
or when there's no allegiant connection (section 10.5.1,
top of page 123), b) target discards the data-out PDUs on
that task, if any, with Rejects (required behavior per 10.17.1),
and (c) initiator will not blindly start retransmitting the
data PDUs on seeing the rejects (it should be really broken
to do that on an aborted task....).

On your second question: it's very close to the scenario
described in 10.17.1, bottom of page 168, but not quite
the same.  You're asking about a payload digest error
on the command PDU, so the task isn't even instantiated
(per section 6.3).  So I don't believe your scenario is
technically bound by the "MUST wait" rule in 10.17.1, but
it's still a good idea to do what Julian suggests to avoid
running into needless exception handling and Rejects down
the road.

Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com



Julian Satran wrote:

> Jane,
>
> ips-admin@ietf.org wrote on 19/02/2004 01:01:46:
>
>
>>Hi,
>>What should the target do when it gets an Abort Task request for a
>>SCSI write command that has an unterminated data sequence? Is it safe
>>to assume that the initiator will not send any more data PDUs for the
>>task to be aborted?
>
>
> No it is not safe. The target should send it's response to TM only after
> receiving all the data (unsolicited and expected).
> The data may be arriving on a different connection than the TM or may be
> generate by a different thread at the initiator (there is no guaranteed
> sequence).
>
>
>>When the target detects a payload digest error on the command PDU for
>>a SCSI write command, what should it do if the offending PDU does not
>>have the F-bit set (unsolicited data PDUs are expected). Section 6.7
>>of the spec says that the target must reject and discard the offending
>>PDU, and "no further action is necessary". Should the target do just
>>that and then reject the unsolicited data PDUs with "Invalid PDU Field"?
>
>
>
> The target may want to delay the reject until it gets all the data.
> Otherwise if the initiator reuses the ITT some races may result.
>
>
>
>>Thanks in advance for all replies.
>>Jane Liu
>
>
> _______________________________________________
> 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

------_=_NextPart_001_01C3F80F.9577D0EF-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 20 20:09:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25926 for ; Fri, 20 Feb 2004 20:09:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLdu-00051D-Vl for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:09:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L19Ir7019285 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:09:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLdu-00050y-RD for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:09:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25920 for ; Fri, 20 Feb 2004 20:09:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLds-0004pX-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:09:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLd0-0004mk-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:08:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuLch-0004jW-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLcg-0004oF-TG; Fri, 20 Feb 2004 20:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLbw-0004cz-TC for ips@optimus.ietf.org; Fri, 20 Feb 2004 20:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25819 for ; Fri, 20 Feb 2004 20:07:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLbu-0004hF-00 for ips@ietf.org; Fri, 20 Feb 2004 20:07:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLaw-0004af-00 for ips@ietf.org; Fri, 20 Feb 2004 20:06:15 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AuLa0-0004SJ-00 for ips@ietf.org; Fri, 20 Feb 2004 20:05:16 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id 6711D1C023E2; Fri, 20 Feb 2004 17:05:16 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id CAAFB8309; Fri, 20 Feb 2004 16:59:09 -0800 (PST) Message-ID: <4036AEAE.2040309@rose.hp.com> Date: Fri, 20 Feb 2004 17:04:46 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am not sure I see the need for multiple discovery sessions from the same initiator to a given iSCSI service access point unless I'm missing something. If you're, OTOH, including the TargetName key and thus establishing session to a specific TPG of a target, the standard "no duplicate I_T nexus" rule applies - but again, I don't see the need for multiple discovery sessions in this case either. Finally, I don't think one initiator needs to worry about the ISIDs of discovery sessions from other initiator network entities. Lakshmi Ramasubramanian wrote: > What is the rule for picking ISIDs for discovery sessions? Since there > is no target can any ISID be used? Or do we need to be aware of other > discovery sessions and not reuse the ISID ? > > thanks! > -lakshmi > -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 20 20:15:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26104 for ; Fri, 20 Feb 2004 20:15:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLjj-0005Nm-8r for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:15:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L1FJ1a020684 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLjj-0005NX-3T for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:15:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26082 for ; Fri, 20 Feb 2004 20:15:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLjh-0005AQ-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLii-00057K-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:14:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuLiT-000554-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLiU-0005GI-5O; Fri, 20 Feb 2004 20:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLhp-0005FW-JP for ips@optimus.ietf.org; Fri, 20 Feb 2004 20:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26059 for ; Fri, 20 Feb 2004 20:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLhn-00054V-00 for ips@ietf.org; Fri, 20 Feb 2004 20:13:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLgr-00051Z-00 for ips@ietf.org; Fri, 20 Feb 2004 20:12:22 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AuLge-0004yF-00 for ips@ietf.org; Fri, 20 Feb 2004 20:12:08 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 20 Feb 2004 17:11:37 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Feb 2004 17:11:38 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 17:11:37 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 20 Feb 2004 17:11:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 20 Feb 2004 17:12:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Date: Fri, 20 Feb 2004 17:11:24 -0800 Message-ID: Thread-Topic: [Ips] [iSCSI] Usage of ISID in discovery session Thread-Index: AcP4FssYwdO3gZMXRjehFSFYhIlmbAAADfig From: "Lakshmi Ramasubramanian" To: "Mallikarjun C." Cc: X-OriginalArrivalTime: 21 Feb 2004 01:12:24.0680 (UTC) FILETIME=[C3A4CE80:01C3F817] Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Assume there's only one discovery session. Is it okay for ISID of a discovery session to be same as ISID of a non-discovery session from the same initiator? If so, initiator can assign ISID for discovery sessions independent of other (Non-Discovery) sessions. Right? -lakshmi -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 Sent: Friday, February 20, 2004 5:05 PM To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session I am not sure I see the need for multiple discovery sessions from the same initiator to a given iSCSI service access point unless I'm missing something. If you're, OTOH, including the TargetName key and thus establishing session to a specific TPG of a target, the standard "no duplicate I_T nexus" rule applies - but again, I don't see the need for multiple discovery sessions in this case either. Finally, I don't think one initiator needs to worry about the ISIDs of discovery sessions from other initiator network entities. Lakshmi Ramasubramanian wrote: > What is the rule for picking ISIDs for discovery sessions? Since there=20 > is no target can any ISID be used? Or do we need to be aware of other > discovery sessions and not reuse the ISID ? >=20 > thanks! > -lakshmi >=20 --=20 Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 20 20:36:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27274 for ; Fri, 20 Feb 2004 20:36:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM43-00072t-Uh for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:36:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L1aJWF027077 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:36:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM43-00072e-QE for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27260 for ; Fri, 20 Feb 2004 20:36:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuM41-00071P-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:36:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuM38-0006yL-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:35:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuM2p-0006v8-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM2p-0006tb-1c; Fri, 20 Feb 2004 20:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM2H-0006sL-K5 for ips@optimus.ietf.org; Fri, 20 Feb 2004 20:34:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27179 for ; Fri, 20 Feb 2004 20:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuM2F-0006tr-00 for ips@ietf.org; Fri, 20 Feb 2004 20:34:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuM1L-0006pu-00 for ips@ietf.org; Fri, 20 Feb 2004 20:33:31 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AuM0x-0006lN-00 for ips@ietf.org; Fri, 20 Feb 2004 20:33:07 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 0A42D1C03FF8; Fri, 20 Feb 2004 20:33:08 -0500 (EST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 6FD06834F; Fri, 20 Feb 2004 17:26:34 -0800 (PST) Message-ID: <4036B51A.9030208@rose.hp.com> Date: Fri, 20 Feb 2004 17:32:10 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit No. The uniqueness expectation from the ISID RULE is on the four tuple: InitiatorName-ISID-TargetName-TPGT. This _does not_ include the session type (discovery vs normal). And I view the discovery session as also one that has to play by the ISID RULE. The net is that discovery and normal sessions share the same ISID numbering space. M Lakshmi Ramasubramanian wrote: > Assume there's only one discovery session. > > Is it okay for ISID of a discovery session to be same > as ISID of a non-discovery session from the same initiator? > If so, initiator can assign ISID for discovery sessions > independent of other (Non-Discovery) sessions. Right? > > -lakshmi > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, February 20, 2004 5:05 PM > To: Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session > > I am not sure I see the need for multiple discovery > sessions from the same initiator to a given iSCSI service > access point unless I'm missing something. > > If you're, OTOH, including the TargetName key and > thus establishing session to a specific TPG of a target, > the standard "no duplicate I_T nexus" rule applies - but > again, I don't see the need for multiple discovery > sessions in this case either. > > Finally, I don't think one initiator needs to worry about > the ISIDs of discovery sessions from other initiator network > entities. > > Lakshmi Ramasubramanian wrote: > > >>What is the rule for picking ISIDs for discovery sessions? Since > > there > >>is no target can any ISID be used? Or do we need to be aware of other > > >>discovery sessions and not reuse the ISID ? >> >>thanks! >> -lakshmi >> > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Feb 20 20:39:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27346 for ; Fri, 20 Feb 2004 20:39:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM6y-0007Vp-AX for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:39:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L1dKX8028871 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:39:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM6y-0007Va-5z for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:39:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27334 for ; Fri, 20 Feb 2004 20:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuM6v-0007C0-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:39:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuM61-00079D-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:38:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuM5f-00076K-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:37:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM5h-0007PL-Dh; Fri, 20 Feb 2004 20:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuM50-0007An-6r for ips@optimus.ietf.org; Fri, 20 Feb 2004 20:37:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27297 for ; Fri, 20 Feb 2004 20:37:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuM4x-00074v-00 for ips@ietf.org; Fri, 20 Feb 2004 20:37:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuM44-00071o-00 for ips@ietf.org; Fri, 20 Feb 2004 20:36:21 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AuM3E-0006v2-00 for ips@ietf.org; Fri, 20 Feb 2004 20:35:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Date: Fri, 20 Feb 2004 17:33:46 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF2905717AB@mail1irv.inside.istor.com> Thread-Topic: [Ips] [iSCSI] Usage of ISID in discovery session Thread-Index: AcP4FssYwdO3gZMXRjehFSFYhIlmbAAADfigAACsYpA= From: "Ramesh Mangamuri" To: "Lakshmi Ramasubramanian" , "Mallikarjun C." Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Lakshmi, As soon as initiator completes a discovery session it logs out on that session and closes that sessions. Hence I don't see any problem reusing that ISID for a Normal Session. -Ramesh -----Original Message----- From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]=20 Sent: Friday, February 20, 2004 5:11 PM To: Mallikarjun C. Cc: ips@ietf.org Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Assume there's only one discovery session. Is it okay for ISID of a discovery session to be same as ISID of a non-discovery session from the same initiator? If so, initiator can assign ISID for discovery sessions independent of other (Non-Discovery) sessions. Right? -lakshmi -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 Sent: Friday, February 20, 2004 5:05 PM To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session I am not sure I see the need for multiple discovery sessions from the same initiator to a given iSCSI service access point unless I'm missing something. If you're, OTOH, including the TargetName key and thus establishing session to a specific TPG of a target, the standard "no duplicate I_T nexus" rule applies - but again, I don't see the need for multiple discovery sessions in this case either. Finally, I don't think one initiator needs to worry about the ISIDs of discovery sessions from other initiator network entities. Lakshmi Ramasubramanian wrote: > What is the rule for picking ISIDs for discovery sessions? Since there=20 > is no target can any ISID be used? Or do we need to be aware of other > discovery sessions and not reuse the ISID ? >=20 > thanks! > -lakshmi >=20 --=20 Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com _______________________________________________ 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 exim@www1.ietf.org Fri Feb 20 20:49:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27589 for ; Fri, 20 Feb 2004 20:49:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMGh-0008B4-U5 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:49:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L1nNMc031428 for ips-archive@odin.ietf.org; Fri, 20 Feb 2004 20:49:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMGh-0008Ap-OA for ips-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 20:49:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27579 for ; Fri, 20 Feb 2004 20:49:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMGf-0007mX-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:49:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMFl-0007ja-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:48:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuMFM-0007gB-00 for ips-web-archive@ietf.org; Fri, 20 Feb 2004 20:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMFN-000845-40; Fri, 20 Feb 2004 20:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMEg-00082Q-TW for ips@optimus.ietf.org; Fri, 20 Feb 2004 20:47:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27526 for ; Fri, 20 Feb 2004 20:47:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMEe-0007ej-00 for ips@ietf.org; Fri, 20 Feb 2004 20:47:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMDk-0007b7-00 for ips@ietf.org; Fri, 20 Feb 2004 20:46:21 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AuMCu-0007Uk-00 for ips@ietf.org; Fri, 20 Feb 2004 20:45:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Date: Fri, 20 Feb 2004 17:43:47 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DF8@mail1irv.inside.istor.com> Thread-Topic: [Ips] [iSCSI] Usage of ISID in discovery session Thread-Index: AcP4GteVWC1QweAKTU+vE7j7oOQQZAAAR9Eg From: "Ramesh Mangamuri" To: "Mallikarjun C." , "Lakshmi Ramasubramanian" Cc: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Once the discovery session was closed reuse of that ISID for a Normal session won't be unique. -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 Sent: Friday, February 20, 2004 5:32 PM To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session No. The uniqueness expectation from the ISID RULE is on the four tuple: InitiatorName-ISID-TargetName-TPGT. This _does not_ include the session type (discovery vs normal). And I view the discovery session as also one that has to play by the ISID RULE. The net is that discovery and normal sessions share the same ISID numbering space. M Lakshmi Ramasubramanian wrote: > Assume there's only one discovery session. >=20 > Is it okay for ISID of a discovery session to be same > as ISID of a non-discovery session from the same initiator? > If so, initiator can assign ISID for discovery sessions > independent of other (Non-Discovery) sessions. Right? >=20 > -lakshmi >=20 > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 > Sent: Friday, February 20, 2004 5:05 PM > To: Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session >=20 > I am not sure I see the need for multiple discovery > sessions from the same initiator to a given iSCSI service > access point unless I'm missing something. >=20 > If you're, OTOH, including the TargetName key and > thus establishing session to a specific TPG of a target, > the standard "no duplicate I_T nexus" rule applies - but > again, I don't see the need for multiple discovery > sessions in this case either. >=20 > Finally, I don't think one initiator needs to worry about > the ISIDs of discovery sessions from other initiator network > entities. >=20 > Lakshmi Ramasubramanian wrote: >=20 >=20 >>What is the rule for picking ISIDs for discovery sessions? Since >=20 > there=20 >=20 >>is no target can any ISID be used? Or do we need to be aware of other >=20 >=20 >>discovery sessions and not reuse the ISID ? >> >>thanks! >> -lakshmi >> >=20 >=20 _______________________________________________ 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 exim@www1.ietf.org Sat Feb 21 03:57:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22774 for ; Sat, 21 Feb 2004 03:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuSwJ-0005x1-E4 for ips-archive@odin.ietf.org; Sat, 21 Feb 2004 03:56:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L8ulkb022874 for ips-archive@odin.ietf.org; Sat, 21 Feb 2004 03:56:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuSwI-0005wr-Mk for ips-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 03:56:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22769 for ; Sat, 21 Feb 2004 03:56:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuSwG-0002TE-00 for ips-web-archive@ietf.org; Sat, 21 Feb 2004 03:56:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuSvL-0002PA-00 for ips-web-archive@ietf.org; Sat, 21 Feb 2004 03:55:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuSuf-0002KH-00 for ips-web-archive@ietf.org; Sat, 21 Feb 2004 03:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuSud-0005nn-Uq; Sat, 21 Feb 2004 03:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuSuJ-0005mD-W0 for ips@optimus.ietf.org; Sat, 21 Feb 2004 03:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22685 for ; Sat, 21 Feb 2004 03:54:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuSuH-0002JU-00 for ips@ietf.org; Sat, 21 Feb 2004 03:54:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuStN-0002Fs-00 for ips@ietf.org; Sat, 21 Feb 2004 03:53:45 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx with esmtp (Exim 4.12) id 1AuSsv-0002BA-00 for ips@ietf.org; Sat, 21 Feb 2004 03:53:17 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1L8qfBT087334; Sat, 21 Feb 2004 08:52:41 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1L8qe0I133868; Sat, 21 Feb 2004 08:52:41 GMT In-Reply-To: To: Jane Liu Cc: ips@ietf.org MIME-Version: 1.0 Subject: RE: [Ips] Abort/error handling for task with pending data sequence e X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sat, 21 Feb 2004 10:54:38 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 21/02/2004 10:54:38, Serialize complete at 21/02/2004 10:54:38 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Here you can safely terminate without additional wait since the logout does the cleaning. The logout specification is the only one that includes "quiescing" (no more data). The reasoning behind not requiring "no data after abort" it is that for regular aborts you don't want necessarily to involve initiator pieces that may work in parallel (like a TM arriving at the target on a different connection than a TM). In case of logout you do not have the above issue. So for regular abort you may have to wait for data. If you do also a logout then you don't have to wait. Julo Jane Liu 20/02/2004 03:17 To Julian Satran/Haifa/IBM@IBMIL cc ips@ietf.org Subject RE: [Ips] Abort/error handling for task with pending data sequenc e Please see comments below. >> Hi, >> What should the target do when it gets an Abort Task request for a >> SCSI write command that has an unterminated data sequence? Is it safe >> to assume that the initiator will not send any more data PDUs for the >> task to be aborted? > No it is not safe. The target should send it's response to TM only after > receiving all the data (unsolicited and expected). > The data may be arriving on a different connection than the TM or may be > generate by a different thread at the initiator (there is no guaranteed > sequence). I'm still not very clear on this. What should the target do in the following scenario: ("I->T CID 0" means "initiator to target on connection with CID 0") I->T CID 0: SCSI write command with ITT = X, F-bit = 0 I->T CID 0: Data-Out with ITT = X, F-bit = 1 Connection 0 fails after the initiator sends out the Data-Out but before the target receives it. Connection 0 gets logged out. I->T CID 1: Abort Task TM to abort ITT X Should the target wait for the event [I->T CID 1: Data-Out with ITT = X, F-bit = 1]? It seems that such an event can only occur after a succesful reassignment of the write command to connection 1. Section 10.5.1 of the spec says that the TM will "establish a new allegiance for the command to be aborted as well as abort it" and "the task to be aborted will not have to be retried or reassigned". I'm not exactly sure what these requirements entail in such a scenario. Again, all help appreciated. Jane Liu _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 23 09:03:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25813 for ; Mon, 23 Feb 2004 09:03:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGfL-0002KP-0E for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 09:02:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NE2YXZ008945 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 09:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGfK-0002KC-Qz for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 09:02:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25808 for ; Mon, 23 Feb 2004 09:02:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvGfJ-0004iR-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 09:02:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvGeR-0004du-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 09:01:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvGdv-0004Yd-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 09:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvGdo-0002B6-SF; Mon, 23 Feb 2004 09:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvEjv-0000Ly-1S for ips@optimus.ietf.org; Mon, 23 Feb 2004 06:59:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20856 for ; Mon, 23 Feb 2004 06:59:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvEjq-0003Ry-00 for ips@ietf.org; Mon, 23 Feb 2004 06:59:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvEiu-0003PD-00 for ips@ietf.org; Mon, 23 Feb 2004 06:58:09 -0500 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AvEiF-0003Jq-00 for ips@ietf.org; Mon, 23 Feb 2004 06:57:28 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 23 Feb 2004 23:01:40 +0530 Received: from naveenb-lnx.cisco.com (naveenb-lnx.cisco.com [10.77.7.56]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NBuiWT009500 for ; Mon, 23 Feb 2004 03:56:44 -0800 (PST) Received: from localhost (localhost [[UNIX: localhost]]) by naveenb-lnx.cisco.com (8.11.6/8.11.6) id i1NBuno18224 for ips@ietf.org; Mon, 23 Feb 2004 17:26:49 +0530 From: Naveen Burmi Reply-To: naveenb@cisco.com To: ips@ietf.org Date: Mon, 23 Feb 2004 17:26:48 +0530 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402231726.48821.naveenb@cisco.com> Content-Transfer-Encoding: 7bit Subject: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Need some clarification on the behavior of iSCSI initiator under the following condition: One of the data PDUs received by the target fails to pass Data Digest Check. The target (542x) rejects the Data PDU with reason code Data Digest Error. The target eventually terminates the task with a response PDU with a CHECK CONDITION Status and an iSCSI Condition of "protocol service CRC error". Are we allowed to retry the command within the iSCSI driver? If yes, does the CmdSN, itt need to be the same? Thanks, Naveen. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 23 13:03:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08909 for ; Mon, 23 Feb 2004 13:03:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvKQM-0003Tx-Mf for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 13:03:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NI3MhT013384 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 13:03:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvKQM-0003Tn-IB for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 13:03:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08885 for ; Mon, 23 Feb 2004 13:03:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvKQK-0002go-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 13:03:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvKPS-0002dm-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 13:02:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvKP5-0002aw-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 13:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvKP3-0003L0-UL; Mon, 23 Feb 2004 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvKOO-0003Jr-4q for ips@optimus.ietf.org; Mon, 23 Feb 2004 13:01:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08863 for ; Mon, 23 Feb 2004 13:01:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvKOM-0002Zx-00 for ips@ietf.org; Mon, 23 Feb 2004 13:01:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvKNT-0002XS-00 for ips@ietf.org; Mon, 23 Feb 2004 13:00:24 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AvKNE-0002UP-00 for ips@ietf.org; Mon, 23 Feb 2004 13:00:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? Date: Mon, 23 Feb 2004 09:58:24 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DF9@mail1irv.inside.istor.com> Thread-Topic: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? Thread-Index: AcP6FXbuZMbA+WQoRBKzACn80DrLoAAIMDog From: "Ramesh Mangamuri" To: , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Section 6.2.1 of Spec says that "Retry of Commands MUST NOT be used for reasons other than plugging command sequence gaps." So I believe that you no need to retry the command from iSCSI driver for this case. Is this correct folks? -----Original Message----- From: Naveen Burmi [mailto:naveenb@cisco.com]=20 Sent: Monday, February 23, 2004 3:57 AM To: ips@ietf.org Subject: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? Need some clarification on the behavior of iSCSI initiator under the=20 following condition: One of the data PDUs received by the target fails to pass Data Digest Check.=20 The target (542x) rejects the Data PDU with reason code Data Digest Error.=20 The target eventually terminates the task with a response PDU with a CHECK=20 CONDITION Status and an iSCSI Condition of "protocol service CRC error". Are we allowed to retry the command within the iSCSI driver? If yes, does the CmdSN, itt need to be the same? Thanks, Naveen. _______________________________________________ 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 exim@www1.ietf.org Mon Feb 23 15:44:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19039 for ; Mon, 23 Feb 2004 15:44:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMvX-0000ec-BV for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 15:43:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NKhhpB002514 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 15:43:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMvX-0000eT-1S for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 15:43:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19032 for ; Mon, 23 Feb 2004 15:43:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMvV-00022u-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 15:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMuU-0001xF-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 15:42:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvMtw-0001s5-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 15:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMtu-0000H7-Jq; Mon, 23 Feb 2004 15:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvMtS-0000EU-E5 for ips@optimus.ietf.org; Mon, 23 Feb 2004 15:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18981 for ; Mon, 23 Feb 2004 15:41:31 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvMtR-0001rD-00 for ips@ietf.org; Mon, 23 Feb 2004 15:41:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvMsZ-0001lv-00 for ips@ietf.org; Mon, 23 Feb 2004 15:40:40 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AvMrg-0001a8-00 for ips@ietf.org; Mon, 23 Feb 2004 15:39:44 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKYNBXB2; Mon, 23 Feb 2004 15:39:08 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Feb 2004 15:39:08 -0500 Message-ID: X-Sybari-Trust: 9b83202c 1d8c424f 3fcaf337 0000013d To: ips@ietf.org Subject: RE: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU D igest Error ? Date: Mon, 23 Feb 2004 15:39:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 > Section 6.2.1 of Spec says that "Retry of Commands MUST NOT be used for > reasons other than plugging command sequence gaps." So I believe that > you no need to retry the command from iSCSI driver for this case. Is > this correct folks? That's correct. Because status has been received (CHECK CONDITION), the command has completed from both the initiator and target perspective. The driver is allowed to resubmit the command to the target, but is not required to; the CHECK CONDITION can be reported upward to SCSI if the driver chooses to do so. If the driver resubmits the command, that is a *new* command as far as iSCSI is concerned, so it MUST use a new CmdSN, and it's a good idea (although not required) to use a new Initiator Task Tag. Be careful about repeated resubmissions of this form - there is often higher level SCSI software (e.g., multipathing) that is operating off of a timeout based on failure to receive a response to a command; it would be bad for that software to go into motion to try to get the command accomplished (e.g., via another path) while the driver is trying to do the same thing. 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-admin@ietf.org [mailto:ips-admin@ietf.org] On > Behalf Of Ramesh Mangamuri > Sent: Monday, February 23, 2004 12:58 PM > To: naveenb@cisco.com; ips@ietf.org > Subject: RE: [Ips] Behavior of iSCSI initiator , in case of > Data-Out PDU Digest Error ? > > > Section 6.2.1 of Spec says that "Retry of Commands MUST NOT be used for > reasons other than plugging command sequence gaps." So I believe that > you no need to retry the command from iSCSI driver for this case. Is > this correct folks? > > -----Original Message----- > From: Naveen Burmi [mailto:naveenb@cisco.com] > Sent: Monday, February 23, 2004 3:57 AM > To: ips@ietf.org > Subject: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU > Digest Error ? > > > Need some clarification on the behavior of iSCSI initiator under the > following condition: > > One of the data PDUs received by the target fails to pass Data Digest > Check. > The target (542x) rejects the Data PDU with reason code Data Digest > Error. > The target eventually terminates the task with a response PDU with a > CHECK > CONDITION Status and an iSCSI Condition of "protocol service > CRC error". > > Are we allowed to retry the command within the iSCSI driver? > If yes, does the CmdSN, itt need to be the same? > > Thanks, > Naveen. > > _______________________________________________ > 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 exim@www1.ietf.org Mon Feb 23 16:52:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24157 for ; Mon, 23 Feb 2004 16:52:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNzB-00052Z-Bx for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 16:51:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NLpXCo019371 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 16:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNzB-00052M-6O for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 16:51:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23814 for ; Mon, 23 Feb 2004 16:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNz9-0000Fn-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 16:51:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNyD-00009v-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 16:50:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvNxn-00006F-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 16:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNxi-0004tc-LE; Mon, 23 Feb 2004 16:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNxN-0004sY-A0 for ips@optimus.ietf.org; Mon, 23 Feb 2004 16:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22453 for ; Mon, 23 Feb 2004 16:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNxL-00004l-00 for ips@ietf.org; Mon, 23 Feb 2004 16:49:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNwV-0007n5-00 for ips@ietf.org; Mon, 23 Feb 2004 16:48:48 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AvNvh-0007d3-00 for ips@ietf.org; Mon, 23 Feb 2004 16:47:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Date: Mon, 23 Feb 2004 13:46:14 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DFA@mail1irv.inside.istor.com> Thread-Topic: [Ips] [iSCSI] Usage of ISID in discovery session Thread-Index: AcP4GteVWC1QweAKTU+vE7j7oOQQZAAAR9EgAI6JxiA= From: "Ramesh Mangamuri" To: Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, Can some one please clarify whether the question I have from my previous mail discussion makes sense, or did I miss any portion here? Any clarifications are appreciated. -----Original Message----- From: Ramesh Mangamuri=20 Sent: Friday, February 20, 2004 5:44 PM To: Mallikarjun C.; Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Once the discovery session was closed reuse of that ISID for a Normal session won't be unique. -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 Sent: Friday, February 20, 2004 5:32 PM To: Lakshmi Ramasubramanian Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session No. The uniqueness expectation from the ISID RULE is on the four tuple: InitiatorName-ISID-TargetName-TPGT. This _does not_ include the session type (discovery vs normal). And I view the discovery session as also one that has to play by the ISID RULE. The net is that discovery and normal sessions share the same ISID numbering space. M Lakshmi Ramasubramanian wrote: > Assume there's only one discovery session. >=20 > Is it okay for ISID of a discovery session to be same > as ISID of a non-discovery session from the same initiator? > If so, initiator can assign ISID for discovery sessions > independent of other (Non-Discovery) sessions. Right? >=20 > -lakshmi >=20 > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 > Sent: Friday, February 20, 2004 5:05 PM > To: Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session >=20 > I am not sure I see the need for multiple discovery > sessions from the same initiator to a given iSCSI service > access point unless I'm missing something. >=20 > If you're, OTOH, including the TargetName key and > thus establishing session to a specific TPG of a target, > the standard "no duplicate I_T nexus" rule applies - but > again, I don't see the need for multiple discovery > sessions in this case either. >=20 > Finally, I don't think one initiator needs to worry about > the ISIDs of discovery sessions from other initiator network > entities. >=20 > Lakshmi Ramasubramanian wrote: >=20 >=20 >>What is the rule for picking ISIDs for discovery sessions? Since >=20 > there=20 >=20 >>is no target can any ISID be used? Or do we need to be aware of other >=20 >=20 >>discovery sessions and not reuse the ISID ? >> >>thanks! >> -lakshmi >> >=20 >=20 _______________________________________________ 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 exim@www1.ietf.org Mon Feb 23 19:50:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05459 for ; Mon, 23 Feb 2004 19:50:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQlV-0006Ya-Pz for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 19:49:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O0nbvp025200 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 19:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQlV-0006YN-Li for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 19:49:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05446 for ; Mon, 23 Feb 2004 19:49:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQlU-0001Zm-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 19:49:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQkZ-0001Vk-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 19:48:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvQk0-0001Rr-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 19:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQjx-0006R9-JD; Mon, 23 Feb 2004 19:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvQjZ-0006Q0-74 for ips@optimus.ietf.org; Mon, 23 Feb 2004 19:47:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05395 for ; Mon, 23 Feb 2004 19:47:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvQjX-0001Qi-00 for ips@ietf.org; Mon, 23 Feb 2004 19:47:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvQif-0001N1-00 for ips@ietf.org; Mon, 23 Feb 2004 19:46:42 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1AvQhv-0001Iq-00 for ips@ietf.org; Mon, 23 Feb 2004 19:45:55 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id 8E0DD1C0216C for ; Mon, 23 Feb 2004 16:45:50 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id AC57A8068 for ; Mon, 23 Feb 2004 16:39:22 -0800 (PST) Message-ID: <403A9E99.6080703@rose.hp.com> Date: Mon, 23 Feb 2004 16:45:13 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session References: <7D036BD3216A084DB1BD9D62BCEAF290570DFA@mail1irv.inside.istor.com> In-Reply-To: <7D036BD3216A084DB1BD9D62BCEAF290570DFA@mail1irv.inside.istor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ramesh, Can you please restate your question? I am not sure I see the question. As I responded below, at any given point of time, all discovery/normal sessions share the same ISID space for a given InitiatorName-TargetName-TPG combination. I am not sure however if that answers your question. Mallikarjun Ramesh Mangamuri wrote: > Folks, > Can some one please clarify whether the question I have from my previous > mail discussion makes sense, or did I miss any portion here? > > Any clarifications are appreciated. > > -----Original Message----- > From: Ramesh Mangamuri > Sent: Friday, February 20, 2004 5:44 PM > To: Mallikarjun C.; Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session > > Once the discovery session was closed reuse of that ISID for a Normal > session won't be unique. > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, February 20, 2004 5:32 PM > To: Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session > > No. > > The uniqueness expectation from the ISID RULE is on the > four tuple: InitiatorName-ISID-TargetName-TPGT. > > This _does not_ include the session type (discovery vs > normal). And I view the discovery session as also one > that has to play by the ISID RULE. > > The net is that discovery and normal sessions share > the same ISID numbering space. > > > M > > > Lakshmi Ramasubramanian wrote: > > >>Assume there's only one discovery session. >> >>Is it okay for ISID of a discovery session to be same >>as ISID of a non-discovery session from the same initiator? >>If so, initiator can assign ISID for discovery sessions >>independent of other (Non-Discovery) sessions. Right? >> >> -lakshmi >> >>-----Original Message----- >>From: Mallikarjun C. [mailto:cbm@rose.hp.com] >>Sent: Friday, February 20, 2004 5:05 PM >>To: Lakshmi Ramasubramanian >>Cc: ips@ietf.org >>Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session >> >>I am not sure I see the need for multiple discovery >>sessions from the same initiator to a given iSCSI service >>access point unless I'm missing something. >> >>If you're, OTOH, including the TargetName key and >>thus establishing session to a specific TPG of a target, >>the standard "no duplicate I_T nexus" rule applies - but >>again, I don't see the need for multiple discovery >>sessions in this case either. >> >>Finally, I don't think one initiator needs to worry about >>the ISIDs of discovery sessions from other initiator network >>entities. >> >>Lakshmi Ramasubramanian wrote: >> >> >> >>>What is the rule for picking ISIDs for discovery sessions? Since >> >>there >> >> >>>is no target can any ISID be used? Or do we need to be aware of other >> >> >>>discovery sessions and not reuse the ISID ? >>> >>>thanks! >>>-lakshmi >>> >> _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Feb 23 21:21:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08160 for ; Mon, 23 Feb 2004 21:21:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSBb-0002D7-JH for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 21:20:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O2KdfM008491 for ips-archive@odin.ietf.org; Mon, 23 Feb 2004 21:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSBb-0002Cs-AK for ips-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 21:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08155 for ; Mon, 23 Feb 2004 21:20:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSBY-0000Xn-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 21:20:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSAa-0000UR-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 21:19:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvSA3-0000RH-00 for ips-web-archive@ietf.org; Mon, 23 Feb 2004 21:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSA1-00023c-Hd; Mon, 23 Feb 2004 21:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvS9d-00023D-5M for ips@optimus.ietf.org; Mon, 23 Feb 2004 21:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08119 for ; Mon, 23 Feb 2004 21:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvS9a-0000Qq-00 for ips@ietf.org; Mon, 23 Feb 2004 21:18:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvS8f-0000Nh-00 for ips@ietf.org; Mon, 23 Feb 2004 21:17:38 -0500 Received: from host28.istor.com ([66.134.214.28] helo=mail1irv.inside.istor.com) by ietf-mx with esmtp (Exim 4.12) id 1AvS7n-0000Gl-00 for ips@ietf.org; Mon, 23 Feb 2004 21:16:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session Date: Mon, 23 Feb 2004 18:14:54 -0800 Message-ID: <7D036BD3216A084DB1BD9D62BCEAF290570DFB@mail1irv.inside.istor.com> Thread-Topic: [Ips] [iSCSI] Usage of ISID in discovery session Thread-Index: AcP6b79qK+f+xWjjSUicRCztPw9G2wAC+udQ From: "Ramesh Mangamuri" To: "Mallikarjun C." , Content-Transfer-Encoding: quoted-printable Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mallikarjun, Your explanation did answer my question. I'm sorry that I missed the portion that ISID is shared by all sessions. Thanks for explaining again this point. -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 Sent: Monday, February 23, 2004 4:45 PM To: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session Ramesh, Can you please restate your question? I am not sure I see the question. As I responded below, at any given point of time, all discovery/normal sessions share the same ISID space for a given InitiatorName-TargetName-TPG combination. I am not sure however if that answers your question. Mallikarjun Ramesh Mangamuri wrote: > Folks, > Can some one please clarify whether the question I have from my previous > mail discussion makes sense, or did I miss any portion here? >=20 > Any clarifications are appreciated. >=20 > -----Original Message----- > From: Ramesh Mangamuri=20 > Sent: Friday, February 20, 2004 5:44 PM > To: Mallikarjun C.; Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: RE: [Ips] [iSCSI] Usage of ISID in discovery session >=20 > Once the discovery session was closed reuse of that ISID for a Normal > session won't be unique. >=20 > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 > Sent: Friday, February 20, 2004 5:32 PM > To: Lakshmi Ramasubramanian > Cc: ips@ietf.org > Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session >=20 > No. >=20 > The uniqueness expectation from the ISID RULE is on the > four tuple: InitiatorName-ISID-TargetName-TPGT. >=20 > This _does not_ include the session type (discovery vs > normal). And I view the discovery session as also one > that has to play by the ISID RULE. >=20 > The net is that discovery and normal sessions share > the same ISID numbering space. >=20 >=20 > M >=20 >=20 > Lakshmi Ramasubramanian wrote: >=20 >=20 >>Assume there's only one discovery session. >> >>Is it okay for ISID of a discovery session to be same >>as ISID of a non-discovery session from the same initiator? >>If so, initiator can assign ISID for discovery sessions >>independent of other (Non-Discovery) sessions. Right? >> >> -lakshmi >> >>-----Original Message----- >>From: Mallikarjun C. [mailto:cbm@rose.hp.com]=20 >>Sent: Friday, February 20, 2004 5:05 PM >>To: Lakshmi Ramasubramanian >>Cc: ips@ietf.org >>Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session >> >>I am not sure I see the need for multiple discovery >>sessions from the same initiator to a given iSCSI service >>access point unless I'm missing something. >> >>If you're, OTOH, including the TargetName key and >>thus establishing session to a specific TPG of a target, >>the standard "no duplicate I_T nexus" rule applies - but >>again, I don't see the need for multiple discovery >>sessions in this case either. >> >>Finally, I don't think one initiator needs to worry about >>the ISIDs of discovery sessions from other initiator network >>entities. >> >>Lakshmi Ramasubramanian wrote: >> >> >> >>>What is the rule for picking ISIDs for discovery sessions? Since >> >>there=20 >> >> >>>is no target can any ISID be used? Or do we need to be aware of other >> >> >>>discovery sessions and not reuse the ISID ? >>> >>>thanks! >>>-lakshmi >>> >> _______________________________________________ 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 exim@www1.ietf.org Tue Feb 24 18:26:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16846 for ; Tue, 24 Feb 2004 18:26:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvlwR-0007oq-6c for ips-archive@odin.ietf.org; Tue, 24 Feb 2004 18:26:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ONQJKi030050 for ips-archive@odin.ietf.org; Tue, 24 Feb 2004 18:26:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvlwQ-0007ob-HD for ips-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 18:26:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16843 for ; Tue, 24 Feb 2004 18:26:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlwN-0006KL-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 18:26:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlvP-0006Fk-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 18:25:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvluT-0006Ap-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 18:24:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvluD-0007dQ-00; Tue, 24 Feb 2004 18:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvltW-0007aR-3k for ips@optimus.ietf.org; Tue, 24 Feb 2004 18:23:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16756 for ; Tue, 24 Feb 2004 18:23:14 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvltT-00065e-00 for ips@ietf.org; Tue, 24 Feb 2004 18:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlsW-00061Q-00 for ips@ietf.org; Tue, 24 Feb 2004 18:22:16 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AvlrZ-0005xx-00 for ips@ietf.org; Tue, 24 Feb 2004 18:21:17 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 7864340137; Tue, 24 Feb 2004 18:21:16 -0500 (EST) Date: Tue, 24 Feb 2004 15:20:43 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: Lakshmi Ramasubramanian , ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session In-Reply-To: <4036B51A.9030208@rose.hp.com> Message-ID: References: <4036B51A.9030208@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 On Fri, 20 Feb 2004, Mallikarjun C. wrote: > No. > > The uniqueness expectation from the ISID RULE is on the > four tuple: InitiatorName-ISID-TargetName-TPGT. > > This _does not_ include the session type (discovery vs > normal). And I view the discovery session as also one > that has to play by the ISID RULE. > > The net is that discovery and normal sessions share > the same ISID numbering space. The one question I have is where in this do TargetName-less discovery sessions fit in the ISID numbering space? Do we treat them as having a TargetName=""? That would have the consequence of keeping the ISID-rule code simple, as it always applies. It would preclude the potential of the same initiator/ISID having two discovery sessions w/o TargetName open at once, but I don't forsee that as a concern. The initiator can always choose a second ISID if it needs two at once.. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Feb 24 20:30:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21101 for ; Tue, 24 Feb 2004 20:30:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avnsb-0006qW-JS for ips-archive@odin.ietf.org; Tue, 24 Feb 2004 20:30:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P1UTcC026313 for ips-archive@odin.ietf.org; Tue, 24 Feb 2004 20:30:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avnsb-0006qJ-EW for ips-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 20:30:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21098 for ; Tue, 24 Feb 2004 20:30:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnsZ-00012V-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 20:30:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avnrg-0000xy-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 20:29:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvnrE-0000sc-00 for ips-web-archive@ietf.org; Tue, 24 Feb 2004 20:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnrA-0006gd-TF; Tue, 24 Feb 2004 20:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avnqd-0006fe-KS for ips@optimus.ietf.org; Tue, 24 Feb 2004 20:28:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20990 for ; Tue, 24 Feb 2004 20:28:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avnqb-0000qh-00 for ips@ietf.org; Tue, 24 Feb 2004 20:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avnpg-0000l4-00 for ips@ietf.org; Tue, 24 Feb 2004 20:27:28 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1Avnoq-0000g6-00 for ips@ietf.org; Tue, 24 Feb 2004 20:26:36 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel13.hp.com (Postfix) with ESMTP id 7A0481C0131A for ; Tue, 24 Feb 2004 17:26:21 -0800 (PST) Received: from rose.hp.com (dhcp-roseor-bdj055.rose.hp.com [15.23.139.55]) by rosemail.rose.hp.com (Postfix) with ESMTP id 0E5658390 for ; Tue, 24 Feb 2004 17:18:44 -0800 (PST) Message-ID: <403BF957.7040202@rose.hp.com> Date: Tue, 24 Feb 2004 17:24:39 -0800 From: "Mallikarjun C." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session References: <4036B51A.9030208@rose.hp.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >It would preclude the potential of the > same initiator/ISID having two discovery sessions w/o TargetName open at > once, but I don't forsee that as a concern. Back at the beginning of this thread, I said: "I am not sure I see the need for multiple discovery sessions from the same initiator to a given iSCSI service access point" I still don't see the need. And yes, I'd recommend using a different ISID for each discovery session established to the same iSCSI service access point (if you really see the need to use multiple sessions). -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm [at] rose.hp.com wrstuden@wasabisystems.com wrote: > On Fri, 20 Feb 2004, Mallikarjun C. wrote: > > >>No. >> >>The uniqueness expectation from the ISID RULE is on the >>four tuple: InitiatorName-ISID-TargetName-TPGT. >> >>This _does not_ include the session type (discovery vs >>normal). And I view the discovery session as also one >>that has to play by the ISID RULE. >> >>The net is that discovery and normal sessions share >>the same ISID numbering space. > > > The one question I have is where in this do TargetName-less discovery > sessions fit in the ISID numbering space? Do we treat them as having a > TargetName=""? That would have the consequence of keeping the ISID-rule > code simple, as it always applies. It would preclude the potential of the > same initiator/ISID having two discovery sessions w/o TargetName open at > once, but I don't forsee that as a concern. The initiator can always > choose a second ISID if it needs two at once.. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Feb 25 04:29:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05681 for ; Wed, 25 Feb 2004 04:29:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvLG-00056T-Q6 for ips-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P9SYbg019616 for ips-archive@odin.ietf.org; Wed, 25 Feb 2004 04:28:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvLG-00056H-E6 for ips-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 04:28:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05516 for ; Wed, 25 Feb 2004 04:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvvLD-0006Hb-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 04:28:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvvJO-0005u8-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 04:26:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvvHS-0005Q7-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 04:24:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvvHL-00043R-HD; Wed, 25 Feb 2004 04:24:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avv3H-00035L-KK for ips@optimus.ietf.org; Wed, 25 Feb 2004 04:09:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04134 for ; Wed, 25 Feb 2004 04:09:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avv3E-0003QK-01 for ips@ietf.org; Wed, 25 Feb 2004 04:09:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvutA-0002P0-00 for ips@ietf.org; Wed, 25 Feb 2004 03:59:33 -0500 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx with esmtp (Exim 4.12) id 1AvusH-0002F6-00; Wed, 25 Feb 2004 03:58:37 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i1P8w7WH041570; Wed, 25 Feb 2004 08:58:07 GMT Received: from d12ml102.megacenter.de.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1P8w6Ep292988; Wed, 25 Feb 2004 08:58:06 GMT In-Reply-To: <200402231726.48821.naveenb@cisco.com> To: naveenb@cisco.com Cc: ips@ietf.org, ips-admin@ietf.org MIME-Version: 1.0 Subject: Re: [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Wed, 25 Feb 2004 11:00:06 +0200 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 6.0.2CF2|July 23, 2003) at 25/02/2004 11:00:08, Serialize complete at 25/02/2004 11:00:08 Content-Type: text/plain; charset="US-ASCII" Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 If the task is terminated at the target by SCSI with a check condition you are supposed to pass this condition to the SCSI layer at the initiator and no retry the command. The target may ask the data again through a recovery R2T and terminate without error. There is little else you can do - except if the initiator has not yet finished the offending sequence when seeing the reject - in which case if data in-sequence can be out-of-order and the recovery level is right you may resend the offending PDU (it may confuse some targets !). Julo Naveen Burmi Sent by: ips-admin@ietf.org 23/02/2004 13:56 Please respond to naveenb To ips@ietf.org cc Subject [Ips] Behavior of iSCSI initiator , in case of Data-Out PDU Digest Error ? Need some clarification on the behavior of iSCSI initiator under the following condition: One of the data PDUs received by the target fails to pass Data Digest Check. The target (542x) rejects the Data PDU with reason code Data Digest Error. The target eventually terminates the task with a response PDU with a CHECK CONDITION Status and an iSCSI Condition of "protocol service CRC error". Are we allowed to retry the command within the iSCSI driver? If yes, does the CmdSN, itt need to be the same? Thanks, Naveen. _______________________________________________ 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 exim@www1.ietf.org Wed Feb 25 15:05:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09273 for ; Wed, 25 Feb 2004 15:05:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5HG-0006ft-FJ for ips-archive@odin.ietf.org; Wed, 25 Feb 2004 15:05:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PK55aM025532 for ips-archive@odin.ietf.org; Wed, 25 Feb 2004 15:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5HD-0006cu-SI for ips-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:05:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09201 for ; Wed, 25 Feb 2004 15:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5HB-0004YS-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 15:05:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5GD-0004Sl-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 15:04:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5FL-0004Nr-00 for ips-web-archive@ietf.org; Wed, 25 Feb 2004 15:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5FG-0004cM-62; Wed, 25 Feb 2004 15:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5Eb-0003qj-AJ for ips@optimus.ietf.org; Wed, 25 Feb 2004 15:02:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09061 for ; Wed, 25 Feb 2004 15:02:17 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5EY-0004I1-00 for ips@ietf.org; Wed, 25 Feb 2004 15:02:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5Dv-0004B1-00 for ips@ietf.org; Wed, 25 Feb 2004 15:01:39 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5Ct-000415-00 for ips@ietf.org; Wed, 25 Feb 2004 15:00:35 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 081434015E; Wed, 25 Feb 2004 15:00:30 -0500 (EST) Date: Wed, 25 Feb 2004 11:59:55 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: "Mallikarjun C." Cc: ips@ietf.org Subject: Re: [Ips] [iSCSI] Usage of ISID in discovery session In-Reply-To: <403BF957.7040202@rose.hp.com> Message-ID: References: <4036B51A.9030208@rose.hp.com> <403BF957.7040202@rose.hp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 On Tue, 24 Feb 2004, Mallikarjun C. wrote: > >It would preclude the potential of the > > same initiator/ISID having two discovery sessions w/o TargetName open at > > once, but I don't forsee that as a concern. > > Back at the beginning of this thread, I said: > > "I am not sure I see the need for multiple discovery > sessions from the same initiator to a given iSCSI service > access point" > > I still don't see the need. I understand _you_ don't see the need. _I_ also agree with you. :-) The question was more to see if anyone else in the working group disagreed. More to the point, I'd like to say that the target doesn't have to support it. :-) Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Feb 26 10:33:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19977 for ; Thu, 26 Feb 2004 10:33:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNVO-0005YW-Rc for ips-archive@odin.ietf.org; Thu, 26 Feb 2004 10:32:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QFWsRZ021350 for ips-archive@odin.ietf.org; Thu, 26 Feb 2004 10:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNVO-0005YH-KN for ips-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 10:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19922 for ; Thu, 26 Feb 2004 10:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNVM-0006t7-00 for ips-web-archive@ietf.org; Thu, 26 Feb 2004 10:32:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNUS-0006kv-00 for ips-web-archive@ietf.org; Thu, 26 Feb 2004 10:31:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwNTk-0006dE-00 for ips-web-archive@ietf.org; Thu, 26 Feb 2004 10:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNTa-0005Ov-Q3; Thu, 26 Feb 2004 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwNTK-0005NI-F6 for ips@optimus.ietf.org; Thu, 26 Feb 2004 10:30:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19786 for ; Thu, 26 Feb 2004 10:30:42 -0500 (EST) From: AClarke@attotech.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwNTI-0006bJ-00 for ips@ietf.org; Thu, 26 Feb 2004 10:30:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwNSN-0006Vk-00 for ips@ietf.org; Thu, 26 Feb 2004 10:29:47 -0500 Received: from noteserv1.attotech.com ([12.32.232.51]) by ietf-mx with esmtp (Exim 4.12) id 1AwNS2-0006QD-00 for ips@ietf.org; Thu, 26 Feb 2004 10:29:27 -0500 To: ips@ietf.org Message-ID: Date: Thu, 26 Feb 2004 10:29:16 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Ips] Current support for error recovery levels 1 and 2 Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 I would be interested in knowing if any iSCSI initiators support or plan on supporting error recovery levels 1and 2 in the near future. This information would be very useful to us in testing and development of our iSCSI target. Please respond to my e-mail address. Also, could anyone tell me if they have seen error recovery in the field? If so, how often and what type? Thanks, Aaron Clarke Systems Engineer ATTO Technology, Inc. 155 Crosspoint Pkwy., Amherst, NY 14068 (716) 691-1999 x107 aclarke@attotech.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Feb 28 13:50:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27631 for ; Sat, 28 Feb 2004 13:50:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax9Wq-0002s8-4y for ips-archive@odin.ietf.org; Sat, 28 Feb 2004 13:49:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1SInaq2011034 for ips-archive@odin.ietf.org; Sat, 28 Feb 2004 13:49:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax9Wp-0002rt-NK for ips-web-archive@optimus.ietf.org; Sat, 28 Feb 2004 13:49:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27622 for ; Sat, 28 Feb 2004 13:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ax9Wn-0001dB-00 for ips-web-archive@ietf.org; Sat, 28 Feb 2004 13:49:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ax9Vp-0001W4-00 for ips-web-archive@ietf.org; Sat, 28 Feb 2004 13:48:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ax9VQ-0001Od-00 for ips-web-archive@ietf.org; Sat, 28 Feb 2004 13:48:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ax9VM-0002jB-Rc; Sat, 28 Feb 2004 13:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwhC3-0006U8-I0 for ips@optimus.ietf.org; Fri, 27 Feb 2004 07:34:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28073 for ; Fri, 27 Feb 2004 07:34:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwhC2-00065O-00 for ips@ietf.org; Fri, 27 Feb 2004 07:34:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwhB4-0005zu-00 for ips@ietf.org; Fri, 27 Feb 2004 07:33:15 -0500 Received: from pfepa.post.tele.dk ([195.41.46.235]) by ietf-mx with esmtp (Exim 4.12) id 1AwhA9-0005v0-00 for ips@ietf.org; Fri, 27 Feb 2004 07:32:17 -0500 Received: from pepdev (unknown [62.243.7.41]) by pfepa.post.tele.dk (Postfix) with ESMTP id 6575F47FE9B for ; Fri, 27 Feb 2004 13:32:08 +0100 (CET) Reply-To: From: "Peter Pedersen" To: Date: Fri, 27 Feb 2004 13:32:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C3FD36.1D1395F0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcP9LbcGmUgGmEm8RiySY43Do4GR9Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Message-Id: <20040227123208.6575F47FE9B@pfepa.post.tele.dk> Subject: [Ips] boot Windows 2000/2003 from iSCSI Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_70_80,HTML_MESSAGE, MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C3FD36.1D1395F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We want to use diskless Windows 200/2003 servers booting directly from a iSCSI target. 1. is this supported by standard NIC using PXE and a bootstrap program with iSCSI initiator? 2. is there any of the iSCSI HBAs there support this by hooking int. 13? 3. other information on this subject Thanks in advance Peter Pedersen SDC Udvikling A/S Borupvang 1A 2750 Ballerup Denmark ------=_NextPart_000_0004_01C3FD36.1D1395F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We want to use diskless Windows 200/2003 servers = booting directly from a iSCSI target.

 

  1. is this supported by = standard NIC using PXE and a bootstrap program with iSCSI = initiator?
  2. is there any of the = iSCSI HBAs there support this by hooking int. = 13?
  3. other information on = this subject

 

Thanks in advance

 

Peter Pedersen

SDC Udvikling A/S

Borupvang 1A

2750 Ballerup

Denmark

 

------=_NextPart_000_0004_01C3FD36.1D1395F0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Feb 29 21:18:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24319 for ; Sun, 29 Feb 2004 21:18:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd02-0004TO-4f for ips-archive@odin.ietf.org; Sun, 29 Feb 2004 21:17:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i212Hgbl017188 for ips-archive@odin.ietf.org; Sun, 29 Feb 2004 21:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axd01-0004T9-VQ for ips-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 21:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24312 for ; Sun, 29 Feb 2004 21:17:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axczz-0006XQ-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 21:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcyv-0006PZ-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 21:16:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxcyR-0006It-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 21:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcyQ-000494-94; Sun, 29 Feb 2004 21:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axcxk-00046z-BA for ips@optimus.ietf.org; Sun, 29 Feb 2004 21:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24203 for ; Sun, 29 Feb 2004 21:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axcxh-0006HW-00 for ips@ietf.org; Sun, 29 Feb 2004 21:15:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axcwm-0006Cz-00 for ips@ietf.org; Sun, 29 Feb 2004 21:14:20 -0500 Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf-mx with smtp (Exim 4.12) id 1Axcw4-00062v-00 for ips@ietf.org; Sun, 29 Feb 2004 21:13:36 -0500 Received: (qmail 15264 invoked from network); 1 Mar 2004 02:00:25 -0000 Received: from unknown (HELO sunzenxp) (159.226.39.251) by mail.ict.ac.cn with SMTP; 1 Mar 2004 02:00:25 -0000 Date: Mon, 1 Mar 2004 10:19:33 +0800 From: "sunzen.w" To: "ips@ietf.org" X-mailer: Foxmail 4.1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Subject: [Ips] is a share disk possible on SCSI/iSCSI level? Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Storaging networking enables storage consolodation and deployment.Typically disk array serves as a storage server, its storage is parted and exported via storage networking protocols such as iSCSI,etc. Share problem arises. Current solutions are mainly on upper file level, either additionally deploying a NAS or using a SAN file system. Is it possible on SCSI/iSCSI level? In iSCSI spec, multi session on a target are allowed. is it for sharing? On SCSI, OSD commands are designed.Is it the way for sharing on disk level? sunzen wangxz@ict.ac.cn 2004-03-01 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Feb 29 22:10:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27392 for ; Sun, 29 Feb 2004 22:10:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdp2-0000eY-2B for ips-archive@odin.ietf.org; Sun, 29 Feb 2004 22:10:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i213AOPk002504 for ips-archive@odin.ietf.org; Sun, 29 Feb 2004 22:10:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdp1-0000eJ-Te for ips-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 22:10:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27344 for ; Sun, 29 Feb 2004 22:10:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axdoy-0004TJ-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 22:10:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axdnz-0004MT-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 22:09:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axdnh-0004IG-00 for ips-web-archive@ietf.org; Sun, 29 Feb 2004 22:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdni-0000Qh-FT; Sun, 29 Feb 2004 22:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axdn6-0000PM-33 for ips@optimus.ietf.org; Sun, 29 Feb 2004 22:08:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27286 for ; Sun, 29 Feb 2004 22:08:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axdn2-0004HW-00 for ips@ietf.org; Sun, 29 Feb 2004 22:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axdm7-0004Cv-00 for ips@ietf.org; Sun, 29 Feb 2004 22:07:23 -0500 Received: from cs.haifa.ac.il ([132.74.120.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxdlV-00047Y-00 for ips@ietf.org; Sun, 29 Feb 2004 22:06:45 -0500 Received: from haifasphere.co.il (unknown [203.234.206.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cs.haifa.ac.il (Postfix) with ESMTP id 4DCEB17C05; Mon, 1 Mar 2004 05:06:35 +0200 (IST) Message-ID: <4042A8B6.5030409@haifasphere.co.il> Date: Mon, 01 Mar 2004 05:06:30 +0200 From: Julian Satran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sunzen.w" Cc: "ips@ietf.org" Subject: Re: [Ips] is a share disk possible on SCSI/iSCSI level? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ips-admin@ietf.org Errors-To: ips-admin@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Storage List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit iSCSI does nothing for sharing beyond what SCSI does. SCSI for block devices does nothing - except the "reserve-release" Sharing has to be managed at higher level. However the OSD command set is a bit richer and allows checking credentials for accessing data. Allocation in OSD is also managed by the device and that somewhat simplifies sharing. However data access coordination (locks,RW exclusion etc.) still has to be managed by some upper level entity like a file system Julo sunzen.w wrote: > Hi, > Storaging networking enables storage consolodation and deployment.Typically disk array > serves as a storage server, its storage is parted and exported via storage networking protocols > such as iSCSI,etc. Share problem arises. Current solutions are mainly on upper file level, either > additionally deploying a NAS or using a SAN file system. Is it possible on SCSI/iSCSI level? > In iSCSI spec, multi session on a target are allowed. is it for sharing? On SCSI, OSD commands > are designed.Is it the way for sharing on disk level? > > > sunzen > wangxz@ict.ac.cn > 2004-03-01 > > > > _______________________________________________ > 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