From exim@www1.ietf.org Mon Dec 1 18:05:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09042 for ; Mon, 1 Dec 2003 18:05:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx6L-0001pS-8C for ips-archive@odin.ietf.org; Mon, 01 Dec 2003 18:05:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1N59tv007026 for ips-archive@odin.ietf.org; Mon, 1 Dec 2003 18:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx6L-0001pF-4G for ips-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 18:05: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 SAA08944 for ; Mon, 1 Dec 2003 18:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx6I-0004la-00 for ips-web-archive@ietf.org; Mon, 01 Dec 2003 18:05:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQx6H-0004lW-00 for ips-web-archive@ietf.org; Mon, 01 Dec 2003 18:05:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx6D-0001oL-ED; Mon, 01 Dec 2003 18:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQx5S-0001mp-12 for ips@optimus.ietf.org; Mon, 01 Dec 2003 18: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 SAA08831 for ; Mon, 1 Dec 2003 18:03:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQx5P-0004kk-00 for ips@ietf.org; Mon, 01 Dec 2003 18:04:11 -0500 Received: from zippy.cmc.optus.net.au ([61.88.176.193]) by ietf-mx with esmtp (Exim 4.12) id 1AQx5O-0004kY-00 for ips@ietf.org; Mon, 01 Dec 2003 18:04:10 -0500 Received: (from smtpd@localhost) by zippy.cmc.optus.net.au (8.11.6+Sun/8.11.6) id hB1N3bd01734 for ; Tue, 2 Dec 2003 10:03:37 +1100 (EST) Received: from UNKNOWN(172.25.19.159), claiming to be "CMCEXCH01.cmchelpdesk.local" via SMTP by zippy.cmc.optus.net.au, id smtpdAAAfnaaxd; Tue Dec 2 10:03:29 2003 Received: by CMCEXCH01.cmchelpdesk.local with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Dec 2003 10:02:34 +1100 Message-ID: <16D5B53687C22A47ACFFC2043DE594B31D1D06@CMCEXCH01.cmchelpdesk.local> From: Andy Plant To: ips@ietf.org Date: Tue, 2 Dec 2003 10:02:33 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Ips] iSCSI Service Assurance 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: , I've been "volunteered" to investigate providing service assurance for iSCSI, has anyone found any tool sets for monitoring the status of connections between host and storage (or at least the fibre switches) and in particular diagnosing that the problem is in the host (with drivers etc) when the remote storage becomes unavailable?? Obviously the base IP connectivity is relatively straight forward but it is the higher level interactions that concern me. Rgds _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Dec 5 17:23:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29803 for ; Fri, 5 Dec 2003 17:23: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 1ASOLz-0000sT-Bw for ips-archive@odin.ietf.org; Fri, 05 Dec 2003 17:23:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5MNFeJ003369 for ips-archive@odin.ietf.org; Fri, 5 Dec 2003 17:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASOLz-0000sG-2e for ips-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 17:23: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 RAA29760 for ; Fri, 5 Dec 2003 17:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASOLw-0003Bs-00 for ips-web-archive@ietf.org; Fri, 05 Dec 2003 17:23:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASOLw-0003Bo-00 for ips-web-archive@ietf.org; Fri, 05 Dec 2003 17:23:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASOLl-0000nk-J3; Fri, 05 Dec 2003 17: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 1ASLbN-0001GG-W0 for ips@optimus.ietf.org; Fri, 05 Dec 2003 14:26:58 -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 OAA19598 for ; Fri, 5 Dec 2003 14:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASLbL-0000PZ-00 for ips@ietf.org; Fri, 05 Dec 2003 14:26:55 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1ASLbK-0000Op-00 for ips@ietf.org; Fri, 05 Dec 2003 14:26:54 -0500 Received: from hawk.corp.netapp.com (hawk [10.10.20.101]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id hB5JQNRG010231 for ; Fri, 5 Dec 2003 11:26:23 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by hawk.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id hB5JQNwf003009 for ; Fri, 5 Dec 2003 11:26:23 -0800 (PST) Received: from rtpexc03.hq.netapp.com ([10.60.4.50]) by svlexc01.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 5 Dec 2003 11:26:23 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BB65.AA53A639" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 5 Dec 2003 14:26:22 -0500 Message-ID: <3A62517F5A8AFE4098ADDBD25B5D4D5C015B39@rtpexc03.hq.netapp.com> Thread-Topic: Question about ABORT_TASK and unsolicited DATA_OUT stream Thread-Index: AcO7ZapY4B3VH7/nQ1y3xBqsxkrJfA== From: "Pittman, Joseph" To: Cc: "Jin, Tao" X-OriginalArrivalTime: 05 Dec 2003 19:26:23.0009 (UTC) FILETIME=[AAEA7910:01C3BB65] Subject: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream 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: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BB65.AA53A639 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question about the interaction between ABORT_TASK (or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited DATA_OUTs. =20 Suppose the target and initiator have negotiated InitialR2T=3Dno ImmediateData=3Dno FirstBurstLength=3D64KB =20 and the initiator sends the following PDUs: =20 SCSI_CMD/WRITE 128KB/F=3D0 DATA_OUT/16KB/F=3D0 DATA_OUT/16KB/F=3D0 ABORT_TASK =20 When the target receives the abort task, should it expect the initiator to send the remaining 32KB of the expected 64KB burst of unsolicited data? =20 Or does the initiator's sending of the ABORT_TASK imply that it will not be sending any more data? =20 I looked through the iSCSI specification for an answer, and found only this text which seems to relate to this topic: =20 3.2.4.2 Data Transfer Overview ... An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength, or all of the data if the total amount is less than the FirstBurstLength. =20 This says the initiator must send the full burst. But somehow, I don't think this section is really talking about the 'ABORT during burst' case. Is there any text, either in the iSCSI spec or the SCSI-3 specifications, which would provide an authoritative statement on this? If not, would any of the authors care to give some guidance? =20 Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com =20 ------_=_NextPart_001_01C3BB65.AA53A639 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I have a=20 question about the interaction between ABORT_TASK
(or=20 ABORT_TASK or CLEAR_TASK_SET) and a burst of = unsolicited
DATA_OUTs.
 
Suppose the=20 target and initiator have negotiated
 =20 InitialR2T=3Dno
 =20 ImmediateData=3Dno
  FirstBurstLength=3D64KB
 =20
and=20 the initiator sends the following PDUs:
 
 =20 SCSI_CMD/WRITE 128KB/F=3D0
 =20 DATA_OUT/16KB/F=3D0
  DATA_OUT/16KB/F=3D0
 =20 ABORT_TASK
 
When the=20 target receives the abort task, should it expect
the=20 initiator to send the remaining 32KB of the expected
64KB burst=20 of unsolicited data?
 
Or=20 does the initiator's sending of the ABORT_TASK = imply
that=20 it will not be sending any more data?
 
I=20 looked through the iSCSI specification for an answer,=20 and
found=20 only this text which seems to relate to this=20 topic:
 
 =20 3.2.4.2 Data Transfer Overview
  ...
  An iSCSI initiator MAY choose not = to send=20 unsolicited data, only
  immediate data or FirstBurstLength = bytes=20 of unsolicited data with a
  command. If any non-immediate = unsolicited=20 data is sent, the total
  unsolicited data MUST be either=20 FirstBurstLength, or all of the data
  if the total amount is = less than=20 the FirstBurstLength.
 
This=20 says the initiator must send the full burst.  But=20 somehow,
I=20 don't think this section is really talking about the=20 'ABORT
during=20 burst' case.
Is there any text, either in = the iSCSI=20 spec or the SCSI-3
specifications, which would provide an=20 authoritative statement
on=20 this?  If not, would any of the authors care to give=20 some
guidance?
 
Thanks in advance for any=20 help.
--
Joe=20 Pittman
jpittman@netapp.com=
 
