RE: More on iSCSI boot

["Douglas Otis" <dotis@sanlight.net>]

Glen,

You are making several assumptions as to what exists on each machine by
assuming a new boot protocol may be available in PROM.  You are also
assuming which arguments this new protocol will need as it becomes developed
and that this protocol can depend on overlaid DHCP settings.  Can DHCP
securely support both an iSCSI and TFTP boot process?  Here you will run
into not only the problem of initially setting shared secrets but also
updating this new boot protocol as it matures.  The angst the shared secret
causes should pale in comparison to maintaining a complex version 1 boot
protocol.  Two ways to do the same thing should suggest this optional iSCSI
approach is not a good one.  If just one is to be used, it can not be an
initial iSCSI boot.  In that case, there is no need to muck with DHCP or
change how the initial boot image is obtained.  Start your scenario at step
two.  Once at step two, I would highly recommend something be used that is
more robust that SLP or DHCP for management.

Doug

> Black_David@emc.com wrote:
> >
> > David Robinson's messages support my inclination to reuse
> > DHCP option 17 (Root Path) by defining iSCSI syntax
> > 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
>  glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
> --
>  The revolution will not be televised, it will be digitised
>