Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to proceed?

[Thomas Huth <[e-mail]>]

Ted Lemon <[e-mail]> wrote on 07/10/2009 02:57:11:

> On Oct 6, 2009, at 3:34 PM, [e-mail] wrote:
> >
>
> Thanks, that helps to make sense of it.   What do you think about the
> idea of just grouping the URI in with the boot parameters?   Also, you
> said that the client might need more than one bootfile, but the
> current draft doesn't provide any way to differentiate, unless it's in
> the bootfile parameters.  Consequently, I understood that the various
> different bootfile parameters were options to try, not files to be
> loaded in sequence.

Right. So maybe we should discuss first what basic functionality shall be
provided by DHCP for network booting before we continue discussing how the
options should exactly look like.

I think there are two basic approaches:

1) The full-blown approach:
(basically what Alfred Hönes described)
DHCPv6 shall support all kind of boot scenarios. The options should provide
the possibility to load different kind of files into memory before starting
the kernel/bootloader, e.g. one or more binaries, a ram-disk, configuration
files, etc. ... maybe there would also be the need to specify the address
in the RAM of the client where the file should be loaded to (e.g. to
specify where to put the ram-disk to), or the need to closer specify the
type of binary images (e.g. if it's for a slave processor like a DSP) and
various kind of other parameters...
Beside the possibility to load multiple images, it would also be nice to
specify some kind of redundancy for every file that should be downloaded.
I.e. if one file server is busy or down, there should be a possibility to
specify an alternative download server for each file.

2) The keep-it-simple approach:
(basically what we did until now after we've been told to get rid of the
sub-option a year ago)
DHCPv6 shall just support downloading one executable for booting. That's
either directly the OS kernel, or it could be a secondary stage boot loader
which then can implement the more complex boot scenarios like loading
ram-disks etc.
Here it would still be nice to also implement some kind of download
redundancy for that single file in case the file server is busy or down
(that's why we allowed the bootfile-url option to occur multiple times).

**** How is it done in DHCPv4? ***

AFAIK DHCPv4 only offers the possibility to specify one single boot image.
For more complex scenarios, there are secondary stage boot loaders, like
"yaboot" on PowerPC machines, a program that can load ram-disks and
config-files before starting the OS kernel. That all basically means the
second, keep-it-simple approach.

Then there is also the PXE extension for DHCPv4, which extends DHCPv4 by a
lot of additional functionality. I think this is not completely what I
described with the "full-blown" approach above, but it resembles it at
least a little bit (lots of additional DHCP options for lots of additional
features).

**** Now where to go from here for DHCPv6? ***

If we decide to do approach 1), that basically means a complete rewrite of
our draft, with a lot of additional brain-storming about what's needed for
all possible scenarios, and to do a modular, extensible option layout like
the sub-options that we used in the first versions of our draft.
Honestly, at least I currently don't have the spare time to lead such a
discussion and rewrite of the draft. And after reading the PXE spec, which
is IMHO very complex and sometimes hard to understand (what can easily end
up in wrong implementations), I think it's not a good idea to introduce
such a complex interface into DHCPv6 - so I'd prefer to leave the complex
scenarios to the secondary stage bootloaders.

So if we decide to do approach 2) instead, that means we could state that
there is only the possibility to load one image via DHCPv6, and that the
multiple bootfile URL options are just there for redundancy reasons. Then
we could remove the "precedence" field from the bootfile parameter option
again, since all the images on the different servers should be the same and
thus also be provided with the same kernel parameters! The bootfile
parameter options then must only be given once (or not at all), the ugly
linking between the options is gone, and hopefully everybody is happy
again...

What do you think?

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.: [phone]          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294