Re: iSCSI: ISID RULE and Discovery sessions

["Julian Satran" <Julian_Satran@il.ibm.com>]

Mallikarjun,

By discussing this further we create
an issue where none exist (an all this for a mechanism that I KNEW will
get to hunt us).
On the long run no serious discovery
will be based in the "discovery session" and if there will be
sometime a second version we can drop it and use only the standardized
alternatives (iSNS, SLP, Bluefin etc.). Meanwhile let the rules be as they
are. There is no harm done if a discovery session is dropped if the same
initiator connects the same target with the same ISID (the target recognizes
itself as the same target!).  

Let sleeping dogs lie..

Julo

"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

29/04/03 06:19

To	<ips@ece.cmu.edu>
cc
Subject	Re: iSCSI: ISID RULE and Discovery sessions

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