SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:32 2001
6315 messages in chronological order