Subject: RE: iSCSI: "conservative reuse" requirement

From: [email-masked]
Date: Mon, 24 Dec 2001 11:01:54 -0500

Not exactly.  "Conservative Reuse" would allow an initiator
to present multiple initiator ports, as long as it presented
each of them to all target ports (assuming that the connectivity
exists).  Why would an Initiator want to present different
ports to different target portal groups?  I don't think there's
another example in which SCSI behaves this way in practice.

--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email-masked]]
> Sent: Monday, December 24, 2001 12:47 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: iSCSI: "conservative reuse" requirement
> 
> 
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
> 
> Mandating "conservative reuse" appears to force initiators to 
> always act
> as a single initiator port (wrt one target; assuming only one 
> session as an
> example) per initiator device - which rules out the case of 
> an initiator 
> intentionally wanting to present a different port to each 
> target portal group.
> 
> IMHO, if iSCSI provides an architected mechanism to support shared 
> persistent reservations ("conservative reuse"),  that should 
> be completely 
> adequate to meet the expectations to be a legal SCSI protocol.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668 
> Roseville CA 95747
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, December 21, 2001 4:50 PM
> Subject: iSCSI: "conservative reuse" requirement
> 
> 
> > Santosh Rao writes:
> >  
> > > I am opposed to the suggestion that "conservative re-use" 
> of ISIDs be
> > > made a MUST. This is really only required when initiators 
> need to be
> > > using the new T10 Reservation scheme that can be shared 
> > > across initiator ports.
> > 
> > Those reservations are a Target feature.  With this 
> approach, the ability
> > to use the target feature depends on details of the initiator
> > implementation.
> > More below ... 
> >  
> > > For those initiators that don't care about this type of 
> reservation,
> > > conservative re-use is of no use and initiators may like to assign
> > > ISID's in a per-initiator node fashion, thereby, being 
> able to use these
> > > ISIDs as a lookup index for the sessions on that initiator node.
> > > 
> > > Hence, I suggest that "conservative re-use" be worded as 
> > > "encouraged to use" or something to that effect, but not MUST USE.
> > > 
> > > Comments ?
> > 
> > The "initiator" is more than one entity.  The iSCSI HBA/NIC 
> and driver
> > doesn't know whether shared persistent reservations are 
> being used and
> > shouldn't have to care - they're just more SCSI commands to 
> transport.
> > Some other entity (e.g., clustering software) will be generating the
> > shared persistent reservations.  This raise the possible scenario
> > involving a target that supports the new shared persistent 
> reservations
> > and an entity that wants to use them.  The entity detects 
> (via SCSI means,
> > e.g., something in a mode page) that the Target supports 
> shared persistent
> > reservations, tries to use them, only to discover that they 
> don't work
> > because the iSCSI HBA/NIC doesn't implement "conservative reuse".
> > 
> > I'm worried about this causing both interoperability issues 
> and possible
> > T10 issues -- from a T10 viewpoint, if shared persistent 
> reservations
> > don't work, the initiating entity should have some SCSI-level means
> > of determining this ... if that means exists only on the Target, the
> > above scenario is iSCSI's problem (Target can't query Initiator to
> > determine whether it does "conservative reuse"), and having 
> a separate
> > initiator side means that the entity has to check only for 
> iSCSI (and
> > not for any other SCSI transport) does not seem like the right
> > approach.
> > 
> > I think this is headed towards "conservative reuse" being a MUST if
> > we're serious about support for shared persistent reservations.
> > 
> > Comments?
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > [email-masked]         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
>

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 28 Dec 2001 15:01:29 -0800

Eddy,
There can be parallel Sessions from the same Initiator NODE but not from
the same Initiator SCSI Port (which I call the Initiator iSCSI/SCSI Port).
It is invalid to have more then one Session between an Initiator SCSI Port
and a specific Target SCSI Port (which I call the Target iSCSI/SCSI Port).

