Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0O6t3u18120 for ips-outgoing; Fri, 24 Jan 2003 01:55:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0O6sxW18114; Fri, 24 Jan 2003 01:54:59 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0O6sqT2018394; Fri, 24 Jan 2003 07:54:52 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0O6spIo203998; Fri, 24 Jan 2003 07:54:51 +0100 In-Reply-To: To: Eddy Quicksall Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: FW: iSCSI: LUN in a ping MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Fri, 24 Jan 2003 08:54:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/01/2003 08:54:51, Serialize complete at 24/01/2003 08:54:51 Content-Type: multipart/alternative; boundary="=_alternative 0025EB40C2256CB8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0025EB40C2256CB8_= Content-Type: text/plain; charset="US-ASCII" As I said - initiator has no iSCSI way of telling if a LUN is "real" or not for things originated at the target. As long as a controller can "route" the resulting outgoing NOP you are free to use any LUN. And in a "monolithic" controller you can always use LUN 0. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 23/01/03 21:28 To ips@ece.cmu.edu cc Subject FW: iSCSI: LUN in a ping Another thing to be said here ... after a login, there may not be any LUN except the required LUN 0 and that may not have any devices attached. But a ping may be necessary if no additional traffic ensues. I assume is acceptable to just always report LUN 0 even though it doesn't have any peripheral devices (peripheral qualifier = 011b). Eddy -----Original Message----- From: Eddy Quicksall Sent: Thursday, January 23, 2003 1:56 PM To: 'Julian Satran' Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison Subject: RE: iSCSI: LUN in a ping True and I apologize for that remark. I asked how the initiator would use it and what you pointed out was that the target would use it to identify origin. If the initiator is only required to echo it and not interpret it, then I see no reason to force a target to fill it in. For example in my case, a valid LUN is not readily available at the time that I want to send a ping. Granted it is not in a fast path but, by my poorly thought out remark, I am saying a spec should not mandate requirements that have no use. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, January 23, 2003 11:47 AM To: Eddy Quicksall Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison Subject: RE: iSCSI: LUN in a ping Eddy, We all appreciate you opinion - but this has been hotly debated more than 18 months ago. And I recall sending you an explanation regarding the middle boxes and how they handle the LUN for routing in a "clustered" target. And your comment about a "requirement with no good reason" besides being derogatory does not add any value to the discussion. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 23/01/03 17:19 To Rod Harrison , Julian Satran , ips@ece.cmu.edu cc Subject RE: iSCSI: LUN in a ping For that, wouldn't the target generate REPORTED LUNS DATA HAS CHANGED (3F/0E)? It is my opinion that this is just another requirement that has been put on the target for no good reason. It should be up to the target as to if the LUN field has meaning and the initiator should be the one that has a requirement to echo the value. Eddy -----Original Message----- From: Rod Harrison [mailto:rod.harrison@windriver.com] Sent: Wednesday, January 22, 2003 1:52 PM To: Eddy Quicksall; Julian Satran; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping The initiator might try to rediscover the LUN topology if it sees a NOP from a LUN that it previously thought was not present. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Wednesday, January 22, 2003 10:28 AM To: Julian Satran; Eddy Quicksall; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping Yes, I remember that but the necessity for the target to set it should be up to the target because the initiator should not be trying to interpret it (it should only be required to echo it). Is there a case where the initiator will interpret the LUN? Eddy -----Original Message----- From: Julian Satran [mailto:julian@cs.haifa.ac.il] Sent: Wednesday, January 22, 2003 12:43 AM To: 'Eddy Quicksall'; ips@ece.cmu.edu Subject: RE: iSCSI: LUN in a ping TTT & LUN uniquely identify the "origin" (if target is a "composite" each of the parts can issue their own TTTs - no coordination needed). Regards, Julo -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Eddy Quicksall Sent: 22 January, 2003 00:07 To: ips@ece.cmu.edu Subject: iSCSI: LUN in a ping Does anyone know why we added "the LUN must be valid" for a target initiated ping? It would seem that it is N/A when the ping is just being used to checkup on the connection. What will the initiator do with the LUN anyway? 10.19.3 LUN A LUN MUST be set to a correct value when the Target Transfer Tag is valid (not the reserved value 0xffffffff). Eddy mailto: Eddy_Quicksall@iVivity.com --=_alternative 0025EB40C2256CB8_= Content-Type: text/html; charset="US-ASCII"
As I said - initiator has no iSCSI way of telling if a LUN is "real" or not for things originated at the target.
As long as a controller can "route" the resulting outgoing NOP you are free to use any LUN.
And in a "monolithic" controller you can always use LUN 0.

