Subject: More on iSCSI boot

From: [email-masked]
Date: Wed, 30 May 2001 22:49:57 -0400

Let's start with a simple boot from a disk - the system
BIOS reads the boot sector(s) off of the disk drive,
loads and runs it/them.  That primary bootloader then
handles whatever else is necessary based on the ability
to do disk reads (a secondary bootloader and/or other
things may be involved).  On Intel systems, it's generally
a combination of the system BIOS and card BIOS that
make the disk reads work.  Simplifying assumptions
are common (e.g., boot from LUN 0 on the first SCSI
target found).  The goal of the iSCSI boot draft is
to explain how to make this "simple boot from a disk"
mechanism work when the boot disk is attached via iSCSI.

An iSCSI adapter has some things to do in order to make
this work, e.g., it has to log into the target before disk
reads can be issued.  I tend to believe that "Don't do this
(i.e., try to boot over iSCSI)" is not an acceptable answer.

In the message that started this whole boot discussion, I
suggested that

	Using DHCP to find SLP to find the boot device seems
	both clumsy and an invitation to problems (one more
	thing that can break and prevent booting), 

I think that's doubly true if LDAP is used instead of SLP.
David Robinson's messages support my inclination to reuse
DHCP option 17 (Root Path) by defining iSCSI syntax
for it.  Between that, any TCP parameters that one wants to
set through DHCP, and iSCSI parameters that can be defaulted,
it should be possible to get the first disk reads done
through iSCSI.

As has been pointed out, booting is often poorly secured in
general.  While it'd be nice to change this, iSCSI will face
the same pressures that other boot mechanisms face - keep
it simple, get the boot image loaded, and let it do something
fancier.  Any signature/validation of the boot image will be
above the level of iSCSI.  Somehow, I don't expect to find
implementations of ESP in card BIOSes anytime soon.

If implementers want to use DHCP and TFTP to boot, I don't
see any point in stopping them, but I don't think either should
be mandated.  DHCP has centralized administration advantages,
and TFTP is a simple way to download code, but both are "one
more thing that can break and prevent booting" and hence may
not be used all the time.

Comments?
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 31 May 2001 14:04:21 -0400

Just one nit.

> On Intel systems, it's generally a combination of the system BIOS
> and card BIOS that make the disk reads work.

It this really true in practice?  Once upon a time, it seemed like
card-specific BIOS extension were becoming deprecated.  Probably all
BIOSes still support BIOS extensions, but I don't think current
adapters actually provide them.

My understanding is that if you want to boot off a disk controller,
you either have to have specific BIOS support for it, or you have to
emulate/implement INT13.  This appeared to be conscious choice of the
platform (BIOS) vendors to only support a bounded set of boot
alternatives (since boot should be a bounded process) on each
particular platform.

If this is the case, it doesn't make sense to provide for iSCSI boot
on a platform that is not conscious of that choice.  This implies that
the resources available for iSCSI boot are the complete resources of
the platform's BIOS environment.

This doesn't seem to substantively change the discussion, but it does
remove one particular scenario from consideration.

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 31 May 2001 14:04:21 -0400

Just one nit.

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Thu, 31 May 2001 14:04:21 -0400

Just one nit.

Steph

---

From: Glen Turner <[email-masked]>
Date: Fri, 01 Jun 2001 11:24:20 +0930

[email-masked] wrote:
> for it.

The "root path" is still useful if the image
has been loaded using iSCSI or TFTP.

An alternative would be to request an option for
"image load protocol" and redefine DHCP's "sname"
and "file" and options 66 "Server name" and option
67 "bootfile name" for interpretation with iSCSI.

Without an allocated option, it might be possible
to simply redefine the sname/66 and file/67 so
that sname/66 beginning with "iscsi:" defines
the iSCSI boot method.

GENERAL COMMENTS ON DRAFT-02

I'm not at all keen on the mechanism in draft-*-boot-02.
The DHCP option should be more generic, as in

  <bootprotocol>:<bootpath>

and defined for iSCSI as

  iscsi:<servername>[:<protocol>[:<port>[:<lun>[:<wwui>]]]]

This would limit future options growth.

Even better would be to define a DHCP option "boot protocol"
and reuse the sname/66 and file/67 fields.  In the absence
of the "boot protocol" option TFTP would be assumed.

Other issues with the draft:

 - if <servername> is a domain name then
     - the "name server" DHCP option SHOULD
       be provided
     - <servername> SHOULD be a FQDN unless
       the "domain name" option DHCP option
       is provided

 - <protocol> may be better to be textual, as
   this allows variants on TCP (such as framing).
   Default value is "tcp" with "tcp-*", "udp" and
   "sctp" intended for future use.  Syntax is:

      <protocol> ::= <lowerstring>
                 ::= <null>
      <lowerstring> ::= <plchar>
               ::= <string><plchar>
      <plchar> ::= <punctuation>
               ::= <lchar>
      <punctuation> ::= - | .
      <lchar> ::= a | b | ... | z

The syntax of all textual options should be defined using
IETF BNF rather than in the text.

 - The "LUN" field is a 16 byte hexadecimal
   representation of the 8-byte LU number in hex.

   does not allow for SCSI to redefine or expand
   the LUN.  Although this is unlikely, I'd suggest 
   text like:

   <LUN> is the SCSI logical unit number in hexadecimal.
   The syntax is:

      <LUN> ::= <hexoctet>
            ::= <LUN><hexoctet>
      <hexoctet> ::= <hexdigit><hexdigit0>
      <hexdigit0> ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f
      <hexdigit> ::= <hexdigit0> | <null>

   If you do want a fixed-length field, then using BNF
   can replace the somewhat unwieldy text

      <lunoption> ::= :<lun> | <null>
      <lun> ::= <hex1><hex1><hex1><hex1><hex1><hex1><hex1><hex1>
      <hex1> ::= <hexdigit><hexdigit>
      <hexdigit> ::= 0 | 1 | ... | 9 | A | B | ... | F | a | b | ... | f

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised