Re: iSCSI Boot Last Call - Technical Comments

[Constantine Sapuntzakis <csapuntz@stanford.edu>]

Many people also use emacs/vi for their configuration too, so they have 
the same problem Mark has with the GUI. I would agree with Mark on his 
point about entry being error-prone.

-Costa


Mark Bakke wrote:
> It would be nice if the GUI could handle this.  However, a DHCP
> GUI (Microsoft, for example), only provides a place to paste in
> the entire root-path option; it won't give you separate fields
> to type in the IP address, LUN, and target name.  So the user is
> left with the job of correctly typing in the root-path option.
> We found (through experience) that the LUN field was particularly
> frustrating, expecially since a 16-bit LUN value actually appears
> in the top characters of the LUN field.  For example, LUN 12 (hex
> 0x0c) would appear as:
> 
> 000c000000000000
> 
> in the option string.  Getting the wrong number of zeroes before
> or after either causes the option to be refused by a network boot
> program, or causes the wrong LUN to be tried.  Either way, the
> user has to decide what the problem is, fix the LUN string,
> and try again.  It's also a bit non-intuitive since most users
> would expect that the LUN should have been entered as
> 
> 000000000000000c
> 
> (BTW, I missed a zero counting that last one, and I caught it
> because the length looked wrong comparing it to the previous
> one).
> 
> Anyway, this is an extremely easy thing to do to make our users'
> lives easier, and we have no control over adding iSCSI user
> interface capabilities to DHCP servers.
> 
> I really think that this is the right thing to do.
> 
> --
> Mark
> 
> Prasenjit Sarkar wrote:
> 
>>
>>
>>
>>
>>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
> 
>