Subject: RE: iSCSI: ISID issue

From: [email-masked]
Date: Mon, 1 Oct 2001 18:11:22 -0400

Santosh Rao wrote:

> I think comparisions to FC's mess-up of the node WWN are not fair to the
> current ISID rule, since, unlike in FC, the worst case scenario with the
> ISID rule, is that each iscsi driver on the system will take up a
> different iscsi initiator name.

At least FC had the Port WWN to fall back on.  This is headed for a
situation
where the iSCSI Initiator Name is unusable for access control configuration
because whether it corresponds to the network interface, the HBA (e.g.,
suppose
there are two interfaces on the HBA), the driver, or the OS image is
implementation-dependent.  In FC it is completely unambiguous what the
Port WWN corresponds to, and that's why it's usually used for LUN masking
and mapping solutions.  We're at risk of screwing that up, e.g. ...

> Given that all iscsi HBA vendors will need to have SOME host O.S. driver
> component which they will be writing, it is possible for them to hand
> out ISIDs to their adapters within their own driver domain. The ISID
> rule works fine as long as ISIDs are ditributed within the domain of
> each iscsi driver and since, the number of iscsi drivers supported on an
> O.S. are'nt going to be that large, I think, this is'nt as big an issue
> as FC's node name problems.(which scales linearly with the number of
> HBAs, not the number of drivers).

Actually it's worse because there isn't a single Initiator Name convention.
The only out I can see here is LUN masking/mapping configurations based on
IP addresses.  Simple stupid rules that ensure that everything works the
same way every time are necessary to make this sort of access control
mechanism useful (otherwise it will get misconfigured by a harried admin
who doesn't have the time to appreciate the subtlety of our discussions).

Jim Hafner wrote:

> First, the T10 folks are trying to come up with "additional and optional
> features" that would move in the diretion you're saying. That is partly to
> make the wedge-driver's job easier.  But that doesn't mean that iSCSI can
> ignore the current defined and well-understood model.  We have to live
with
> the current model AND see how what we do might affect (enable or prevent
> enabling) the new features.
> 
> Having the target provide the SSID, in my mind, will prevent the new
> features from being made available.

I worry that we're already in trouble with the new features.
In Parallel SCSI or Fibre Channel, ports are hardware entities and
exhaustive connection setup results in every Initiator Port being connected
to every possible Target Port, and the reservation spanning works, in part
because things like Unix /dev names are used to encode which Initiator
port was used.

At least as iSCSI currently stands, we're not in that situation because
ISID usage is implementation-dependent - if an Initiator chooses to never
reuse an ISID across all of its connections to all Target Ports, the result
is no reservation sharing.  That's permissible as things currently stand
and "will prevent the new features from being made available".  If I follow
Jim's line of reasoning, I think the result is "SHOULD use the same ISID
values
to connect to different Targets and Target Portal Groups" as a
recommendation
for boot and setup behavior so that the Ports behave in the same fashion as
existing SCSI Ports - one can then rebuild existing structures (e.g., /dev
names in Unix) on that base.

That seems like a change from what's been discussed - in essence, one or
a few ISIDs would get configured into each iSCSI implementation and all of
them would be exhaustively connected to every validly accessible (where
"validly"
is meant to encompass discovery scope restrictions) Target Portal Group on
boot.
How many current implementations are doing or anticipate doing that?  How
many
current implementations intend to set up multiple sessions (initially or for
error recovery) to the same Target Portal Group and hence need more than one
ISID?

One alternative would be to eliminate the ISID as a carrier of the Initiator
Port Name and assign that to a text key, which splits the issues of how to
provide support for this to be created reservation functionality from lower
level functional issues in the iSCSI protocol.

FWIW, Jim is right to observe that this is a consequence of multi-connection
sessions that span hardware interfaces.  SAM's world view is that a Port is
a hardware interface and hence some sort of hardware interface identifier
can
be used to name it.  Sessions that span hardware interfaces cause the SCSI
Initiator Port to become a software entity and are at the root of this.
Sessions with multiple connections but restricted to a hardware interface
do not cause issues - to a first approximation Fibre Channel does this
already
via multiple concurrent exchanges within a single N_Port to N_Port session.
This is another alternative - if iSCSI Ports were hardware ports, we'd be
guaranteed to line up well with T10, but that would be a major change.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 2 Oct 2001 10:25:19 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 01, 2001 3:11 PM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI: ISID issue
> 
> 
> Santosh Rao wrote:
> 

I would like to second David's concern about not leaving targets with a
deterministic way of knowing who/what the initiators identifier relates to.
This is not only bad for access control mechanisms but it make topology
mapping (and related concepts) more difficult for management software
developers.

-Shawn

-------------------------------------------------------
 Shawn Carl Erickson           (805) 883-4319 [Telnet]
 Hewlett Packard Company         OV NSSO Joint Venture
  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
            <http://ecardfile.com/id/shawnce>
-------------------------------------------------------

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 3 Oct 2001 20:20:53 +0300

I agree that LU mapping might be tricky but topology mapping is not 
affected by ISID allocation. You have to get a consistent mapping of 
target ports (and the model does that) and Initiators that know how to 
reach targets. Initiators have to know the physical identity of the portal 
when they open the connection (or they can get it through a local service) 
and the ISID has no role in topology mapping. 

I would also say that for any practical purpose we may request the LU 
mapping - for  iSCSI - be defined only by the InitiatorName part of the 
InitiatorPortName.

Julo

"ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
02-10-01 19:25
Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)"

        To:     [email-masked], [email-masked]
        cc:     "[email-masked]'" <[email-masked]>
        Subject:        RE: iSCSI: ISID issue