The Identifier of the Initiator iSCSI/SCSI Port is the Concatenation of
Initiator Node Name and the ISID.  The Identifier of the Target iSCSI/SCSI
Port is the Concatenation of the Target Node Name and a Target Portal Group
Tag.

SAM-2 Initiator Port Identifier, in the context of iSCSI, is the Identifier
of what I called the Initiator iSCSI/SCSI Port.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Eddy Quicksall" <[email-masked]>@ece.cmu.edu on 12/28/2001
11:19:33 AM

Sent by:    [email-masked]

To:    Jim Hafner/Almaden/IBM@IBMUS
cc:    "ips@ece. cmu. edu \(E-mail\)" <[email-masked]>
Subject:    RE: FW: iSCSI: "conservative reuse" requirement

Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target
port, there can be only one I_T nexus (session)", aren't we always
"assuming no more than one session"?

Or are you talking about more than one session between different SCSI
initiator ports and a single SCSI target port?

Is the ISID equivalent to SAM-2's Initiator Port Identifier?

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, December 28, 2001 12:15 PM
To: John Hufferd; Eddy Quicksall; Mallikarjun C.; [email-masked]
Cc: [email-masked]
Subject: Re: FW: iSCSI: "conservative reuse" requirement

Folks,

Sorry for taking so long to jump into this discussion.

There are a number of issues raised in this thread:
1) should "conservative reuse" of ISIDs be made a MUST
2) does "conservative reuse" imply that all hosts look "single SCSI
ported"

Here's my two cents (using "CR" as a shorthand for "conservative
reuse")

I don't believe that CR needs to be a MUST.  The only time this has
any
real value is in configurations that use SCSI persistent reservations
(and
where new SCSI target reservation features are enabled -- NB.  these
features are yet to be approved but are working their way through the
process). I don't think these are going to be (even in the future) the
majority of installations.  There are many ways then that CR could be
something that is not generally available in most drivers but is added
by
configuration and perhaps even "value add" (:-{)).

In short, I don't see a strong case for this to be a MUST.  So, to
David
Black, my answer is that having a mechanism to enable this feature or
have
it as a "purchase requirement" is an acceptable mechanism to make sure
the
feature is there when needed, but it is need not be a requirement of
the
protocol.  To Mallikarjun, I think I'm agreeing with you that so long
as
there is a mechanism defined, iSCSI has done it's job.

As for the second issue (raised by Mallikarjun), let's look at the
definition of CR.  What is means is that when an iSCSI initiator
(node)
creates ISIDs for use in session identifiers, it attempts to reuse
them
as
much as possible with different SCSI target ports (iSCSI target portal
groups).  This is the only way that a SCSI target or LU can see the
same
SCSI initiator port through two or more of its SCSI target ports --
that
is, that the target can determine multiple paths *from* the same SCSI
initiator port.   But, the model for generating ISIDs is not really at
the
node level but at the initiator portal group level.
So, IMO, the conclusion that all hosts must then look "single SCSI
ported"
is too dramatic.  As I mentioned,  ISIDs are conceptually generated
within
initiator portal groups (that's why we defined the mechanism for
generating
ISIDs).  The conclusion I draw is that (assuming no more than one
session
to any given target portal group), an iSCSI initiator implementing CR
will
have as many SCSI initiator ports as iSCSI initiator portal groups
(independent HBAs?).  Each initiator portal group would generate one
ISID
(that is different from that generated by/for the other initiator
portal
groups) and use CR for repeatability.  [This is consistent with a
model
that mapped SCSI initiator ports to initiator portal groups, which we
had
to abandon because the "assuming no more than one session..." was no
acceptable as a requirement!!!]  This independence of ISIDs for each
initiator portal group allows each initiator portal group to open
sessions
with *every* target portal group it knows about without having to
worry
about interfering with other sessions. [This has shades of the
"partitioning" rule for ISIDs that has been discussed ad nauseum!!!]