=00 ------_=_NextPart_001_01C3BB65.AA53A639-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Dec 6 12:37:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14413 for ; Sat, 6 Dec 2003 12:37:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASgMj-0000TQ-Nj for ips-archive@odin.ietf.org; Sat, 06 Dec 2003 12:37:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB6HbDtX001806 for ips-archive@odin.ietf.org; Sat, 6 Dec 2003 12:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASgMh-0000SG-F2 for ips-web-archive@optimus.ietf.org; Sat, 06 Dec 2003 12:37: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 MAA14396 for ; Sat, 6 Dec 2003 12:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASgMf-0004KS-00 for ips-web-archive@ietf.org; Sat, 06 Dec 2003 12:37:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASgMf-0004KP-00 for ips-web-archive@ietf.org; Sat, 06 Dec 2003 12:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASgMa-0000PK-CV; Sat, 06 Dec 2003 12:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASgM4-0000Nd-Ue for ips@optimus.ietf.org; Sat, 06 Dec 2003 12:36: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 MAA14388; Sat, 6 Dec 2003 12:36:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASgM3-0004K9-00; Sat, 06 Dec 2003 12:36:31 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx with esmtp (Exim 4.12) id 1ASgM2-0004Jt-00; Sat, 06 Dec 2003 12:36:30 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB6HZvn0135968; Sat, 6 Dec 2003 17:35:57 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB6HZud9255448; Sat, 6 Dec 2003 18:35:57 +0100 In-Reply-To: <3A62517F5A8AFE4098ADDBD25B5D4D5C015B39@rtpexc03.hq.netapp.com> To: "Pittman, Joseph" Cc: ips@ietf.org, ips-admin@ietf.org, "Jin, Tao" Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sat, 6 Dec 2003 12:35:54 -0500 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 06/12/2003 19:35:57, Serialize complete at 06/12/2003 19:35:57 Content-Type: multipart/alternative; boundary="=_alternative 0060941C85256DF4_=" 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: , This is a multipart message in MIME format. --=_alternative 0060941C85256DF4_= Content-Type: text/plain; charset="US-ASCII" The text considers this as another one of the "data and commands in flight" situation and says only that the target should cancel excution (that assumes also should not expect more data) return whatever status is pending - make sure all status was receive then send the response to abort. Julo "Pittman, Joseph" Sent by: ips-admin@ietf.org 05/12/2003 14:26 To cc "Jin, Tao" Subject [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream I have a question about the interaction between ABORT_TASK (or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited DATA_OUTs. Suppose the target and initiator have negotiated InitialR2T=no ImmediateData=no FirstBurstLength=64KB and the initiator sends the following PDUs: SCSI_CMD/WRITE 128KB/F=0 DATA_OUT/16KB/F=0 DATA_OUT/16KB/F=0 ABORT_TASK When the target receives the abort task, should it expect the initiator to send the remaining 32KB of the expected 64KB burst of unsolicited data? Or does the initiator's sending of the ABORT_TASK imply that it will not be sending any more data? I looked through the iSCSI specification for an answer, and found only this text which seems to relate to this topic: 3.2.4.2 Data Transfer Overview ... An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength, or all of the data if the total amount is less than the FirstBurstLength. This says the initiator must send the full burst. But somehow, I don't think this section is really talking about the 'ABORT during burst' case. Is there any text, either in the iSCSI spec or the SCSI-3 specifications, which would provide an authoritative statement on this? If not, would any of the authors care to give some guidance? Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com --=_alternative 0060941C85256DF4_= Content-Type: text/html; charset="US-ASCII"
The text considers this as another one of the "data and commands in flight" situation and says only that the target should cancel excution (that assumes also should not expect more data) return whatever status is pending - make sure all status was receive then send the response to abort.

Julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>
Sent by: ips-admin@ietf.org

05/12/2003 14:26

To
<ips@ietf.org>
cc
"Jin, Tao" <Tao.Jin@netapp.com>
Subject
[Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream





I have a question about the interaction between ABORT_TASK
(or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited
DATA_OUTs.
 
Suppose the target and initiator have negotiated
  InitialR2T=no
  ImmediateData=no
  FirstBurstLength=64KB
 
and the initiator sends the following PDUs:
 
  SCSI_CMD/WRITE 128KB/F=0
  DATA_OUT/16KB/F=0
 DATA_OUT/16KB/F=0
  ABORT_TASK
 
When the target receives the abort task, should it expect
the initiator to send the remaining 32KB of the expected
64KB burst of unsolicited data?
 
Or does the initiator's sending of the ABORT_TASK imply
that it will not be sending any more data?
 
I looked through the iSCSI specification for an answer, and
found only this text which seems to relate to this topic:
 
  3.2.4.2 Data Transfer Overview
 ...
  An iSCSI initiator MAY choose not to send unsolicited data, only
 immediate data or FirstBurstLength bytes of unsolicited data with a
 command. If any non-immediate unsolicited data is sent, the total
 unsolicited data MUST be either FirstBurstLength, or all of the data
 if the total amount is less than the FirstBurstLength.
 
This says the initiator must send the full burst.  But somehow,
I don't think this section is really talking about the 'ABORT
during burst' case.

Is there any text, either in the iSCSI spec or the SCSI-3
specifications, which would provide an authoritative statement
on this?  If not, would any of the authors care to give some
guidance?
 
Thanks in advance for any help.
--
Joe Pittman
jpittman@netapp.com
 
--=_alternative 0060941C85256DF4_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Dec 8 12:19:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19214 for ; Mon, 8 Dec 2003 12: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 1ATP2L-0000h1-GR for ips-archive@odin.ietf.org; Mon, 08 Dec 2003 12:19:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8HJ9G1002659 for ips-archive@odin.ietf.org; Mon, 8 Dec 2003 12:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATP2L-0000go-Be for ips-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 12:19: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 MAA19128 for ; Mon, 8 Dec 2003 12:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATP2J-0000eX-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 12:19:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATP2J-0000eT-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 12:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATP2D-0000fj-Ab; Mon, 08 Dec 2003 12: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 1ATP1l-0000ek-DC for ips@optimus.ietf.org; Mon, 08 Dec 2003 12:18: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 MAA18969; Mon, 8 Dec 2003 12:18:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATP1h-0000aP-00; Mon, 08 Dec 2003 12:18:29 -0500 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1ATP1e-0000YE-00; Mon, 08 Dec 2003 12:18:26 -0500 Received: from ivvt2dxrc11 (c-66-177-56-11.se.client2.attbi.com[66.177.56.11]) by comcast.net (rwcrmhc13) with SMTP id <2003120817172301500bs78ie> (Authid: esquicksall); Mon, 8 Dec 2003 17:17:24 +0000 Message-ID: <000f01c3bdaf$25b4d3c0$0b38b142@ivvt2dxrc11> From: "Eddy Quicksall" To: "Julian Satran" Cc: , , "Jin, Tao" References: Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream Date: Mon, 8 Dec 2003 12:17:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C3BD85.3BFE08B0" 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 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: , This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C3BD85.3BFE08B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Julian, can you please give a paragraph reference for that? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Pittman, Joseph=20 Cc: ips@ietf.org ; ips-admin@ietf.org ; Jin, Tao=20 Sent: Saturday, December 06, 2003 12:35 PM Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT = stream The text considers this as another one of the "data and commands in = flight" situation and says only that the target should cancel excution = (that assumes also should not expect more data) return whatever status = is pending - make sure all status was receive then send the response to = abort.=20 Julo=20 "Pittman, Joseph" =20 Sent by: ips-admin@ietf.org=20 05/12/2003 14:26=20 To =20 cc "Jin, Tao" =20 Subject [Ips] Question about ABORT_TASK and unsolicited = DATA_OUT stream=20 =20 =20 I have a question about the interaction between ABORT_TASK=20 (or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited=20 DATA_OUTs.=20 =20 Suppose the target and initiator have negotiated=20 InitialR2T=3Dno=20 ImmediateData=3Dno=20 FirstBurstLength=3D64KB=20 =20 and the initiator sends the following PDUs:=20 =20 SCSI_CMD/WRITE 128KB/F=3D0=20 DATA_OUT/16KB/F=3D0 DATA_OUT/16KB/F=3D0=20 ABORT_TASK=20 =20 When the target receives the abort task, should it expect=20 the initiator to send the remaining 32KB of the expected=20 64KB burst of unsolicited data?=20 =20 Or does the initiator's sending of the ABORT_TASK imply=20 that it will not be sending any more data?=20 =20 I looked through the iSCSI specification for an answer, and=20 found only this text which seems to relate to this topic:=20 =20 3.2.4.2 Data Transfer Overview ...=20 An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength, or all of the data if the total amount is less than the FirstBurstLength.=20 =20 This says the initiator must send the full burst. But somehow,=20 I don't think this section is really talking about the 'ABORT=20 during burst' case.=20 Is there any text, either in the iSCSI spec or the SCSI-3=20 specifications, which would provide an authoritative statement=20 on this? If not, would any of the authors care to give some=20 guidance?=20 =20 Thanks in advance for any help.=20 --=20 Joe Pittman=20 jpittman@netapp.com=20 =20 ------=_NextPart_000_000C_01C3BD85.3BFE08B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian, can you please give a paragraph = reference=20 for that?
 
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Cc: ips@ietf.org ; ips-admin@ietf.org ; Jin, = Tao
Sent: Saturday, December 06, = 2003 12:35=20 PM
Subject: Re: [Ips] Question = about=20 ABORT_TASK and unsolicited DATA_OUT stream


The text considers = this as=20 another one of the "data and commands in flight" situation and says = only that=20 the target should cancel excution (that assumes also should not expect = more=20 data) return whatever status is pending - make sure all status was = receive=20 then send the response to abort.

Julo


"Pittman, = Joseph" <Joseph.Pittman@netapp.com&g= t;=20
Sent by: ips-admin@ietf.org =

05/12/2003 14:26

To
<ips@ietf.org>=20
cc
"Jin, Tao" = <Tao.Jin@netapp.com>=20
Subject
[Ips] = Question about=20 ABORT_TASK and unsolicited DATA_OUT=20 stream

=




I have a question about the interaction = between=20 ABORT_TASK
(or = ABORT_TASK or=20 CLEAR_TASK_SET) and a burst of unsolicited
DATA_OUTs.
 
Suppose the target and initiator have=20 negotiated
 =20 InitialR2T=3Dno
 =20 ImmediateData=3Dno
 =20 FirstBurstLength=3D64KB
 =20
and the initiator sends = the=20 following PDUs:
 
  SCSI_CMD/WRITE 128KB/F=3D0 =
 =20 DATA_OUT/16KB/F=3D0
 DATA_OUT/16KB/F=3D0
  ABORT_TASK
 
When = the target=20 receives the abort task, should it expect
the initiator to send the remaining 32KB of the = expected=20
64KB burst of unsolicited = data?=20
 
Or does the=20 initiator's sending of the ABORT_TASK imply
that it will not be sending any more = data?=20
 
I looked=20 through the iSCSI specification for an answer, and
found only this text which seems to = relate to this=20 topic:
 
  3.2.4.2 Data Transfer Overview
 ... =
  An iSCSI initiator MAY choose not = to send=20 unsolicited data, only
 immediate data or FirstBurstLength = bytes of=20 unsolicited data with a
 command. If any non-immediate = unsolicited=20 data is sent, the total
 unsolicited data MUST be either=20 FirstBurstLength, or all of the data
 if the total amount is = less than=20 the FirstBurstLength.
  =
This says the initiator must send the = full burst.=20  But somehow,
I = don't think=20 this section is really talking about the 'ABORT
during burst' case.

Is there any text, either in the iSCSI = spec or the=20 SCSI-3
specifications, = which would=20 provide an authoritative statement
on this?  If not, would any of the authors care to give=20 some
guidance? =
 
Thanks = in advance for=20 any help.
-- =
Joe Pittman
jpittman@netapp.com
 =20
------=_NextPart_000_000C_01C3BD85.3BFE08B0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Dec 8 17:27:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07409 for ; Mon, 8 Dec 2003 17:27: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 1ATTqP-0008PJ-Au for ips-archive@odin.ietf.org; Mon, 08 Dec 2003 17:27:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8MR97x032313 for ips-archive@odin.ietf.org; Mon, 8 Dec 2003 17:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTqP-0008P3-6A for ips-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 17:27: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 RAA07336 for ; Mon, 8 Dec 2003 17:26:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTqM-0007Qd-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 17:27:06 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ATTqM-0007Qa-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 17:27:06 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ATTqV-0005gm-TV for ips-web-archive@ietf.org; Mon, 08 Dec 2003 17:27:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTqH-0008Mt-5o; Mon, 08 Dec 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTpb-0008Li-PJ for ips@optimus.ietf.org; Mon, 08 Dec 2003 17: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 RAA07305 for ; Mon, 8 Dec 2003 17:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTpP-0007P0-00 for Ips@ietf.org; Mon, 08 Dec 2003 17:26:07 -0500 Received: from zippy.cmc.optus.net.au ([61.88.176.193]) by ietf-mx with esmtp (Exim 4.12) id 1ATToz-0007O0-00 for Ips@ietf.org; Mon, 08 Dec 2003 17:25:41 -0500 Received: (from smtpd@localhost) by zippy.cmc.optus.net.au (8.11.6+Sun/8.11.6) id hB8MNhd15876 for ; Tue, 9 Dec 2003 09:23:43 +1100 (EST) Received: from UNKNOWN(172.25.19.159), claiming to be "CMCEXCH01.cmchelpdesk.local" via SMTP by zippy.cmc.optus.net.au, id smtpdAAA_saG_E; Tue Dec 9 09:23:36 2003 Received: by CMCEXCH01.cmchelpdesk.local with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 09:22:29 +1100 Message-ID: <16D5B53687C22A47ACFFC2043DE594B31D1FEE@CMCEXCH01.cmchelpdesk.local> From: Andy Plant To: Ips@ietf.org Subject: FW: [Ips] iSCSI Service Assurance Date: Tue, 9 Dec 2003 09:22:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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: , -----Original Message----- From: Aggarwal, Vikas (OFT) [mailto:Vikas.Aggarwal@oft.state.ny.us] Sent: Tuesday, 2 December 2003 10:08 To: Andy Plant Subject: RE: [Ips] iSCSI Service Assurance fcping http://www.tcloud.com/fcping_datacapture.htm http://dbforums.com/arch/184/2002/9/489106 Or otherwise the Fibre Channel Bus analyzers. thx -vikas -----Original Message----- From: Andy Plant [mailto:Andrew.Plant@cmc.optus.net.au] Sent: Monday, December 01, 2003 6:03 PM To: ips@ietf.org Subject: [Ips] iSCSI Service Assurance I've been "volunteered" to investigate providing service assurance for iSCSI, has anyone found any tool sets for monitoring the status of connections between host and storage (or at least the fibre switches) and in particular diagnosing that the problem is in the host (with drivers etc) when the remote storage becomes unavailable?? Obviously the base IP connectivity is relatively straight forward but it is the higher level interactions that concern me. Rgds _______________________________________________ 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 Dec 8 17:28:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07514 for ; Mon, 8 Dec 2003 17:28: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 1ATTrP-0000F2-Va for ips-archive@odin.ietf.org; Mon, 08 Dec 2003 17:28:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8MSBm2000920 for ips-archive@odin.ietf.org; Mon, 8 Dec 2003 17:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATTrP-0000Ek-Gu for ips-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 17:28: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 RAA07480 for ; Mon, 8 Dec 2003 17:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTrN-0007U4-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 17:28:09 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ATTrJ-0007Ti-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 17:28:07 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ATTrO-0005kc-Gl for ips-web-archive@ietf.org; Mon, 08 Dec 2003 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 1ATTrF-000084-QU; Mon, 08 Dec 2003 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 1ATTr2-00007O-Hr for ips@optimus.ietf.org; Mon, 08 Dec 2003 17:27: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 RAA07454 for ; Mon, 8 Dec 2003 17:27:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTr0-0007T4-00 for Ips@ietf.org; Mon, 08 Dec 2003 17:27:46 -0500 Received: from zippy.cmc.optus.net.au ([61.88.176.193]) by ietf-mx with esmtp (Exim 4.12) id 1ATTqz-0007Qm-00 for Ips@ietf.org; Mon, 08 Dec 2003 17:27:45 -0500 Received: (from smtpd@localhost) by zippy.cmc.optus.net.au (8.11.6+Sun/8.11.6) id hB8MRDj16186 for ; Tue, 9 Dec 2003 09:27:13 +1100 (EST) Received: from UNKNOWN(172.25.19.159), claiming to be "CMCEXCH01.cmchelpdesk.local" via SMTP by zippy.cmc.optus.net.au, id smtpdAAA4waqMF; Tue Dec 9 09:27:05 2003 Received: by CMCEXCH01.cmchelpdesk.local with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 09:25:59 +1100 Message-ID: <16D5B53687C22A47ACFFC2043DE594B31D1FF1@CMCEXCH01.cmchelpdesk.local> From: Andy Plant To: Ips@ietf.org Subject: FW: FW: [Ips] iSCSI Service Assurance Date: Tue, 9 Dec 2003 09:25:55 +1100 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: , As you can see from the responses to my question including the detailed one from the author of the FCPING utility Bill Pierce I still don't really have a solution (other than writing my own script). It seems to me that service assurance facilities for iSCSI need to be built into the specification and not "Bolted on" afterwards. Does anyone have any thoughts on what tool sets have been discussed to provide "healthcheck" type facilities across iSCSI based storage connections at levels above ICMP PING? Rgds Andy -----Original Message----- From: Bill Pierce [mailto:systems_r_up@yahoo.com] Sent: Saturday, 6 December 2003 03:18 To: Andy Plant Subject: Re: FW: [Ips] iSCSI Service Assurance Hi Andy, Thanks for your inquiry. Fcping works through a FibreChannel HBA API interface, so it can be used for FibreChannel, FCIP, or iFCP, not iSCSI. Said differently, it should work if you have FC on the host end and their are IP segments of the link, but not if the link from the host is purely IP or ethernet. If you're going iSCSI through and IP NIC card, why not just use ping to the IP address of your storage proxy. That will test the IP links up to the iSCSI switch (the 9509 I'm guessing). If you're trying to verify volume(DAS, NAS, SAN) availability to the application layer, which is what Vikas seems to be after, why not just write a simple program or script to open and read from a file on the suspect volume (or any LUN on the array in question) and check for errors. Are also some decent commercial and free monitoring tools out there as well if you're looking for a more heavyweight solution (eg. bb4.com). I wish I could direct you to TeraCloud's SRM product for this, but it's more focused on Space availability and capacity planning than physical health monitoring. Good luck. We visited Australia last year and really loved it. G'Day. - Bill Pierce --- Andy Plant wrote: > > G'Day Bill, > I know I'm pushing my luck here but I've been > reading what I can get on > FCPING and before I commit time and resources to > setting up a test I wanted > to confirm that it is possible to use this utility > to ping from a host using > i-SCSI to access a LUN on a storage array across an > IP network via a Cisco > 9509 fibre switch. The techo's here are telling me > this can only be used on > a directly connected fibre channel and thus couldn't > be used to test the IP > part of the connection. > Hope you can help. > Rgds > Andy > > -----Original Message----- > From: Aggarwal, Vikas (OFT) > [mailto:Vikas.Aggarwal@oft.state.ny.us] > Sent: Tuesday, 2 December 2003 10:10 > To: Andy Plant > Subject: RE: [Ips] iSCSI Service Assurance > > > http://www.tcloud.com/fcping_support.htm > __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Dec 8 21:23:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20969 for ; Mon, 8 Dec 2003 21:23: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 1ATXWu-0002Gt-1h for ips-archive@odin.ietf.org; Mon, 08 Dec 2003 21:23:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB92NGdG008725 for ips-archive@odin.ietf.org; Mon, 8 Dec 2003 21:23:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXWt-0002Ge-Tz for ips-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 21:23: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 VAA20943 for ; Mon, 8 Dec 2003 21:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATXWn-00058J-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 21:23:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATXWm-00058D-00 for ips-web-archive@ietf.org; Mon, 08 Dec 2003 21:23:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATXWf-0002BD-RK; Mon, 08 Dec 2003 21: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 1ATXWa-0002Ar-Cw for ips@optimus.ietf.org; Mon, 08 Dec 2003 21:22: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 VAA20936 for ; Mon, 8 Dec 2003 21:22:39 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATXWX-000588-00 for Ips@ietf.org; Mon, 08 Dec 2003 21:22:53 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1ATXWW-000585-00 for Ips@ietf.org; Mon, 08 Dec 2003 21:22:52 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 479E440134; Mon, 8 Dec 2003 21:22:49 -0500 (EST) Date: Mon, 8 Dec 2003 18:19:06 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Andy Plant Cc: Ips@ietf.org Subject: Re: FW: FW: [Ips] iSCSI Service Assurance In-Reply-To: <16D5B53687C22A47ACFFC2043DE594B31D1FF1@CMCEXCH01.cmchelpdesk.local> Message-ID: References: <16D5B53687C22A47ACFFC2043DE594B31D1FF1@CMCEXCH01.cmchelpdesk.local> 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: , On Tue, 9 Dec 2003, Andy Plant wrote: > As you can see from the responses to my question including the detailed one > from the author of the FCPING utility Bill Pierce I still don't really have > a solution (other than writing my own script). It seems to me that service > assurance facilities for iSCSI need to be built into the specification and > not "Bolted on" afterwards. Does anyone have any thoughts on what tool sets > have been discussed to provide "healthcheck" type facilities across iSCSI > based storage connections at levels above ICMP PING? I think there are definitely pieces in the spec that can be used for this. It's too late to add service assurance to the iSCSI standard, and I think it would have been inappropriate. I think the best thing to do (which we will be doing) will be to play with the standard we have, and see what works and what doesn't. The SCSI command, TEST UNIT READY, certainly is available for service monitoring. You also can use NOP-OUT and NOP-IN to monitor iSCSI functioning, but it would require more of a hook into the initiator. There are (obvious :-) hooks to pass SCSI commads across an iSCSI connection, but there aren't defined ones yet to inject iSCSI packets into an iSCSI connection. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Dec 9 01:56:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00434 for ; Tue, 9 Dec 2003 01:56: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 1ATbn1-00038S-32 for ips-archive@odin.ietf.org; Tue, 09 Dec 2003 01:56:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB96uBPt012052 for ips-archive@odin.ietf.org; Tue, 9 Dec 2003 01:56:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbn0-00038J-TE for ips-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 01:56: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 BAA00426 for ; Tue, 9 Dec 2003 01:55:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbmx-0001dn-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 01:56:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATbmv-0001dk-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 01:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbmt-00037V-EH; Tue, 09 Dec 2003 01:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbmL-00035g-Gm for ips@optimus.ietf.org; Tue, 09 Dec 2003 01:55: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 BAA00372 for ; Tue, 9 Dec 2003 01:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbmI-0001cF-00 for ips@ietf.org; Tue, 09 Dec 2003 01:55:26 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1ATbmG-0001am-00 for ips@ietf.org; Tue, 09 Dec 2003 01:55:24 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB96spPg039862; Tue, 9 Dec 2003 06:54:51 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB96snUU257060; Tue, 9 Dec 2003 07:54:50 +0100 In-Reply-To: <000f01c3bdaf$25b4d3c0$0b38b142@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org, "Jin, Tao" Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 9 Dec 2003 08:54:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/12/2003 08:54:50, Serialize complete at 09/12/2003 08:54:50 Content-Type: multipart/alternative; boundary="=_alternative 0025DFCEC2256DF7_=" 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: , This is a multipart message in MIME format. --=_alternative 0025DFCEC2256DF7_= Content-Type: text/plain; charset="US-ASCII" Eddy, The paragraphs are 10.5 & 10.6. You have there what is expected from the initiator and target in case of abort. Particularly the target must wait only for answers to R2Ts it issued and initiator can truncate them by setting the F bit ASAP. etc. Regards, Julo "Eddy Quicksall" 08/12/2003 19:17 To Julian Satran/Haifa/IBM@IBMIL cc , , "Jin, Tao" Subject Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream Julian, can you please give a paragraph reference for that? Eddy ----- Original Message ----- From: Julian Satran To: Pittman, Joseph Cc: ips@ietf.org ; ips-admin@ietf.org ; Jin, Tao Sent: Saturday, December 06, 2003 12:35 PM Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream The text considers this as another one of the "data and commands in flight" situation and says only that the target should cancel excution (that assumes also should not expect more data) return whatever status is pending - make sure all status was receive then send the response to abort. Julo "Pittman, Joseph" Sent by: ips-admin@ietf.org 05/12/2003 14:26 To cc "Jin, Tao" Subject [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream I have a question about the interaction between ABORT_TASK (or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited DATA_OUTs. Suppose the target and initiator have negotiated InitialR2T=no ImmediateData=no FirstBurstLength=64KB and the initiator sends the following PDUs: SCSI_CMD/WRITE 128KB/F=0 DATA_OUT/16KB/F=0 DATA_OUT/16KB/F=0 ABORT_TASK When the target receives the abort task, should it expect the initiator to send the remaining 32KB of the expected 64KB burst of unsolicited data? Or does the initiator's sending of the ABORT_TASK imply that it will not be sending any more data? I looked through the iSCSI specification for an answer, and found only this text which seems to relate to this topic: 3.2.4.2 Data Transfer Overview ... An iSCSI initiator MAY choose not to send unsolicited data, only immediate data or FirstBurstLength bytes of unsolicited data with a command. If any non-immediate unsolicited data is sent, the total unsolicited data MUST be either FirstBurstLength, or all of the data if the total amount is less than the FirstBurstLength. This says the initiator must send the full burst. But somehow, I don't think this section is really talking about the 'ABORT during burst' case. Is there any text, either in the iSCSI spec or the SCSI-3 specifications, which would provide an authoritative statement on this? If not, would any of the authors care to give some guidance? Thanks in advance for any help. -- Joe Pittman jpittman@netapp.com --=_alternative 0025DFCEC2256DF7_= Content-Type: text/html; charset="US-ASCII"
Eddy,

The paragraphs are 10.5 & 10.6. You have there what is expected from the initiator and target in case of abort. Particularly the target must wait only for answers to R2Ts it issued and initiator can truncate them by setting the F bit ASAP. etc.

Regards,
Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>

08/12/2003 19:17

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>, <ips-admin@ietf.org>, "Jin, Tao" <Tao.Jin@netapp.com>
Subject
Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream





Julian, can you please give a paragraph reference for that?
 
 
Eddy
----- Original Message -----
From: Julian Satran
To: Pittman, Joseph
Cc: ips@ietf.org ; ips-admin@ietf.org ; Jin, Tao
Sent: Saturday, December 06, 2003 12:35 PM
Subject: Re: [Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream


The text considers this as another one of the "data and commands in flight" situation and says only that the target should cancel excution (that assumes also should not expect more data) return whatever status is pending - make sure all status was receive then send the response to abort.

Julo

"Pittman, Joseph" <Joseph.Pittman@netapp.com>
Sent by: ips-admin@ietf.org

05/12/2003 14:26


To
<ips@ietf.org>
cc
"Jin, Tao" <Tao.Jin@netapp.com>
Subject
[Ips] Question about ABORT_TASK and unsolicited DATA_OUT stream







I have a question about the interaction between ABORT_TASK
(or ABORT_TASK or CLEAR_TASK_SET) and a burst of unsolicited
DATA_OUTs.
 
Suppose the target and initiator have negotiated
 InitialR2T=no
 ImmediateData=no
 FirstBurstLength=64KB
 
and the initiator sends the following PDUs:
 
 SCSI_CMD/WRITE 128KB/F=0
 DATA_OUT/16KB/F=0
DATA_OUT/16KB/F=0
 ABORT_TASK
 
When the target receives the abort task, should it expect
the initiator to send the remaining 32KB of the expected
64KB burst of unsolicited data?
 
Or does the initiator's sending of the ABORT_TASK imply
that it will not be sending any more data?
 
I looked through the iSCSI specification for an answer, and
found only this text which seems to relate to this topic:
 
 3.2.4.2 Data Transfer Overview
...
 An iSCSI initiator MAY choose not to send unsolicited data, only
immediate data or FirstBurstLength bytes of unsolicited data with a
command. If any non-immediate unsolicited data is sent, the total
unsolicited data MUST be either FirstBurstLength, or all of the data
if the total amount is less than the FirstBurstLength.
 
This says the initiator must send the full burst.  But somehow,
I don't think this section is really talking about the 'ABORT
during burst' case.

Is there any text, either in the iSCSI spec or the SCSI-3
specifications, which would provide an authoritative statement
on this?  If not, would any of the authors care to give some
guidance?
 
Thanks in advance for any help.
--
Joe Pittman
jpittman@netapp.com
 
--=_alternative 0025DFCEC2256DF7_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Dec 9 02:09:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10369 for ; Tue, 9 Dec 2003 02:09:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbzZ-0004Nt-0i for ips-archive@odin.ietf.org; Tue, 09 Dec 2003 02:09:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9798pL016846 for ips-archive@odin.ietf.org; Tue, 9 Dec 2003 02:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbzV-0004N6-Qp for ips-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 02:09: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 CAA09790 for ; Tue, 9 Dec 2003 02:08:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbzS-0001ru-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 02:09:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATbzS-0001rr-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 02:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbzS-0004Ll-GX; Tue, 09 Dec 2003 02: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 1ATbz8-0004Gw-JT for ips@optimus.ietf.org; Tue, 09 Dec 2003 02:08: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 CAA09384; Tue, 9 Dec 2003 02:08:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbz4-0001r8-00; Tue, 09 Dec 2003 02:08:38 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1ATbz2-0001qs-00; Tue, 09 Dec 2003 02:08:37 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB9781RJ107422; Tue, 9 Dec 2003 07:08:01 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB977sEl123078; Tue, 9 Dec 2003 08:08:00 +0100 In-Reply-To: <16D5B53687C22A47ACFFC2043DE594B31D1FF1@CMCEXCH01.cmchelpdesk.local> To: Andy Plant Cc: Ips@ietf.org, ips-admin@ietf.org Subject: Re: FW: FW: [Ips] iSCSI Service Assurance MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Tue, 9 Dec 2003 09:07:53 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/12/2003 09:08:00, Serialize complete at 09/12/2003 09:08:00 Content-Type: multipart/alternative; boundary="=_alternative 00271201C2256DF7_=" 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: , This is a multipart message in MIME format. --=_alternative 00271201C2256DF7_= Content-Type: text/plain; charset="US-ASCII" Andy, There is a pair of of NOPs built in just for that. I thing you may want to read them (and the rest of the spec) before finishing your recommendations. Julo Andy Plant Sent by: ips-admin@ietf.org 09/12/2003 00:25 To Ips@ietf.org cc Subject FW: FW: [Ips] iSCSI Service Assurance As you can see from the responses to my question including the detailed one from the author of the FCPING utility Bill Pierce I still don't really have a solution (other than writing my own script). It seems to me that service assurance facilities for iSCSI need to be built into the specification and not "Bolted on" afterwards. Does anyone have any thoughts on what tool sets have been discussed to provide "healthcheck" type facilities across iSCSI based storage connections at levels above ICMP PING? Rgds Andy -----Original Message----- From: Bill Pierce [mailto:systems_r_up@yahoo.com] Sent: Saturday, 6 December 2003 03:18 To: Andy Plant Subject: Re: FW: [Ips] iSCSI Service Assurance Hi Andy, Thanks for your inquiry. Fcping works through a FibreChannel HBA API interface, so it can be used for FibreChannel, FCIP, or iFCP, not iSCSI. Said differently, it should work if you have FC on the host end and their are IP segments of the link, but not if the link from the host is purely IP or ethernet. If you're going iSCSI through and IP NIC card, why not just use ping to the IP address of your storage proxy. That will test the IP links up to the iSCSI switch (the 9509 I'm guessing). If you're trying to verify volume(DAS, NAS, SAN) availability to the application layer, which is what Vikas seems to be after, why not just write a simple program or script to open and read from a file on the suspect volume (or any LUN on the array in question) and check for errors. Are also some decent commercial and free monitoring tools out there as well if you're looking for a more heavyweight solution (eg. bb4.com). I wish I could direct you to TeraCloud's SRM product for this, but it's more focused on Space availability and capacity planning than physical health monitoring. Good luck. We visited Australia last year and really loved it. G'Day. - Bill Pierce --- Andy Plant wrote: > > G'Day Bill, > I know I'm pushing my luck here but I've been > reading what I can get on > FCPING and before I commit time and resources to > setting up a test I wanted > to confirm that it is possible to use this utility > to ping from a host using > i-SCSI to access a LUN on a storage array across an > IP network via a Cisco > 9509 fibre switch. The techo's here are telling me > this can only be used on > a directly connected fibre channel and thus couldn't > be used to test the IP > part of the connection. > Hope you can help. > Rgds > Andy > > -----Original Message----- > From: Aggarwal, Vikas (OFT) > [mailto:Vikas.Aggarwal@oft.state.ny.us] > Sent: Tuesday, 2 December 2003 10:10 > To: Andy Plant > Subject: RE: [Ips] iSCSI Service Assurance > > > http://www.tcloud.com/fcping_support.htm > __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00271201C2256DF7_= Content-Type: text/html; charset="US-ASCII"
Andy,

There is a pair of of NOPs built in just for that. I thing you may want to read them (and the rest of the spec) before finishing your recommendations.

Julo


Andy Plant <Andrew.Plant@cmc.optus.net.au>
Sent by: ips-admin@ietf.org

09/12/2003 00:25

To
Ips@ietf.org
cc
Subject
FW: FW: [Ips] iSCSI Service Assurance





As you can see from the responses to my question including the detailed one
from the author of the FCPING utility Bill Pierce I still don't really have
a solution (other than writing my own script). It seems to me that service
assurance facilities for iSCSI need to be built into the specification and
not "Bolted on" afterwards. Does anyone have any thoughts on what tool sets
have been discussed to provide "healthcheck" type facilities across iSCSI
based storage connections at levels above ICMP PING?
Rgds
Andy

-----Original Message-----
From: Bill Pierce [mailto:systems_r_up@yahoo.com]
Sent: Saturday, 6 December 2003 03:18
To: Andy Plant
Subject: Re: FW: [Ips] iSCSI Service Assurance


Hi Andy,

Thanks for your inquiry.
Fcping works through a FibreChannel HBA API
interface, so it can be used for FibreChannel,
FCIP, or iFCP, not iSCSI.  Said differently,
it should work if you have FC on the host end
and their are IP segments of the link, but not
if the link from the host is purely IP or
ethernet.
If you're going iSCSI through
and IP NIC card, why not just use ping to the
IP address of your storage proxy. That will
test the IP links up to the iSCSI switch
(the 9509 I'm guessing).

If you're trying to verify volume(DAS, NAS, SAN)
availability to the application layer, which
is what Vikas seems to be after, why not just
write a simple program or script to
open and read from a file on the suspect
volume (or any LUN on the array in question)
and check for errors.
Are also some decent commercial and free
monitoring tools out there as well if
you're looking for a more heavyweight
solution (eg. bb4.com).

I wish I could direct you to TeraCloud's
SRM product for this, but it's more focused on
Space availability and capacity planning
than physical health monitoring.

Good luck. We visited Australia last year
and really loved it.  G'Day.

    - Bill Pierce

--- Andy Plant <Andrew.Plant@cmc.optus.net.au> wrote:
>
> G'Day Bill,
> I know I'm pushing my luck here but I've been
> reading what I can get on
> FCPING and before I commit time and resources to
> setting up a test I wanted
> to confirm that it is possible to use this utility
> to ping from a host using
> i-SCSI to access a LUN on a storage array across an
> IP network via a Cisco
> 9509 fibre switch.  The techo's here are telling me
> this can only be used on
> a directly connected fibre channel and thus couldn't
> be used to test the IP
> part of the connection.
> Hope you can help.
> Rgds
> Andy
>
> -----Original Message-----
> From: Aggarwal, Vikas (OFT)
> [mailto:Vikas.Aggarwal@oft.state.ny.us]
> Sent: Tuesday, 2 December 2003 10:10
> To: Andy Plant
> Subject: RE: [Ips] iSCSI Service Assurance
>
>
> http://www.tcloud.com/fcping_support.htm
>


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00271201C2256DF7_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Dec 9 15:24:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13549 for ; Tue, 9 Dec 2003 15: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 1AToP4-0006y8-2P for ips-archive@odin.ietf.org; Tue, 09 Dec 2003 15:24:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9KOIM4026784 for ips-archive@odin.ietf.org; Tue, 9 Dec 2003 15:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToP3-0006xv-Pg for ips-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 15:24: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 PAA13520 for ; Tue, 9 Dec 2003 15:24:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AToP2-0007Cc-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 15:24:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AToP1-0007Bx-00 for ips-web-archive@ietf.org; Tue, 09 Dec 2003 15:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToOm-0006wi-HJ; Tue, 09 Dec 2003 15:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AToNy-0006vg-5a for ips@optimus.ietf.org; Tue, 09 Dec 2003 15:23: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 PAA13450 for ; Tue, 9 Dec 2003 15:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AToNw-0007B2-00 for ips@ietf.org; Tue, 09 Dec 2003 15:23:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AToNw-00079l-00 for ips@ietf.org; Tue, 09 Dec 2003 15:23:08 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2003 20:23:34 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB9KMZAt025390; Tue, 9 Dec 2003 12:22:36 -0800 (PST) Received: from aboonkon-w2k01.cisco.com (dhcp-171-71-49-201.cisco.com [171.71.49.201]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKP29295; Tue, 9 Dec 2003 12:22:35 -0800 (PST) Message-Id: <4.3.2.7.2.20031209111725.04e5a200@mira-sjc5-9.cisco.com> X-Sender: aboonkon@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Dec 2003 12:18:37 -0800 To: "Priya Viswambharan" , "K. V. Subramaniam" , From: Arpakorn Boonkongchuen Subject: Re: [Ips] iSNS: generating SCNs on DD change (Scaling concern) In-Reply-To: <086801c3b041$93c57520$5b13a8c0@hcltntl.co.in> References: <3FBDF109.206@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8367632==_.ALT" 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: , --=====================_8367632==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hello All, My concern for requiring iSNS server to send all affected nodes to each client is one of scaling. Pls see my example below. At 08:40 PM 11/21/2003 +0530, Priya Viswambharan wrote: >Hi KVS, > >Regular SCNs will be generated by the iSNS server to be sent to only those >iSNS clients that have registered (through SCNReg) for such state changes. > >In your example, the iSNS server would send an SCN with the OBJECT REMOVED >bit set and listing iqn.b and iqn.c as the nodes that were removed. If iqn.a >wants to be doubly sure about iqn.b and iqn.c being no longer registered in >the iSNS DB, an iSNS DevAttrQry with the node names as the MessageAttributes >(plus some operating attributes for the nodes) may be sent for which the >iSNS server would respond with no values in the Operating Attributes since >the devices have been removed or have moved to a different DD. > >Regards, >Priya > > >----- Original Message ----- >From: "K. V. Subramaniam" >To: >Sent: Friday, November 21, 2003 4:33 PM >Subject: [Ips] iSNS: generating SCNs on DD change > > > I have a question regarding generation of regular SCNs. When a DD member is > > removed, or if a DD is removed or if DDS is disabled, it affects > > multiple initiators/targets. > > Do we then generate regular SCNs to each affected node? For example, > > consider > > that due to change in DD, iqn.a can no longer access iqn.b and iqn.c, then > > do we > > (a)send an SCN to iqn.a giving the info that some change has occured to > > SELF and expect it to query iSNS again > > (b) send an SCN giving OBJECT_REMOVED as reason and listing out iqn.b > > and iqn.c as the nodes that are no longer visible. > > > > > > Thanks > > kvs Finding out all affected node is easy for the case when one node goes online/offline but it can be computationally expensive for the case when DDS changes. To illustrate this, the following steps need to be performed before sending the SCN: for (each node x affected by the change in DDS) - oldAccessibleSet = set of nodes accessible by x before DDS change - newAccessibleSet = set of nodes accessible by x after DDS change - diff = difference between newAccessibleSet and oldAccessibleSet // difference is really the union of the two sets - the intersection. - Filter the result based on whether the initiator has registered to receive SCN for initiator/target (and self) only or not - Send SCN containing (subset of) the difference to node x Let us consider an example where a discovery domain set changes with (a, b, c) (d, e, f) being the initial active DDS and (a, b, e) (c, d, f) being the DDS after the change. If all nodes have registered to receive SCNs, then we have to compute accessibility for each node. We have to perform 3*2 operations before the DDS change and 3*2 operations after the DDS change. In general, the total operations required is 2*M*N*K where there are M Active Discovery Domain Sets, N Discovery Domains in each DDS, and K nodes in each DD. The load can potentially be significant in a large-scale deployment. This is different from what happens in the FC fabric where a port registering to receive a RSCN is sent an RSCN that indicates that there is a change. The responsibility of getting the change lies with the port receiving the SCN. This model alleviates the workload from the server and thus helps overall scaling by making all clients handle the difference and filtering computation for itself. What does people think? Regards, Arpakorn --=====================_8367632==_.ALT Content-Type: text/html; charset="us-ascii" Hello All,

My concern for requiring iSNS server to send all affected nodes to
each client is one of scaling.  Pls see my example below.

At 08:40 PM 11/21/2003 +0530, Priya Viswambharan wrote:
Hi KVS,

Regular SCNs will be generated by the iSNS server to be sent to only those
iSNS clients that have registered (through SCNReg) for such state changes.

In your example, the iSNS server would send an SCN with the OBJECT REMOVED
bit set and listing iqn.b and iqn.c as the nodes that were removed. If iqn.a
wants to be doubly sure about iqn.b and iqn.c being no longer registered in
the iSNS DB, an iSNS DevAttrQry with the node names as the MessageAttributes
(plus some operating attributes for the nodes) may be sent for which the
iSNS server would respond with no values in the Operating Attributes since
the devices have been removed or have moved to a different DD.

Regards,
Priya


----- Original Message -----
From: "K. V. Subramaniam" <kalsubra@cisco.com>
To: <ips@ietf.org>
Sent: Friday, November 21, 2003 4:33 PM
Subject: [Ips] iSNS: generating SCNs on DD change

> I have a question regarding generation of regular SCNs. When a DD member is
> removed, or if a DD is removed or if  DDS is disabled, it affects
> multiple initiators/targets.
> Do we then generate regular SCNs to each affected node? For example,
> consider
> that due to change in DD, iqn.a can no longer access iqn.b and iqn.c, then
> do we
>     (a)send an SCN to iqn.a giving the info that some change has occured to
>     SELF and expect it to query iSNS again
>     (b) send an SCN giving OBJECT_REMOVED as reason and listing out iqn.b
>     and iqn.c as the nodes that are no longer visible.
>
>
> Thanks
> kvs

Finding out all affected node is easy for the case when one node goes
online/offline but it can be computationally expensive for the
case when DDS changes.  To illustrate this, the following steps need
to be performed before sending the SCN:

for (each node x affected by the change in DDS)
   - oldAccessibleSet = set of nodes accessible by x before DDS change
  - newAccessibleSet = set of nodes accessible by x after DDS change
  - diff = difference between newAccessibleSet and oldAccessibleSet
     // difference is really the union of the two sets - the intersection.
   - Filter the result based on whether the initiator has registered
     to receive SCN for initiator/target (and self) only or not
  - Send SCN containing (subset of) the difference to node x

Let us consider an example where a discovery domain set changes with
(a, b, c) (d, e, f) being the initial active DDS and (a, b, e) (c, d, f)
being the DDS after the change.   If all nodes have registered
to receive SCNs, then we have to compute accessibility for each node.
We have to perform 3*2 operations before the DDS change and
3*2 operations after the DDS change. In general, the total
operations required is 2*M*N*K where there are M Active Discovery
Domain Sets, N Discovery Domains in each DDS, and K nodes in each DD.
The load can potentially be significant in a large-scale deployment.

This is different from what happens in the FC fabric where a port
registering to receive a RSCN is sent an RSCN that indicates that
there is a change. The responsibility of getting the change lies
with the port receiving the SCN.   This model alleviates the
workload from the server and thus helps overall scaling by making
all clients handle the difference and filtering computation for
itself.

What does people think?

Regards,
Arpakorn
 --=====================_8367632==_.ALT-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Dec 10 15:41:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15450 for ; Wed, 10 Dec 2003 15:41: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 1AUB8x-0005Re-LA for ips-archive@odin.ietf.org; Wed, 10 Dec 2003 15:41:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAKfBgZ020926 for ips-archive@odin.ietf.org; Wed, 10 Dec 2003 15:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUB8x-0005RR-AX for ips-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 15:41: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 PAA15402 for ; Wed, 10 Dec 2003 15:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUB8v-0000sl-00 for ips-web-archive@ietf.org; Wed, 10 Dec 2003 15:41:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUB8u-0000sh-00 for ips-web-archive@ietf.org; Wed, 10 Dec 2003 15:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUB8o-0005QK-BQ; Wed, 10 Dec 2003 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUB80-0005PU-5F for ips@optimus.ietf.org; Wed, 10 Dec 2003 15:40:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15265; Wed, 10 Dec 2003 15:40:09 -0500 (EST) Message-Id: <200312102040.PAA15265@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, 10 Dec 2003 15:40:09 -0500 Subject: [Ips] I-D ACTION:draft-ietf-ips-auth-mib-05.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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Definitions of Managed Objects for User Identity Authentication Author(s) : M. Bakke, J. Muchow Filename : draft-ietf-ips-auth-mib-05.txt Pages : 30 Date : 2003-12-10 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This draft was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB provides only the set of identities to be used within access lists; it is the responsibility of other MIBs making use of this one to tie them to their own access lists or other authorization control methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-05.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-auth-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-auth-mib-05.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: <2003-12-10160018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-auth-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-auth-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-10160018.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 Dec 10 22:35:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02872 for ; Wed, 10 Dec 2003 22:35: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 1AUHbZ-0006Bf-SA for ips-archive@odin.ietf.org; Wed, 10 Dec 2003 22:35:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB3Z9pe023783 for ips-archive@odin.ietf.org; Wed, 10 Dec 2003 22:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHbZ-0006BW-Op for ips-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 22:35: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 WAA02866 for ; Wed, 10 Dec 2003 22:35:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUHbV-0001Mm-00 for ips-web-archive@ietf.org; Wed, 10 Dec 2003 22:35:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUHbV-0001Mj-00 for ips-web-archive@ietf.org; Wed, 10 Dec 2003 22:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHbS-0006AW-BW; Wed, 10 Dec 2003 22: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 1AUHax-00069l-Fz for ips@optimus.ietf.org; Wed, 10 Dec 2003 22:34: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 WAA02856 for ; Wed, 10 Dec 2003 22:34:27 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUHat-0001MB-00 for ips@ietf.org; Wed, 10 Dec 2003 22:34:27 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AUHat-0001Lz-00 for ips@ietf.org; Wed, 10 Dec 2003 22:34:27 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 22:33:53 -0500 Message-ID: To: ips@ietf.org Date: Wed, 10 Dec 2003 22:33:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3BF97.80427CD0" Subject: [Ips] FW: RFC 3643 on Fibre Channel (FC) Frame Encapsulation 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: , 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_000_01C3BF97.80427CD0 Content-Type: text/plain FYI, --David -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of rfc-editor@rfc-editor.org Sent: Wednesday, December 10, 2003 7:33 PM Cc: rfc-editor@rfc-editor.org; ips@ece.cmu.edu Subject: RFC 3643 on Fibre Channel (FC) Frame Encapsulation A new Request for Comments is now available in online RFC libraries. RFC 3643 Title: Fibre Channel (FC) Frame Encapsulation Author(s): R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar Status: Standards Track Date: December 2003 Mailbox: roweber@ieee.org, muralir@broadcom.com, travos@nortelnetworks.com, mike.o'donnell@mcdata.com, cmonia@pacbell.net, milan.merhar@sun.com Pages: 20 Characters: 39980 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ips-fcencapsulation-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3643.txt This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames. This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ------_=_NextPart_000_01C3BF97.80427CD0 Content-Type: message/rfc822 To: Subject: Date: Wed, 10 Dec 2003 22:33:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C3BF97.80427CD0" ------_=_NextPart_002_01C3BF97.80427CD0 Content-Type: text/plain ------_=_NextPart_002_01C3BF97.80427CD0 Content-Type: application/octet-stream; name="ATT48298" Content-Disposition: attachment; filename="ATT48298" Content-type: message/external-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <031210163109.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3643 ------_=_NextPart_002_01C3BF97.80427CD0 Content-Type: message/external-body; site="in-notes"; dir="rfc3643.txt"; mode="ftp.isi.edu"; access-type="anon-ftp" ------_=_NextPart_002_01C3BF97.80427CD0-- ------_=_NextPart_000_01C3BF97.80427CD0-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Dec 13 08:54:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04084 for ; Sat, 13 Dec 2003 08:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVADh-0005Qe-K0 for ips-archive@odin.ietf.org; Sat, 13 Dec 2003 08:54:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBDDs91m020864 for ips-archive@odin.ietf.org; Sat, 13 Dec 2003 08:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVADh-0005QR-Dv for ips-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 08:54: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 IAA04074 for ; Sat, 13 Dec 2003 08:54:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVADg-0002TK-00 for ips-web-archive@ietf.org; Sat, 13 Dec 2003 08:54:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVADf-0002TG-00 for ips-web-archive@ietf.org; Sat, 13 Dec 2003 08:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVADZ-0005PR-87; Sat, 13 Dec 2003 08: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 1AVADK-0005PC-Hg for ips@optimus.ietf.org; Sat, 13 Dec 2003 08:53: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 IAA04065 for ; Sat, 13 Dec 2003 08:53:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVADI-0002T6-00 for ips@ietf.org; Sat, 13 Dec 2003 08:53:44 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx with esmtp (Exim 4.12) id 1AVADI-0002SL-00 for ips@ietf.org; Sat, 13 Dec 2003 08:53:44 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (rwcrmhc12) with SMTP id <20031213135313014000pbpqe> (Authid: esquicksall); Sat, 13 Dec 2003 13:53:13 +0000 Message-ID: <001e01c3c180$737c3380$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Sat, 13 Dec 2003 08:53:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C3C156.89D65860" 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: connection 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: , This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C3C156.89D65860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If I have only one connection in a session and the logout is for only = the connection, is 5.3.4 and 10.14 (9th paragraph) saying that the = initiator can: 1) logout the connection only (on a single connection session) 2) later log in using the same ISID-TSIH-CID combination to re-instate = the connection? If so, how long does the target need to keep the session information? Eddy ------=_NextPart_000_001B_01C3C156.89D65860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If I have only one connection in a = session and the=20 logout is for only the connection, is 5.3.4 and 10.14 (9th=20 paragraph) saying that the initiator can:
 
1) logout the connection only (on = a single=20 connection session)
2) later log in using the same = ISID-TSIH-CID=20 combination to re-instate the connection?
 
If so, how long does the target need to = keep the=20 session information?
 
Eddy
------=_NextPart_000_001B_01C3C156.89D65860-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Dec 13 16:19:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13966 for ; Sat, 13 Dec 2003 16:19: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 1AVHAI-0002Ju-9z for ips-archive@odin.ietf.org; Sat, 13 Dec 2003 16:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBDLJ6uv008912 for ips-archive@odin.ietf.org; Sat, 13 Dec 2003 16: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 1AVHAH-0002Jf-Vk for ips-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 16:19: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 QAA13960 for ; Sat, 13 Dec 2003 16:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVHAG-0000fR-00 for ips-web-archive@ietf.org; Sat, 13 Dec 2003 16:19:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVHAG-0000fO-00 for ips-web-archive@ietf.org; Sat, 13 Dec 2003 16: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 1AVHAE-0002Ia-3e; Sat, 13 Dec 2003 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVH9r-0002Hy-H3 for ips@optimus.ietf.org; Sat, 13 Dec 2003 16:18: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 QAA13947 for ; Sat, 13 Dec 2003 16:18:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVH9p-0000f1-00 for ips@ietf.org; Sat, 13 Dec 2003 16:18:37 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AVH9p-0000eT-00 for ips@ietf.org; Sat, 13 Dec 2003 16:18:37 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc11) with SMTP id <2003121321180501100ij3mle> (Authid: esquicksall); Sat, 13 Dec 2003 21:18:05 +0000 Message-ID: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Date: Sat, 13 Dec 2003 16:18:04 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C3C194.B0069D90" 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: a Reject during text negotiations 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C3C194.B0069D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From 5.4: "the target sets the F bit to 1 on the last response."=20 "A target may reset an operational parameter negotiation by answering a = Text request with a Reject PDU." "Parameters negotiated by a text exchange negotiation sequence only = become effective after the negotiation sequence is completed." There could be a few Text Requests used. The first one may be good but = the 2nd one may be bad and rejected. I->T MaxRecvDataSegmentLength=3D512, F=3D0 T->I F=3D0 I->T (changed the ITT) F=3D1 T->I Reject The reject has the F bit always set to 1. So it could be considered that = it ends the sequence and hence the 512 takes effect. But on the other = hand, since it is used to reset the negotiation, that could be taken to = mean that the good PDU should not take effect. Can you please advise me as to the correct action? Eddy ------=_NextPart_000_0022_01C3C194.B0069D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From 5.4:
 
"the target sets the F bit to 1 on the = last=20 response."
 
"A target may reset an operational = parameter=20 negotiation by answering a Text request with a Reject PDU."
 
"Parameters = negotiated by a text=20 exchange negotiation sequence only become effective after the = negotiation=20 sequence is completed."
 
There could be a few Text Requests = used. The first=20 one may be good but the 2nd one may be bad and rejected.
 
I->T MaxRecvDataSegmentLength=3D512, = F=3D0
T->I F=3D0
I->T (changed the ITT) = F=3D1
T->I Reject
 
The reject has the F bit always set to = 1. So it=20 could be considered that it ends the sequence and hence the 512 takes = effect.=20 But on the other hand, since it is used to reset the negotiation, that = could be=20 taken to mean that the good PDU should not take effect.
 
Can you please advise me as to the = correct=20 action?
 
Eddy
 
 
------=_NextPart_000_0022_01C3C194.B0069D90-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Dec 14 17:59:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28912 for ; Sun, 14 Dec 2003 17:59: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 1AVfCd-000673-IX for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 17:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEMx7WE023491 for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 17:59:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfCc-00066o-Pn for ips-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 17:59: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 RAA28906 for ; Sun, 14 Dec 2003 17:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfCa-0005FF-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 17:59:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVfCZ-0005FB-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 17:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfCY-00065n-9T; Sun, 14 Dec 2003 17:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfC8-00065Z-LI for ips@optimus.ietf.org; Sun, 14 Dec 2003 17:58: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 RAA28891 for ; Sun, 14 Dec 2003 17:58:32 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfC6-0005Em-00 for ips@ietf.org; Sun, 14 Dec 2003 17:58:34 -0500 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AVfC5-0005EY-00 for ips@ietf.org; Sun, 14 Dec 2003 17:58:33 -0500 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Dec 2003 17:57:57 -0500 Message-ID: To: Paul.Vonbehren@Sun.COM Cc: ips@ietf.org Date: Sun, 14 Dec 2003 17:57:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Ips] Target online notification & SAM-3 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: , Sorry about getting to this one late. Paul von Behren wrote: > > From the RFC: > > > > The codes used for iSCSI Asynchronous Messages (events) are: > > > > 0 - a SCSI Asynchronous Event is reported in the sense data. > > Asynchronous event reporting was removed from SAM-3 last November, > see http://www.t10.org/ftp/t10/document.02/02-458r0.pdf - and > look at recent SAM 3 versions (current is R9). > > My impression is that AER was considered unimplementable (at > least by some). > > It sounds like the iSCSI spec needs to be updated since this > is no longer a valid option. That's not quite correct because iSCSI is based on SAM-2, so removal of this value would not be appropriate. However, it would be appropriate to add a note warning implementers that T10 has deprecated AER in SAM-3, hence this AER support is likely to be removed from a future version of iSCSI that is based on SAM-3, therefore using it is not recommended (NB: lower case to avoid invoking RFC 2119 meaning). OTOH, I wouldn't hold my breath waiting for an effort to start to update iSCSI to SAM-3. 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 Sun Dec 14 18:01:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29067 for ; Sun, 14 Dec 2003 18:01: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 1AVfEZ-0006O4-C4 for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 18:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEN16OE024492 for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 18:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfEX-0006Kk-Ax for ips-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 18:01: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 SAA29025 for ; Sun, 14 Dec 2003 18:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfEU-0005HC-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 18:01:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVfEU-0005H9-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 18:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfEV-0006J8-Tj; Sun, 14 Dec 2003 18: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 1AVfDi-0006G1-PF for ips@optimus.ietf.org; Sun, 14 Dec 2003 18: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 SAA28986; Sun, 14 Dec 2003 18:00:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfDe-0005GU-00; Sun, 14 Dec 2003 18:00:10 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx with esmtp (Exim 4.12) id 1AVfDd-0005FU-00; Sun, 14 Dec 2003 18:00:10 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBEMxYGs036720; Sun, 14 Dec 2003 22:59:34 GMT Received: from d10ml001.telaviv.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 hBEMxX8K201816; Sun, 14 Dec 2003 23:59:33 +0100 In-Reply-To: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 15 Dec 2003 00:59:23 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 15/12/2003 00:59:33, Serialize complete at 15/12/2003 00:59:33 Content-Type: multipart/alternative; boundary="=_alternative 0061E754C2256DFC_=" 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: , This is a multipart message in MIME format. --=_alternative 0061E754C2256DFC_= Content-Type: text/plain; charset="US-ASCII" Reset is reset :-) Nothing new holds - everything is at it was at the outset. Julo "Eddy Quicksall" Sent by: ips-admin@ietf.org 13/12/2003 23:18 To cc Subject [Ips] iSCSI: a Reject during text negotiations From 5.4: "the target sets the F bit to 1 on the last response." "A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU." "Parameters negotiated by a text exchange negotiation sequence only become effective after the negotiation sequence is completed." There could be a few Text Requests used. The first one may be good but the 2nd one may be bad and rejected. I->T MaxRecvDataSegmentLength=512, F=0 T->I F=0 I->T (changed the ITT) F=1 T->I Reject The reject has the F bit always set to 1. So it could be considered that it ends the sequence and hence the 512 takes effect. But on the other hand, since it is used to reset the negotiation, that could be taken to mean that the good PDU should not take effect. Can you please advise me as to the correct action? Eddy --=_alternative 0061E754C2256DFC_= Content-Type: text/html; charset="US-ASCII"
Reset is reset :-) Nothing new holds - everything is at it was at the outset.  Julo


"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

13/12/2003 23:18

To
<ips@ietf.org>
cc
Subject
[Ips] iSCSI: a Reject during text negotiations





From 5.4:
 
"the target sets the F bit to 1 on the last response."
 
"A target may reset an operational parameter negotiation by answering a Text request with a Reject PDU."
 
"Parameters negotiated by a text exchange negotiation sequence only become effective after the negotiation sequence is completed."
 
There could be a few Text Requests used. The first one may be good but the 2nd one may be bad and rejected.
 
I->T MaxRecvDataSegmentLength=512, F=0
T->I F=0
I->T (changed the ITT) F=1
T->I Reject
 
The reject has the F bit always set to 1. So it could be considered that it ends the sequence and hence the 512 takes effect. But on the other hand, since it is used to reset the negotiation, that could be taken to mean that the good PDU should not take effect.
 
Can you please advise me as to the correct action?
 
Eddy
 
 
--=_alternative 0061E754C2256DFC_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sun Dec 14 18:01:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29082 for ; Sun, 14 Dec 2003 18:01:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfEg-0006WG-6R for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 18:01:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEN1DQY024997 for ips-archive@odin.ietf.org; Sun, 14 Dec 2003 18:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfEe-0006V6-QQ for ips-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 18:01: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 SAA29045 for ; Sun, 14 Dec 2003 18:01:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfEb-0005HX-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 18:01:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVfEb-0005HS-00 for ips-web-archive@ietf.org; Sun, 14 Dec 2003 18:01:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfEZ-0006OX-S1; Sun, 14 Dec 2003 18:01:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVfDT-0006CN-B8 for ips@optimus.ietf.org; Sun, 14 Dec 2003 17:59: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 RAA28953; Sun, 14 Dec 2003 17:59:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVfDQ-0005G3-00; Sun, 14 Dec 2003 17:59:56 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1AVfDP-0005FT-00; Sun, 14 Dec 2003 17:59:55 -0500 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBEMxNPg104212; Sun, 14 Dec 2003 22:59:23 GMT Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id hBEMxNDp265438; Sun, 14 Dec 2003 23:59:23 +0100 In-Reply-To: <001e01c3c180$737c3380$0303a8c0@ivvt2dxrc11> To: "Eddy Quicksall" Cc: ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: connection reinstatement MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Mon, 15 Dec 2003 00:59:13 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 15/12/2003 00:59:22, Serialize complete at 15/12/2003 00:59:22 Content-Type: multipart/alternative; boundary="=_alternative 0060FC04C2256DFC_=" 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: , This is a multipart message in MIME format. --=_alternative 0060FC04C2256DFC_= Content-Type: text/plain; charset="US-ASCII" ips-admin@ietf.org wrote on 13/12/2003 15:53:12: > If I have only one connection in a session and the logout is for only > the connection, is 5.3.4 and 10.14 (9th paragraph) saying that the > initiator can: > > 1) logout the connection only (on a single connection session) > 2) later log in using the same ISID-TSIH-CID combination to re-instate > the connection? > Yes - although if no tasks are outstanding ... > If so, how long does the target need to keep the session information? > Time2Retain > Eddy --=_alternative 0060FC04C2256DFC_= Content-Type: text/html; charset="US-ASCII"

ips-admin@ietf.org wrote on 13/12/2003 15:53:12:

> If I have only one connection in a session and the logout is for only
> the connection, is 5.3.4 and 10.14 (9th paragraph) saying that the
> initiator can:
>  
> 1) logout the connection only (on a single connection session)
> 2) later log in using the same ISID-TSIH-CID combination to re-instate
> the connection?
>
Yes - although if no tasks are outstanding ...
> If so, how long does the target need to keep the session information?
>  
Time2Retain
> Eddy --=_alternative 0060FC04C2256DFC_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Dec 15 13:49:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19909 for ; Mon, 15 Dec 2003 13:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxmF-0000qU-A1 for ips-archive@odin.ietf.org; Mon, 15 Dec 2003 13:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFIn7n7003243 for ips-archive@odin.ietf.org; Mon, 15 Dec 2003 13:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxmF-0000qE-3y for ips-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 13:49: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 NAA19897 for ; Mon, 15 Dec 2003 13:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxmC-0002TA-00 for ips-web-archive@ietf.org; Mon, 15 Dec 2003 13:49:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVxmC-0002T7-00 for ips-web-archive@ietf.org; Mon, 15 Dec 2003 13:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxm8-0000os-S3; Mon, 15 Dec 2003 13:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVxln-0000oI-KC for ips@optimus.ietf.org; Mon, 15 Dec 2003 13:48: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 NAA19878 for ; Mon, 15 Dec 2003 13:48:37 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVxll-0002SN-00 for ips@ietf.org; Mon, 15 Dec 2003 13:48:37 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AVxlk-0002SJ-00 for ips@ietf.org; Mon, 15 Dec 2003 13:48:36 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 259444013C; Mon, 15 Dec 2003 13:48:35 -0500 (EST) Date: Mon, 15 Dec 2003 10:44:46 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$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: , Sorry, Eddy, you were the only one who got the last reply. I'm resending it. On Sat, 13 Dec 2003, Eddy Quicksall wrote: > >From 5.4: > > "the target sets the F bit to 1 on the last response." > > "A target may reset an operational parameter negotiation by answering a > Text request with a Reject PDU." > > "Parameters negotiated by a text exchange negotiation sequence only > become effective after the negotiation sequence is completed." > > There could be a few Text Requests used. The first one may be good but > the 2nd one may be bad and rejected. > > I->T MaxRecvDataSegmentLength=512, F=0 > T->I F=0 > I->T (changed the ITT) F=1 > T->I Reject > > The reject has the F bit always set to 1. So it could be considered that > it ends the sequence and hence the 512 takes effect. But on the other > hand, since it is used to reset the negotiation, that could be taken to > mean that the good PDU should not take effect. I believe Julian is correct here, that a reject will reset the text negotiation. The fact the 'F' bit is set doesn't matter; the PDU isn't a text response PDU. However I have a question for the list. In the example above, the second Text Request has a different ITT than the first. Thus to a target that sorts everything by ITT, they look like two different text negotiations (which is an error). The reject obviously resets the "second" negotiation, but does it also reset the first (as they look like different tasks)? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Mon Dec 15 14:25:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21336 for ; Mon, 15 Dec 2003 14:25: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 1AVyL3-0002gD-FY for ips-archive@odin.ietf.org; Mon, 15 Dec 2003 14:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFJP5Ec010295 for ips-archive@odin.ietf.org; Mon, 15 Dec 2003 14:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyL3-0002fy-AZ for ips-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 14:25: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 OAA21319 for ; Mon, 15 Dec 2003 14:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyL0-0003BR-00 for ips-web-archive@ietf.org; Mon, 15 Dec 2003 14:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVyL0-0003BO-00 for ips-web-archive@ietf.org; Mon, 15 Dec 2003 14:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVyL1-0002et-Qc; Mon, 15 Dec 2003 14: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 1AVyKx-0002dv-1g for ips@optimus.ietf.org; Mon, 15 Dec 2003 14:24: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 OAA21313 for ; Mon, 15 Dec 2003 14:24:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVyKu-0003BF-00 for ips@ietf.org; Mon, 15 Dec 2003 14:24:56 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AVyKu-0003Aj-00 for ips@ietf.org; Mon, 15 Dec 2003 14:24:56 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc11) with SMTP id <2003121519242501100imu1ue> (Authid: esquicksall); Mon, 15 Dec 2003 19:24:26 +0000 Message-ID: <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Mon, 15 Dec 2003 14:24:25 -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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with you and Julian both. This actually happened to me from a 3rd party so I figured I would ask for the proper interpretation. Regarding the changing ITT, the spec says the ITT can't change ("An initiator MUST have at most one outstanding Text Request on a connection at any given time") and that was the reason I gave the reject. So in my opinion, the whole sequence must be discarded when I give the reject. Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Monday, December 15, 2003 1:44 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > Sorry, Eddy, you were the only one who got the last reply. I'm resending > it. > > On Sat, 13 Dec 2003, Eddy Quicksall wrote: > > > >From 5.4: > > > > "the target sets the F bit to 1 on the last response." > > > > "A target may reset an operational parameter negotiation by answering a > > Text request with a Reject PDU." > > > > "Parameters negotiated by a text exchange negotiation sequence only > > become effective after the negotiation sequence is completed." > > > > There could be a few Text Requests used. The first one may be good but > > the 2nd one may be bad and rejected. > > > > I->T MaxRecvDataSegmentLength=512, F=0 > > T->I F=0 > > I->T (changed the ITT) F=1 > > T->I Reject > > > > The reject has the F bit always set to 1. So it could be considered that > > it ends the sequence and hence the 512 takes effect. But on the other > > hand, since it is used to reset the negotiation, that could be taken to > > mean that the good PDU should not take effect. > > I believe Julian is correct here, that a reject will reset the text > negotiation. The fact the 'F' bit is set doesn't matter; the PDU isn't a > text response PDU. > > However I have a question for the list. In the example above, the second > Text Request has a different ITT than the first. Thus to a target that > sorts everything by ITT, they look like two different text negotiations > (which is an error). The reject obviously resets the "second" negotiation, > but does it also reset the first (as they look like different tasks)? > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Dec 16 16:38:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09356 for ; Tue, 16 Dec 2003 16:38:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMtS-0007bw-IN for ips-archive@odin.ietf.org; Tue, 16 Dec 2003 16:38:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGLcEt3029252 for ips-archive@odin.ietf.org; Tue, 16 Dec 2003 16:38:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMtS-0007bj-EQ for ips-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:38: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 QAA09302 for ; Tue, 16 Dec 2003 16:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMtQ-0006GY-00 for ips-web-archive@ietf.org; Tue, 16 Dec 2003 16:38:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMtP-0006GR-00 for ips-web-archive@ietf.org; Tue, 16 Dec 2003 16:38:12 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWMtP-0006GO-00 for ips-web-archive@ietf.org; Tue, 16 Dec 2003 16:38:11 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWMtO-00088H-PJ for ips-web-archive@ietf.org; Tue, 16 Dec 2003 16:38:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMtF-0007Zl-Op; Tue, 16 Dec 2003 16: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 1AWMsT-0007Ni-Hk for ips@optimus.ietf.org; Tue, 16 Dec 2003 16: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 QAA09230 for ; Tue, 16 Dec 2003 16:37:10 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMsR-0006DB-00 for ips@ietf.org; Tue, 16 Dec 2003 16:37:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMsQ-0006D4-00 for ips@ietf.org; Tue, 16 Dec 2003 16:37:10 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AWMsQ-0006D1-00 for ips@ietf.org; Tue, 16 Dec 2003 16:37:10 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 0DB9C40134; Tue, 16 Dec 2003 16:37:09 -0500 (EST) Date: Tue, 16 Dec 2003 13:33:17 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$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, 15 Dec 2003, Eddy Quicksall wrote: > I agree with you and Julian both. This actually happened to me from a 3rd > party so I figured I would ask for the proper interpretation. > > Regarding the changing ITT, the spec says the ITT can't change ("An > initiator MUST have at most one outstanding Text Request on a connection at > any given time") and that was the reason I gave the reject. So in my > opinion, the whole sequence must be discarded when I give the reject. I don't take "An initiator MUST have at most one outstanding Text Request on a connection at any given time" as meaning the ITT can't change. I take it as meaning that you can't have two outstanding Text Requests. Since the two requests have different ITTs, they are different tasks. The fact that they are both Text Request tasks (of which there can be only one) is secondary to their different ITTs. So while we both argree that the second request is in error, the difference is its impact on the first (and that's why I'm still EMailing about it :-) . Since they are different tasks, I don't see why the first would be impacted by the (incorrect) second. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Thu Dec 18 03:14:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10763 for ; Thu, 18 Dec 2003 03:14: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 1AWtIU-0005QV-NX for ips-archive@odin.ietf.org; Thu, 18 Dec 2003 03:14:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8EEBe020856 for ips-archive@odin.ietf.org; Thu, 18 Dec 2003 03:14:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtIU-0005QH-3m for ips-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 03:14: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 DAA10751 for ; Thu, 18 Dec 2003 03:14:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtIS-0005ML-00 for ips-web-archive@ietf.org; Thu, 18 Dec 2003 03:14:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtIQ-0005MD-00 for ips-web-archive@ietf.org; Thu, 18 Dec 2003 03:14:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtIQ-0005MA-00 for ips-web-archive@ietf.org; Thu, 18 Dec 2003 03:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtII-0005P5-DX; Thu, 18 Dec 2003 03: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 1AWtIF-0005OL-GU for ips@optimus.ietf.org; Thu, 18 Dec 2003 03: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 DAA10738 for ; Thu, 18 Dec 2003 03:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtID-0005LW-00 for ips@ietf.org; Thu, 18 Dec 2003 03:13:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtIC-0005LP-00 for ips@ietf.org; Thu, 18 Dec 2003 03:13:57 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx with esmtp (Exim 4.12) id 1AWtIB-0005K8-00 for ips@ietf.org; Thu, 18 Dec 2003 03:13:55 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBI8DMPg037616; Thu, 18 Dec 2003 08:13:22 GMT Received: from d10ml001.telaviv.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 hBI8DLk5255290; Thu, 18 Dec 2003 09:13:21 +0100 In-Reply-To: To: wrstuden@wasabisystems.com Cc: Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Thu, 18 Dec 2003 10:13:19 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 18/12/2003 10:13:21, Serialize complete at 18/12/2003 10:13:21 Content-Type: multipart/alternative; boundary="=_alternative 002D2168C2256E00_=" 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 is a multipart message in MIME format. --=_alternative 002D2168C2256E00_= Content-Type: text/plain; charset="US-ASCII" I think taht you have one of those Solomonic cases in which rejecting any or both is legal (the come from the same initiator!). Julo wrstuden@wasabisystems.com Sent by: ips-admin@ietf.org 16/12/2003 23:33 To Eddy Quicksall cc ips@ietf.org Subject Re: [Ips] iSCSI: a Reject during text negotiations On Mon, 15 Dec 2003, Eddy Quicksall wrote: > I agree with you and Julian both. This actually happened to me from a 3rd > party so I figured I would ask for the proper interpretation. > > Regarding the changing ITT, the spec says the ITT can't change ("An > initiator MUST have at most one outstanding Text Request on a connection at > any given time") and that was the reason I gave the reject. So in my > opinion, the whole sequence must be discarded when I give the reject. I don't take "An initiator MUST have at most one outstanding Text Request on a connection at any given time" as meaning the ITT can't change. I take it as meaning that you can't have two outstanding Text Requests. Since the two requests have different ITTs, they are different tasks. The fact that they are both Text Request tasks (of which there can be only one) is secondary to their different ITTs. So while we both argree that the second request is in error, the difference is its impact on the first (and that's why I'm still EMailing about it :-) . Since they are different tasks, I don't see why the first would be impacted by the (incorrect) second. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002D2168C2256E00_= Content-Type: text/html; charset="US-ASCII"
I think taht you have one of those Solomonic cases in which rejecting any or both is legal (the come from the same initiator!).

