Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h3TMpHN06812
	for ips-outgoing; Tue, 29 Apr 2003 18:51:17 -0400 (EDT)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h3TMpEb06799
	for <ips@ece.cmu.edu>; Tue, 29 Apr 2003 18:51:14 -0400 (EDT)
Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191])
	by atlrel8.hp.com (Postfix) with ESMTP
	id BB8E81C01916; Tue, 29 Apr 2003 18:51:12 -0400 (EDT)
Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187])
	by xatlrelay2.atl.hp.com (Postfix) with ESMTP
	id 816BE1C000B1; Tue, 29 Apr 2003 18:51:12 -0400 (EDT)
Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2655.55)
	id <JLC5LCRP>; Tue, 29 Apr 2003 18:51:12 -0400
Message-ID: <6BD67FFB937FD411A04F00D0B74FE878102F6172@xrose06.rose.hp.com>
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie.krueger@hp.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>,
   "Mallikarjun C." <cbm@rose.hp.com>
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: ISID RULE and Discovery sessions
Date: Tue, 29 Apr 2003 18:51:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C30EA1.D3F554E0"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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_01C30EA1.D3F554E0
Content-Type: text/plain

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_01C30EA1.D3F554E0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2722.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=114420921-29042003><FONT face=Georgia color=#0000ff size=2>I'm 
inclined&nbsp;to&nbsp;agree with&nbsp;Julian, discovery sessions are a crufty 
short-term "protocol assist" and&nbsp;I wouldn't &nbsp;change the rules to 
&nbsp;be more friendly to the use of this discovery method.&nbsp; I feel the 
rules should stand as currently stated, with some clarification.&nbsp; I 
question the wisdom in developing a different set of rules for "discovery 
sessions" and see&nbsp;no harm in enforcing the ISID rule on a discovery 
session.&nbsp; Let's keep enforcement as simple as possible.&nbsp; 
</FONT></SPAN></DIV>
<DIV><SPAN class=114420921-29042003><FONT face=Georgia color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=114420921-29042003><FONT face=Georgia color=#0000ff size=2>The 
ambiguity in enforcing the ISID rule on a discovery session arises from the fact 
that there is no "target node" identified.&nbsp; Since a discovery session can 
conceptually be thought to be to "all targets on this iSCSI entity" we 
could&nbsp;say that any (every?)&nbsp;target node within an iSCSI entity will 
enforce the ISID rule on discovery sessions from a particular 
initiator.&nbsp;&nbsp;&nbsp; I can't see any&nbsp;particular hardship that this 
causes for an initiator?&nbsp; One discovery session is all that's necessary to 
"discover" all the target nodes serviced by that&nbsp;target portal group. 
&nbsp;It makes target enforcement symmetric regardless of session 
type.</FONT></SPAN></DIV>
<DIV><SPAN class=114420921-29042003><FONT face=Georgia color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=114420921-29042003><FONT face=Georgia color=#0000ff size=2>
<P><FONT size=2>Marjorie Krueger<BR>Networked Storage Architecture<BR>Networked 
Storage Solutions<BR>Hewlett-Packard</FONT></FONT></SPAN></P></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Julian Satran 
  [mailto:Julian_Satran@il.ibm.com] <BR><B>Sent:</B> Monday, April 28, 2003 
  11:07 PM<BR><B>To:</B> Mallikarjun C.<BR><B>Cc:</B> 
  ips@ece.cmu.edu<BR><B>Subject:</B> Re: iSCSI: ISID RULE and Discovery 
  sessions<BR><BR></FONT></DIV><BR><FONT face=sans-serif 
  size=2>Mallikarjun,</FONT> <BR><BR><FONT face=sans-serif size=2>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).</FONT> <BR><FONT face=sans-serif size=2>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!). &nbsp;</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Let sleeping dogs lie..</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Julo</FONT> <BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD width="40%"><FONT face=sans-serif size=1><B>"Mallikarjun C." 
        &lt;cbm@rose.hp.com&gt;</B> </FONT><BR><FONT face=sans-serif size=1>Sent 
        by: owner-ips@ece.cmu.edu</FONT> 
        <P><FONT face=sans-serif size=1>29/04/03 06:19</FONT> </P>
      <TD width="59%">
        <TABLE width="100%">
          <TBODY>
          <TR>
            <TD>
              <DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
            <TD vAlign=top><FONT face=sans-serif 
              size=1>&lt;ips@ece.cmu.edu&gt;</FONT> 
          <TR>
            <TD>
              <DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
            <TD vAlign=top>
          <TR>
            <TD>
              <DIV align=right><FONT face=sans-serif size=1>Subject</FONT></DIV>
            <TD vAlign=top><FONT face=sans-serif size=1>Re: iSCSI: ISID RULE 
              and Discovery sessions</FONT></TR></TBODY></TABLE><BR>
        <TABLE>
          <TBODY>
          <TR vAlign=top>
            <TD>
            <TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><FONT 
  size=2><TT>ISID is there for reasons that do not have anything <BR>to do with 
  ISID RULE. &nbsp;The rule only takes advantage <BR>of ISID to enforce I_T 
  nexus uniqueness. &nbsp;<BR><BR>As Julian and I said, a discovery session is 
  just an <BR>iSCSI protocol-ism that simply isn't related to an <BR>I_T 
  nexus.<BR>--<BR>Mallikarjun<BR><BR>Mallikarjun Chadalapaka<BR>Networked 
  Storage Architecture<BR>Network Storage Solutions<BR>Hewlett-Packard MS 5668 
  <BR>Roseville CA 95747<BR>cbm@rose.hp.com<BR><BR><BR>----- Original Message 
  ----- <BR>From: "mphaneen" &lt;mphaneen@npd.hcltech.com&gt;<BR>To: 
  "Mallikarjun C." &lt;cbm@rose.hp.com&gt;; "Julian Satran" 
  &lt;Julian_Satran@il.ibm.com&gt;<BR>Cc: &lt;ips@ece.cmu.edu&gt;<BR>Sent: 
  Monday, April 28, 2003 7:16 PM<BR>Subject: Re: iSCSI: ISID RULE and Discovery 
  sessions<BR><BR><BR>&gt; Hi,<BR>&gt; &nbsp; &nbsp; *If* ISID RULE does not 
  apply to Discovery session, then<BR>&gt; I believe, the ISID information is 
  immaterial for the Discovery session.<BR>&gt; And thus I propose, an ISID need 
  not be generated for a Discovery<BR>&gt; session at all.<BR>&gt; <BR>&gt; 
  &nbsp; &nbsp; Regards<BR>&gt; &nbsp; &nbsp; Phani<BR>&gt; <BR>&gt; Phaneendra. 
  M<BR>&gt; Member Technical Staff<BR>&gt; HCL TECHNOLOGIES LTD.<BR>&gt; 
  Chennai, India.<BR>&gt; Phone: +91 044 23728366 extn: 1135<BR>&gt; <BR>&gt; 
  Visit us at:<BR>&gt; http://www.hcltech.com/san<BR>&gt; <BR>&gt; <BR>&gt; 
  ----- Original Message -----<BR>&gt; From: "Mallikarjun C." 
  &lt;cbm@rose.hp.com&gt;<BR>&gt; To: "Julian Satran" 
  &lt;Julian_Satran@il.ibm.com&gt;<BR>&gt; Cc: &lt;ips@ece.cmu.edu&gt;<BR>&gt; 
  Sent: Monday, April 28, 2003 11:16 PM<BR>&gt; Subject: Re: iSCSI: ISID RULE 
  and Discovery sessions<BR>&gt; <BR>&gt; <BR>&gt; &gt; Julian,<BR>&gt; 
  &gt;<BR>&gt; &gt; &gt;or another<BR>&gt; &gt; &gt; discovery session with the 
  same InitiatorName and Isid.<BR>&gt; &gt;<BR>&gt; &gt; This may be hard to 
  specify and also to implement. &nbsp;The question that<BR>&gt; comes<BR>&gt; 
  &gt; up will be - to the same target network entity or to the same target 
  node?<BR>&gt; &gt; There may be concurrent discovery sessions attached to just 
  one specific<BR>&gt; &gt; TargetName as well within that network entity, and I 
  presume we don't want<BR>&gt; &gt; to bring them down when a new entity-level 
  discovery session is<BR>&gt; instantiated.<BR>&gt; &gt;<BR>&gt; &gt; My 
  preference is to just not apply the ISID RULE in any scope to the<BR>&gt; &gt; 
  discovery sessions. &nbsp;There's no logical correctness issue in any case 
  with<BR>&gt; them.<BR>&gt; &gt;<BR>&gt; &gt; If we agree that it's the 
  reasonable thing to do, it might be useful to<BR>&gt; add<BR>&gt; &gt; the 
  following text to 12.21 ("SessionType"), if doing so is possible<BR>&gt; 
  anymore.....<BR>&gt; &gt; (David? &nbsp;Or is it something that has to wait 
  for getting in to the command<BR>&gt; &gt; ordering draft? )<BR>&gt; 
  &gt;<BR>&gt; &gt; "A discovery session is an iSCSI-level protocol construct 
  and so is not<BR>&gt; &gt; &nbsp;an I_T nexus. &nbsp;The "ISID RULE" stated in 
  section 3.4.3 is thus not<BR>&gt; applicable<BR>&gt; &gt; &nbsp;to discovery 
  sessions."<BR>&gt; &gt;<BR>&gt; &gt; Thanks.<BR>&gt; &gt; --<BR>&gt; &gt; 
  Mallikarjun<BR>&gt; &gt;<BR>&gt; &gt; Mallikarjun Chadalapaka<BR>&gt; &gt; 
  Networked Storage Architecture<BR>&gt; &gt; Network Storage Solutions<BR>&gt; 
  &gt; Hewlett-Packard MS 5668<BR>&gt; &gt; Roseville CA 95747<BR>&gt; &gt; 
  cbm@rose.hp.com<BR>&gt; &gt;<BR>&gt; &gt; ----- Original Message -----<BR>&gt; 
  &gt; From: "Julian Satran" &lt;Julian_Satran@il.ibm.com&gt;<BR>&gt; &gt; To: 
  "Pittman, Joseph" &lt;Joseph.Pittman@netapp.com&gt;<BR>&gt; &gt; Cc: 
  &lt;cbm@rose.hp.com&gt;; &lt;csapuntz@cisco.com&gt;; "dl-iscsi-eng"<BR>&gt; 
  &lt;dl-iscsi-eng@netapp.com&gt;; &lt;efri@sangate.com&gt;;<BR>&gt; &gt; 
  &lt;ips@ece.cmu.edu&gt;; "Kalman Meth" &lt;meth@il.ibm.com&gt;; 
  &lt;ips@ece.cmu.edu&gt;<BR>&gt; &gt; Sent: Saturday, April 26, 2003 12:44 
  AM<BR>&gt; &gt; Subject: Re: iSCSI: ISID RULE and Discovery sessions<BR>&gt; 
  &gt;<BR>&gt; &gt;<BR>&gt; &gt; &gt; It is true that &nbsp;in the discovery 
  session the initiator does not have to<BR>&gt; &gt; &gt; specify a TargetName 
  as &nbsp;the purpose of the discovery session was to<BR>&gt; &gt; &gt; 
  discover the targets.<BR>&gt; &gt; &gt; As such the discovery session is 
  technically a session with the "iSCSI<BR>&gt; &gt; &gt; Node" and the only 
  thing that can bring it down is logout or another<BR>&gt; &gt; &gt; discovery 
  session with the same InitiatorName and Isid.<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt; Regards,<BR>&gt; &gt; &gt; Julo<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; "Pittman, Joseph" 
  &lt;Joseph.Pittman@netapp.com&gt;<BR>&gt; &gt; &gt; 25/04/03 21:08<BR>&gt; 
  &gt; &gt;<BR>&gt; &gt; &gt; To<BR>&gt; &gt; &gt; Julian 
  Satran/Haifa/IBM@IBMIL, Kalman Meth/Haifa/IBM@IBMIL,<BR>&gt; &gt; &gt; 
  &lt;csapuntz@cisco.com&gt;, &lt;efri@sangate.com&gt;, 
  &lt;cbm@rose.hp.com&gt;,<BR>&gt; &gt; &gt; &lt;ips@ece.cmu.edu&gt;<BR>&gt; 
  &gt; &gt; cc<BR>&gt; &gt; &gt; "dl-iscsi-eng" 
  &lt;dl-iscsi-eng@netapp.com&gt;<BR>&gt; &gt; &gt; Subject<BR>&gt; &gt; &gt; 
  iSCSI: ISID RULE and Discovery sessions<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; 
  &gt;<BR>&gt; &gt; &gt; iSCSI specification authors and experts,<BR>&gt; &gt; 
  &gt; My name is Joe Pittman, an engineering at Network Appliance.<BR>&gt; &gt; 
  &gt; My group has implemented an iSCSI target based on draft 20<BR>&gt; &gt; 
  &gt; of the iSCSI specification.<BR>&gt; &gt; &gt; During interoperability 
  testing, we have encountered an initiator<BR>&gt; &gt; &gt; (Cisco Linux 
  initiator from SourceForge), whose implementers have<BR>&gt; &gt; &gt; 
  interpreted the ISID RULE differently from the NetApp target<BR>&gt; &gt; &gt; 
  implementation. &nbsp;I need an authoritative ruling on the 
  applicability<BR>&gt; &gt; &gt; of the ISID RULE for Discovery 
  sessions.<BR>&gt; &gt; &gt; The ISID RULE states the following 
  (draft-ietf-ips-iscsi-20.txt,<BR>&gt; &gt; &gt; section 3.4.3):<BR>&gt; &gt; 
  &gt; &nbsp; &nbsp;ISID RULE: Between a given iSCSI Initiator and iSCSI Target 
  Portal<BR>&gt; &gt; &gt; &nbsp; &nbsp;Group (SCSI target port), there can only 
  be one session with a given<BR>&gt; &gt; &gt; &nbsp; &nbsp;value for ISID that 
  identifies the SCSI initiator port.<BR>&gt; &gt; &gt; Consider the case where 
  an initiator {InitiatorName X, ISID I} has<BR>&gt; &gt; &gt; created a 
  Discovery session to a target. &nbsp;Then, without terminating<BR>&gt; &gt; 
  &gt; this session via LOGOUT, the same initiator {X,I} creates a new<BR>&gt; 
  &gt; &gt; Normal session to the same target, at the same target portal. 
  &nbsp;The<BR>&gt; &gt; &gt; question is, should the target terminate the 
  existing Discovery<BR>&gt; &gt; &gt; session in order to enforce the ISID 
  RULE?<BR>&gt; &gt; &gt; Because there is no mention of Discovery sessions vs. 
  Normal sessions<BR>&gt; &gt; &gt; in the ISID RULE section, my interpretation 
  of the specification<BR>&gt; &gt; &gt; was that the existing Discovery session 
  MUST be terminated.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; But one of the authors 
  of the Cisco Linux initiator interpreted<BR>&gt; &gt; &gt; the specification 
  differently. &nbsp;Here is an excerpt from an e-mail<BR>&gt; &gt; &gt; message 
  describing his logic:<BR>&gt; &gt; &gt; &gt; Discovery sessions don't have 
  TargetNames, and the implicit logout<BR>&gt; &gt; &gt; &gt; only occurs when 
  the InitiatorName, ISID, and TargetName all match.<BR>&gt; &gt; &gt; &gt; It 
  should thus be impossible for a normal session to logout a<BR>&gt; &gt; &gt; 
  &gt; discovery session, since the TargetNames for the two sessions can<BR>&gt; 
  &gt; &gt; &gt; never match. &nbsp;I think your target has a bug.<BR>&gt; &gt; 
  &gt; &gt;<BR>&gt; &gt; &gt; &gt; Discovery sessions don't really connect to a 
  particular iSCSI<BR>&gt; &gt; &gt; &gt; target. &nbsp;It's more a connection 
  to the iSCSI Node as a whole.<BR>&gt; &gt; &gt; &gt; Normal sessions connect 
  to particular iSCSI targets. &nbsp;This should<BR>&gt; &gt; &gt; &gt; keep the 
  two session types from conflicting, even if the ISIDs<BR>&gt; &gt; &gt; &gt; 
  are the same.<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; So, will one of you authors 
  rule on this disagreement? &nbsp;I am<BR>&gt; &gt; &gt; eager to fix my bug, 
  if my interpretation was in error.<BR>&gt; &gt; &gt; One followup 
  question:<BR>&gt; &gt; &gt; Also, if the Cisco interpretation is correct, then 
  does the ISID<BR>&gt; &gt; &gt; rule apply to two Discovery sessions? 
  &nbsp;That is, if the target<BR>&gt; &gt; &gt; receives a second Discovery 
  session while the first Discovery<BR>&gt; &gt; &gt; session is still active, 
  MUST the target terminate the first<BR>&gt; &gt; &gt; Discovery session in 
  order to enforce the ISID RULE?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Thanks in 
  advance for any help you can provide.<BR>&gt; &gt; &gt; --<BR>&gt; &gt; &gt; 
  Joe Pittman<BR>&gt; &gt; &gt; jpittman@netapp.com<BR>&gt; &gt; &gt;<BR>&gt; 
  <BR>&gt; <BR><BR></TT></FONT><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C30EA1.D3F554E0--