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

[Thomas Huth <THUTH at de.ibm.com>]

Jarrod Johnson <jarrod.b.johnson+dhcwg at gmail.com> wrote on 10/10/2009
22:19:28:
>
> With all that said, it seems exceedingly common that at least two
> things are commonly referenced in a potentially common way in a
> typical netboot fashion:
> -The second stage loader executable code
> -Optionally, a configuration file or script for that second stage
> loader, that typically points to other requisite files that vary from
> OS to os (i.e. multiboot images, or a linux kernel/initrd, and various
> things in a Windows BCD file, though the Windows search for BCD file
> is less flexible today than I would like)

Ok, but since those second stage bootloaders could also be used in IPv6
scenarios, the question is now whether they are a bad thing that we should
get rid of? Would it make sense to implement all the functionality of those
second stage loaders into DHCPv6 directly? Is it possible at all, since
every operating system has slightly different requirements?

IMHO if we tried to implement all those functionality into DHCPv6 directly,
we would end up in a very, very complex implementation that still does not
support all boot scenarios since we've forgot to have a look at operating
systems that are not too common. So people would continue to use second
stage bootloaders anyway. Thus, I think we should follow the keep-it-simple
approach and only allow to load and boot one executable at the DHCPv6 level
and leave the more complex scenarios to the second stage bootloaders.

By the way, I've done some "research" this weekend, and to me it looks like
the main reason for using a secondary stage bootloader for DHCPv4 was often
only the fact that they provide an additional configuration file (see
http://syslinux.zytor.com/wiki/index.php/PXELINUX#How_do_I_Configure_PXELINUX.3F
 for example), which then is used to specify additional kernel parameters.
These kernel parameters could not be passed by DHCPv4 directly. But since
we've got a "parameter option" in our draft for DHCPv6 netbooting already,
the second stage bootloader would become unnecessary in that case. So for
most scenarios we would already get rid of the second stage loaders, we
would just need them for some more complex scenarios.

> As a potential slight tangent, this discussion has been focused on
> netboot scenarios focused on downloading an executable and running it,
> but what about registering network based SAN strategies (i.e. iSCSI
> per RFC 4173)?  One aspect I didn't like of that standard was to imply
> it was used for configuring a boot volume only with the expectation
> that it would be the boot device of that boot, as I have a scenario
> where the two actions on the client network device are separate (i.e.
> it will configure itself and connect to the iSCSI target, and
> configure firmware tables, but then still allow me to boot via
> 'filename' so that the PXE booted OS would be aware of the iSCSI
> target configuration).  I mention that in fear that it is suggested to
> simply re-use boot-uri, which would preclude the potential of
> DHCP-driven SAN configuration at the same time a netboot is desired.

Wouldn't it work to specify the kernel image with the boot-uri, and then to
configure that kernel with our "parameter option" to use the iSCSI target
as root device?


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