Re: iSCSI: Send Targets and Report Portal Groups

["Mallikarjun C." <cbm@rose.hp.com>]

Some comments -

- I think SendTargets is a useful functionality and should find
  place in the main draft.  It is a discovery mechanism to find the
  multiple iSCSI targets behind one iSCSI address, just as the 
  REPORT LUNS which finds the multiple LUs behind one SCSI target.
  Former is an iSCSI-ism with an iSCSI solution, the second is a 
  SCSI-ism with a SCSI solution.

- I fail to see why SendTargets should be placed in an annex, when
  it is not informative.  I see this as no different from other areas 
  like error recovery where we are hopeful of future simplifications, 
  which  we certainly are not placing in annexes today. 
 
- I agree with Paul that "Report Portal Groups" is nice but something
  that doesn't seem like a requirement, particularly if aggregation tags
  are supported by SendTargets. 

- I share the concern about feature creep in SendTargets.  For 
  example, the TargetAlias feature seems more like a management
  issue to me which I feel should be dropped.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


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