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 h3T2JGW11228 for ips-outgoing; Mon, 28 Apr 2003 22:19:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3T2JCb11223 for ; Mon, 28 Apr 2003 22:19:12 -0400 (EDT) Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HNWQ91DB; Tue, 29 Apr 2003 07:46:45 +0530 Received: from mphaneenpc (MPHANEEN-PC [192.168.19.83]) by pilex.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JYTN3KNL; Tue, 29 Apr 2003 07:46:21 +0530 Message-ID: <018e01c30df5$534b53a0$5313a8c0@hcltntl.co.in> Reply-To: "mphaneen" From: "mphaneen" To: "Mallikarjun C." , "Julian Satran" Cc: References: <002301c30dae$237beaa0$766f030f@rose.hp.com> Subject: Re: iSCSI: ISID RULE and Discovery sessions Date: Tue, 29 Apr 2003 07:46:21 +0530 Organization: HCL TECHNOLOGIES LTD. 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, *If* ISID RULE does not apply to Discovery session, then I believe, the ISID information is immaterial for the Discovery session. And thus I propose, an ISID need not be generated for a Discovery session at all. Regards Phani Phaneendra. M Member Technical Staff HCL TECHNOLOGIES LTD. Chennai, India. Phone: +91 044 23728366 extn: 1135 Visit us at: http://www.hcltech.com/san ----- Original Message ----- From: "Mallikarjun C." To: "Julian Satran" Cc: Sent: Monday, April 28, 2003 11:16 PM Subject: Re: iSCSI: ISID RULE and Discovery sessions > Julian, > > >or another > > discovery session with the same InitiatorName and Isid. > > This may be hard to specify and also to implement. The question that comes > up will be - to the same target network entity or to the same target node? > There may be concurrent discovery sessions attached to just one specific > TargetName as well within that network entity, and I presume we don't want > to bring them down when a new entity-level discovery session is instantiated. > > My preference is to just not apply the ISID RULE in any scope to the > discovery sessions. There's no logical correctness issue in any case with them. > > If we agree that it's the reasonable thing to do, it might be useful to add > the following text to 12.21 ("SessionType"), if doing so is possible anymore..... > (David? Or is it something that has to wait for getting in to the command > ordering draft? ) > > "A discovery session is an iSCSI-level protocol construct and so is not > an I_T nexus. The "ISID RULE" stated in section 3.4.3 is thus not applicable > to discovery sessions." > > Thanks. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Julian Satran" > To: "Pittman, Joseph" > Cc: ; ; "dl-iscsi-eng" ; ; > ; "Kalman Meth" ; > Sent: Saturday, April 26, 2003 12:44 AM > Subject: Re: iSCSI: ISID RULE and Discovery sessions > > > > 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 > >