(I have a feeling that this note is not well composed -- it is the
holidays, you know).  I hope I've addressed everyone's concerns and we
can
lay this one to rest.

Jim Hafner

John Hufferd
12/25/2001 08:49 AM

To:   "Eddy Quicksall" <[email-masked]>
cc:   Jim Hafner/Almaden/IBM@IBMUS
From: John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document
link:
      Jim Hafner)

You are correct.  The section was created by Jim Hafner, and via this
note
I will ask him if he could answer Mallikarjun Directly since I did not
understand his issue.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

"Eddy Quicksall" <[email-masked]> on 12/24/2001 06:06:44
PM

To:   John Hufferd/San Jose/IBM@IBMUS
cc:
Subject:  FW: iSCSI: "conservative reuse" requirement

John,

Were you the author of "conservative reuse"? I am wondering about some
issues. Maybe you could educate me somewhat ...

I started this subject in a different thread by saying that it may be
good to make "conservative reuse" a MUST.

I got one objection from Santosh below. Then David Black picked it up
by basically agreeing with me. Then Mallikarjun objected to that.

It seems like the objective would be to give targets a way to figure
out that two or more sessions are coming from the same Initiator Port.
That is needed support persistent reservations.

If an initiator does not use "conservative reuse", I don't think
targets will be able to make that determination.

Comments?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Monday, December 24, 2001 12:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

> we're serious about support for shared persistent reservations.

Mandating "conservative reuse" appears to force initiators to always
act
as a single initiator port (wrt one target; assuming only one session
as
an
example) per initiator device - which rules out the case of an
initiator

intentionally wanting to present a different port to each target
portal
group.

IMHO, if iSCSI provides an architected mechanism to support shared
persistent reservations ("conservative reuse"),  that should be
completely
adequate to meet the expectations to be a legal SCSI protocol.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 4:50 PM
Subject: iSCSI: "conservative reuse" requirement

> Santosh Rao writes:
>
> > I am opposed to the suggestion that "conservative re-use" of ISIDs
be
> > made a MUST. This is really only required when initiators need to
be
> Those reservations are a Target feature.  With this approach, the
ability
reservation,
> > ISID's in a per-initiator node fashion, thereby, being able to use
these
> The "initiator" is more than one entity.  The iSCSI HBA/NIC and
driver
> doesn't know whether shared persistent reservations are being used
and
transport.
reservations
> and an entity that wants to use them.  The entity detects (via SCSI
means,
> e.g., something in a mode page) that the Target supports shared
persistent
> reservations, tries to use them, only to discover that they don't
work
> I'm worried about this causing both interoperability issues and
possible
reservations
> determine whether it does "conservative reuse"), and having a
separate
> initiator side means that the entity has to check only for iSCSI
(and

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 28 Dec 2001 15:57:22 -0800

It is true that this does not need to be MUST, but it seems silly not to
make it MUST or SHOULD.  To think that a vendor would want to have a price
feature that has the HBA or the Device Driver using the same ISID with
Conservative reuse, seems very unlikely.

Likewise, I can not think of a customer advantage not to have Conservative
reuse.  When a customer installs the HBA and Device Driver and then finds
that he must change the SW or HW if he wishes to Share LUs among a number
of Systems, that customer will be very disappointed, and will be upset if
the vendor then tries to sell him this upgrade especially when the vendors
do not charge extra.

Since Conservative Reuse (just reusing the same ISID over and over)
requires no more and probably less code, and has potential customer impacts
if not done, we should strongly come down on the side of the customer.  I
think the Spec should work to prevent this silliness, and specify either
MUST or SHOULD.

.
.
.
John L. Hufferd

Jim Hafner
12/28/2001 09:14 AM

To:    John Hufferd/San Jose/IBM@IBMUS, "Eddy Quicksall"
       <[email-masked]>, "Mallikarjun C." <[email-masked]>,
       [email-masked]
cc:    [email-masked]
From:  Jim Hafner/Almaden/IBM@IBMUS
Subject:    Re: FW: iSCSI: "conservative reuse" requirement  (Document
       link: John Hufferd)

Folks,

There are a number of issues raised in this thread:
1) should "conservative reuse" of ISIDs be made a MUST
2) does "conservative reuse" imply that all hosts look "single SCSI ported"

