RE: iSCSI: Wrapping up SendTargets

[Black_David@emc.com]

Since this seems to need a consensus call, I believe the
WG consensus on SendTargets for iSCSI is:

- Retain the functionality, document it in the main
	portion of the specification.
- SendTargets will not return Aliases or Certificates.
	This is part of limiting its functionality to
	basic description of the iSCSI device to which
	it is attached.
- Add an <iSCSI Target Name> argument to Send Targets
	to enable it to perform what has previously been
	called Report Portal Groups.  When the target name
	is present (even the canonical "iscsi" target),
	the result is to return portal information.

Reviewing the mail thread since Mark's initial message
with the above subject line:
- Doug Otis's objections appear to be to iSNS and not
	to the above proposed SendTargets consensus.
- The proposed consensus to document SendTargets in
	the main part of the specification takes note
	of and hence overrides Larry Lamers's preference
	for documenting in an Annex.
Anyone who disagrees with the above statement of consensus
should post to the list.

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

Comments?

Thanks,
--David

> -----Original Message-----
> From:	Mark Bakke [SMTP:mbakke@cisco.com]
> Sent:	Wednesday, June 20, 2001 10:02 AM
> To:	John Hufferd
> Cc:	ips@ece.cmu.edu
> Subject:	Re: iSCSI: Wrapping up SendTargets
> 
> 
> This thread turned out more interesting than I had expected,
> but anyway, after reading through the messages sent while I
> was gone, it looks like we at least have some consensus on
> keeping SendTargets.
> 
> I would like to see John's option #2 as well.  Currently,
> SendTargets is documented in the naming & discovery document;
> where should we put it in the iSCSI spec?
> 
> We will also need to close on some of the previous threads
> about aggregation tags, iteration, etc.
> 
> It looks like we should continue the thread on the future
> (SLP, iSNS, etc.) discovery stuff, but I should have started
> that one separately.
> 
> --
> Mark
> 
> John Hufferd wrote:
> > 
> > iSCSI Team,
> > I think that Jim has said it well.  I had a proposal about an Annex, for
> > the SendTargets, but whether we do that or not, I am getting the feeling
> > that most folks think, at least for this version of the protocol that we
> > keep SendTargets, and the subset that can be used as a Report Portal
> > Groups.  Even Mark, even though he thought he could Hack the SLP Source
> > code to do a similar thing, thought that it was best to keep
> SendTargets.
> > 
> > I would like to propose that we Close on Keeping the SendTargets
> command,
> > and the subset that is either Report Portal Groups or SendTargets <iSCSI
> > Target Name> (which returns only the information for that target only).
> > 
> > Now as to where we put the command.  I suggested an Annex, but can
> clearly
> > live with it in the Main document.  I seemed to get very little support
> for
> > the idea of the Annex, and since I think that the functions of Report
> > Portal Groups, must be part of the base,  I would like to suggest that
> we
> > either
> > 1) Place the SendTargets in the Annex, and put a Report Portal Groups in
> > the main document, or
> > 2) Keep the Send Targets in the Main Document and add the argument of
> > <iSCSI Target Name>
> > 
> > Please state your positions
> > 
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Internet address: hufferd@us.ibm.com
> > 
> > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 06/12/2001 04:56:10 PM
> > 
> > Sent by:  owner-ips@ece.cmu.edu
> > 
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  RE: iSCSI: Wrapping up SendTargets
> > 
> > Folks,
> > 
> > I think this thread is wandering off the field.
> > 
> > The question is the issue of SendTargets.  Let's remind ourselves of the
> > original purpose of this proposed protocol: namely, it's designed for a
> > storage box that contains one or more iSCSI target devices to report
> about
> > ITSELF, about what's in it!  This includes both a list of the iSCSI
> targets
> > it has PLUS the session coordination (via tags) of the various
> > IPaddress/tcpport combos it supports.
> > 
> > In other words, it's job is to report about itself!  The use of
> (unicast)
> > SLP as an alternative to SendTargets was focused exactly on the same
> > question: I ask a single box to tell me about itself.   This function
> lies
> > between the two extremes of (a) static configuration of initiators and
> (b)
> > centralized management via iSNS style services.
> > 
> > Somehow, someway, we need to define a protocol for a box to "tell us
> about
> > itself" in the absense of the centralized management infrastructure.
> That
> > seems critical to me.  Even if I want to do static configuration, the
> guy
> > doing the configuration needs a way to get at the guts of each new box
> > he/she rolls into the environment.
> > 
> > The choices are, it seems, that *every* box would need to support at
> least
> > one of:
> > a) SendTargets
> > b) modified SLP
> > c) iSNS
> > 
> > What's the consensus on the protocol we aim for to solve this middle
> ground
> > discovery problem?
> > Jim Hafner
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054