I would like to second David's concern about not leaving targets with a
deterministic way of knowing who/what the initiators identifier relates 
to.
This is not only bad for access control mechanisms but it make topology
mapping (and related concepts) more difficult for management software
developers.

-Shawn

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 3 Oct 2001 11:00:41 -0700

All,

Let me just reiterate more strongly Julo's comment "we may request the LU
mapping - for  iSCSI - be defined only by the InitiatorName".
T10 has approved use of the iSCSI InitiatorName as the "TransportID" for
SCSI access controls (lu mapping).  The portnames have no direct function
in this context for iSCSI (though they do have an indirect affect that
isn't worth discussing here).

Whether this standardized approach to lu mapping is adopted by vendors is a
different question, but the standard is there.

The issue of port name/identity is primarily an issue for persistent
reservations (in all its current and future forms).

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 10/03/2001 10:20:53 am

To:   "ERICKSON,SHAWN (HP-Roseville,ex1)" <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>, [email-masked],
      [email-masked], [email-masked]
Subject:  RE: iSCSI: ISID issue

I agree that LU mapping might be tricky but topology mapping is not
affected by ISID allocation. You have to get a consistent mapping of target
ports (and the model does that) and Initiators that know how to reach
targets. Initiators have to know the physical identity of the portal when
they open the connection (or they can get it through a local service) and
the ISID has no role in topology mapping.

Julo

                           "ERICKSON,SHAWN                                  
                           (HP-Roseville,ex1)"              To:             
                           <[email-masked]>  [email-masked],    
                           Sent by:                 [email-masked]         
                           [email-masked]            cc:             
                                                    "[email-masked]'" 
                           02-10-01 19:25           <[email-masked]>   
                           Please respond to                Subject:        
                           "ERICKSON,SHAWN          RE: iSCSI: ISID issue   
                           (HP-Roseville,ex1)"                              

-Shawn

---

From: [email-masked]
Date: Wed, 3 Oct 2001 15:23:42 -0400

I'm getting ready to give up on this due to lack of interest on the list.
As near as I can tell the arguments in favor of ISIDs are:

(1) They've been in the spec for a long time.
(2) Provide symmetry in session identification and a clean mapping to SAM-2
	concepts.
(3) Accommodates possible future persistent reserve functionality.

Of these, I regard (1) and (2) as weak, and will explain in a moment
why (3) is incorrect as things currently stand.

The arguments against are:

(4) ISID existence is the direct cause of the Option A/Option B issue
	about whether setting up a connection with an existing ISID is
	supposed to blow away an existing connection with the same ISID.
(5) The ISID rule does not appear to be uniformly implementable in practice
	on common OS platforms via means other than (error-prone) manual
	configuration.  The whole notion that OS vendors will address this
	sort of allocation issue just because we think they should is an
	exercise in wishful thinking.
(6) Argument (3) above is incorrect, as the possible future persistent
	reserve functionality will not work as expected when different
	ISID values are used by the same Initiator to access Targets or
	Target Portal Groups for which sharing of persistent reserves is
	desired.

To correct the problem with (3), we would have to require that the same
ISID values be used across all Targets that may share an LU, which in
practice probably means all Targets as the LU sharing structure across
Targets is unlikely to be visible to iSCSI.  I hesitate to write such
a rule into iSCSI now to anticipate functionality that is still in a
"to be defined" state at T10, because it will impact implementations.

Julian and Jim's comments on specification of LU mapping miss the point.
The point is that really simple consistent rules for how things work at
this basic level are necessary to get management that scales decently.

To be specific, suppose I have a reasonable sized SMP machine that has
5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers
- how many iSCSI Initiator Names have to be configured into a Target LUN
masking implementation to give that machine access to its storage from
all 5 ports?

The iSCSI answer is a long version of "it depends" that starts with "find
the iSCSI documentation for your host and each of the HBAs to see how each
of them deal with iSCSI Initiator Names".  The possible values probably
range from 1-3.  In contrast, the corresponding Fibre Channel answer of 5
(Port WWN for each FC port) is superior even though it's a larger number
because it's the only possible answer and all the HBAs have to work the
same way.  The reason it's superior is that neither the management software
programmers nor the system administrators have to spend any mental cycles
having to think about instances of the same protocol that have to be
administered differently.

For iSCSI, the ideal answer to the above question is 1.  IMHO, removing
ISIDs
visibly increases the likelihood of that actually being the case all the
time
in practice.  Alternatively, if we leave ISIDs in, I'd want to see a hard
look at how to toughen the current ISID rule to prevent the problem
identified
in (6), and even then, I think the result is still less likely to lead to
the desired goal.

I think part of the difference I have with Jim Hafner is that I think he
wants to make it possible for the future target-spanning persistent
reservation functionality to work without requiring that it work (i.e.,
it'd be ok to have initiators behave in a way that reservations never
span targets, even when targets implement the new functionality).  I
don't think that's good enough - if we go to the trouble of enabling
this, we should do so in a fashion that is guaranteed to work in
the presence of target support for the feature.

As I said, I'm getting ready to give up on this, because I don't see much
in the way of appreciation of the importance of scalable management and
the role of simplicity (in the extreme) in enabling it on the list.

--David

> To:             
>                            Sent by:                 
> [email-masked]         
>                            [email-masked]            
> cc:             
> <[email-masked]>

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 3 Oct 2001 13:23:04 -0700

David,

I think your list of why we want ISIDs is missing some things (or perhaps
I've forgotten why they we're dropped from the list before).  But I'll take
a different tact.

My point is not to fixate on the ISID itself.  My point general point is
that I believe we need to have an unambiguous identifier of the SCSI
initiator port.  This is for reasons of
(a) persistent reserverations (as defined today) as well as for future
extensions
(b) there is an obligation today (I think) for the transport layer to
present to the OS layers above a "picture" of the SCSI Initiator Ports
(isn't that what you keep saying goes in /dev stuff?).   Wedge drivers rely
on this stuff too.
(c) some access control stuff (as defined by T10) but this is not a hard
requirement

I don't find the "Target gives the ports names" as meeting the needs listed
here (and I don't think it makes any sense from a model point of view
either).

One solution to this (which it sounds like you find acceptable) is the one
I've tossed on the table before:  every iSCSI Node is single ported and
you're back in the FC management headache space for target access control
configuration.

But you argue this is acceptable because that's what FC does and as long as
the implementation model is the same for everybody, it's easier.  You argue
that the direction we're going will make this much harder in iSCSI (you're
'that depends' remarks).  But aren't we going to have that anyway, as not
all systems will run HBAs of the same caliber?  We'll have some purely
software iSCSI drivers using generic nics, we'll have some purely software
iSCSI drivers bound to specific nics, we'll have some SW/HW driver combos
bound to TOEs, and some bound to iSCSI HBAs.  Each will have a different
infrastructure for even the iSCSI Names.   It will be a very long time (if
ever) where we have the "single instance of the protocol for management
purposes" you allude to as good about FC.

If you want to avoid the multiple 'names' management problem per OS image,
then you have to have names for SCSI Ports derived from (by appending)
something else.   I frankly don't care what it is, but I've argued that the
ISIDs are already there in the spec, so why not use them.  However, perhaps
because some feel that the ISID is closer to a dynamic pointer, we should
move off it for the purposes of naming SCSI ports.  It doesn't really
matter.  Given any name, it use has to be coordinated within the scope of
the iSCSI node, period.

In either case (one port per node OR many ports per node) you still have
the OptionA/OptionB problem in that you still have to define a rule that
says the same SCSI Initiator Port can't build more than one session to the
same SCSI Target Port (Target portal group)   AND you need an enforcement
of that by the target (option A or B).

Perhaps in the one port per node model, it is much less likely for this
RULE to be broken, so the consequences are less severe.

It looks to me like the trade offs boil down to
(a) managing a complex set of iSCSI Names (both detection in the OS and for
target access control configuration) [and I've argued that detection is not
as simple as FC, where even there, discovery took many years just to get a
common API to the drivers!]
OR
(b) finding a way to get name coordination (both iSCSI Name and Portname)
within an OS [and you've argued that this isn't going to happen.]

Does this encapsulate things more clearly (at least between us)?

I have a few other nits on some of your comments below, but I don't think
they'd help change any opinions.

Jim Hafner

[email-masked] on 10/03/2001 12:23:42 pm

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   [email-masked]
Subject:  RE: iSCSI: ISID issue

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 3 Oct 2001 13:23:03 -0700

David,

Jim Hafner

--David

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 4 Oct 2001 01:00:31 -0700

David,
We spent a lot of time yesterday at the end of the Naming and Discovery
Team (NDT) meeting, trying to rectify everything that you and Jim had been
sending notes about.  We tried to see if we could fully understand the
various positions.  I even argued your position regarding the Target
handling out the ISID but the group beat me back with their logic.  And
that Logic was included in Jim's latest Note.  Sorry I could not do a
better Job of representing your position.

However, there were some other things that we batted around that I will
cover here.  First, the Name which you want to work with in the iSCSI ACLs
is the iSCSI Initiator Node Name.  That should be the same for ALL iSCSI
Initiators in a Host Node.  If vendors attempt to use anything else, I
think they are not following the spec.  And should be sent to Singapore for
Caning :-)

