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

From: Alfred Hönes <[email-masked]>
Date: Wed, 7 Oct 2009 00:34:16 +0200 (MESZ)

Folks,
I'd like to present additional considerations for the structuring
of netboot information, entirely independent from the DHCP-centric
discussion on the list so far.  These considerations turn out out
to result in support for the baseline of the currently proposed
structure with independent instances of netboot option(s).

When I reviewed one of the previous versions of the netboot draft,
I also appreciated the "repeated, independent options" design from
an operational point of view far outside DHCP protocol considerations.

It may be that the application scenarios I had in mind those days
actually is not relevant for typical PXE boot environments, but my
ideas were influenced by past experience with other architectures
and should still be applicable to various kinds of possible
deployment scenarios for DHCPv6 netboot support.

A typical diskless boot scenario might require the following
categories of boot files:
o  'binaries' in the narrow sense: executable code and static data,
   linked with libraries etc. -- say, one file for the main system
   and optionally secondary image files for slave processors (DSPs,
   line cards, crypto processors, or the like);
o  a memory-based file system with additional files and work space,
   most likely with client specific configuration/"personalization"
   data;
o  message file[s] for native language support - one or more
   languages depending on deployment and user group.

The first category is per system type, subject to uniform update
policies (over some DHCP client popolution), i.e. one file for many
clients, frequently updated to patch defects and security flaws.  :-)
The second category is single client-specific, and perhaps rather
static over time.
The third category is shared again, but for smaller populations
in a heterogenous environment (say, routers / CPE with language
support configured depending on the country where they are located),
and perhaps more long-lived than the first category (needs update
only for major software release levels).

I omit the discussion of possible related boot parameters, leaving
it as an exercise to the reader.   :-)

The administrator of a hypothetical site with shared bootfile
storage and a DHCP server for a large population of similar
diskless clients would have to follow very different maintenance
strategies for the above categories of bootfiles.
(I assume that a small number of file 'generations' is being stored
on the boot server(s) for all file instances in use, with unique
names / URLs allowing to identify used files after the fact.)

Having a single complex netboot option would necessitate
maintaining the complex configuration information for that option
and updating it independently for all clients affected by a single
change (switch-over for a particular file of group of files).

Having split netboot options would allow a checkboard like
configuration interface allowing the admin to specify the
clients (via various available criteria) that shall recieve
particular instances of the configured netboot options.
Should, for instance, a new binary image for some basic client
system (or, say, some crypto accessory) become available,
only a single netboot option would need to be modified,
leaving its allocation to the 'interested' client population
untouched.

Thus, overall the split-option design allows for lower-volume,
more manageable, and hence less error-prone DHCP server
configuration environments.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Oct 2009 17:57:11 -0700

On Oct 6, 2009, at 3:34 PM, [email-masked] 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.

---

From: Thomas Huth <[email-masked]>
Date: Sat, 10 Oct 2009 17:11:19 +0200

> different bootfile parameters were options to try, not files to be

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.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Oct 2009 10:32:55 -0700

Wow, a lot to think about.   I guess we should have had this  
discussion a year ago - I'm sorry for not doing more to make it happen  
earlier.

I like the idea of getting rid of the priority entirely, and that  
makes sense if the bootfiles are all the same.   And since there's no  
way to differentiate between them, it makes sense that they are the  
same.   However, mentioning PXE and yaboot does point out a problem  
with this approach: it failed last time.   We wound up with yaboot  
options that were allocated without a draft or contact with the IANA,  
and PXE was a bit of a mess too.

So let me ask you this: suppose we took out the priority option, and  
only allowed a single boot parameters option.   Would that draft be  
something that people here would actually use as it was?   Or would  
they find themselves adding extensions?

---

From: Jarrod Johnson <[email-masked]>
Date: Sat, 10 Oct 2009 16:18:17 -0400

I know that gPXE and pxelinux also support distinct sets of extended
options (sometimes mixing and matching using a 'plain' option and
using an option encapsulating other options).  Even with that all in
place, they almost all additionally reference a configuration file
(which they usually do via excessive requests based on their identity,
though I usually drive a more specific behavior through a dhcp
option).  For second-stage loaders with rich scripting behaviors,
cramming that into a DHCP option would probably not be nice for many
administrators.

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)

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.

