Subject: RE: FW: iSCSI: "conservative reuse" requirement

From: "John Hufferd" <[email-masked]>
Date: Tue, 1 Jan 2002 11:56:59 -0800

Eddy,
You might think so, but a number of vendors, for some reason, wanted to
give every session a unique ID, and they did not want to give that design
up.  Therefore, we needed to include the Conservative Reuse, statement.
You saw how some folks felt about making the requirement a MUST.  That was
just a sample of the folks that  had built their design on an idea -- which
we had not understood to be a problem, until late in the game.
.
.
.
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/31/2001 07:25:23 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    [email-masked]
Subject:    RE: FW: iSCSI: "conservative reuse" requirement

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
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]

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

Sent by:    [email-masked]

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

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]

> -----Original Message-----
> From: Eddy Quicksall [mailto:[email-masked]]
> Sent: Monday, December 31, 2001 10:39 AM
> To: Jim Hafner
> Cc: ips@ece. cmu. edu (E-mail)
> Subject: RE: FW: iSCSI: "conservative reuse" requirement
>
>
> 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,
>
> 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
>
> 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
>
> > 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: Tue, 1 Jan 2002 12:18:35 -0800

Amir,
It could have been a lot of things.  We had many folks look at as many
different approaches as possible, and it bothered us for a long time.  I am
trying to tell you that we DID look at IP addresses being part of the Name.
That was turned down because of a lot of reasons, one of them was the fact
that with Hot Swap, Plug and Play etc. the IP address could change, and
then the name would change, and the reservations could not be reclaimed,
etc.  We even thought that there could be take over of the IP address by
the other HBAs, etc.  And that got just too complicated for the more simple
HBAs and device drivers, and we did not need that level of complexity.  We
were trying to reduce complexity, and I think we did it.

The protocol and the Names and the reason for the names are just different
then IP/ATM, SCTP etc.  We are talking about a higher level protocol, and
the needs of that protocol, and not trying to match it to a lower level
protocol which has no issues with Storage and Reservations.

Bottom Line; Your thoughts were factored in, they  were discarded as Not
Approprate for this protocol and the ISID name.

.
.
.
John L. Hufferd

"Amir Shalit" <[email-masked]>@ece.cmu.edu on 12/31/2001 05:22:13
PM

cc:    <[email-masked]>

It could have been defined as {IP address, port, channel_id}
or {IP address, port, stream_number}.

This would let you span multiple HBAs etc. and still be consistent
with other IP/ATM protocols like SCTP and AAL2.

Amir

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: "Jim Hafner" <[email-masked]>
Date: Tue, 1 Jan 2002 13:15:44 -0800

Eddy,

I don't know why you think we've done a bad job of defining these terms.
I don't have a copy of the draft around at the moment but this is my
recollection:

These are the iSCSI architectural level components:
      There is a definition of an iSCSI node (that has a WWU name).

      There is a definition of Portal Group (which does NOT apply only to
targets but is applicable to both targets and initiators).   (I even
thought there was text that said that this definition applied to both
initiator and target, but I could be wrong about this.)

      There is a definition of sessions and the specification of how SSIDs
are generated from the ISID component and the TSID component.

There is the (required by any SCSI protocol) a mapping of the SCSI
constructs to iSCSI constructs.  The SCSI constructs of concern here are
(a) device -- both initiator and target (b) port -- initiator, target and
initiator/target and (c) nexus:

      There is explicit language that defines the SCSI device as a
component of an iSCSI node (and that there is only one such SCSI device
construct within an iSCSI node -- and this allows us to define the SCSI
device name as equal to the iSCSI node name).

      There is explicit language that maps the SCSI initiator port to an
iSCSI construct and *different* language that maps the SCSI target port to
an iSCSI construct.  For the SCSI initiator port, the mapping is to the
initiator end of a session.  For the SCSI target port, the mapping is to
the iSCSI target portal group.  It is NOT symmetric and is stated so
explicitly.

      There is explicit language the maps the SCSI nexus to the session.
