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

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

Are people drawing a distinction between providing service location information
and providing service configuration information? It seems to me that providing
location information is really only possible from a third party, whereas
configuration information can be provided by the service itself once it is
found. DHCP provides configuration information to hosts as the IP address and
(for IPv4) subnet mask, and service location information through the DNS server,
printers, etc.

Regarding:


> >
> > I think there are some tradeoffs to take into account between e.g.
> > securing a single channel for configuration information (between the client
> > and the DHCP server) with the DHCP server being a single point of failure,
> > and securing N channels to N entities providing configuration information
> > co-located with the actual service (with fate sharing between the
> > configuration entity and the sevice itself).
> > I'm sure there are other tradeoffs as well.
>
> - Configuring vs reconfiguring: in the latter case given an adaquate
>   caching scheme (and an adaquate implementation, grr), one is probably
>   in a better position to keep going if the configuration system
>   (whether monolithic or distributed) is on the blink.
>
> - Single config protocol vs multiple config protocol: not the same
>   thing as Erik's single point of failure vs co-location tradeoff, one
>   could use a single protocol with the co-location model, so that
>   one's toaster would only have to implement one config protocol
>   (applies both to client toasters and server toasters).  Oh, right,
>   this is supposed to be a tradeoff, well, I suppose that having N
>   separate protocols to do the same thing is good for the economy :).
>

The multiple sources case is also of interest in smaller, minimally managed
networks. Though single source DHCP-based address assignment has worked for home
NAT boxes in IPv4, I don't think anybody has used the DHCP solution for broader
home network service discovery.

And I agree with Rob: having one protocol for this is better than N, if
possible. With any amount of luck, it is early enough in IPv6 that we can fix
this. The situation in IPv4 is fairly grim, since N is large and growing.

FWIW, Apple is pushing very hard on their new Rendezvous discovery protocol that
is based on mDNS. There was recently an article in Business Week about it, and
Infoworld had something on it last week. They are also proposing it as the next
generation for UpNP, an industry forum that Microsoft started which deals with
service discovery protocols. Problem is, Rendezvous queries tend to leak into
the global DNS, and have resulted in an increase in NXDOMAIN responses for the
Rendezvouz .LOCAL domain. Rendezvous is an example of a periodic phenomenon in
the IPv4 service discovery world, the last such case of a poorly engineered
solution was Microsoft's SDP, which MS is now in the process of deprecating.

            jak