On Sat, Oct 10, 2009 at 1:32 PM, Ted Lemon <[email-masked]> wrote:
> Wow, a lot to think about.   I guess we should have had this discussion a
> year ago - I'm sorry for not doing more to make it happen earlier.
>
> I like the idea of getting rid of the priority entirely, and that makes
> sense if the bootfiles are all the same.   And since there's no way to
> differentiate between them, it makes sense that they are the same.
> However, mentioning PXE and yaboot does point out a problem with this
> approach: it failed last time.   We wound up with yaboot options that were
> allocated without a draft or contact with the IANA, and PXE was a bit of a
> mess too.
>
> So let me ask you this: suppose we took out the priority option, and only
> allowed a single boot parameters option.   Would that draft be something
> that people here would actually use as it was?   Or would they find
> themselves adding extensions?
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Jarrod Johnson <[email-masked]>
Date: Sat, 10 Oct 2009 16:19:28 -0400

---

From: Thomas Huth <[email-masked]>
Date: Sun, 18 Oct 2009 10:46:06 +0200

> Ted Lemon <[email-masked]> wrote on 10/10/2009 19:32:55:
>

Sorry, I didn't quite get this... I am not aware of yaboot using any
non-standard DHCP options.
Or did you maybe mean pxelinux options instead? pxelinux is also a
secondary stage boot loader, but for x86 instead of PowerPC machines.
pxelinux seems to highjack some DHCP options (see RFC 5071).

Looking at those options, it seems to me that these are all configuration
options for the bootloader... that highlights one of the main problems with
DHCPv4 network booting again: There was no official way to pass parameters
to the bootloader or OS kernel that was loaded by the firmware.
So I think that such an option highjacking won't happen with DHCPv6 again:
Since we've got a "parameter option" in our draft already which can be used
to pass such configuration data to the bootloader/kernel, there is no more
need that they abuse extra DHCP options for this.

---

From: Thomas Huth <[email-masked]>
Date: Sun, 18 Oct 2009 11:23:10 +0200

Jarrod Johnson <[email-masked]> wrote on 10/10/2009
> 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.

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

---

From: Jarrod Johnson <[email-masked]>
Date: Sun, 18 Oct 2009 13:31:53 -0400

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

> configure that kernel with our "parameter option" to use the iSCSI target

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.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Oct 2009 14:55:00 -0700

On Oct 18, 2009, at 1:46 AM, Thomas Huth wrote:
> I think that such an option highjacking won't happen with DHCPv6  
> again:

Okay.   The draft doesn't really say that.   I think it would be worth  
saying that specifically, so that people realize that that is one  
valid use for these options.   Otherwise we may find that people think  
these serve some other purpose--it certainly didn't occur to me that  
this was what bootfile parameters were for, although now that you  
mention it I see no reason why they wouldn't work for this.

So, assuming you make that clear in the draft, would you consider a  
draft that had just one bootfile-url option, and just one bootfile- 
parameters option to be useful?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Oct 2009 14:57:45 -0700

BTW, one way to do redundant tftp servers that I think makes a lot of  
sense is to have the redundancy in the domain name, because DNS  
already specifies a load balancing mechanism for names that return  
multiple A or AAAA records.   This would eliminate the problem you  
were trying to solve with multiple bootfile-url options.

---

From: [email-masked]
Date: Mon, 19 Oct 2009 08:29:49 +0100

Ted Lemon wrote:
> sense is to have the redundancy in the domain name, because DNS already 
> specifies a load balancing mechanism for names that return multiple A or 
> AAAA records.   

	Don't you mean load scattering (rather than balancing),
	or am I missing something?

	Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Oct 2009 01:03:34 -0700

> 	or am I missing something?

Try looking up the A record on a name with three different A records,  
three different times, and notice how the ordering changes.

---

From: Chuck Anderson <[email-masked]>
Date: Mon, 19 Oct 2009 07:50:41 -0400

> three different times, and notice how the ordering changes.

The ordering rotation isn't guaranteed.  If there is some standard out 
there that specifies this behavior, I'd love to know what it is.  
There was some recent controversy over this idea of relying on the 
ordering of DNS answers for load balancing (or scattering) purposes in 
the context of RFC3484 and Linux's glibc:

