RE: iSCSI: Wrapping up SendTargets

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

> Restricting SendTargets to only describe targets
> accessible through the <IP address, TCP port>
> on which it was issued prevents X from returning
> information about Y and Z.  It also prevents
> X from returning information about targets on
> X that are only accessible through other IP
> addresses and/or TCP ports.

I don't see the value of this restriction.  

One method to implement an iSCSI solution might use a configuration utility
to specify a list of IP addresses representing separate targets (minimal
configuration information), and then expect that a SendTargets command
issued to the "iSCSI" target at these IP addresses to allow discovery of all
IP addresses and accessable targets that are a part of the reporting iSCSI
implementation.

If duplicate target information is 'discovered', it can be reconciled by
comparing target names.

The rules you've outlined would preclude this?

> This forces
> more <IP address, TCP port> pairs to be
> discovered prior to issuing Send Targets.

How?

> 
> That may be a good thing - for example it makes
> it possible for a management tool to figure out
> where all of some Initiator's storage is without
> ever issuing any SendTarget commands.

That might be 'nice', but not mandatory.

> It would
> be a "bad thing" if the only way to find Y was
> to issue a SendTargets to X (e.g., simple
> mistake in configuring X can hide Y from
> the management tool, even if all the Initiators
> still work).  This argument is somewhat less
> compelling when we're dealing with two ports
> on X instead of X and Y.

I wouldn't necessarily advocate such a solution, but it's implementation
dependant.  We MUST NOT dictate implementation.

> 
> "same canonical target" was an attempt to deal
> with the "It also prevents ..." sentence above.
> The concern I have is about someone placing
> information about X, Y, and Z on all of X, Y,
> and Z, and then claiming that the "iscsi"
> canonical target on X, Y, and Z is the same
> target because the same information is returned
> in each case.  This seems to make the "same
> <IP address, TCP port>" approach preferable.

I don't see your concern here.  The "iSCSI" target name is not unique, does
not represent a fully functional target, and MUST NOT be compared to
determine 'target identity'.  That seems clear.  If different IP addresses
report the same information via SendTargets, the initiator's functional
sessions will be to the <full target names> reported.  What's the harm?  I'm
not advocating this approach, but if implemented correctly, it should work.

When we talk about SendTargets "returning a list of targets", we are mostly
thinking about the notion that a single iSCSI target node might chose to
export different capabilities (LUN maps, features?) by exporting multiple
target names.  I'm not sure anyone envisioned the scenario you outline, but
I don't see any real issues with it.

> 
> Do you see a
> need for a SendTargets issued to system X to
> return information about system Y?

No, but I see no reason to prohibit this.

-Marj