Re: iSCSI Boot Last Call - Technical Comments

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

Mark and Costa,

If you are so very concerned with entering the value wrong, you can leave
the lun value blank. The lun value defaults to zero and you can always use
lun mapping in the target to make the boot lun to be zero for the initiator.

Analogous to the other issue you brought up, I think this is going to be the
common case.

Sincerely,
Prasenjit

----- Original Message -----
From: "Constantine Sapuntzakis" <csapuntz@stanford.edu>
To: "Mark Bakke" <mbakke@cisco.com>
Cc: "Prasenjit Sarkar" <psarkar@almaden.ibm.com>; "Jim Hafner"
<hafner@almaden.ibm.com>; "David Black" <Black_David@emc.com>; "Duncan
Missimer" <duncan_missimer@hp.com>; "Elizabeth Rodriguez"
<erodrigu@Brocade.COM>; "IPS" <ips@ece.cmu.edu>; "John Hufferd"
<hufferd@us.ibm.com>; <owner-ips@ece.cmu.edu>
Sent: Tuesday, September 10, 2002 11:17 AM
Subject: Re: iSCSI Boot Last Call - Technical Comments


> 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
> >
> >
>
>
>
>