http://people.redhat.com/drepper/linux-rfc3484.html

getaddrinfo() doesn't maintain the DNS server's ordering of answers, 
because it needs to sort the results for sane behavior in the face of 
dual-stack servers and source-address selection.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Oct 2009 08:50:40 -0700

> dual-stack servers and source-address selection.

That's just a godawful solution.   The way Apple does it is better -  
they try every address in parallel and keep the one that answers  
first.   Because the fact is that the host has no way of making the  
judgment the Linux guys are attempting to have it make here - there is  
simply no way to know which address is preferable without trying.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Tue, 20 Oct 2009 09:23:02 +0900

On 10/20/2009 12:50 AM, Ted Lemon wrote:
> That's just a godawful solution. The way Apple does it is better - they
> try every address in parallel and keep the one that answers first.
> Because the fact is that the host has no way of making the judgment the
> Linux guys are attempting to have it make here - there is simply no way
> to know which address is preferable without trying.

It truly is.  It almost killed the load balancing on www.kernel.org 
after that was deployed.  Fortunately that stuff got pulled quickly.

	-hpa

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Oct 2009 17:59:03 -0700

> after that was deployed.  Fortunately that stuff got pulled quickly.

Nothing like an object lesson... :')

---

From: [email-masked]
Date: Tue, 20 Oct 2009 10:11:55 +0200

> three different times, and notice how the ordering changes.

	I know. Unless the nameserver has custom policy tuning, I'll
	probably get three different permutations of the records.

	It's quite a leap from there to what you claimed.

Ted Lemon wrote:
 > [...] DNS already
 > specifies a load balancing mechanism for names that return multiple
 > A or AAAA records.

	The online version of the (4th edition of the) "Cricket book"
	points out, "Note that this is really load distribution, not
	load balancing [...]".

	I'm not aware of any DNS-related RFC which "specifies a
	load-balancing mechanism".

	Best regards

	Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Oct 2009 11:26:35 -0700

> 	It's quite a leap from there to what you claimed.

I claimed that this permutation process acts to balance the load.    
Which it does.   I guess if you want something cleverer than that, you  
could implement a protocol that balances the load through some sort of  
query-based handoff system, but that's completely out of the realm of  
what we've been talking about.

---

From: Thomas Huth <[email-masked]>
Date: Thu, 22 Oct 2009 09:19:03 +0200

> mention it I see no reason why they wouldn't work for this.

OK, but how would you call such parameters instead? For normal programs, I
would call them "command line options", but there is no command line at the
firmware level...

> parameters option to be useful?

We talked to a couple of people in the past days, and I think now yes, such
a one-option approach would be useful for most scenarios (and the others
can be solved by other means, like second stage bootloaders etc., just like
in the IPv4 world).
So since the multi-option idea rather caused confusion and/or dislike
instead of ardour, we're going to remove that and submit a new version of
our draft with just one bootfile- and parameter-option.

---

From: Thomas Huth <[email-masked]>
Date: Thu, 22 Oct 2009 09:24:49 +0200

Ted Lemon <[email-masked]> wrote on 18/10/2009 23:57:45:

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

Ok, we didn't consider that while writing the draft. And I guess when doing
an http boot, the situation is similar to a "normal" load balancing for a
web server, so administrators should already know how to deal with that.
--> We'll remove the multi-option approach from our draft.

---

From: Thomas Huth <[email-masked]>
Date: Thu, 22 Oct 2009 09:33:28 +0200

>    load-balancing mechanism".

There is maybe no standard for this available, but according to
http://en.wikipedia.org/wiki/Round_robin_DNS :

"Methods exist to overcome such limitations. For example, modified DNS
servers (such as lbnamed) can routinely poll mirrored servers for
availability and load factor. If a server does not reply as required, the
server can be temporarily removed from the DNS pool, until it reports that
it is once again operating within specifications. "

That sounds like real load-balancing to me.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Oct 2009 14:14:29 -0400

I am opposed to relying on DNS round robin as the
default/best/recommended approach to do load balancing when booting.

Round Robin DNS load balancing is not officially supported in the IETF
because the only way you can get it to work properly is to disable DNS
caching (i.e, use TTLs of 0) so that a query always goes back to a
server than can explicitely modify the ordering. But disabling caching
has negative implications for DNS performance, reliability, etc. You
then also have to have specially modified servers (that reorder
results based on various criteria) that are again not officially
blessed by the IETF.

