Re: [dhcwg] Review of Service-Discovery-Type options in DHCP

Jitesh,

On 7/17/02 5:39 AM, "Jitesh N Verma" <jitesh@india.hp.com> wrote:
> Hi all,
> Around a year back, I had sent a mail to this mailing list citing
> that other working groups (like Stateless Autoconfiguration, DNS etc.)
> are trying to hijack DHCP working group's agenda. Now, I am seeing that fear
> becoming realty.

Lots of folks have hammers for all those things they think look like
nails... :-)

> I just want to raise one point against DNS implementing server location.
> DNS name resolution is hitting perfomance bottleneck due to large size of
> database. 

No it isn't.  Particular implementations are hitting bottlenecks for various
reasons, however I know of a couple of implementations that can do wire
speed on 100 Mbps without breaking a sweat.  There is empirical evidence the
DNS scales to hundreds of millions of zones or tens of millions of names in
a zone while responding to tens of thousands of queries per second. I am
skeptical that any service location use of DNS would add significantly to
the scaling requirements.

However, if you want to talk about scaling, how many DHCP servers out there
can do more than (say) 30,000 lease allocations or even renewals per second?

> My point is why to increase load to already overloaded DNS server
> with extra features (which are already available in DHCP)?

DNS, in particular the SRV record, was specifically designed to provide
information on where to find a particular service.  Since SRV contains both
a priority and a preference field, I believe it can provide more flexibility
to clients attempting to locate a service than DHCP can.

In any event, I personally believe having multiple tools in a toolbox is a
good thing.  I can imagine scenarios in which either DHCP or DNS or SLP are
better suited to the service location function than the others.  Where it
would be wrong to go would be to twist the protocol to meet a particular
requirement that one of the other protocols already meets.

Rgds,
-drc

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg