|
Title: Message
I'm
inclined to agree with Julian, discovery sessions are a crufty
short-term "protocol assist" and I wouldn't change the rules to
be more friendly to the use of this discovery method. I feel the
rules should stand as currently stated, with some clarification. I
question the wisdom in developing a different set of rules for "discovery
sessions" and see no harm in enforcing the ISID rule on a discovery
session. Let's keep enforcement as simple as possible.
The
ambiguity in enforcing the ISID rule on a discovery session arises from the fact
that there is no "target node" identified. Since a discovery session can
conceptually be thought to be to "all targets on this iSCSI entity" we
could say that any (every?) target node within an iSCSI entity will
enforce the ISID rule on discovery sessions from a particular
initiator. I can't see any particular hardship that this
causes for an initiator? One discovery session is all that's necessary to
"discover" all the target nodes serviced by that target portal group.
It makes target enforcement symmetric regardless of session
type.
Marjorie Krueger Networked Storage Architecture Networked
Storage Solutions Hewlett-Packard
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 > > > >
>
Home
Last updated: Tue Apr 29 19:19:25 2003
12556 messages in chronological order
|