I agree with Malikarjun's preference
below. I don't think we should just drop the other discovery session ...
it may not be expected by the initiator. An identical ISID for a second
discovery session does not hurt anything.
Eddy
-----Original Message-----
From: Julian Satran
[mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, April 29, 2003 2:07
AM
To: Mallikarjun C.
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: ISID RULE and
Discovery sessions
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
> > >
>
>