Here's my two cents (using "CR" as a shorthand for "conservative reuse")

I don't believe that CR needs to be a MUST.  The only time this has any
real value is in configurations that use SCSI persistent reservations (and
where new SCSI target reservation features are enabled -- NB.  these
features are yet to be approved but are working their way through the
process). I don't think these are going to be (even in the future) the
majority of installations.  There are many ways then that CR could be
something that is not generally available in most drivers but is added by
configuration and perhaps even "value add" (:-{)).

In short, I don't see a strong case for this to be a MUST.  So, to David
Black, my answer is that having a mechanism to enable this feature or have
it as a "purchase requirement" is an acceptable mechanism to make sure the
feature is there when needed, but it is need not be a requirement of the
protocol.  To Mallikarjun, I think I'm agreeing with you that so long as
there is a mechanism defined, iSCSI has done it's job.

As for the second issue (raised by Mallikarjun), let's look at the
definition of CR.  What is means is that when an iSCSI initiator (node)
creates ISIDs for use in session identifiers, it attempts to reuse them as
much as possible with different SCSI target ports (iSCSI target portal
groups).  This is the only way that a SCSI target or LU can see the same
SCSI initiator port through two or more of its SCSI target ports -- that
is, that the target can determine multiple paths *from* the same SCSI
initiator port.   But, the model for generating ISIDs is not really at the
node level but at the initiator portal group level.
So, IMO, the conclusion that all hosts must then look "single SCSI ported"
is too dramatic.  As I mentioned,  ISIDs are conceptually generated within
initiator portal groups (that's why we defined the mechanism for generating
ISIDs).  The conclusion I draw is that (assuming no more than one session
to any given target portal group), an iSCSI initiator implementing CR will
have as many SCSI initiator ports as iSCSI initiator portal groups
(independent HBAs?).  Each initiator portal group would generate one ISID
(that is different from that generated by/for the other initiator portal
groups) and use CR for repeatability.  [This is consistent with a model
that mapped SCSI initiator ports to initiator portal groups, which we had
to abandon because the "assuming no more than one session..." was no
acceptable as a requirement!!!]  This independence of ISIDs for each
initiator portal group allows each initiator portal group to open sessions
with *every* target portal group it knows about without having to worry
about interfering with other sessions. [This has shades of the
"partitioning" rule for ISIDs that has been discussed ad nauseum!!!]

(I have a feeling that this note is not well composed -- it is the
holidays, you know).  I hope I've addressed everyone's concerns and we can
lay this one to rest.

Jim Hafner

John Hufferd
12/25/2001 08:49 AM

       link: Jim Hafner)

You are correct.  The section was created by Jim Hafner, and via this note
I will ask him if he could answer Mallikarjun Directly since I did not
understand his issue.

.
.
.
John L. Hufferd

"Eddy Quicksall" <[email-masked]> on 12/24/2001 06:06:44 PM

John,

Comments?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Monday, December 24, 2001 12:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

Mallikarjun Chadalapaka

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 4:50 PM
Subject: iSCSI: "conservative reuse" requirement

