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

["Woundy, Richard" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, October 22, 2009 3:21 PM
To: Woundy, Richard
Cc: [e-mail]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to
proceed?

"Woundy, Richard" <[e-mail]> writes:

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

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

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