Re: iSCSI: ISID RULE and Discovery sessions

["mphaneen" <mphaneen@npd.hcltech.com>]

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
> >