Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

[Alfred Hönes <[e-mail]>]

Folks,
I'd like to present additional considerations for the structuring
of netboot information, entirely independent from the DHCP-centric
discussion on the list so far.  These considerations turn out out
to result in support for the baseline of the currently proposed
structure with independent instances of netboot option(s).

When I reviewed one of the previous versions of the netboot draft,
I also appreciated the "repeated, independent options" design from
an operational point of view far outside DHCP protocol considerations.

It may be that the application scenarios I had in mind those days
actually is not relevant for typical PXE boot environments, but my
ideas were influenced by past experience with other architectures
and should still be applicable to various kinds of possible
deployment scenarios for DHCPv6 netboot support.

A typical diskless boot scenario might require the following
categories of boot files:
o  'binaries' in the narrow sense: executable code and static data,
   linked with libraries etc. -- say, one file for the main system
   and optionally secondary image files for slave processors (DSPs,
   line cards, crypto processors, or the like);
o  a memory-based file system with additional files and work space,
   most likely with client specific configuration/"personalization"
   data;
o  message file[s] for native language support - one or more
   languages depending on deployment and user group.

The first category is per system type, subject to uniform update
policies (over some DHCP client popolution), i.e. one file for many
clients, frequently updated to patch defects and security flaws.  :-)
The second category is single client-specific, and perhaps rather
static over time.
The third category is shared again, but for smaller populations
in a heterogenous environment (say, routers / CPE with language
support configured depending on the country where they are located),
and perhaps more long-lived than the first category (needs update
only for major software release levels).

I omit the discussion of possible related boot parameters, leaving
it as an exercise to the reader.   :-)


The administrator of a hypothetical site with shared bootfile
storage and a DHCP server for a large population of similar
diskless clients would have to follow very different maintenance
strategies for the above categories of bootfiles.
(I assume that a small number of file 'generations' is being stored
on the boot server(s) for all file instances in use, with unique
names / URLs allowing to identify used files after the fact.)

Having a single complex netboot option would necessitate
maintaining the complex configuration information for that option
and updating it independently for all clients affected by a single
change (switch-over for a particular file of group of files).

Having split netboot options would allow a checkboard like
configuration interface allowing the admin to specify the
clients (via various available criteria) that shall recieve
particular instances of the configured netboot options.
Should, for instance, a new binary image for some basic client
system (or, say, some crypto accessory) become available,
only a single netboot option would need to be modified,
leaving its allocation to the 'interested' client population
untouched.

Thus, overall the split-option design allows for lower-volume,
more manageable, and hence less error-prone DHCP server
configuration environments.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+