If you accept that HBAs should get the iSCSI Initiator Node Name passed to
it in some manner from the OS, then we did not see why it can not get the
ISID at the same time also.  If one were to argue that the HBA can not get
the iSCSI Initiator Node Name, I think this is a bit strange, since almost
every thing I install in systems, has to go through some type of Wizard, or
vendor install routine  that actually installs the support driver, etc.
(This is all set when the OS is fully up and the Registry etc. is clearly
available.)  I would expect that with current OSs, this would be a normal
approach.  In the future, I suppose it might be possible that  the OSs
might have a more dynamic routine to hand out the iSCSI Initiator Node Name
and ISID so that Hot Swap HBAs could come up without effort.  However,
until then, I am not sure it is unreasonable for a vendor to require the
customer to run an update routine,  even after performing an HBA Hot Swap.

There is of course, the first up boot situation.  I think it should be
possible to have a default, first time HBA boot Name that uses the iqn form
of the iSCSI Name, and an ISID of 0.  This should be enough to bring up a
"first time up boot", since after the OS is started, the approprate install
routine should be kicked off, and the real iSCSI Initiator Node Name and
real ISID set in the Flash for that, and any other iSCSI HBAs.

So based on the above, I do not think requiring the HBAs to have an
install/update routine (which sets its Flash) is even a problem.

