Re: automating the network: the big picture...

["James Kempf" <kempf@docomolabs-usa.com>]

> in the case where I have a DHCP server controlled by someone-not-me (some
> ISPs seem to want to run DHCP for their customers, for some reason), having
> a separate mechanism for configuring stuff the DHCP server's owner doesn't
> care about seems like a Good Idea.
>
> also, if my OS doesn't provide APIs to get at info the DHCP server chose to
> tell the OS at network-init time, having a non-DHCP mechanism to get at
> that config info seems like a Good Idea.
>
> both are examples of config entities probably not being fate-sharing, but I
> just wanted to make sure we don't lemming too fast over the "DHCP for
> everything" cliff.
>

I think this gets close to the primary tradeoff of stateless or stateful
configuration, and centralized or distributed service advertisement.

With stateful configuration and centralized service advertisement
(approximately, using a DHCP server) someone must configure the server. For
address configuration, this isn't really such a big problem because topology
changes rarely, nor for something like a DNS server where replication is simple.
Additionally, the policies for a particular ISP or network operator may require
more operator control over address provisioning than address autoconfiguration
gives. But for other services, it can be a problem. Users may want to bring up
their own services, a video camera for example, and requiring the DHCP server to
be updated for this is an inconvenience, as it pushes the configuration problem
back. Similarly, when a service goes down, the DHCP server will continue to
advertise it until somebody updates the server. This is a particular issue for
services like printers, that have a specific physical location which users care
about, or that are differentiated based on characteristics important to users,
like whether or not the printer does color. For these kinds of services, having
the service advertisement done by the actual service itself, with some
soft-state centralization options for scalability, seems a better design, so
that the advertisement of the service is fate-shared (verbizing again) with the
actual service itself.

Another issue along these lines is extensibility. A simple, low overhead way for
developers and users to define their own services facilitates development and
deployment. Requiring a standards track RFC for an extension is probably not the
easiest way to facilitate extension, IMHO.

            jak