Re: iSCSI Boot Last Call - Technical Comments

[Mark Bakke <mbakke@cisco.com>]

It's true that in many cases, zero is all that is needed.  However,
consider an application where a host will be able to be booted from
a small set of different LUNs, perhaps to change O/S levels in a
test environment, or to make a different application available
on the host.  Having these LUNs mapped behind the same iSCSI target
and editing the LUN in the root-path string is a lot simpler than
having several different targets, and changing the iSCSI name in
the root-path.

I still think that allowing a 16-bit LUN in the string is the
simplest, least error-prone approach.

--
Mark

Prasenjit Sarkar wrote:
> 
> 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
> > >
> > >
> >
> >
> >
> >

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