This means that a Single iSCSI Initiator Node Name should be easy to obtain
and will apply for all the iSCSI Initiators, whether HW or SW.

When Jim talked about the new SCSI idea that would have Persistent Reserves
being tied to the Initiator Node,  it seemed clear to me, and I think to
the others on the team, that the iSCSI Initiator Node Name was ideal to be
used for that purpose.  Jim pointed out, again to us, that this name was
NOT part of any other Nexus meaning, it is only to be used with Persistent
Reserves.   All other Nexus meanings are against the iSCSI Initiator's FULL
NAME which is the  iSCSI initiator Node Name and the ISID.

.
.
.
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
Internet address: [email-masked]

[email-masked]@ece.cmu.edu on 10/03/2001 12:23:42 PM

--David

---

From: [email-masked]
Date: Thu, 4 Oct 2001 12:24:38 -0400

John,

Lacking additional visible support, I'm going to give up on this
issue, but I think a serious mistake is being made.  Two portions

> think they are not following the spec.  And should be sent to Singapore
for

Not :-), rather an unrealistic exercise in wishful thinking.  I have yet
to see a coherent explanation of why this will not repeat the Fibre Channel
Node WWN experience (which started out with the same intention and the same
"not following the spec" notion for use of different Node WWNs on the same
Platform - nonetheless, that's what happened).  I expect problems to arise
not so much in iSCSI ACLs (a new mechanism), but in the adaptation of
existing
SCSI LU access control mechanisms to iSCSI.

> NAME which is the  iSCSI initiator Node Name and the ISID.

That is a change from what Jim has described on the list, which required
a persistent name for the iSCSI Initiator Port (not Node); what you have
described in the above paragraph does not.  Given that this sort of change
is possible in what T10 is considering, I think we should cease trying to
anticipate and provide for what T10 might (or might not) do, and instead
deal with the results of what T10 does after it happens.

The upshot is that ISIDs now serve no visible purpose, aside from
complicating session setup - nonetheless, they're apparently going to
stay in the specification ... did the N&D folks really intend this result?

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Thu, 4 Oct 2001 19:36:14 +0100

David,

>stay in the specification ... did the N&D folks really intend this result?

The N&D folks never had any input to the creation or defintion or
specification of the ISID itself (that was in the main draft long before we
ever formed as a team).  Nor as a team were they involved directly with how
ISIDs are used in the current model.  I'll take almost sole responsibility
for that, with appreciation to some individuals of the N&D team for their
useful discussions and support.   So, don't blame the team, blame me and by
association a few others who were involved (and happen to be also on the
N&D team).
However, all I/we did was take the defined existence of the ISID in the
protocol and give it an additional role in the SCSI model.

As I said in my last note, I'm willing to abandon use of the ISID for the
purposes of naming SCSI Initiator Ports and replace that with some text key
(so that ISIDs are removed from the dual role of identifying sessions AND
SCSI initiator ports).  But I haven't seen any specific proposal to that
effect and that addresses all the issues involved (as outlined also in my
last note).

In fact, if we do find an alternative to the ISID for naming SCSI Initiator
Ports, then the ISID would be  irrelevant to the SCSI model (as the TSID is
now) and we won't need the ISID rule anymore (we'd need another rule for
port names, however).  We can then ask if there is any value in the iSCSI
protocol for either the ISID or the TSID (as I did many many months ago
prior to this dicussion).

