RE: iSCSI: Wrapping up SendTargets

[Black_David@emc.com]

Marj,

> I don't understand what you're thinking of here - SendTargets is intended
> partly as a discovery mechanism.  Why would we limit it to only "only
return
> information about targets that are accessible through an <IP address, TCP
> port>"?  
> 
> What's your concern about "same canonical target"??

Suppose we have three independent iSCSI systems,
X, Y and Z.  My understanding of the sense of
the discussion is that the desired approach
is that an Initiator discovers via some other
means that it should talk to X, Y, and Z,
and then SendTargets on each system only returns
information about targets on that system.

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.  This forces
more <IP address, TCP port> pairs to be
discovered prior to issuing Send Targets.

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

"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.

Does that make things clearer?  Do you see a
need for a SendTargets issued to system X to
return information about system Y?

Thanks,
--David


> -----Original Message-----
> From:	KRUEGER,MARJORIE (HP-Roseville,ex1) [SMTP:marjorie_krueger@hp.com]
> Sent:	Friday, June 22, 2001 8:13 PM
> To:	'Black_David@emc.com'; mbakke@cisco.com
> Cc:	ips@ece.cmu.edu
> Subject:	RE: iSCSI: Wrapping up SendTargets
> 
> ..snipping..
> > 
> > There's one issue that's not completely clear to me from
> > the discussion, and that is how to limit the scope of
> > information that is returned by SendTargets to match what
> > I believe to be the sense of the discussion that SendTargets's
> > purpose is to describe the device/implementation/instance
> > to which it is issued. I can see a couple of choices:
> > (A) SendTargets only returns information about targets that
> > 	are accessible through the <IP address, TCP port> to
> > 	which the SendTargets was issued.
> > (B) SendTargets only returns information about targets that
> > 	are accessible through an <IP address, TCP port> that
> > 	can also access the *same* canonical iSCSI target
> > 	instance to which the SendTargets was issued.
> 
> I don't understand what you're thinking of here - SendTargets is intended
> partly as a discovery mechanism.  Why would we limit it to only "only
> return
> information about targets that are accessible through an <IP address, TCP
> port>"?  
> 
> What's your concern about "same canonical target"??
> 
> > (A) is the simpler one to explain and understand, and may
> > do a better job of structuring the discovery process (new
> > iSCSI "instances" can't be discovered as a result of issuing
> > SendTargets) at the price of potentially having to discover
> > more iSCSI communication endpoints to which SendTargets
> > has to be issued at the earlier stage of discovery.
> 
> This defeats part of the intent of SendTargets?
> 
> > (B) allows configuration to be centralized in some cases where
> > (A) does not, but the notion of "*same* canonical iSCSI
> > target instance" strikes me as hard to define and enforce
> > in a protocol spec, and opens SendTargets up to
> > virtualization of the canonical target (e.g., by
> > replication of state information) in a fashion that could
> > turn SendTargets into a network-wide discovery mechanism,
> > which seems contrary to the sense of the discussion.
> > (A) seems to be the choice that better fits what I
> > believe the sense of the discussion is.
> 
> The behavior outlined by the Naming and Discovery team for SendTargets is
> dependant on what target name an initiator is logged into. 
> 
> SendTarget response: 
>    **logged into 'iSCSI' target ->  repeating (list of targetname and 
>      all associated paths to that name w/aggregation tags) 
>      filtered by initiator access rights.
> 
>    **logged into <explicit target name> - should be 'report portal groups'
> flavor of SendTargets where the information is limited to the information
> about "the target being addressed" rather than a list of all accessible
> targets for this initiator.
> 
> 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