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:hafner@almaden.ibm.com]
Sent: Tuesday, January 01, 2002
4:16 PM
To: Eddy Quicksall
Cc: ips@ece.cmu.edu
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:
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
Sent by: owner-ips@ece.cmu.edu
To: John Hufferd/San
Jose/IBM@IBMUS
cc: ips@ece.cmu.edu
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:hufferd@us.ibm.com]
Sent: Monday, December 31, 2001 8:01 PM
To: Amir Shalit
Cc: ips@ece.cmu.edu
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: hufferd@us.ibm.com
"Amir
Shalit" <amir@astutenetworks.com>@ece.cmu.edu on 12/31/2001 03:35:56
PM
Sent by:
owner-ips@ece.cmu.edu
To:
"Eddy Quicksall" <Eddy_Quicksall@ivivity.com>,
"KRUEGER,MARJORIE
\(HP-Roseville,ex1\)" <marjorie_krueger@hp.com>,
Jim
Hafner/Almaden/IBM@IBMUS
cc: "ips@ece. cmu. edu \(E-mail\)"
<ips@ece.cmu.edu>
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: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]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:marjorie_krueger@hp.com]
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: marjorie_krueger@hp.com
>
-----Original Message-----
> From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
> 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:hafner@almaden.ibm.com]
> 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" <Eddy_Quicksall@iVivity.com> on
12/28/2001
> 07:19:33 PM
>
> To: Jim Hafner/Almaden/IBM@IBMUS
> cc: "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
> 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:hafner@almaden.ibm.com]
> Sent: Friday, December 28, 2001 12:15 PM
> To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com
> Cc: ips@ece.cmu.edu
> 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"
<Eddy_Quicksall@iVivity.com>
> 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: hufferd@us.ibm.com
>
>
> "Eddy Quicksall" <Eddy_Quicksall@iVivity.com> 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:cbm@rose.hp.com]
> Sent: Monday, December 24, 2001 12:47 AM
> To: Black_David@emc.com
> Cc: ips@ece.cmu.edu
> 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: <Black_David@emc.com>
> To: <santoshr@cup.hp.com>
> Cc: <ips@ece.cmu.edu>
> 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
> > black_david@emc.com Cell: +1 (978)
394-7754
> > ---------------------------------------------------
> >
> >
>
>
>