Jim Hafner

[email-masked]@ece.cmu.edu on 10/04/2001 05:24:38 PM

To:   John Hufferd/San Jose/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: ISID issue

John,

--David

---

From: [email-masked]
Date: Thu, 4 Oct 2001 14:33:04 -0400

Jim,

Ok, I think this is the key piece of your last note:

> My point general point is

I would do the following:

(a) Set aside all notion of "future extensions" thereby removing a need
	for an externally visible iSCSI Initiator Port Name for this
purpose.
(b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID
	for this purpose.  
(c) Do nothing in the absence of a "hard requirement", and try to use
	the Initiator Node Name for this purpose rather than a Port Name.

I would plan to deal with "future extensions" via a possible "future text
key"
to be specified after the "future extensions" are so that we have a concrete
set of requirements and objectives to work to.  In the Interim, we can
advise T10 that iSCSI strongly prefers reservations to be associated with
Initiators, rather than Initiator Ports.
 
> port names, however).

This includes one more reason:

(d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to.

As we discussed, and I think agreed, earlier, it is sufficient to assert
the existence of such an entity in an iSCSI implementation (some sort of
session data structure) for the purpose of mapping, but not provide an
externally visible name that is independently useful outside the bounds of
the specific iSCSI implementation.

I think this leads to removing ISIDs and the ISID RULE without substituting
a port name rule.  What goes wrong if this is done?

> We can then ask if there is any value in the iSCSI
> protocol for either the ISID or the TSID (as I did many many 
> months ago prior to this dicussion).

I'm not seeing any.  We might be better off using that field to hold
the Target Portal Group number; TSIDs would then only need to be unique
to an Initiator within a Target Portal Group, and hence could be
independently managed on a per-Portal Group basis, as opposed to the
current TSID RULE that spans the entire Target (instead of configuring
TSID ranges, one configures the Portal Group Number, which probably
needs to be configured anyway).  This also makes any attempt to span
Target Portal Groups or recover a session across Target Portal Groups
immediately obvious to the Target (the first is forbidden, the
second might work, but probably requires special handling at the Target,
and may need some more protocol support).  One consequence of
this field change would be to add Target Portal Group to (b) above, and
that may actually be a good thing  as it forces exposure of this
fundamental level of structure.

John had previously had a bad reaction to my additional suggestion to
change the TSID field size to 24 bits and the Portal Group field size to
8 bits if the ISID to Target Portal Group change is made, but that's a
second order issue at best (and one that I don't care that strongly about).

Are we getting anywhere?

Thanks,
--David

---

From: "Jim Hafner" <[email-masked]>
Date: Thu, 4 Oct 2001 19:56:56 +0100

David,

Comments in line.

Jim Hafner

[email-masked] on 10/04/2001 06:56:46 PM

To:   Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
cc:
Subject:  RE: iSCSI: ISID issue

Jim,

<JLH>
If we do (b), then we're effectively having hte target "name/identify" SCSI
Initiator Port.  OK, now, suppose the initiator has two sessions active to
given target portal group.  On one (say with TSID=5) he sends persistent
reserve registration and on another (say with TSID=7) he sends persistent
reserve registration + reservation.  Now the target resets and the
initiator cleans up context and starts up one new session.  What does the
target do?  Does it assign TSID=5 or 7 or 9?  What logic does it use?  The
order in which they were originally established?  Does it decide to use 7
cause that had more 'stuff' associated with it?  Does it decide to use 9 so
that it can forget/discard all the persistent reservation information?  The
point here is that the target doesn't have any basis on which to bind the
persistence property based on initiator port identifier.

I just don't see how that works even in today's model.

I don't know what you mean by (c).  What "purpose" are you talking about?
</JLH>

to be specified after the "future extensions" are so that we have a
concrete

<JLH>
But I also argued that existing OS's like to see some consistency (you've
even said they put stuff in /dev) on their initiator ports.  If these are
all driven by the target (in the sense of identification), then where can
the iSCSI layer provide such consistency?
</JLH>

I think this leads to removing ISIDs and the ISID RULE without substituting
a port name rule.  What goes wrong if this is done?
<JLH>
I hope my discussion above touches on what I see as going wrong.
</JLH>

<JLH>
You're proposal to include the target portal group number in the TSID is an
*implementation of configuring TSID ranges* for each target portal group,
isn't it?  In fact, that would be how I would implement it my target (if I
was building one, whether the spec said that it had this form or not -- and
I'm implement my host driver pretty much the same way, via enumeration of
drivers/devices  (which pretty much constitute initiator portal groups) as
they are discovered/loaded by the OS).  Such an implementation guarantees
compliance with the TSID RULE (and would do the same for the ISID RULE as
well).  So, you haven't avoided it, you've simply spec'ed an implementation
that meets the requirements.