Julo


Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

23/01/03 21:28

To
ips@ece.cmu.edu
cc
Subject
FW: iSCSI: LUN in a ping





Another thing to be said here ... after a login, there may not be any LUN
except the required LUN 0 and that may not have any devices attached. But a
ping may be necessary if no additional traffic ensues.

I assume is acceptable to just always report LUN 0 even though it doesn't
have any peripheral devices (peripheral qualifier = 011b).

Eddy

-----Original Message-----
From: Eddy Quicksall
Sent: Thursday, January 23, 2003 1:56 PM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison
Subject: RE: iSCSI: LUN in a ping


True and I apologize for that remark.

I asked how the initiator would use it and what you pointed out was that the
target would use it to identify origin.

If the initiator is only required to echo it and not interpret it, then I
see no reason to force a target to fill it in. For example in my case, a
valid LUN is not readily available at the time that I want to send a ping.
Granted it is not in a fast path but, by my poorly thought out remark, I am
saying a spec should not mandate requirements that have no use.

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, January 23, 2003 11:47 AM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu; Julian Satran; owner-ips@ece.cmu.edu; Rod Harrison
Subject: RE: iSCSI: LUN in a ping



Eddy,

We all appreciate you opinion - but this has been hotly debated more than 18
months ago.
And I recall sending you an explanation regarding the middle boxes and how
they handle the LUN for routing in a "clustered" target.
And your comment about a "requirement with no good reason" besides being
derogatory does not add any value to the discussion.

Julo



Eddy Quicksall <eddy_quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu


23/01/03 17:19


To
Rod Harrison <rod.harrison@windriver.com>, Julian Satran
<julian@cs.haifa.ac.il>, ips@ece.cmu.edu

cc

Subject
RE: iSCSI: LUN in a ping                

                                 




For that, wouldn't the target generate REPORTED LUNS DATA HAS CHANGED
(3F/0E)?

It is my opinion that this is just another requirement that has been put on
the target for no good reason.

It should be up to the target as to if the LUN field has meaning and the
initiator should be the one that has a requirement to echo the value.

Eddy

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Wednesday, January 22, 2003 1:52 PM
To: Eddy Quicksall; Julian Satran; ips@ece.cmu.edu
Subject: RE: iSCSI: LUN in a ping



The initiator might try to rediscover the LUN topology if it sees a NOP from
a
LUN that it previously thought was not present.

- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Wednesday, January 22, 2003 10:28 AM
To: Julian Satran; Eddy Quicksall; ips@ece.cmu.edu
Subject: RE: iSCSI: LUN in a ping


Yes, I remember that but the necessity for the target to set it should be up
to the target because the initiator should not be trying to interpret it (it
should only be required to echo it).

Is there a case where the initiator will interpret the LUN?

Eddy

-----Original Message-----
From: Julian Satran [mailto:julian@cs.haifa.ac.il]
Sent: Wednesday, January 22, 2003 12:43 AM
To: 'Eddy Quicksall'; ips@ece.cmu.edu
Subject: RE: iSCSI: LUN in a ping


TTT & LUN uniquely identify the "origin" (if target is a "composite"
each of the parts can issue their own TTTs - no coordination needed).

Regards,
Julo


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Eddy Quicksall
Sent: 22 January, 2003 00:07
To: ips@ece.cmu.edu
Subject: iSCSI: LUN in a ping


Does anyone know why we added "the LUN must be valid" for a target
initiated ping? It would seem that it is N/A when the ping is just being
used to checkup on the connection.

What will the initiator do with the LUN anyway?

10.19.3 LUN
A LUN MUST be set to a correct value when the Target Transfer Tag is
valid (not the reserved value 0xffffffff).

Eddy
mailto: Eddy_Quicksall@iVivity.com
--=_alternative 0025EB40C2256CB8_=--