iSCSI: Send Targets and Report Portal Groups

["Kaladhar Voruganti" <kaladhar@us.ibm.com>]

John,
I am supporting your solution because it is a compromise, and there are
many who are already using the SendTarget discovery method.

Reasons for having it (others can add to this list):
1) Already many implementations are using it.
2) Purists will argue that it is a simple discovery method and not a
management mechanism.
3 ) Can use the same Login and authentication mechanism as iSCSI.
4) iSCSI will not be the first protocol to have an in-band discovery
mechanism (Report_Luns in SCSI).
5) Simple implementations will not have to use SLP or iSNS.

Reasons for not having it (others can add to this list):
1) Do not want discovery mechanism as part of the protocol.
2) It will continue to evolve and is not as simple as it seems.
3) IETF standards approving body will have a problem with it, and this will
delay the approval of the whole standard.
4) Can use SLP or iSNS to get the same functionality, and we can piggyback
on the future enhancements to these discovery protocols.

If we do keep the SendTarget command, then I want the following two points
clarified:

1) If we keep SendTargets in version 1 annex, will it still be optional to
implement?
2) What is the impact (if any) of passing digital certificates with  the
SendTarget response?

I also agree that there is a need for a Report Portal Groups type of
command. I will let people argue whether it is a separate issue than the
SendTargets command.

Kaladhar






---------------------- Forwarded by Kaladhar Voruganti/Almaden/IBM on
06/07/2001 12:59 PM ---------------------------

John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 06/06/2001 07:34:01 PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: Send Targets and Report Portal Groups



iSCSI Team,
I would like to propose the following approaches to address the issues of
Send-Targets, and Report Portal Groups.

The way Send-Targets has evolved, which is now a separate interaction with
its own Login, makes it seem like the same function can be rationally
performed by current Discovery Functions in SLP or iSNS.  Now this is not
completely correct, but close enough for me to propose a compromise.
Before I state the compromise let me address the items that are current
concerns with an SLP or iSNS approach of replacing Send-Targets.

1. The current SLP Open Source does not do a Unicast to ask for the
information.  This is not a shortcoming of the SLP protocol, just the
current API/Implementation.  Mark Bakke has made a Hack into the Open
Source and believes that it will work just fine, and also thinks he has
support for that approach from the Owners of the Open Source.  However,
there is still some uncertainty here, which will only be cleared up with
time and multiple implementations.
2. There are separate Authentication models followed by SLP/iSNS as opposed
to iSCSI.  Therefore, any Initiator attempting to do SLP or iSNS for basic
discovery, needs to address two Authentication models, the discovery
method's authentication approach, and iSCSI's.
3. In small installations it is not clear that there will be an SLP or iSNS
setup on which to leverage this approach.

Now,  I am cretin there will be arguments about the importance of any of
those points,  the issue is -- the uncertainty of favorable results.

I am of the belief that it maybe worth the effort to move in the direction
of "atrophying" the Send Targets Command and Processes.  That is, it serves
a current and valuable function, of which a favorable replacement, though
probable, is uncertain at this time.  So we should begin moving in the
direction of the SLP/iSNS approach, but without additional care and feeding
of Send Targets.  An approach to this is to move the Send Target Command
and Processes, into an Annex of the main iSCSI protocol document.  As such
it will be a current requirement for implementation, but it will also be
clear that we believe it may be eliminated in version 2 of the iSCSI
document (when ever that occurs) and is not something in which feature
creep will be permitted.

I think the above approach will satisfy the folks that have been building
and testing various product approaches that depend on Send Targets, and yet
give them time to move to an SLP or iSNS type approach as the concerns
specified above are worked out.

It is also possible that in the future, we will find that we are
fundamentally wrong in some of our key assumptions, and that Version 2 may
move it back into the main document.  That would also be acceptable,
because I do not believe it would happen lightly, and would have to have
great reasoning and logic behind such a move.

Now, I would like to address the Report Portal Groups.  I do not place this
in the same category as Send Targets.  It is a specific query about the
environment of the specific session in which the command is issued.  It is
analogous to Report LUNs, and querying Mode Pages.

For those of you that have not been following this closely, the Report
Portal Groups, is a command that responds with the IP addresses that can be
used by the initiator of the current session, to add additional connections
to the current session (and thereby support Multiple Connections per
Session).

It is specific to its own session, and not to some general management item.
Some might say that this too could be discovered by some management
function, however, that could also be true about many of the Mode Page
setting also.  In my opinion the Portal Groups will probably be "wired in"
by the Storage Controller vendor and not be something that is settable by
the administrator.  In fact with Report Portal Groups, being part of the
base protocol, the SLP/iSNS (or the Send Targets Command)  will not have to
include the portal group identification/tagging in its responses, thus
simplifying them.

So as part of my proposed compromise I recommend that we put "Report Portal
Groups" into the main iSCSI Protocol Document, like any of the other iSCSI
Commands, and move the Send-Targets command to an Annex as specified above.



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