Subject: Re: iSCSI Boot Last Call - Technical Comments

From: Mark Bakke <[email-masked]>
Date: Tue, 10 Sep 2002 11:30:28 -0500

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
>                       <[email-masked]        To:       Mark Bakke <[email-masked]>
>                       bm.com>                  cc:       Prasenjit Sarkar <[email-masked]>, Duncan
>                       Sent by:                  Missimer <[email-masked]>, Costa Sapuntzakis
>                       [email-masked]         <[email-masked]>, Elizabeth Rodriguez
>                       .edu                      <[email-masked]>, David Black <[email-masked]>,
>                                                 John Hufferd/San Jose/IBM@IBMUS, IPS <[email-masked]>
>                                                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:        [email-masked]
> 
> To:        Prasenjit Sarkar <[email-masked]>, Duncan Missimer
> <[email-masked]>, Costa Sapuntzakis <[email-masked]>,
> Elizabeth Rodriguez <[email-masked]>, David Black
> <[email-masked]>, John Hufferd/San Jose/IBM@IBMUS, IPS
> <[email-masked]>
> 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
> [email-masked]
> 763.398.1054

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Prasenjit Sarkar <[email-masked]>
Date: Tue, 10 Sep 2002 09:00:55 -0700

Mark,

Thanks,

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                      Jim Hafner                                                                               

Mark,

Jim Hafner

Page 4

Page 5

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Tue, 10 Sep 2002 16:39:50 -0500

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" <[email-masked]>
> To: "Mark Bakke" <[email-masked]>
> Cc: "Prasenjit Sarkar" <[email-masked]>; "Jim Hafner"
> <[email-masked]>; "David Black" <[email-masked]>; "Duncan
> Missimer" <[email-masked]>; "Elizabeth Rodriguez"
> <[email-masked]>; "IPS" <[email-masked]>; "John Hufferd"
> <[email-masked]>; <[email-masked]>
> Sent: Tuesday, September 10, 2002 11:17 AM
> > 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:
> > >>                      Sent by:                  Missimer
> <[email-masked]>, Costa Sapuntzakis

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Prasenjit Sarkar" <[email-masked]>
Date: Tue, 10 Sep 2002 14:10:46 -0700

Mark and Costa,

Sincerely,
Prasenjit

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 10 Sep 2002 17:03:33 -0700

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

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?

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

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

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
[email-masked]

----- Original Message -----
From: "Mark Bakke" <[email-masked]>
To: "Prasenjit Sarkar" <[email-masked]>
Cc: "Constantine Sapuntzakis" <[email-masked]>; "Jim Hafner" <[email-masked]>; "David Black"
<[email-masked]>; "Duncan Missimer" <[email-masked]>; "Elizabeth Rodriguez"
<[email-masked]>; "IPS" <[email-masked]>; "John Hufferd" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 10, 2002 2:39 PM
Subject: Re: iSCSI Boot Last Call - Technical Comments

---

From: Constantine Sapuntzakis <[email-masked]>
Date: Tue, 10 Sep 2002 11:17:39 -0700

-Costa

---

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Sep 2002 17:29:50 -0500

Mallikarjun-

My comments are embedded.

--
Mark

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

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

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

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: "Prasenjit Sarkar" <[email-masked]>
Date: Wed, 11 Sep 2002 16:18:02 -0700

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" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>
Cc: "Prasenjit Sarkar" <[email-masked]>; "Constantine Sapuntzakis"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, September 11, 2002 3:29 PM
Subject: Re: iSCSI Boot Last Call - Technical Comments

> > > > > >>generally hold true, but at the same time, I feel that we should
not
> > > > make
> > > > > >>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
> > > > > >>                      <[email-masked]        To:       Mark
Bakke
> > > > <[email-masked]>
> > > > > >>                      bm.com>                  cc:
Prasenjit
> > > > Sarkar <[email-masked]>, Duncan
> > > > > >>                      Sent by:                  Missimer
> > > > > >>                      [email-masked]
<[email-masked]>,
> > > > Elizabeth Rodriguez
> > > > > >>                      .edu
<[email-masked]>,
> > > > David Black <[email-masked]>,
> > > > > >>                                                John Hufferd/San
> > > > > >>                                               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
> > > > > >>nonzero) digits, you'll need to carefully specify where these
digits go
> > > > in
<[email-masked]>,
> > > > > >>>   number.  Digits above 9 may be either lower or upper case,
and all
> > > > 16
> > > > > >>In this case, I think that we should pick one to take
precedence,
> > > > instead

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 11 Sep 2002 16:00:41 -0700

Mark,

>I don't think most

Having a 32/48/64-bit LUN, I believe, doesn't mean that there are
more than 2^16 LUNs.  IIRC, the 64-bit LUN address space
can be sparsely populated, depending on how many levels of
addressing a target supports and which specific LUs are distributed
into which level.  So, I cannot agree with this statement.

>>so the boot
> What customer or user looks at iSCSI PDUs?

A boot client is not a customer, but a very thin code probably running
on the iSCSI NICs, and working off the DHCP responses.
--
Mallikarjun

Mallikarjun Chadalapaka

----- Original Message -----
From: "Mark Bakke" <[email-masked]>
To: "Mallikarjun C." <[email-masked]>
Cc: "Prasenjit Sarkar" <[email-masked]>; "Constantine Sapuntzakis" <[email-masked]>;
<[email-masked]>

---

From: Luben Tuikov <[email-masked]>
Date: Thu, 12 Sep 2002 16:05:41 -0400

> into which level.  So, I cannot agree with this statement.

Agreed completely with Mallikarjun on all 2 points.

A LUN _is_ 64 bit and so it should be used.

The argument regarding the error-prone user input and GUI problems
has NOTHING to do with the issue. Those are HCI (human computer
interaction) issues and should be raised as such elsewhere.

E.g. Let blank mean a default LUN (maybe 0, or in the future if T10 defines
a well-known to boot from LUN), else a 64 bit lun should be entered.
(IPv6 argument as well...)

-- 
Luben

P.S. I raised the exact same argument on Linux SCSI a month ago --
the move towards 64 bit LUN for the exact same points: sparce space,
LUN mapping, etc.