Julo


wrstuden@wasabisystems.com
Sent by: ips-admin@ietf.org

16/12/2003 23:33

To
Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@Comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





On Mon, 15 Dec 2003, Eddy Quicksall wrote:

> I agree with you and Julian both. This actually happened to me from a 3rd
> party so I figured I would ask for the proper interpretation.
>
> Regarding the changing ITT, the spec says the ITT can't change ("An
> initiator MUST have at most one outstanding Text Request on a connection at
> any given time") and that was the reason I gave the reject. So in my
> opinion, the whole sequence must be discarded when I give the reject.

I don't take "An initiator MUST have at most one outstanding Text Request
on a connection at any given time" as meaning the ITT can't change. I take
it as meaning that you can't have two outstanding Text Requests. Since the
two requests have different ITTs, they are different tasks. The fact that
they are both Text Request tasks (of which there can be only one) is
secondary to their different ITTs.

So while we both argree that the second request is in error, the
difference is its impact on the first (and that's why I'm still EMailing
about it :-)  . Since they are different tasks, I don't see why the first
would be impacted by the (incorrect) second.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002D2168C2256E00_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Fri Dec 19 15:07:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23549 for ; Fri, 19 Dec 2003 15:07: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 1AXQtw-0001Ig-BU for ips-archive@odin.ietf.org; Fri, 19 Dec 2003 15:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJK78qO004996 for ips-archive@odin.ietf.org; Fri, 19 Dec 2003 15:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQtv-0001IN-9B for ips-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 15:07: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 PAA23497 for ; Fri, 19 Dec 2003 15:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQts-0007jC-00 for ips-web-archive@ietf.org; Fri, 19 Dec 2003 15:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQtr-0007j5-00 for ips-web-archive@ietf.org; Fri, 19 Dec 2003 15:07:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXQtr-0007j2-00 for ips-web-archive@ietf.org; Fri, 19 Dec 2003 15:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXQtq-0001GK-0j; Fri, 19 Dec 2003 15: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 1AXQtH-0001Eb-MX for ips@optimus.ietf.org; Fri, 19 Dec 2003 15:06: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 PAA23418 for ; Fri, 19 Dec 2003 15:06:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXQtE-0007gw-00 for ips@ietf.org; Fri, 19 Dec 2003 15:06:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXQtD-0007go-00 for ips@ietf.org; Fri, 19 Dec 2003 15:06:24 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AXQtD-0007fi-00 for ips@ietf.org; Fri, 19 Dec 2003 15:06:23 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc11) with SMTP id <2003121920055301100ik0jqe> (Authid: esquicksall); Fri, 19 Dec 2003 20:05:53 +0000 Message-ID: <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Fri, 19 Dec 2003 15:05:50 -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 This is simple for me to change my code because I could care less what the ITT is but there is at least one party out there that thinks it can't change (he has not spoken up yet). I just need to know which way to go. Julian, can you please comment definitively? Can the ITT change before the F bit is set in a Text Response? Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Tuesday, December 16, 2003 4:33 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Mon, 15 Dec 2003, Eddy Quicksall wrote: > > > I agree with you and Julian both. This actually happened to me from a 3rd > > party so I figured I would ask for the proper interpretation. > > > > Regarding the changing ITT, the spec says the ITT can't change ("An > > initiator MUST have at most one outstanding Text Request on a connection at > > any given time") and that was the reason I gave the reject. So in my > > opinion, the whole sequence must be discarded when I give the reject. > > I don't take "An initiator MUST have at most one outstanding Text Request > on a connection at any given time" as meaning the ITT can't change. I take > it as meaning that you can't have two outstanding Text Requests. Since the > two requests have different ITTs, they are different tasks. The fact that > they are both Text Request tasks (of which there can be only one) is > secondary to their different ITTs. > > So while we both argree that the second request is in error, the > difference is its impact on the first (and that's why I'm still EMailing > about it :-) . Since they are different tasks, I don't see why the first > would be impacted by the (incorrect) second. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Sat Dec 20 01:02:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13304 for ; Sat, 20 Dec 2003 01:02: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 1AXaBj-0003zv-Tc for ips-archive@odin.ietf.org; Sat, 20 Dec 2003 01:02:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBK627KZ015367 for ips-archive@odin.ietf.org; Sat, 20 Dec 2003 01:02:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXaBj-0003zm-2D for ips-web-archive@optimus.ietf.org; Sat, 20 Dec 2003 01:02: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 BAA13293 for ; Sat, 20 Dec 2003 01:02:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXaBg-0001vU-00 for ips-web-archive@ietf.org; Sat, 20 Dec 2003 01:02:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXaBe-0001vN-00 for ips-web-archive@ietf.org; Sat, 20 Dec 2003 01:02:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXaBe-0001vK-00 for ips-web-archive@ietf.org; Sat, 20 Dec 2003 01:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXaBd-0003zA-SH; Sat, 20 Dec 2003 01: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 1AXaBQ-0003yv-Ol for ips@optimus.ietf.org; Sat, 20 Dec 2003 01:01: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 BAA13289 for ; Sat, 20 Dec 2003 01:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXaBN-0001vG-00 for ips@ietf.org; Sat, 20 Dec 2003 01:01:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXaBM-0001v9-00 for ips@ietf.org; Sat, 20 Dec 2003 01:01:45 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx with esmtp (Exim 4.12) id 1AXaBL-0001ue-00 for ips@ietf.org; Sat, 20 Dec 2003 01:01:43 -0500 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBK61CjB064904 for ; Sat, 20 Dec 2003 06:01:12 GMT Received: from d10ml001.telaviv.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 hBK61AgE249216 for ; Sat, 20 Dec 2003 07:01:11 +0100 To: ips@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 From: Julian Satran Message-ID: Date: Sat, 20 Dec 2003 08:01:07 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at 20/12/2003 08:01:10, Serialize complete at 20/12/2003 08:01:10 Content-Type: multipart/alternative; boundary="=_alternative 00210EF0C2256E02_=" Subject: [Ips] (no subject) 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 is a multipart message in MIME format. --=_alternative 00210EF0C2256E02_= Content-Type: text/plain; charset="US-ASCII" Eddy, Here is the comment I sent yesterday. It is wrong to change ITT (another case of reject) but it is up to you to reject the first task, the second or both as they both come from the same initiator - Julo ----- Forwarded by Julian Satran/Haifa/IBM on 20/12/2003 07:58 ----- Julian Satran/Haifa/IBM 18/12/2003 10:12 To wrstuden@wasabisystems.com cc Eddy Quicksall , ips@ietf.org, ips-admin@ietf.org Subject Re: [Ips] iSCSI: a Reject during text negotiations I think taht you have one of those Solomonic cases in which rejecting any or both is legal (the come from the same initiator!). Julo wrstuden@wasabisystems.com Sent by: ips-admin@ietf.org 16/12/2003 23:33 To Eddy Quicksall cc ips@ietf.org Subject Re: [Ips] iSCSI: a Reject during text negotiations On Mon, 15 Dec 2003, Eddy Quicksall wrote: > I agree with you and Julian both. This actually happened to me from a 3rd > party so I figured I would ask for the proper interpretation. > > Regarding the changing ITT, the spec says the ITT can't change ("An > initiator MUST have at most one outstanding Text Request on a connection at > any given time") and that was the reason I gave the reject. So in my > opinion, the whole sequence must be discarded when I give the reject. I don't take "An initiator MUST have at most one outstanding Text Request on a connection at any given time" as meaning the ITT can't change. I take it as meaning that you can't have two outstanding Text Requests. Since the two requests have different ITTs, they are different tasks. The fact that they are both Text Request tasks (of which there can be only one) is secondary to their different ITTs. So while we both argree that the second request is in error, the difference is its impact on the first (and that's why I'm still EMailing about it :-) . Since they are different tasks, I don't see why the first would be impacted by the (incorrect) second. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ----- Forwarded by Julian Satran/Haifa/IBM on 20/12/2003 07:58 ----- "Eddy Quicksall" Sent by: ips-admin@ietf.org 19/12/2003 22:05 To cc Subject Re: [Ips] iSCSI: a Reject during text negotiations This is simple for me to change my code because I could care less what the ITT is but there is at least one party out there that thinks it can't change (he has not spoken up yet). I just need to know which way to go. Julian, can you please comment definitively? Can the ITT change before the F bit is set in a Text Response? Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Tuesday, December 16, 2003 4:33 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Mon, 15 Dec 2003, Eddy Quicksall wrote: > > > I agree with you and Julian both. This actually happened to me from a 3rd > > party so I figured I would ask for the proper interpretation. > > > > Regarding the changing ITT, the spec says the ITT can't change ("An > > initiator MUST have at most one outstanding Text Request on a connection at > > any given time") and that was the reason I gave the reject. So in my > > opinion, the whole sequence must be discarded when I give the reject. > > I don't take "An initiator MUST have at most one outstanding Text Request > on a connection at any given time" as meaning the ITT can't change. I take > it as meaning that you can't have two outstanding Text Requests. Since the > two requests have different ITTs, they are different tasks. The fact that > they are both Text Request tasks (of which there can be only one) is > secondary to their different ITTs. > > So while we both argree that the second request is in error, the > difference is its impact on the first (and that's why I'm still EMailing > about it :-) . Since they are different tasks, I don't see why the first > would be impacted by the (incorrect) second. > > Take care, > > Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 00210EF0C2256E02_= Content-Type: text/html; charset="US-ASCII"
Eddy,

Here is the comment I sent yesterday. It is wrong to change ITT (another case of reject) but it is up to you to reject the first task, the second or both as they both come from the same initiator - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 20/12/2003 07:58 -----
Julian Satran/Haifa/IBM

18/12/2003 10:12

To
wrstuden@wasabisystems.com
cc
Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@Comcast.net>, ips@ietf.org, ips-admin@ietf.org
Subject
Re: [Ips] iSCSI: a Reject during text negotiationsLink




I think taht you have one of those Solomonic cases in which rejecting any or both is legal (the come from the same initiator!).

Julo


wrstuden@wasabisystems.com
Sent by: ips-admin@ietf.org

16/12/2003 23:33

To
Eddy Quicksall <eddy_quicksall_iVivity_iSCSI@Comcast.net>
cc
ips@ietf.org
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





On Mon, 15 Dec 2003, Eddy Quicksall wrote:

> I agree with you and Julian both. This actually happened to me from a 3rd
> party so I figured I would ask for the proper interpretation.
>
> Regarding the changing ITT, the spec says the ITT can't change ("An
> initiator MUST have at most one outstanding Text Request on a connection at
> any given time") and that was the reason I gave the reject. So in my
> opinion, the whole sequence must be discarded when I give the reject.

I don't take "An initiator MUST have at most one outstanding Text Request
on a connection at any given time" as meaning the ITT can't change. I take
it as meaning that you can't have two outstanding Text Requests. Since the
two requests have different ITTs, they are different tasks. The fact that
they are both Text Request tasks (of which there can be only one) is
secondary to their different ITTs.

