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 h3Q7ibx18389 for ips-outgoing; Sat, 26 Apr 2003 03:44:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3Q7iZF18385 for ; Sat, 26 Apr 2003 03:44:35 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h3Q7iSCi106202; Sat, 26 Apr 2003 09:44:28 +0200 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3Q7iK6a230432; Sat, 26 Apr 2003 09:44:20 +0200 In-Reply-To: To: "Pittman, Joseph" Cc: cbm@rose.hp.com, csapuntz@cisco.com, "dl-iscsi-eng" , efri@sangate.com, ips@ece.cmu.edu, "Kalman Meth" , ips@ece.cmu.edu Subject: Re: iSCSI: ISID RULE and Discovery sessions MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1 February 07, 2003 From: "Julian Satran" Message-ID: Date: Sat, 26 Apr 2003 10:44:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 26/04/2003 10:44:27, Serialize complete at 26/04/2003 10:44:27 Content-Type: multipart/alternative; boundary="=_alternative 0025D0ACC2256D14_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0025D0ACC2256D14_= Content-Type: text/plain; charset="US-ASCII" It is true that in the discovery session the initiator does not have to specify a TargetName as the purpose of the discovery session was to discover the targets. As such the discovery session is technically a session with the "iSCSI Node" and the only thing that can bring it down is logout or another discovery session with the same InitiatorName and Isid. Regards, Julo "Pittman, Joseph" 25/04/03 21:08 To Julian Satran/Haifa/IBM@IBMIL, Kalman Meth/Haifa/IBM@IBMIL, , , , cc "dl-iscsi-eng" Subject iSCSI: ISID RULE and Discovery sessions iSCSI specification authors and experts, My name is Joe Pittman, an engineering at Network Appliance. My group has implemented an iSCSI target based on draft 20 of the iSCSI specification. During interoperability testing, we have encountered an initiator (Cisco Linux initiator from SourceForge), whose implementers have interpreted the ISID RULE differently from the NetApp target implementation. I need an authoritative ruling on the applicability of the ISID RULE for Discovery sessions. The ISID RULE states the following (draft-ietf-ips-iscsi-20.txt, section 3.4.3): ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), there can only be one session with a given value for ISID that identifies the SCSI initiator port. Consider the case where an initiator {InitiatorName X, ISID I} has created a Discovery session to a target. Then, without terminating this session via LOGOUT, the same initiator {X,I} creates a new Normal session to the same target, at the same target portal. The question is, should the target terminate the existing Discovery session in order to enforce the ISID RULE? Because there is no mention of Discovery sessions vs. Normal sessions in the ISID RULE section, my interpretation of the specification was that the existing Discovery session MUST be terminated. But one of the authors of the Cisco Linux initiator interpreted the specification differently. Here is an excerpt from an e-mail message describing his logic: > Discovery sessions don't have TargetNames, and the implicit logout > only occurs when the InitiatorName, ISID, and TargetName all match. > It should thus be impossible for a normal session to logout a > discovery session, since the TargetNames for the two sessions can > never match. I think your target has a bug. > > Discovery sessions don't really connect to a particular iSCSI > target. It's more a connection to the iSCSI Node as a whole. > Normal sessions connect to particular iSCSI targets. This should > keep the two session types from conflicting, even if the ISIDs > are the same. So, will one of you authors rule on this disagreement? I am eager to fix my bug, if my interpretation was in error. One followup question: Also, if the Cisco interpretation is correct, then does the ISID rule apply to two Discovery sessions? That is, if the target receives a second Discovery session while the first Discovery session is still active, MUST the target terminate the first Discovery session in order to enforce the ISID RULE? Thanks in advance for any help you can provide. -- Joe Pittman jpittman@netapp.com --=_alternative 0025D0ACC2256D14_= Content-Type: text/html; charset="US-ASCII"
It is true that  in the discovery session the initiator does not have to specify a TargetName as  the purpose of the discovery session was to discover the targets.
As such the discovery session is technically a session with the "iSCSI Node" and the only thing that can bring it down is logout or another discovery session with the same InitiatorName and Isid.

Regards,
Julo


"Pittman, Joseph" <Joseph.Pittman@netapp.com>

25/04/03 21:08

To
Julian Satran/Haifa/IBM@IBMIL, Kalman Meth/Haifa/IBM@IBMIL, <csapuntz@cisco.com>, <efri@sangate.com>, <cbm@rose.hp.com>, <ips@ece.cmu.edu>
cc
"dl-iscsi-eng" <dl-iscsi-eng@netapp.com>
Subject
iSCSI: ISID RULE and Discovery sessions





iSCSI specification authors and experts,

My name is Joe Pittman, an engineering at Network Appliance.
My group has implemented an iSCSI target based on draft 20
of the iSCSI specification.

During interoperability testing, we have encountered an initiator
(Cisco Linux initiator from SourceForge), whose implementers have
interpreted the ISID RULE differently from the NetApp target
implementation.  I need an authoritative ruling on the applicability
of the ISID RULE for Discovery sessions.

The ISID RULE states the following (draft-ietf-ips-iscsi-20.txt,
section 3.4.3):

   ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
  Group (SCSI target port), there can only be one session with a given
  value for ISID that identifies the SCSI initiator port.

Consider the case where an initiator {InitiatorName X, ISID I} has
created a Discovery session to a target.  Then, without terminating
this session via LOGOUT, the same initiator {X,I} creates a new
Normal session to the same target, at the same target portal.  The
question is, should the target terminate the existing Discovery
session in order to enforce the ISID RULE?

Because there is no mention of Discovery sessions vs. Normal sessions
in the ISID RULE section, my interpretation of the specification
was that the existing Discovery session MUST be terminated.

But one of the authors of the Cisco Linux initiator interpreted
the specification differently.  Here is an excerpt from an e-mail
message describing his logic:

> Discovery sessions don't have TargetNames, and the implicit logout
> only occurs when the InitiatorName, ISID, and TargetName all match.
> It should thus be impossible for a normal session to logout a
> discovery session, since the TargetNames for the two sessions can
> never match.  I think your target has a bug.
>
> Discovery sessions don't really connect to a particular iSCSI
> target.  It's more a connection to the iSCSI Node as a whole.
> Normal sessions connect to particular iSCSI targets.  This should
> keep the two session types from conflicting, even if the ISIDs
> are the same.

So, will one of you authors rule on this disagreement?  I am
eager to fix my bug, if my interpretation was in error.

One followup question:
Also, if the Cisco interpretation is correct, then does the ISID
rule apply to two Discovery sessions?  That is, if the target
receives a second Discovery session while the first Discovery
session is still active, MUST the target terminate the first
Discovery session in order to enforce the ISID RULE?

Thanks in advance for any help you can provide.
--
Joe Pittman
jpittman@netapp.com

--=_alternative 0025D0ACC2256D14_=--