RE: iSCSI: Wrapping up SendTargets

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

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