The proposal to include the target portal group tag in the message header
(either within or separate from the TSID) is an independent issue from the
ISID one.
</JLH>

Are we getting anywhere?

Thanks,
--David

---

From: [email-masked]
Date: Thu, 4 Oct 2001 18:29:53 -0400

Yet more comments inline.  --David
 
>      for an externally visible iSCSI Initiator Port Name for this purpose.
> target do?  Does it assign TSID=5 or 7 or 9?

If the Initiator wants the state from TSID 5 (or 7), the Initiator sets TSID
to 5 (or 7) on Login.  If the Initiator does not want that state, it sets
TSID
to 0 on Login, and the Target can assign 9 or 15 or 523.  If the Target has
removed or lost the state for TSID 5 or 7, the Initiator gets back an error
when attempting to login using those TSID values.  Targets SHOULD NOT
aggressively reuse TSID values to avoid possible confusion (e.g., if in
the interim, the Target has assigned 5 to a new session from the same
Initiator, confusion may result - correctly written Initiators can avoid
such confusion, but not aggressively reusing TSID values increases
robustness).

[.. text asking how the above could work elided ..]

> I don't know what you mean by (c).  What "purpose" are you talking about?

Access control.  I think it should be clear by now that given the choice,
iSCSI Node Names are the preferred entities to use to express Access
Control policy and decisions, not iSCSI Port Names.  Note that my (a), (b),
and (c) were intended to respond to your (a), (b) and (c).

