Re: iSCSI Boot Last Call - Technical Comments

[Mark Bakke <mbakke@cisco.com>]

Mallikarjun-

My comments are embedded.

--
Mark

"Mallikarjun C." wrote:
> 
> > 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
> 
> How does the DHCP server distinguish which O/S level the client
> wants to boot from, to provide the right LUN in the Root Path?

The DHCP server doesn't.  In this type of environment, the DHCP server
is generally under the control of the same test folks who are booting
the servers.  One would manually change the LUN in the DHCP server
GUI or config file, and reboot.  The DHCP server doesn't have to do
anything special, but it's one more scenario where the LUN field is
directly manipulated by a user, which is why I'd like to keep it
simple.


> If it's a well-known LUN->O/S_rev mapping that the client boot
> code uses by convention, then there's no issue with always leaving
> the LUN field blank (for 0) in the DHCP response.  What am I missing?
> 
> > I still think that allowing a 16-bit LUN in the string is the
> > simplest, least error-prone approach.
> 
> AFAICT, this assumes that the user knows how to figure out which
> 16-bits of the 64-bit LUN are to be entered into the DHCP server
> file.  I'm not sure that's a valid assumption.


Actually, the user only has to worry about this when the 64-bit LUN
field is used.  The 16-bit version always ends up in the high
bytes of the LUN field in the protocol, and the user never sees
this structure, which is really not pretty.  I don't think most
users will ever want (or need) to see more than a 16-bit LUN.


> My preference is to require 64-bits always (if non-blank), so the boot
> client can simply copy the value in the iSCSI PDUs as-is.

What customer or user looks at iSCSI PDUs?  Would they copy and
paste one from a network analyzer?  This doesn't make sense to
me.  End users don't care about PDUs.


> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
> 
> ----- Original Message -----
> From: "Mark Bakke" <mbakke@cisco.com>
> To: "Prasenjit Sarkar" <psarkar@almaden.ibm.com>
> Cc: "Constantine Sapuntzakis" <csapuntz@stanford.edu>; "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 2:39 PM
> Subject: Re: iSCSI Boot Last Call - Technical Comments
> 
> > 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
> >

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