be
be
ability
reservation,
these
driver
and
transport.
reservations
means,
persistent
work
possible
reservations
separate
(and

---

From: "Jim Hafner" <[email-masked]>
Date: Sat, 29 Dec 2001 23:14:16 +0000

Eddy,

The SCSI initiator port is modeled as the endpoint of the iSCSI session;
the SCSI target port is modeled as the iSCSI target portal group.  The
reason we did it this way was to allow more than one session between portal
groups by allowing multi-plexing of sessions with different ISIDs from the
same iSCSI initiator portal group to the same target portal group.

So, the answer to your questions are:
1) no, we're assuming no more than on session *with the same ISID* to the
same target portal group (that'd be more than one nexus), but by allowing
different ISIDs we get different SCSI initiator ports.
2) no, we're allowing more than one session between an iSCSI initiator
portal group and an iSCSI target portal group (each session has a different
SCSI initiator port (id'ed by its ISID) but the same SCSI target port
(id'ed by its portal group tag).
3) sort of, the ISID together with the iSCSI Initiator Name fully
identifies the SCSI initiator port (and so defines the SCSI initiator port
name and the identifier).

Does that clear this up?

Jim Hafner

"Eddy Quicksall" <[email-masked]> on 12/28/2001 07:19:33 PM

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, December 28, 2001 12:15 PM
To: John Hufferd; Eddy Quicksall; Mallikarjun C.; [email-masked]
Cc: [email-masked]
Subject: Re: FW: iSCSI: "conservative reuse" requirement

Folks,

Jim Hafner

John Hufferd
12/25/2001 08:49 AM

.
.
.
John L. Hufferd

John,

Comments?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Monday, December 24, 2001 12:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

Mallikarjun Chadalapaka

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 4:50 PM
Subject: iSCSI: "conservative reuse" requirement

be
be
ability
reservation,
these
driver
and
transport.
reservations
means,
persistent
work
possible
reservations
separate
(and

---

From: "Jim Hafner" <[email-masked]>
Date: Sat, 29 Dec 2001 23:21:03 +0000

John,

You make sense here.  I have no problem with SHOULD, I just don't think
there is a fundamental structural or architectural need for MUST.

Jim Hafner

John Hufferd
12/28/2001 11:57 PM

To:   Jim Hafner/Almaden/IBM
cc:   [email-masked]
From: John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document link:
      Jim Hafner)

.
.
.
John L. Hufferd

Jim Hafner
12/28/2001 09:14 AM

To:   John Hufferd/San Jose/IBM@IBMUS, "Eddy Quicksall"
      <[email-masked]>, "Mallikarjun C." <[email-masked]>,
      [email-masked]
cc:   [email-masked]
From: Jim Hafner/Almaden/IBM@IBMUS
Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document link:
      John Hufferd)

Folks,

Jim Hafner

John Hufferd
12/25/2001 08:49 AM

To:   "Eddy Quicksall" <[email-masked]>
cc:   Jim Hafner/Almaden/IBM@IBMUS
From: John Hufferd/San Jose/IBM@IBMUS
Subject:  Re: FW: iSCSI: "conservative reuse" requirement  (Document link:
      Jim Hafner)

.
.
.
John L. Hufferd

John,

Comments?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Monday, December 24, 2001 12:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

Mallikarjun Chadalapaka

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 4:50 PM
Subject: iSCSI: "conservative reuse" requirement

be
be
ability
reservation,
these
driver
and
transport.
reservations
means,
persistent
work
possible
reservations
separate
(and

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 31 Dec 2001 13:39:01 -0500

Regarding answer 2 below:
There is no given definition for an iSCSI Initiator Portal Group (however,
it is implied to be the same as the endpoint in 9.1.1, which would be the
same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is
the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is
the same as a SCSI Target Port, then each session in answer number 2 would
not have a "different SCSI initiator port"; hence you would have a parallel
nexus.
One thing that is not clear in section 9.1.1 (however, it is loosely
implied) is that the reuse of ISID's applies to a given initiator endpoint
(SCSI Initiator Port or what should be called an iSCSI Initiator Portal
Group)). I think that should be made clear.
What am I missing? Could it be that an iSCSI Initiator Portal Group is not
equivalent to a SCSI Target Port?

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Saturday, December 29, 2001 6:14 PM
To: Eddy Quicksall
Cc: ips
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Eddy,

Does that clear this up?

Jim Hafner

Eddy

-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Friday, December 28, 2001 12:15 PM
To: John Hufferd; Eddy Quicksall; Mallikarjun C.; [email-masked]
Cc: [email-masked]
Subject: Re: FW: iSCSI: "conservative reuse" requirement

Folks,

Jim Hafner

John Hufferd
12/25/2001 08:49 AM

.
.
.
John L. Hufferd

John,

Comments?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Monday, December 24, 2001 12:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

Mallikarjun Chadalapaka

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 21, 2001 4:50 PM
Subject: iSCSI: "conservative reuse" requirement

be
be
ability
reservation,
these
driver
and
transport.
reservations
means,
persistent
work
possible
reservations
separate
(and

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 31 Dec 2001 13:48:18 -0800

Your assumption of what is meant by an initiator portal group is incorrect
(I don't think it's implied that IPG = IP???)  An initiator portal group is
the same concept as a target portal group - it's the collection of IP
addresses which can be combined to create a single iSCSI session.
Frequently this is thought of as an iSCSI HBA, but that is not necessarily
so, it could be a number of iSCSI HBAs, etc.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> From: Eddy Quicksall [mailto:[email-masked]]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)

---

From: Eddy Quicksall <[email-masked]>
Date: Mon, 31 Dec 2001 22:25:23 -0500

My problem is that we have not done a good job of defining the iSCSI
Initiator Portal Group in the spec. If defined correctly, there should be no
need for the "conservative reuse" clause.

Here is how I think it should be defined ... SCSI Initiator Port: this maps
to an iSCSI Initiator Portal Group.

You could go on to say something like Marjorie said below ... that it is a
collection of IP addresses that can be used to support one or more iSCSI
sessions.

Given that it is equivalent to a SCSI Initiator Port and that it is
identified by the InitiatorName+ISID, it follows that every session from
that "port" would have to use the same ISID; and that is what will make
persistent reservations work.

It is not that "conservative reuse" won't work ... it is more that it is
hard to explain because we don't have a clear definition of a SCSI Initiator
Port and Initiator Port Identifier.

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Monday, December 31, 2001 8:01 PM
To: Amir Shalit
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

We overtly chose NOT to identify an ISID with a TCP/IP address, since the
ISID may span several HBAs and/or TCP/IP addresses.  It was more general
and consistent NOT to be tied to a  TCP/IP address.

.
.
.
John L. Hufferd

"Amir Shalit" <[email-masked]>@ece.cmu.edu on 12/31/2001 03:35:56
PM

To:    "Eddy Quicksall" <[email-masked]>, "KRUEGER,MARJORIE
       \(HP-Roseville,ex1\)" <[email-masked]>, Jim
       Hafner/Almaden/IBM@IBMUS
cc:    "ips@ece. cmu. edu \(E-mail\)" <[email-masked]>
Subject:    RE: FW: iSCSI: "conservative reuse" requirement

Marjorie,

If an "initiator/target portal group" concept is
"the collection of IP addresses which can be combined to create a single
iSCSI session."
why isn't it defined as such in the draft?

IMO, it would have been better to define ISID/TSID in simple networking
terms
like {TCP/IP address + Name} instead of coming up with network entity,
network portal
and portal group terminology.

Amir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Eddy Quicksall
Sent: Monday, December 31, 2001 2:15 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Marjorie,

If "an initiator portal group is the same concept as the target portal
group", then it must be equivalent to the SCSI Initiator Port (because we
have said that the SCSI Target Port maps to an iSCSI Target Portal Group).

Comments?

Eddy

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Monday, December 31, 2001 4:48 PM
To: 'Eddy Quicksall'; Jim Hafner
Cc: ips@ece. cmu. edu (E-mail)
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Marjorie Krueger