SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI Boot Last Call - Technical Comments



                                                                                                                   
                                                                                                                   
                                                                                                                   
    
    
    Mark,
    
    I tend to agree with Jim that machines can help with 8-byte entities.
    
    Regarding the prioritization, I do not doubt that your assertion will
    generally hold true, but at the same time, I feel that we should not make
    any assumptions about the order of updates to the Discovery and DHCP
    databases in a boot environment. However, if people insist, I can make the
    change.
    
    Thanks,
    
       Prasenjit Sarkar
       Research Staff Member
       IBM Almaden Research
       San Jose
    
    
    
                                                                                                                   
                          Jim Hafner                                                                               
                          <hafner@almaden.i        To:       Mark Bakke <mbakke@cisco.com>                         
                          bm.com>                  cc:       Prasenjit Sarkar <psarkar@almaden.ibm.com>, Duncan    
                          Sent by:                  Missimer <duncan_missimer@hp.com>, Costa Sapuntzakis           
                          owner-ips@ece.cmu         <csapuntz@stanford.edu>, Elizabeth Rodriguez                   
                          .edu                      <erodrigu@Brocade.COM>, David Black <Black_David@emc.com>,     
                                                    John Hufferd/San Jose/IBM@IBMUS, IPS <ips@ece.cmu.edu>         
                                                   Subject:  Re: iSCSI Boot Last Call - Technical Comments         
                          09/10/2002 07:59                                                                         
                          AM                                                                                       
                                                                                                                   
                                                                                                                   
    
    
    
    
    Mark,
    
    I would rather not go the route your going with the LUN number issue.  GUIs
    can always do the translation to more nibbles under the covers.  Besides,
    if you have a LUN that has only 16bits or less of significant (i.e.,
    nonzero) digits, you'll need to carefully specify where these digits go in
    the 8 byte defined SCSI LUN and that depends on the LUN number convention
    of the target.   So, to avoid that can of worms and the extra descriptions
    required, I'd suggest leaving this as an 8byte (16 hex nibble) field.
    
    On the other point, I have no opinion.
    
    Jim Hafner
    
    
    Sent by:        owner-ips@ece.cmu.edu
    
    
    To:        Prasenjit Sarkar <psarkar@almaden.ibm.com>, Duncan Missimer
    <duncan_missimer@hp.com>, Costa Sapuntzakis <csapuntz@stanford.edu>,
    Elizabeth Rodriguez <erodrigu@Brocade.COM>, David Black
    <Black_David@emc.com>, John Hufferd/San Jose/IBM@IBMUS, IPS
    <ips@ece.cmu.edu>
    cc:
    Subject:        iSCSI Boot Last Call - Technical Comments
    
    
    
    
    I have only a few technical comments on the boot draft.  The editorials
    have been sent to the authors.  The draft looks good!
    
    Page 4
    
    >    The "LUN" field is a hexadecimal representation of the 8-byte LU
    >    number.  Digits above 9 may be either lower or upper case, and all 16
    >    nibbles must be present. If the LUN field is blank, then LUN 0 is
    >    assumed.
    
    Since most LUNs are just 16 bits (and many of these are even smaller),
    I'd like to relax this a bit.  Typing 14 or 15 zeroes plus the actual
    LUN value into a field in the DHCP GUI is quite error-prone, since in
    a DHCP server's user interface or /etc/dhcpd.conf, this string will be
    entered directly by the end user.
    
    So in addition to the rules above, how about:
    
    - If the LUN field contains four or fewer hex digits, these digits
    constitute the LUN number from which to boot.
    
    
    Page 5
    
    >    It is possible that the port number obtained from the Discovery
    >    Service may conflict with the one obtained from the DHCP service. In
    >    such a case, the implementor has the option to try both port numbers
    >    in the Boot stage.
    
    In this case, I think that we should pick one to take precedence, instead
    of leaving it up to the implementor.  Since the discovery service should
    have the most up-to-date IP address and port number information, I think
    that it should be the one that is used.
    
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

Last updated: Tue Sep 10 12:18:59 2002
11797 messages in chronological order