key"
concrete
> the iSCSI layer provide such consistency?

It won't be the TSID, and it probably won't be the ISID because, as
currently
specified, it also lacks sufficient consistency for this purpose.  The info
will come out of local device configuration information on the Initiator,
which may or may not turn out to match up with Initiator Portal Groups.
This
kind of thing is already platform-specific and will remain so.  Folks like
Veritas will continue to rely on their own volume headers for configuration
of VxVM and the like rather that device names (FWIW, this is the only
technique
that has proven to have sufficient robustness in practice).
 
> (either within or separate from the TSID) is an independent issue from the

I agree, but observe that if we specify the one and only way in which
the Target Portal Group MUST be encoded in the TSID, then code can be
written in both iSCSI implementations and management tools that relies
on the encoding being done that way.  I think there's value to that.

--David

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 5 Oct 2001 12:35:36 +0300

David,

Only a slight correction to ease your conscience. The text calls for a
dynamic ISID allocated by the OS. Jim just suggested that
in the kickoff stage implementation can get away with an almost static
allocation and even later may use a dynamic partitioning scheme instead of
a recourse to OS on every session creation.

Julo

                    Black_David@em                                                             
                    c.com                To:     John Hufferd/San Jose/IBM@IBMUS,              
                    Sent by:              [email-masked]                                      
                    owner-ips@ece.       cc:                                                   
                    cmu.edu              Subject:     RE: iSCSI: ISID issue                    

                    04-10-01 18:24                                                             
                    Please respond                                                             
                    to Black_David                                                             

John,

--David