Re: iSCSI Boot Last Call - Technical Comments

[Mark Bakke <mbakke@cisco.com>]

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

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054