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 h3T3JtU14774 for ips-outgoing; Mon, 28 Apr 2003 23:19:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3T3Jkb14759 for ; Mon, 28 Apr 2003 23:19:46 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel12.hp.com (Postfix) with ESMTP id 29D431C00FFA for ; Mon, 28 Apr 2003 20:19:45 -0700 (PDT) Received: from swathi (pal1nai162069.nsr.hp.com [15.244.162.69]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id UAA02913 for ; Mon, 28 Apr 2003 20:19:44 -0700 (PDT) Message-ID: <004401c30dfe$2dbb26c0$45a2f40f@rose.hp.com> From: "Mallikarjun C." To: References: <002301c30dae$237beaa0$766f030f@rose.hp.com> <018e01c30df5$534b53a0$5313a8c0@hcltntl.co.in> Subject: Re: iSCSI: ISID RULE and Discovery sessions Date: Mon, 28 Apr 2003 20:19:42 -0700 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ips@ece.cmu.edu Precedence: bulk ISID is there for reasons that do not have anything to do with ISID RULE. The rule only takes advantage of ISID to enforce I_T nexus uniqueness. As Julian and I said, a discovery session is just an iSCSI protocol-ism that simply isn't related to an I_T nexus. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "mphaneen" To: "Mallikarjun C." ; "Julian Satran" Cc: Sent: Monday, April 28, 2003 7:16 PM Subject: Re: iSCSI: ISID RULE and Discovery sessions > 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 > > > > >