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

[Bud Millwood <[e-mail]>]

On Tuesday 06 October 2009, Damien Neil wrote:
> On Oct 6, 2009, at 12:18 PM, Thomas Narten wrote:
> > Would a resonable criteria be that multiple options are OK if you can
> > process them in whatever order you find them easily, without having to
> > go through the entire message and find other related options that must
> > be processed together?
>
> I think that ordering of options should not be significant, although
> I'm not convinced that non-significant ordering is sufficient reason
> to use multiple instances of an option.
>
> One of my concerns is the complexity of presenting option data to a
> user--to a server administrator specifying what to send to a client,
> or to a network configuration script executed by a client.

I prefer this:

OPTION_NETBOOT
  SUBOPT_BOOTFILE_URL
  SUBOPT_BOOTFILE_PARAMS
  SUBOPT_CLIENT_ARCH_TYPE
  SUBOPT_NII

I think Damien has a point about presentation. I also think it's easier to 
present a subencoded option to the user with multiple (possibly required) 
suboptions than to present top-level options (just because there are so many 
top-level options).

The way our GUI works, for example, you define a subencoded option, 
then "inside it" you can only define the suboptions declared for that parent. 
So the list of data you can put in the suboption is short and easy to 
comprehend.

The big issue with encoding, as I understand it, is that this one 
configuration setting has multiple kinds of data associated with it. So 
either we cram different kinds of data into one option (ie, "boot=mykernel 
acpi=off"), which is not pretty, or we encode the data separately and 
associate the encodings together. Subencoding will make an implicit 
association between the encodings, nicely tucked away inside a parent 
container specifically for net booting.

Then the issue is whether or not to support multiple OPTION_NETBOOT options.

Thomas, you said:

> In the past years, I've seen a couple of cluster installations with _a lot_
> of computers, ... so the scenario is really valid (though it's something
> that you might not use at home ;-) )

How does that work in practice today with DHCPv4? Are they configured to have 
multiple boot files somehow, or is this an attempt to solve a need that 
wasn't solved in DHCPv4?

- Bud


>
> With DHCPv4 single-instance options, you can say "the value of option
> <foo> is <bar>".  For example, in ISC dhcpd:
>
>    option domain-name-servers = 10.0.0.1, 10.0.0.2;
>
> When you introduce multiple-instance options, this becomes more
> complicated.  There are various means of presenting this to the user,
> but I don't find any of them truly satisfactory.
>
> I note that ISC dhcpd doesn't appear to support defining multiple
> instances of an option at this time.  The dhcp-options(5) manpage
> states, "normally [multiply-instanced options] are options which are
> digested by the DHCP protocol software, and not by users or
> applications."  (If I'm wrong about this, and such support does exist
> in ISC dhcpd, my apologies.)
>
> I'm not absolutely opposed to multiply-instanced options, but I do
> think there's more implementation complexity to them than may first
> meet the eye.  The existing multiple-instanced IA* options don't
> trigger that complexity as much, since they don't need to be directly
> exposed to users.
>
> I'd be very interested to hear what other implementors of generic
> servers or clients think; it's possible that my view is an outlier, in
> which case I withdraw the objection.
>
>                - Damien
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



-- 
Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: [phone]
fax: [phone]