Re: iSCSI Boot Last Call - Technical Comments

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

My personal opinion is that an argument is on a very slippery slope when it
relies on editing iscsi names vs editing luns. I do not find this mult-OS
testing scenario compelling enough to make this change.

I dont think Mallikarjun was referring to users looking into PDUs - he was
referring to LUN equivalence.

Regardless of my personal opinion, I think there are more voices against
making the change than in favor.

Sincerely,
Prasenjit







----- Original Message -----
From: "Mark Bakke" <mbakke@cisco.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: "Prasenjit Sarkar" <psarkar@almaden.ibm.com>; "Constantine Sapuntzakis"
<csapuntz@stanford.edu>; <ips@ece.cmu.edu>
Sent: Wednesday, September 11, 2002 3:29 PM
Subject: Re: iSCSI Boot Last Call - Technical Comments


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