SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Wrapping up SendTargets



    
    John & Company,
    
    I think that the arguments for (and against) leaving SendTargets
    in the main draft, as an annex, or outside of the iSCSI draft
    altogether all have some merit and that's why this is a difficult
    decision.  I tend to agree with Marjorie's assesment of the 
    situation...
    
    >IMO, it's a judgement call where you draw the line between architectural
    >purity and practical functional encapsulation.  My current feeling is that
    a
    >limited SendTargets function adds a small amount of implementation burden
    >and a large amount of functional value to product solutions.
    
    The work towards implementing the SendTargets targets functionality
    outside of iSCSI should likely continue.  At this point, we have Mark's
    verification of workability, but still we have questions about
    security/authentication, changes to drafts, etc.
    
    Finally, the ReportPortalGroups is good idea, and it seems to me
    more closely tied to the session nature of the iSCSI protocol.
    However, because I'm leaning towards leaving SendTargets in the
    main draft, I would recommend the SendTargets <iSCSI name> syntax.
    
    So, I'm arguing for John's suggestion of #2.
    
    Thanks,
    Todd.
    
    -----Original Message-----
    From: John Hufferd [mailto:hufferd@us.ibm.com]
    Sent: Tuesday, June 12, 2001 6:09 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI: Wrapping up SendTargets
    
    
    
    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
    
    
    
    


Home

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