Re: iSCSI: ISID RULE and Discovery sessions

["Mallikarjun C." <cbm@rose.hp.com>]

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" <mphaneen@npd.hcltech.com>
To: "Mallikarjun C." <cbm@rose.hp.com>; "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
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." <cbm@rose.hp.com>
> To: "Julian Satran" <Julian_Satran@il.ibm.com>
> Cc: <ips@ece.cmu.edu>
> 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" <Julian_Satran@il.ibm.com>
> > To: "Pittman, Joseph" <Joseph.Pittman@netapp.com>
> > Cc: <cbm@rose.hp.com>; <csapuntz@cisco.com>; "dl-iscsi-eng"
> <dl-iscsi-eng@netapp.com>; <efri@sangate.com>;
> > <ips@ece.cmu.edu>; "Kalman Meth" <meth@il.ibm.com>; <ips@ece.cmu.edu>
> > 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" <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
> > >
> 
>