So while we both argree that the second request is in error, the
difference is its impact on the first (and that's why I'm still EMailing
about it :-)  . Since they are different tasks, I don't see why the first
would be impacted by the (incorrect) second.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips

----- Forwarded by Julian Satran/Haifa/IBM on 20/12/2003 07:58 -----
"Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@comcast.net>
Sent by: ips-admin@ietf.org

19/12/2003 22:05

To
<wrstuden@wasabisystems.com>
cc
<ips@ietf.org>
Subject
Re: [Ips] iSCSI: a Reject during text negotiations





This is simple for me to change my code because I could care less what the
ITT is but there is at least one party out there that thinks it can't change
(he has not spoken up yet).

I just need to know which way to go.

Julian, can you please comment definitively? Can the ITT change before the F
bit is set in a Text Response?

Eddy

----- Original Message -----
From: <wrstuden@wasabisystems.com>
To: "Eddy Quicksall" <eddy_quicksall_iVivity_iSCSI@Comcast.net>
Cc: <ips@ietf.org>
Sent: Tuesday, December 16, 2003 4:33 PM
Subject: Re: [Ips] iSCSI: a Reject during text negotiations


> On Mon, 15 Dec 2003, Eddy Quicksall wrote:
>
> > I agree with you and Julian both. This actually happened to me from a
3rd
> > party so I figured I would ask for the proper interpretation.
> >
> > Regarding the changing ITT, the spec says the ITT can't change ("An
> > initiator MUST have at most one outstanding Text Request on a connection
at
> > any given time") and that was the reason I gave the reject. So in my
> > opinion, the whole sequence must be discarded when I give the reject.
>
> I don't take "An initiator MUST have at most one outstanding Text Request
> on a connection at any given time" as meaning the ITT can't change. I take
> it as meaning that you can't have two outstanding Text Requests. Since the
> two requests have different ITTs, they are different tasks. The fact that
> they are both Text Request tasks (of which there can be only one) is
> secondary to their different ITTs.
>
> So while we both argree that the second request is in error, the
> difference is its impact on the first (and that's why I'm still EMailing
> about it :-)  . Since they are different tasks, I don't see why the first
> would be impacted by the (incorrect) second.
>
> Take care,
>
> Bill


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 00210EF0C2256E02_=-- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Tue Dec 23 15:50:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09164 for ; Tue, 23 Dec 2003 15:50: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 1AYtTO-0000ST-1G for ips-archive@odin.ietf.org; Tue, 23 Dec 2003 15:49:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKnkfu001755 for ips-archive@odin.ietf.org; Tue, 23 Dec 2003 15:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtTN-0000SE-Tm for ips-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:49: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 PAA09128 for ; Tue, 23 Dec 2003 15:49:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtTM-0002TI-00 for ips-web-archive@ietf.org; Tue, 23 Dec 2003 15:49:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtRU-0002PA-00 for ips-web-archive@ietf.org; Tue, 23 Dec 2003 15:47:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtPt-0002Lq-00 for ips-web-archive@ietf.org; Tue, 23 Dec 2003 15:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtPn-0000J1-TO; Tue, 23 Dec 2003 15:46:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtPX-0000Hf-1h for ips@optimus.ietf.org; Tue, 23 Dec 2003 15:45: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 PAA09010 for ; Tue, 23 Dec 2003 15:45:44 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtPV-0002Jz-00 for ips@ietf.org; Tue, 23 Dec 2003 15:45:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtNe-0002GG-00 for ips@ietf.org; Tue, 23 Dec 2003 15:43:51 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1AYtM0-0002CG-00 for ips@ietf.org; Tue, 23 Dec 2003 15:42:08 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 22BA840138; Tue, 23 Dec 2003 15:42:03 -0500 (EST) Date: Tue, 23 Dec 2003 12:38:07 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@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 Fri, 19 Dec 2003, Eddy Quicksall wrote: > This is simple for me to change my code because I could care less what the > ITT is but there is at least one party out there that thinks it can't change > (he has not spoken up yet). The ITT can't change. If it changes, we're talking about a different task. > I just need to know which way to go. > > Julian, can you please comment definitively? Can the ITT change before the F > bit is set in a Text Response? Eddy, I think you're looking at this backwards. The ITT takes precedence over the fact a PDU is a Text Request. From section 3.2.2.1 Command numbering and Acknowledgement (para 2): iSCSI considers a task to be instantiated on the target in response every request issued by the initiator. A set of task management operations including abort and reassign (see Section 10.5 Task Management Function Request) may be performed on any iSCSI task. Some iSCSI tasks are SCSI tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In all cases, the task is identified by the Initiator Task Tag for the life of the task. Note the "In all cases, the task is identified by the Initiator Task Tag for the life of the task". If the ITT differs, we are looking at different tasks. So back to the original question, the ITT can't "change" for a Text Request task, because if the ITT is different, we aren't talking about the same task. Does that make sense? Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From exim@www1.ietf.org Wed Dec 24 23:08:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03448 for ; Wed, 24 Dec 2003 23:08: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 1AZMnM-00083Y-CL for ips-archive@odin.ietf.org; Wed, 24 Dec 2003 23:08:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBP48Jfr030906 for ips-archive@odin.ietf.org; Wed, 24 Dec 2003 23:08:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZMnI-00081u-JF for ips-web-archive@optimus.ietf.org; Wed, 24 Dec 2003 23:08: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 XAA03424 for ; Wed, 24 Dec 2003 23:08:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZMnD-00039W-00 for ips-web-archive@ietf.org; Wed, 24 Dec 2003 23:08:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZMlr-00036r-00 for ips-web-archive@ietf.org; Wed, 24 Dec 2003 23:06:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AZMkE-00033I-00 for ips-web-archive@ietf.org; Wed, 24 Dec 2003 23:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZMkB-0007Ra-8N; Wed, 24 Dec 2003 23:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AZMjU-0007QH-22 for ips@optimus.ietf.org; Wed, 24 Dec 2003 23:04: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 XAA03313 for ; Wed, 24 Dec 2003 23:04:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AZMjP-00031j-00 for ips@ietf.org; Wed, 24 Dec 2003 23:04:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AZMhI-0002yE-00 for ips@ietf.org; Wed, 24 Dec 2003 23:02:05 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AZMfP-0002t5-00 for ips@ietf.org; Wed, 24 Dec 2003 23:00:07 -0500 Received: from ivvt2dxrc11 (c-66-177-53-111.se.client2.attbi.com[66.177.53.111]) by comcast.net (sccrmhc13) with SMTP id <2003122503593801600rioqie> (Authid: esquicksall); Thu, 25 Dec 2003 03:59:38 +0000 Message-ID: <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> From: "Eddy Quicksall" To: Cc: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> Subject: Re: [Ips] iSCSI: a Reject during text negotiations Date: Wed, 24 Dec 2003 22:59:37 -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 I think this was cleared up by Julian on Dec 22 around 1AM (no subject). Yes, it makes sense and I don't think I ever said anything that debated that. My question is based on 10.10 saying: An initiator MUST have at most one outstanding Text Request on a connection at any given time. I think this means only one "task" can be outstanding and I think the "at a given time" means "until the target responds with the F bit set to 1". So, if that is the case, the ITT can't change until the target responds with the F bit set to 1. My question further asked if a reject is given to an ITT that changed before F==1 (a second "outstanding Text Request") then is the original ITT reset? And the answer was [yes] because "reset is reset". So, in my original example given below, MaxRecvDataSegmentLength will not have changed at the target. -- snip -- I->T MaxRecvDataSegmentLength=512, F=0 T->I F=0 I->T (changed the ITT) F=1 T->I Reject Finally, are you saying that more than one task can be outstanding at the target before the target sets F==1? If so, we may have something to debate. Eddy ----- Original Message ----- From: To: "Eddy Quicksall" Cc: Sent: Tuesday, December 23, 2003 3:38 PM Subject: Re: [Ips] iSCSI: a Reject during text negotiations > On Fri, 19 Dec 2003, Eddy Quicksall wrote: > > > This is simple for me to change my code because I could care less what the > > ITT is but there is at least one party out there that thinks it can't change > > (he has not spoken up yet). > > The ITT can't change. If it changes, we're talking about a different task. > > > I just need to know which way to go. > > > > Julian, can you please comment definitively? Can the ITT change before the F > > bit is set in a Text Response? > > Eddy, I think you're looking at this backwards. The ITT takes precedence > over the fact a PDU is a Text Request. > > From section 3.2.2.1 Command numbering and Acknowledgement (para 2): > > iSCSI considers a task to be instantiated on the target in response every > request issued by the initiator. A set of task management operations > including abort and reassign (see Section 10.5 Task Management Function > Request) may be performed on any iSCSI task. Some iSCSI tasks are SCSI > tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In > all cases, the task is identified by the Initiator Task Tag for the life > of the task. > > Note the "In all cases, the task is identified by the Initiator Task Tag > for the life of the task". If the ITT differs, we are looking at different > tasks. > > So back to the original question, the ITT can't "change" for a Text > Request task, because if the ITT is different, we aren't talking about the > same task. > > Does that make sense? > > 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 Dec 29 13:38:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07912 for ; Mon, 29 Dec 2003 13:38: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 1Ab2HR-0004To-Tf for ips-archive@odin.ietf.org; Mon, 29 Dec 2003 13:38:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTIcHl3017215 for ips-archive@odin.ietf.org; Mon, 29 Dec 2003 13:38:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2HR-0004Ta-Pa for ips-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 13:38: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 NAA07886 for ; Mon, 29 Dec 2003 13:38:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab2HP-00002g-00 for ips-web-archive@ietf.org; Mon, 29 Dec 2003 13:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab2FZ-0007jK-00 for ips-web-archive@ietf.org; Mon, 29 Dec 2003 13:36:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab2EQ-0007en-00 for ips-web-archive@ietf.org; Mon, 29 Dec 2003 13:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab2EI-0003zS-Ox; Mon, 29 Dec 2003 13: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 1Ab2DS-0003uK-H5 for ips@optimus.ietf.org; Mon, 29 Dec 2003 13:34: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 NAA07569 for ; Mon, 29 Dec 2003 13:34:08 -0500 (EST) From: wrstuden@wasabisystems.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab2DQ-0007aP-00 for ips@ietf.org; Mon, 29 Dec 2003 13:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab2Bo-0007Ub-00 for ips@ietf.org; Mon, 29 Dec 2003 13:32:29 -0500 Received: from mononoke.wasabisystems.com ([151.199.66.145]) by ietf-mx with esmtp (Exim 4.12) id 1Ab29m-0007P4-00 for ips@ietf.org; Mon, 29 Dec 2003 13:30:22 -0500 Received: by mononoke.wasabisystems.com (Postfix, from userid 1021) id 948AB40134; Mon, 29 Dec 2003 13:30:22 -0500 (EST) Date: Mon, 29 Dec 2003 10:26:22 -0800 (PST) X-X-Sender: wrstuden@neverwinter.home-net.icnt.net To: Eddy Quicksall Cc: ips@ietf.org Subject: Re: [Ips] iSCSI: a Reject during text negotiations In-Reply-To: <005401c3ca9b$842cb550$0303a8c0@ivvt2dxrc11> Message-ID: References: <002501c3c1be$99600660$0303a8c0@ivvt2dxrc11> <001a01c3c341$0d679a90$0303a8c0@ivvt2dxrc11> <003801c3c66b$81c53050$3d33b142@ivvt2dxrc11> <005401c3ca9b$842cb550$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 Wed, 24 Dec 2003, Eddy Quicksall wrote: > I think this was cleared up by Julian on Dec 22 around 1AM (no subject). > > Yes, it makes sense and I don't think I ever said anything that debated > that. > > My question is based on 10.10 saying: > > An initiator MUST have at most one outstanding Text Request on a > connection at any given time. > > I think this means only one "task" can be outstanding and I think the "at a > given time" means "until the target responds with the F bit set to 1". > > So, if that is the case, the ITT can't change until the target responds with > the F bit set to 1. Eddie, you are talking about an invariant of a task, the ITT, changing. Invariants don't change; that's the point of an invariant. :-) > My question further asked if a reject is given to an ITT that changed before > F==1 (a second "outstanding Text Request") then is the original ITT reset? > And the answer was [yes] because "reset is reset". > > So, in my original example given below, MaxRecvDataSegmentLength will not > have changed at the target. Yes, but for a different reason. :-) It won't have changed because the first Text Negotiation task is still active. While I agree the second PDU should get a reject, since it's a different ITT, it's a different task. Since it's a different task, I don't see why it getting killed for a reject should impact the first. > -- snip -- > I->T MaxRecvDataSegmentLength=512, F=0 > T->I F=0 > I->T (changed the ITT) F=1 > T->I Reject > > Finally, are you saying that more than one task can be outstanding at the > target before the target sets F==1? If so, we may have something to debate. No, I'm saying that since the second PDU had a different had a different ITT, the target should have started up a second text nego task. Said task should have noticed that there already was a text nego task and thus aborted itself. Take care, Bill _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips