Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3UGL9Y16217 for ; Wed, 30 Apr 2003 12:21:09 -0400 (EDT) Received: by hazard.ece.cmu.edu (Postfix, from userid 953) id A5FA987; Wed, 30 Apr 2003 12:21:07 -0400 (EDT) Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27]) by hazard.ece.cmu.edu (Postfix) with ESMTP id C3DC579; Wed, 30 Apr 2003 12:20:21 -0400 (EDT) Received: by sos.ece.cmu.edu (Postfix) id 5CE9B8958; Wed, 30 Apr 2003 12:20:04 -0400 (EDT) Received: from sos.ece.cmu.edu (localhost [127.0.0.1]) by sos.ece.cmu.edu (Postfix) with ESMTP id E6A138959 for ; Wed, 30 Apr 2003 12:20:02 -0400 (EDT) Received: (from majordom@localhost) by sos.ece.cmu.edu (8.12.9+Sun/8.12.2/Submit) id h3UGK2VZ016936 for ips-outgoing; Wed, 30 Apr 2003 12:20:02 -0400 (EDT) X-Authentication-Warning: sos.ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f X-Original-To: ips@sos.ece.cmu.edu Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by sos.ece.cmu.edu (Postfix) with ESMTP id 306FC8958 for ; Wed, 30 Apr 2003 12:20:01 -0400 (EDT) Received: by bache.ece.cmu.edu (Postfix) id AB61E72; Wed, 30 Apr 2003 12:20:00 -0400 (EDT) Delivered-To: ips@ece.cmu.edu Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 7BFFF73; Wed, 30 Apr 2003 12:20:00 -0400 (EDT) Received: from mail.ivivity.com (unknown [64.238.111.99]) by bache.ece.cmu.edu (Postfix) with ESMTP id 12EF272 for ; Wed, 30 Apr 2003 12:19:36 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id <2CY0SSCW>; Wed, 30 Apr 2003 12:19:34 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran Cc: "Mallikarjun C." , ips@ece.cmu.edu, "KRUEGER,MARJORIE (HP-Roseville,ex1)" Subject: RE: iSCSI: ISID RULE and Discovery sessions Date: Wed, 30 Apr 2003 12:19:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30F34.4967A0B0" Sender: owner-ips@ece.cmu.edu Precedence: bulk X-Spam-Status: No, hits=-7.1 required=5.0 tests=HTML_40_50,HTML_FONT_COLOR_BLUE,HTML_FONT_COLOR_NAME, HTML_FONT_FACE_ODD,HTML_MESSAGE,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30F34.4967A0B0 Content-Type: text/plain >The current rule leaves it clearly to the target. I am assuming you mean that dropping the connection is up to the target implementation. Is that the correct interpretation? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, April 30, 2003 9:26 AM To: Eddy Quicksall Cc: Mallikarjun C.; ips@ece.cmu.edu; KRUEGER,MARJORIE (HP-Roseville,ex1) Subject: RE: iSCSI: ISID RULE and Discovery sessions The current rule leaves it clearly to the target. If the target recognizes the Initiator-ISID (it is in its own domain) it will drop the session. It does not say that the target must be designed so as to recognize any other target instances on the same node. And we should leave it so. Julo Eddy Quicksall 30/04/03 15:25 To "KRUEGER,MARJORIE (HP-Roseville,ex1)" , Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." cc ips@ece.cmu.edu Subject RE: iSCSI: ISID RULE and Discovery sessions I think you should just leave it as is. Since there is no TargetName, then the ISID rule would not apply. If initiators would like to use a different ISID for each simultaneous discovery session, then that would be perfectly fine. If you enforce the ISID rule where it was not really intended, you could open a can of worms. Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com] Sent: Tuesday, April 29, 2003 6:51 PM To: 'Julian Satran'; Mallikarjun C. Cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISID RULE and Discovery sessions 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 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, April 28, 2003 11:07 PM 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." Sent by: owner-ips@ece.cmu.edu 29/04/03 06:19 To 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" To: "Mallikarjun C." ; "Julian Satran" Cc: 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." > To: "Julian Satran" > Cc: > 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" > > To: "Pittman, Joseph" > > Cc: ; ; "dl-iscsi-eng" > ; ; > > ; "Kalman Meth" ; > > 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" > > > 25/04/03 21:08 > > > > > > To > > > Julian Satran/Haifa/IBM@IBMIL, Kalman Meth/Haifa/IBM@IBMIL, > > > , , , > > > > > > cc > > > "dl-iscsi-eng" > > > 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 > > > > > ------_=_NextPart_001_01C30F34.4967A0B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

>The current rule leaves it = clearly to the target.

 

=

I am assuming you mean that = dropping the connection is up to the target implementation. Is that the correct interpretation?

 

=

Eddy

 

=

-----Original = Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, April = 30, 2003 9:26 AM
To: Eddy Quicksall
Cc: Mallikarjun C.; = ips@ece.cmu.edu; KRUEGER,MARJORIE (HP-Roseville,ex1)
Subject: RE: iSCSI: ISID = RULE and Discovery sessions

 


The current rule leaves it clearly to the = target. If the target recognizes the Initiator-ISID (it is in  its own = domain) it will drop the session.
It does not say that the target must be designed so as to recognize any = other target instances on the same node.
And we should leave it so.

Julo

Eddy Quicksall <eddy_quicksall@ivivity.com> =

30/04/03 15:25

To

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie.krueger@hp.com>, Julian Satran/Haifa/IBM@IBMIL, "Mallikarjun C." = <cbm@rose.hp.com>

cc

ips@ece.cmu.edu =

Subject

RE: iSCSI: ISID RULE and Discovery = sessions

 

 

 




I think you should just leave it as is. = Since there is no TargetName, then the ISID rule would not = apply.

 

If initiators = would like to use a different ISID for each simultaneous discovery session, then = that would be perfectly fine.

 

If you enforce = the ISID rule where it was not really intended, you could open a can of = worms.

 

Eddy

 

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie.krueger@hp.com]
Sent: Tuesday, April 29, 2003 6:51 PM
To: 'Julian Satran'; Mallikarjun C.
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: ISID RULE and Discovery = sessions

 

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
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] =
Sent: Monday, April 28, 2003 11:07 PM
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
> > >
>
>

------_=_NextPart_001_01C30F34.4967A0B0--