RE: iSCSI: Send Targets and Report Portal Groups

[Joshua Tseng <jtseng@NishanSystems.com>]

Kal,

I agree with you in supporting John's compromise.
Sendtargets should be documented SOMEWHERE, since many
have already implemented it.  In addition, I believe
a lightweight discovery mechanism would be useful in the
short term until iSNS and SLP integration issues are
"shaken out".  Therefore, I believe an annex would be a
convenient place to document Sendtargets until the other
discovery mechanisms can move forward.

Josh

> -----Original Message-----
> From: Kaladhar Voruganti [mailto:kaladhar@us.ibm.com]
> Sent: Thursday, June 07, 2001 1:31 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Send Targets and Report Portal Groups
> 
> 
> 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
> 
> 
> 
>