Re: iSCSI: ISID RULE and Discovery sessions

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

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
>