Note that a nexus is a relationship between a SCSI initiator port and a
SCSI target port (that's the SAM definition!).   What iSCSI does is map
this relationship from the iSCSI initiator end of a session (SCSI initiator
port) to the iSCSI target portal group (SCSI target port).

Does the text not say this?

Note that the approach we've taken here is to define the iSCSI architecture
and then MAP the iSCSI constructs to SAM-defined SCSI constructs.

And, an attempt to map SCSI initiator port to the iSCSI initiator portal
group (as you suggest) will force a requirement that there can be only one
session between an iSCSI initiator portal group and an iSCSI target portal
group!   If one thinks that most "portal groups" will be instantiated by an
iSCSI HBA, then this requirement is unacceptable.

Jim Hafner

Eddy Quicksall <[email-masked]>@ece.cmu.edu on 12/31/2001 07:
25:23 PM

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 2 Jan 2002 08:12:05 -0500

I see I must have offended you. I didn't mean to do that ... 
 
I was referring to the definition of iSCSI Initiator Portal Group and that
it has been left out. It is an important item to define (as mapping to the
SCSI Initiator Port). It is what is needed for persistent reservations.
Defining it properly will eliminate the need for the "conservative reuse"
clause.
 
The problem I saw was that many people have misunderstood the ISID and how
it should be used to be compliant with SAM-2.
 
I said much earlier that the definition of iSCSI Initiator Portal Group was
implied and that is exactly what you have pointed out below.
 
It seems so silly not to define it. Can you give me a reason why it should
not be defined?
 
Eddy
 
-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Tuesday, January 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Eddy,

I don't know why you think we've done a bad job of defining these terms. I
don't have a copy of the draft around at the moment but this is my
recollection:

There is a definition of Portal Group (which does NOT apply only to targets
but is applicable to both targets and initiators). (I even thought there was
text that said that this definition applied to both initiator and target,
but I could be wrong about this.)

There is a definition of sessions and the specification of how SSIDs are
generated from the ISID component and the TSID component. 

There is the (required by any SCSI protocol) a mapping of the SCSI
constructs to iSCSI constructs. The SCSI constructs of concern here are (a)
device -- both initiator and target (b) port -- initiator, target and
initiator/target and (c) nexus: 

There is explicit language that defines the SCSI device as a component of an
iSCSI node (and that there is only one such SCSI device construct within an
iSCSI node -- and this allows us to define the SCSI device name as equal to
the iSCSI node name).

There is explicit language that maps the SCSI initiator port to an iSCSI
construct and *different* language that maps the SCSI target port to an
iSCSI construct. For the SCSI initiator port, the mapping is to the
initiator end of a session. For the SCSI target port, the mapping is to the
iSCSI target portal group. It is NOT symmetric and is stated so explicitly. 

There is explicit language the maps the SCSI nexus to the session. Note that
a nexus is a relationship between a SCSI initiator port and a SCSI target
port (that's the SAM definition!). What iSCSI does is map this relationship
from the iSCSI initiator end of a session (SCSI initiator port) to the iSCSI
target portal group (SCSI target port). 

Jim Hafner

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.

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 2 Jan 2002 13:05:48 -0500

Did you read Jim's response carefully?  You repeat the statement "It
(initiator portal group" is an important item to define (as mapping to the
SCSI Initiator Port). It is what is needed for persistent reservations.
Defining it properly will eliminate the need for the "conservative reuse"
clause." and Jim has explained to you that this statement is incorrect.
Several of us have given you the definition of initiator portal group and
you still have this misconception.  I don't know how putting the definition
in the draft would clear up your misunderstanding?
 
If "initiator portal group" is not explicitly defined in the draft, it is in
part because that concept plays no part in the iSCSI protocol - it's very
important that you understand that.  In order for an initiator to connect to
a target, the initiator must know the target's portal groups.  The converse
is NOT true - nothing external to the target that participates in the iSCSI
protocol needs to know the initiator's address information.  Perhaps if you
let go of the idea that the initiator portal group is an important thing in
the iSCSI protocol, you'll understand what has been explained?
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 
-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 5:12 AM
To: Jim Hafner
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 

 
Eddy
 
-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Tuesday, January 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Eddy,

Jim Hafner

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 2 Jan 2002 13:55:33 -0500

If you don't want to define it, then you should not use it.
 
There is an "endpoint" that represents the SCSI Initiator Port. If that
"endpoint" can you just give that "endpoint" a term?
 
Eddy

 
-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 5:12 AM
To: Jim Hafner
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 

Eddy
 
-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Tuesday, January 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Eddy,

Jim Hafner

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 2 Jan 2002 11:40:27 -0800

? You asked for the definition it, but you don't want me to use it?  Could
you point out where the iSCSI protocol document uses the term "initiator
portal group" in a manner that confuses you?
 
The "endpoint" that represents the SCSI Initiator Port is the iSCSI
initiator node's end of the iSCSI session.
 
Marjorie Krueger
-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 10:56 AM
To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 
Eddy

 
-----Original Message-----
From: Eddy Quicksall [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 5:12 AM
To: Jim Hafner
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

 

Eddy
 
-----Original Message-----
From: Jim Hafner [mailto:[email-masked]]
Sent: Tuesday, January 01, 2002 4:16 PM
To: Eddy Quicksall
Cc: [email-masked]
Subject: RE: FW: iSCSI: "conservative reuse" requirement

Eddy,

Jim Hafner

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

.
.
.
John L. Hufferd

Marjorie,

Amir

-----Original Message-----

Marjorie,

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

(however,
is
is
would
parallel
endpoint
not

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 02 Jan 2002 13:21:13 -0800

Now that I'm back from vacation, let me offer some (delayed)
comments on this.  I also read Jim's reply where he appeared 
to mostly agree with me.

>...as long as it presented
> each of them to all target ports...

I disagree with your assumption that an initiator must 
"present" *all* its ports to every target port in a target
device.  Each distinct initiator port (signified by a unique 
ISID) may want to talk to only one target port (i.e. one portal 
group) - that's a typical usage of multi-HBA (i.e. multi-port) 
hosts talking to multi-FC port targets today.  As far as I 
can understand, a mandatory "conservative reuse" would 
preclude this usage.  Please comment if your visualization
of conservative reuse is different.

OTOH, I can see that the ability of *one* initiator SCSI 
port to establish nexii with multiple target SCSI ports in 
a target device is highly desirable (perhaps even T10-required
shortly).  IMO, iSCSI had already met this need by defining 
and enabling "conservative reuse", and that's where we should 
stop.  I would actually advocate wording along the lines of -
    
    "When a given initiator implementation seeks to present 
     a single SCSI port abstraction to multiple target portal 
     groups (thus multiple SCSI target ports) of an iSCSI target 
     node, conservative reuse is the means to realize it.
     Conservative reuse hence MUST be used in this case."

and leave it at that.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

[email-masked] wrote:
> 
> 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
> 
> > 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.
> >
> > persistent reservations ("conservative reuse"),  that should
> > be completely
> > > > 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
> > > > 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
> > > 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
> > > determine whether it does "conservative reuse"), and having
> > a separate
> > > initiator side means that the entity has to check only for
> > iSCSI (and

---

From: Eddy Quicksall <[email-masked]>
Date: Wed, 2 Jan 2002 17:09:23 -0500

That's not the way I understand "conservative reuse".

I understand it as saying that the endpoint at the initiator should use the
same ISID when it is talking to different iSCSI Target Portal Groups. This
is basic to SCSI Initiator Ports as they have Initiator Port Identifiers
that serve the same purpose (technically the Initiator Port Identifier is
the iSCSI InitiatorName+ISID but on a given initiator, you can factor out
the InitiatorName).

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 4:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

   

and leave it at that.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 3 Jan 2002 02:54:35 -0800

In regards to the first (the important) point you made.  Perhaps an example
would be best. (Since I think what I said is completely consistent with the
draft.)

Suppose the vendor "xxx" assigns the qualifier "1" to the SCSI Initiator
Port's ISID.  Then suppose the IANA Enterprise Number is 5. The name of the
SCSI Initiator Port then might be "main_node"+i+ISID where ISID is made up
of type= 1, vendor=5, qualifier=1. Or in other words ISID=0x010000050001.

So lets suppose the vendor had an HBA/Device Driver combo that assigns the
SCSI Initiator Port to be "main_node"+i+0x010000050001.  Now this same
Initiator Node Name and ISID can be used with every Session that is
connected via the Same HBA/Device Driver (which is in this case, the SCSI
Initiator Port).  They only thing it can not do is connect to the same SCSI
Target Port more then once.  If the iSCSI Initiator Node wants another
connection to the same SCSI Target Port it must establish another SCSI
Initiator Port and change the qualifier.  That means that the new SCSI
Initiator Port might be called "main_node"+i+0x010000050002.  Further,
every session that the new SCSI initiator creates will have the same name
SCSI Initiator Port Name.  This New SCSI Initiator Port can be via another
HBA/Device Driver, or even via the original HBA/Device Driver.

So it is possible for the Conservative Reuse to be used with a Single iSCSI
Initiator Node, yet have more then one SCSI Initiator Port each uniquely
defined, and with each having its own single ISID, which it uses for all of
its connections.  In this case  the iSCSI Initiator Node would have more
then one session to the same iSCSI Target Node, via the same SCSI Target
Port.

I think that is exactly what I intended to say in the previous note and is
consistent with the Version 9 of the Draft.

.
.
.
John L. Hufferd

"Mallikarjun C." <[email-masked]> on 01/02/2002 06:12:32 PM

John,

>This is called Conservative Reuse
> since when we start/restart a session we are not choosing a different
ISID.

That doesn't seem to be what's meant by rev09 when it says in section
9.1.1 -
   " the same ISID should be used in the Login process to multiple
     target portal groups (of the same iSCSI Target or different iSCSI
    Targets)."
and further it says -
   "The principle of conservative reuse "encourages" reuse to other
    target portal groups. When a SCSI target device sees the same
    (InitiatorName, ISID) pair in different sessions to different target
    portal groups, it can identify the underlying SCSI Initiator Port on
    each session as the same SCSI port (in effect, it can recognize
    multiple paths from the same source)."

>The Name of the SCSI Initiator Port is made
> up of the iSCSI Initiator Node Name and the ISID.

Just a nit - also includes the letter 'i'!

> If those other iSCSI Initiators have HBAs which have been made by the
                                  same
                                  ^^^^^^^
Somehow it appears to me that this isn't "carefully qualified", :-)

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 02, 2002 4:57 PM
Subject: Re: iSCSI: "conservative reuse" requirement

>
> Mallikarjun,
> Comments in line between [Huff/] and [\Huff].
>
> .
> .
> .
> John L. Hufferd
> "Mallikarjun C." <[email-masked]>@ece.cmu.edu on 01/02/2002 01:21:13 PM
>
> Please respond to [email-masked]
>
> [Huff/]
> We have now fallen into the problem that Jim, Julian, Marjorie, and I
spent
> the Holidays exchanging e-Mails about.  You use the term Initiator to
> represent the Total Initiator Node (and indeed our draft definitions
> encourage that view).  However, some others, when they talk, use the SCSI
> interpretation of the word Initiator, which is the SCSI Initiator Port.
So
> as Marjorie has clearly pointed out to me, I need to be more precise, and
I
> think the rest of us also.  We need to fully qualify the term Initiator
> when we use it, in these types of discussions.  We need to say iSCSI
> Initiator Node, or SCSI Initiator Port etc.  So let me try that below, in
> hopes of perhaps clearing up some concepts.
>
> The use of Conservative Reuse applies to the how the Name of the SCSI
> Initiator Port will be chosen.  The Name of the SCSI Initiator Port is
made
> up of the iSCSI Initiator Node Name and the ISID.
>
> We are attempting to ensure that any one SCSI Initiator Port will not
pick
> various different ISIDs in a manner that will prevent the Persistent
> Reserves from being reestablished across a Session Restart.  To do that
we
> strongly suggest that the Vendor follow the Type and Vendor ID approach
to
> creating and ISID as specified in version 9 of the Draft. Also they
should
> pick the 16 bit Qualifier part in a way that will usually be the same
> number each time a Session from that SCSI Initiator Port is restarted.
The
> easiest way to do this is for the iSCSI Process to Identify the SCSI
> Initiator Port with the same ISID Qualifier every time an iSCSI Session
is
> started with any SCSI Target Port (via its iSCSI Target Portal Group).
>
> When this is done, everything works.  This is called Conservative Reuse
> since when we start/restart a session we are not choosing a different
ISID.
>
> Please note I did not restrict the actions of any other SCSI Initiator
Port
> within the iSCSI Initiator Node.  They can each have their own ISID and
use
> the iSCSI Transport to connect to what ever SCSI Target Nodes they wish.
> If those other iSCSI Initiators have HBAs which have been made by the
same
> vendor (and if that vendor does not support Multiple Connections per
> Session across the HBAs), it is the Vendors responsibility to chose an
ISID
> Qualifier for its second (and subsequent) SCSI Initiator Port, which does
> not conflict with the first one.  When done correctly, then if by chance,
> the second SCSI Initiator Port connects to the same SCSI Target Port to
> which the First one connected, they will each be seen, by the Target, as
> different Sessions from different SCSI Initiator Ports and things are
> completely legal.
>
> In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node)
> will have to be very careful how work is handed out to the different SCSI
> Initiator Ports, so that Work arrives in the correct order and there is
no
> conflicts with Reserves.  (The process that does that balancing between
the
> HBAs is what, in Fibre Channel, we have called a Wedge Driver).
>
> So what I have said above, is that when we carefully qualify the Term
> Initiator, we can see that Conservative Reuse does NOT cause any
> restrictions on the way we use the Sessions within an iSCSI Initiator
Node.
> [\Huff]

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 3 Jan 2002 03:15:23 -0800

Mallikarjun,
Perhaps I have spotted the problem we are having with the notes we are
exchanging.

If you read the section below with the eye that says that the words iSCSI
Target is defined (in the iSCSI Draft) to be what we are calling the iSCSI
Target Node, I think you will see that what I am saying and what the Draft
Said is basically the same.

.
.
.
John L. Hufferd

"Mallikarjun C." <[email-masked]>@ece.cmu.edu on 01/02/2002 06:12:32 PM

John,

ISID.

                                  same
                                  ^^^^^^^

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: "John Hufferd" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 02, 2002 4:57 PM
Subject: Re: iSCSI: "conservative reuse" requirement

spent
So
I
made
pick
we
to
should
The
is
ISID.
Port
use
same
ISID
no
the
Node.

---

From: Eddy Quicksall <[email-masked]>
Date: Thu, 3 Jan 2002 11:04:17 -0500

John, I like your wording here much better.

I was thinking that if we could relate directly to SAM-2, wouldn't that
solve these problems?

SAM-2 has a SCSI Initiator Device with an Initiator Device Name; and the
device has one or more SCSI Initiator Ports, each of which have an Initiator
Port Identifier and an optional Initiator Port Name.

IMHO, SAM-2's Initiator Device Name should be our InitiatorName, the
Initiator Port Identifier should be the ISID and the Initiator Port Name
should be the concatenation of InitiatorName+i+ISID. The Initiator Port Name
has to be World Wide Unique but the Initiator Port Identifier does not. That
would really make things relate well.

Given that they relate well, understanding of SAM-2 would give better
understanding of "conservative reuse" and simplify the clause.

Eddy

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 7:58 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI: "conservative reuse" requirement

Mallikarjun,

.
.
.
John L. Hufferd

To:    [email-masked]
cc:    [email-masked]

[Huff/]
We have now fallen into the problem that Jim, Julian, Marjorie, and I spent
the Holidays exchanging e-Mails about.  You use the term Initiator to
represent the Total Initiator Node (and indeed our draft definitions
encourage that view).  However, some others, when they talk, use the SCSI
interpretation of the word Initiator, which is the SCSI Initiator Port.  So
as Marjorie has clearly pointed out to me, I need to be more precise, and I
think the rest of us also.  We need to fully qualify the term Initiator
when we use it, in these types of discussions.  We need to say iSCSI
Initiator Node, or SCSI Initiator Port etc.  So let me try that below, in
hopes of perhaps clearing up some concepts.

The use of Conservative Reuse applies to the how the Name of the SCSI
Initiator Port will be chosen.  The Name of the SCSI Initiator Port is made
up of the iSCSI Initiator Node Name and the ISID.

We are attempting to ensure that any one SCSI Initiator Port will not pick
various different ISIDs in a manner that will prevent the Persistent
Reserves from being reestablished across a Session Restart.  To do that we
strongly suggest that the Vendor follow the Type and Vendor ID approach to
creating and ISID as specified in version 9 of the Draft. Also they should
pick the 16 bit Qualifier part in a way that will usually be the same
number each time a Session from that SCSI Initiator Port is restarted.  The
easiest way to do this is for the iSCSI Process to Identify the SCSI
Initiator Port with the same ISID Qualifier every time an iSCSI Session is
started with any SCSI Target Port (via its iSCSI Target Portal Group).

When this is done, everything works.  This is called Conservative Reuse
since when we start/restart a session we are not choosing a different ISID.

Please note I did not restrict the actions of any other SCSI Initiator Port
within the iSCSI Initiator Node.  They can each have their own ISID and use
the iSCSI Transport to connect to what ever SCSI Target Nodes they wish.
If those other iSCSI Initiators have HBAs which have been made by the same
vendor (and if that vendor does not support Multiple Connections per
Session across the HBAs), it is the Vendors responsibility to chose an ISID
Qualifier for its second (and subsequent) SCSI Initiator Port, which does
not conflict with the first one.  When done correctly, then if by chance,
the second SCSI Initiator Port connects to the same SCSI Target Port to
which the First one connected, they will each be seen, by the Target, as
different Sessions from different SCSI Initiator Ports and things are
completely legal.

In this case, as it is in Fibre Channel, the Host (iSCSI Initiator Node)
will have to be very careful how work is handed out to the different SCSI
Initiator Ports, so that Work arrives in the correct order and there is no
conflicts with Reserves.  (The process that does that balancing between the
HBAs is what, in Fibre Channel, we have called a Wedge Driver).

So what I have said above, is that when we carefully qualify the Term
Initiator, we can see that Conservative Reuse does NOT cause any
restrictions on the way we use the Sessions within an iSCSI Initiator Node.
[\Huff]

and leave it at that.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: Eddy Quicksall <[email-masked]>
Date: Thu, 3 Jan 2002 13:12:22 -0500

- SHOULD use "conservative reuse" in setting up sessions from the same
	Initiator Portal Group (set of IP addresses) to different Target
	Portal Groups (i.e., reuse an existing ISID in preference to
	creating a new one).

This gets my vote.

Eddy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, January 03, 2002 11:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: "conservative reuse" requirement

> Thanks for the message.  Let me comment on what I agree with first.
>
> >if "conservative reuse" does not
> > happen (breaking shared persistent reservations), the reason that
> > it does not happen MUST be externally configurable as opposed to
> > being an unchangeable internal characteristic of the implementation.
>
> Agreed.  If I understand you correctly, you're concerned that NICs
> that are hard-coded not to allow single initiator port abstraction (i.e.
that
> don't do conservative reuse) will break the new shared persistent
reservations.
> I agree that it currently is an issue, I propose that we have a NIC
requirement
> in the implementation notes (like the node name configurability
requirement)
> that says something like - Every iSCSI NIC MUST provide a means of
> enabling a strict "conservative reuse" of ISIDs across different target
portal
> groups.

Good.  Once that's done, what's the value in permitting operating modes
other than "conservative reuse"?  The risk of multiple operating modes is
that there'll be:
- The mode that works, and
- The mode that complies with the standards.
Having only one mode avoids this problem.  Don't laugh too loudly -
versions of this situation are occurring in Fibre Channel switches
today.

> With that said, here's the idea (repeated in several places)
> that I have a problem with -
> > every possible connection is
> > attempted, and the reasons that not every connection is established
> > are external (and configurable, modulo physical constraints).
>
> First off, I am not sure what you meant by "connection" here, and
"presented"
> in your previous message.  I took it that you meant "establishing a SCSI
nexus".
> If that's indeed so, the assertion that it's only the external factors
that decide
> nexii is not always true.  Consider the case of an FC initiator
> port discovering target ports using an FC Name Server, and an iSCSI
initiator
> port discovering target ports using a "SendTargets" command.  In either
case,
> the initiator SCSI port may not really establish a nexus with a discovered
> target SCSI port, unless the application (or
> even the SCSI class driver) really wants to do an I/O (starting with an
open()
> system call in Unix systems).

I strongly disagree with that.  Virtually all commercial OS implementations
of SCSI do aggressive establishments of the nexii as part of the boot
sequence,
as SCSI code tends to expect a "bus walker" to find devices in the boot
sequence, and make sure they work.  Put a trace analyzer to work on a boot
and watch all the TEST UNIT READY and similar commands flow by.  Is anyone
making significant changes to this "bus walker" boot paradigm out there?

There's also a subtle issue to watch out for here in that this delays
error discovery - if the shared persistent reservations are being
used by cluster software, discovering that the alternate path nexus can't
be established when trying to fail over to it is way too late.  For things
like quorum volumes, I'm fairly sure that cluster software checks all the
access paths at initialization time, but can someone familiar with cluster
software comment on whether the alternate access paths needed for failover
of application volumes are checked in advance, vs. relying on the OS to
complain if the SCSI connection to the device didn't set up correctly?

> But in any case, it appears to be in the implementation territory.

That's something I can agree with - namely that when nexii are established
is an orthogonal issue to the session identifiers used to establish
them, although I would caution implementers that there's a lot of code
out there that operates under the "bus walker" paradigm and hence wants
to see nexii (sessions) established aggressively.  In a code stack that
doesn't operate under the "bus walker" paradigm, "conservative reuse"
is still applicable, as it need only constrain what ISIDs have to be
used, and not when they are used.

Taking a whack at requirements, I think there are at least two of them:
- MUST support "conservative reuse" without requiring any iSCSI sessions
        to be terminated in order to set up the required sessions (i.e.,
        one can take the ISID from an existing session and a target portal
        group to which that ISID is not in use and set up an iSCSI session
        with that ISID without having to terminate any existing session for
        ISID usage reasons - this is tricky to state precisely when the
        possibility of allowing sessions to be set up on the fly well after
        booting is allowed).
- SHOULD use "conservative reuse" in setting up sessions from the same
        Initiator Portal Group (set of IP addresses) to different Target
        Portal Groups (i.e., reuse an existing ISID in preference to
        creating a new one).
I presume the "mapping police" will let us know if Initiator Portal Group
is not the right term for the second requirement ;-).

Thanks,
--David

---

From: [email-masked]
Date: Thu, 3 Jan 2002 14:13:59 -0500

> >Once that's done, what's the value in permitting operating modes
> > other than "conservative reuse"?
> 
> I thought we already discussed this - that of two initiator NICs
> each establishing a session (acting as independent initiator ports)
> to a different target portal group.

That's actually the same "operating mode" as far as I'm concerned -
one assigns a separate ISID to each NIC, and then some sort of
configuration restriction prevents each NIC from talking to both
Target Portal Groups (i.e., if one of the NICs could talk to
both Target Portal Groups, it would use the same ISID(s) for
its session(s) to both TPGs).  One NIC with one session to each
of two different Target Portal Groups really ought to be using
the same ISID for each session.  

> > - SHOULD use "conservative reuse" in setting up sessions
> 
> I guess this is okay, the other alternative/complement is wording 
> (proposed earlier in this thread) that focuses on where conservative 
> reuse is a MUST.

I think a complementary "MUST implement" and "SHOULD use" are needed:
- MUST implement "conservative reuse" of ISIDs in a fashion that
	doesn't require session teardown.  In the above example,
	it would be wrong to have to reset one of the NICs in
	order to get it to use the same ISID to talk to both
	Target Portal Groups.
- SHOULD use "conservative reuse" of ISIDs in setting up sessions
	(i.e., in the absence of some sort of configuration setting
	that forces "conservative reuse").  
The MUST is needed to avoid the "two operating modes" problem.
The SHOULD is to encourage persistent shared reserves to
"just work" without annoying additional configuration fiddling,
and may need an additional MUST to force "conservative reuse".

It would be simpler to make "conservative reuse" a "MUST use", but
I've heard objections to that ... so the above is what the alternative
appears to look like.

> >         Portal Groups
> In the sense you used "initiator portal group" here, it ought
> to be defined (otherwise, simply use "initiator node" in your sentence)
> as "the set of initiator portals sharing the same ISID Type & ISID
> Naming Authority values and sharing one ISID Qualifier name space,
> and that allow a session to span an arbitrary subset of the portals."

That sounds about right, thanks.
 
> IOW, if two NICs A and B from the same vendor (so same Type and Naming 
> Authority) are present in a host (so share the ISID Qualifier space,
> perhaps with a s/w "ISID allocator" in the host or whatever), but can
> not span a session across them, then they are technically two independent
> "initiator portal groups".

Yes, that specific example is definitely ok.

Thanks,
--David