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

[Jarrod Johnson <[e-mail]>]

On Sun, Oct 18, 2009 at 5:23 AM, Thomas Huth <[e-mail]> wrote:
> Jarrod Johnson <[e-mail]> 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.

Ok, the use of the argument list paired with the executable I think
covers it (the format of argument would be dictated by the executable
in question).

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

I realize that RFC 4173 would 'automatically' cover the scenario if a
root-path (or whatever you wanted to name it) exists.
"The Root Path option is not currently defined for DHCPv6;
   if the option is defined for DHCPv6 in the future, the use of the
   option as defined for iSCSI boot will apply."

One thing I like about the way RFC 4173 is generally implemented is
that OS state may be more opaque to the DHCP server than 'filename'
style booting.  I.e. if I have an iSCSI booting Linux image and
suddently in the client change from grub to elilo (or deploy windows
with ntldr completely client side), the DHCP server doesn't have to be
aware of any of it.  It also is nice in that I can format it the same
way for any system rather than picking a different string format
depending on OS dictated preference.

One thing I particularly like about some particular implementations is
that root-path is used to configure OS-agnostic firmware configuration
tables and 'filename' can still be used to start an OS image  that
would source that table without me having to explicitly manage
permutations of netboot to reference an iSCSI root device, netboot to
reference local block storage, local boot to local block storage, and
'local' boot to iSCSI storage.


>
>
> 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
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>