SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: ISID issue



    
    David,
    
    Only a slight correction to ease your conscience. The text calls for a
    dynamic ISID allocated by the OS. Jim just suggested that
    in the kickoff stage implementation can get away with an almost static
    allocation and even later may use a dynamic partitioning scheme instead of
    a recourse to OS on every session creation.
    
    Julo
    
    
                                                                                                   
                        Black_David@em                                                             
                        c.com                To:     John Hufferd/San Jose/IBM@IBMUS,              
                        Sent by:              ips@ece.cmu.edu                                      
                        owner-ips@ece.       cc:                                                   
                        cmu.edu              Subject:     RE: iSCSI: ISID issue                    
                                                                                                   
                                                                                                   
                        04-10-01 18:24                                                             
                        Please respond                                                             
                        to Black_David                                                             
                                                                                                   
                                                                                                   
    
    
    
    John,
    
    Lacking additional visible support, I'm going to give up on this
    issue, but I think a serious mistake is being made.  Two portions
    of your message reinforce my opinion:
    
    > However, there were some other things that we batted around that I will
    > cover here.  First, the Name which you want to work with in the iSCSI
    ACLs
    > is the iSCSI Initiator Node Name.  That should be the same for ALL iSCSI
    > Initiators in a Host Node.  If vendors attempt to use anything else, I
    > think they are not following the spec.  And should be sent to Singapore
    for
    > Caning :-)
    
    Not :-), rather an unrealistic exercise in wishful thinking.  I have yet
    to see a coherent explanation of why this will not repeat the Fibre Channel
    Node WWN experience (which started out with the same intention and the same
    "not following the spec" notion for use of different Node WWNs on the same
    Platform - nonetheless, that's what happened).  I expect problems to arise
    not so much in iSCSI ACLs (a new mechanism), but in the adaptation of
    existing
    SCSI LU access control mechanisms to iSCSI.
    
    > When Jim talked about the new SCSI idea that would have Persistent
    Reserves
    > being tied to the Initiator Node,  it seemed clear to me, and I think to
    > the others on the team, that the iSCSI Initiator Node Name was ideal to
    be
    > used for that purpose.  Jim pointed out, again to us, that this name was
    > NOT part of any other Nexus meaning, it is only to be used with
    Persistent
    > Reserves.   All other Nexus meanings are against the iSCSI Initiator's
    FULL
    > NAME which is the  iSCSI initiator Node Name and the ISID.
    
    That is a change from what Jim has described on the list, which required
    a persistent name for the iSCSI Initiator Port (not Node); what you have
    described in the above paragraph does not.  Given that this sort of change
    is possible in what T10 is considering, I think we should cease trying to
    anticipate and provide for what T10 might (or might not) do, and instead
    deal with the results of what T10 does after it happens.
    
    The upshot is that ISIDs now serve no visible purpose, aside from
    complicating session setup - nonetheless, they're apparently going to
    stay in the specification ... did the N&D folks really intend this result?
    
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    
    


Home

Last updated: Fri Oct 05 07:18:17 2001
7063 messages in chronological order