The IETF DNS WGs have discussed this many many times, and have so far
not been willing to bless such load balancing. I do know that it is
used in some environments and can be a useful tool at times.

If it is a requirement that remote booting include support for load
balancing, I think we need to first make note of that and develop a
proper solution. There are number that could work that are fairly
simple (e.g., consider the DNS SRV "weight" mechanism).

That said, it is not clear to me that load balancing is actually a
requirement that needs solving. At least not for preboot loading.

Comments?

Thomas

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 22 Oct 2009 14:49:34 -0400

What about use of anycast addresses for severs?

Thomas Narten wrote:

blessed by the IETF.

Comments?

Thomas

dhcwg mailing list

[email-masked]

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 22 Oct 2009 15:10:52 -0400

I don't have any personal interest in this netboot approach, but I can
understand why load balancing could be interesting to the netbook folks.
After a power outage, I can imagine a lot of devices simultaneously
rebooting, and therefore there may be a much higher load of netboot
traffic. At the same time, one might not want to purchase lots of
netboot servers for a once-a-year power outage event.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Narten
Sent: Thursday, October 22, 2009 2:14 PM
To: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to
proceed?

Comments?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Oct 2009 15:21:19 -0400

> netboot servers for a once-a-year power outage event.

What I'd like to be very clear about is distinguishing between a
feature we think *might* be useful, in a theoretical sense, as opposed
to a feature that those doing netboot believe is necessary feature
based on the experience we have with netboot today.

In this case, I've spoken with one internal person who is familiar
with how netboot is used in a certain class of products today, and he
asserted that load balancing, at least for the "first stage" boot, was
not a requirement. Even in the power failure scenario, the load placed
on the first stage boot server can be handled without load
balancing. (Later stages in the boot sequence may be different, but
for that a different approach would be needed anyway.)

He did say that failover, the ability to use a fallback server in case
the first server didn't respond could be useful. But this was not for
loadbalancing reasons. It was more for dealing with configuration
errors, where a machine has been running for months reboots, but the
boot server it tries to boot from is no longer available due to a
configuration change. Yes, this is an administrative error (the DHC
server should have been updated to provide corrected information), but
for some reason it was not caught at the time the change was made.

Thomas

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 22 Oct 2009 15:33:23 -0400

Sigh. I guess I wasn't clear in that I hoped to provoke some netbook
experts to speak up.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 3:21 PM
To: Woundy, Richard
Cc: [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to
proceed?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Oct 2009 15:41:28 -0400

> Sigh. I guess I wasn't clear in that I hoped to provoke some netbook

Well, I wasn't all that clear in my first note either! I'm really
hoping for the same. I'd be happy to support load balancing, but only
if was a real requirement coming from the folk who are using netboot
and have experience with it. Otherwise, I'd prefer that we keep things
simple.

Thomas

---

From: Thomas Huth <[email-masked]>
Date: Fri, 23 Oct 2009 10:45:28 +0200

> results based on various criteria) that are again not officially

I don't think that DNS caching is an issue when we're talking about
netbooting. The firmware normally lives for just some few seconds, so it
will not use the IP address of the server for a very long time.

Another possibility to do some kind of load balancing might be to use HTTP
as download protocol and then to use the HTTP-Redirect mechanism to point
the client to another server. Or maybe to use anycast, as Jarrod suggested?
Anyway, there seem to be a couple of other possibilities to do load
balancing (and I guess also failover handling), so we do not urgently need
this at the DHCP level already. So we will definitely remove the
multi-option approach from our draft and submit a new version soon.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Oct 2009 09:08:56 -0700

On Oct 22, 2009, at 12:41 PM, Thomas Narten wrote:

simple.

I may be speaking out of turn here, but I think that the fact that this draft explicitly recommends http over tftp for downloading the boot file will solve a lot of the load problems that exist with the current DHCP/tftp boot mechanism in DHCPv4.   As I understand it, the primary problem with netbooting in IPv4 is that tftp is such a low-performance solution (due to the lock-step nature of the protocol), not that tftp boot servers get overloaded during power events.