[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


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

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