SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSNS comments



    Sandeep,
    	thanks for the iSNS feedback.  Please see responses below.
    		Regards, Kevin
    
    -----Original Message-----
    From: sandeepj@research.bell-labs.com
    [mailto:sandeepj@research.bell-labs.com]
    Sent: Thursday, March 08, 2001 7:35 AM
    To: ips@ece.cmu.edu
    Subject: Re: iSNS comments
    
    
    > some comments on the new iSNS draft
    > 
    > 1) it lacks a Table of contents, unlike iSCSI.  please add one.
    >    (given that, i am liable to have missed some section which 
    >     might have answered the questions raised below!)
    
    kg> we can add a TOC to the next update of the document.
    
    > 
    > 2) What happens if an iSNS client tries to update its 
    >    TCP/UDP port or IP address (for Portal/ESI/etc) ?
    >    
    >    So the entry exists, and now the client sends a RegDevAttr
    >    request with the update flag set for changing the above.
    >    
    >    If the port(s) is going to be well-known, the questions below 
    >    may not arise.  If not,...
    >  
    >    a) Will the old TCP connection be broken by the iSNS server ?
    
    kg> Who breaks the former connection first is implementation 
    dependent.  However, the iSNS server initiates the TCP 
    connection to the new port for the next ESI message.  The ip 
    address and port used for ESI messages does not have to be the 
    same as portal addresses that an entity has registered.
    
    >    b) Would the RegDevResponse be sent to the old/new port ?
    
    kg> as described in section 7.2, the response will be sent 
    to the same IP Address and Port that the registration 
    message originated from.
    
    >    c) Who initiates the new connection (client or server) ?
    
    kg> the iSNS server will initiate the connection for the next 
    ESI.  There was concern during the design that the server, 
    rather then the client, be in control of the ESI period and 
    connection process to manage the ESI handling overhead.
    
    >    d) How would the client know the request succeeded ?
    
    > i see what i missed here.. SLP, which is orthogonally managing 
    > the "control" plane.  the questions above dont arise.
    
    kg> The client will know the request succeeded from the 
    RegDevResponse message status field, sent by the iSNS is 
    response to the request.
    
    >    
    > 3) Is there a requirement to provide (keyword=MUST) a secondary 
    >    iSNS server ?  If I am not mistaken, DNS does mandate a  
    >    secondary server for every zone to avoid single-pt-of-failure.
    >   
    
    kg> There was concern that the design not mandate a requirement 
    for a secondary server for situations where High Availability 
    is not a concern.  If desired, additional text can be added to 
    recommend secondary server in HA configurations.
    
    > 
    > -Sandeep
    


Home

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