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

[Bud Millwood <budm at weird-solutions.com>]

On Saturday 10 October 2009, Thomas Huth wrote:
> Bud Millwood <budm at weird-solutions.com> wrote on 07/10/2009 21:39:12:
> > I think Damien has a point about presentation. I also think it's easier
>
> to
>
> > present a subencoded option to the user with multiple (possibly required)
> >
> > suboptions than to present top-level options (just because there are so
>
> many
>
> > top-level options).
> >
> > The way our GUI works, for example, you define a subencoded option,
> > then "inside it" you can only define the suboptions declared for that
>
> parent.
>
> > So the list of data you can put in the suboption is short and easy to
> > comprehend.
>
> Ok, these "sub-options" might work fine with a GUI, but I think the plain
> text configuration files of the DHCP server gets more complicated with
> sub-options. The settings then have to specified in a nested way like:
>
> option netboot = {
>    url = http://...
>    params = "acpi = off ..."
>    ...
> }

I think that text format is... beautiful. :)

>
> > Thomas, you said:
> > > In the past years, I've seen a couple of cluster installations with _a
>
> lot_
>
> > > of computers, ... so the scenario is really valid (though it's
>
> something
>
> > > that you might not use at home ;-) )
> >
> > How does that work in practice today with DHCPv4? Are they configured to
>
> have
>
> > multiple boot files somehow, or is this an attempt to solve a need that
> > wasn't solved in DHCPv4?
>
> With DHCPv4, the only way to work-around overloaded TFTP servers was:
> 1) Introduce a random delay in the boot process of the nodes, so that they
> don't try to contact the TFTP server at the same time.
> 2) Add new TFTP servers and then hard-code a given set of nodes to always
> boot from these servers.

By overloaded TFTP server you mean a server with too much traffic, right?

This may be an implementation thing. Another way to distribute booting nodes 
across multiple TFTP servers is to vary the "Next server" or "Overload TFTP 
server name" by time, mac hash, ip hash, shoe size, etc. A DHCP server should 
be able to let you vary the TFTP server location (name or address) in 
realtime. Even better, the server should maintain a list of TFTP servers and 
only rotate between those that are online and under a certain work 
threshhold.

- Bud

> There was no way to specify redundant boot servers in the DHCPv4 protocol,
> so this would be a new feature in DHCPv6 which makes the configuration of
> large networks much easier (you don't have to assign a given set of MAC
> addresses to only one of the available server which still might to fail.
> You could simply say, that all nodes should try to boot from either
> server1, or if it fails try server2, then server3, etc.).
>
> Mit freundlichen Grüßen / Kind regards,
>    Thomas Huth
>
>     IBM Deutschland                 Vorsitzender des Aufsichtsrats:
>     Research & Development GmbH     Martin Jetter
>     Schönaicher Str. 220            Geschäftsführung: Erich Baier
>     71032 Böblingen                 Sitz der Gesellschaft: Böblingen
>     Tel.: +49-7031-16-2183          Registergericht: Amtsgericht
>                                     Stuttgart, HRB 243294



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687