[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Perry E. Metzger" <perry@piermont.com>
CC: Randy Bush <randy@psg.com>, Matt Crawford <crawdad@fnal.gov>, ngtrans@sunroof.eng.sun.com, users@ipv6.org, dnsop@cafax.se
From: "Joseph T. Klein" <jtk@titania.net>
Date: Sat, 27 Jan 2001 13:22:43 -0500
Sender: owner-dnsop@cafax.se
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0
Subject: Re: (ngtrans) Re: IPv6 dns

For the purposes of public deployment of root IPv6 DNS services
the discussion here seem for the most part in consensus that it
can be achieved without A6. So how about moving forward without it?
IMHO it is more important to start providing the basic
infrastructure for deployment then to try and support the more
arcane elements. Is is most assuredly true that elements having
fundamental problems in scalebility should remain experimental
or be dropped.

Address allocations have been made; stable products are out and
seem to work; it is time to make it so consumers can use IPv6.

I would be interested in seeing some statistical analysis of the
A6 issues rather than less rigorous verbal parley. Do I need to
replicate conditions in my lab to understand the full impact of
each element of IPv6? Does anyone have a publish, reproducible
scientific analysis of the A6 performance issues?

Perry E. Metzger wrote:

> Randy Bush <randy@psg.com> writes:
> 
>>>> as fred succintly said, how often does renumbering occur?  how often do
>>>> lookups occur?  so, for which should we optimize?
>>> 
>>> I can imagine some mobile devices/subnets that are renumbered more
>>> often than their address is looked up.  But, if there's only one nice
>>> thing about A6, it's that you get to break up the bits wherever you
>>> want, including nowhere.
>> 
>> here at ripe, operators and implementors are not impressed with a6, dname,
>> ...
> 
> 
> I'm not impressed with A6 -- I'd like it to die.
> 
> It does not, in practice, solve the renumbering problem. It just
> causes new trouble in the DNS.
> 
> The issues in the renumbering problem are database management issues,
> not protocol issues. I've been saying this for about six years but I
> don't think I get many people to listen to me outside of folks who've
> seen things like how MIT Project Athena did machine management.
> 
> The sad thing is, it isn't just the IETF types who don't understand
> the lesson -- thousands of sysadmins labor late into the night
> needlessly because they don't understand how to use relational
> databases to make their lives simpler. Entire companies, like Tivoli,
> have been founded and operated on a misunderstanding of the systems
> management problem.
> 
> Anyway, no amount of protocol tinkering will help renumbering
> significantly, any more than any number of bamboo air traffic control
> towers will cause the planes to land for the cargo cults. The issue
> isn't protocol support. It is trivial to convey information via a
> dozen protocols -- we've got plenty to handle all of this. The issue
> is assuring consistency among hundreds of management databases used in
> the average network of machines, and that is *not* a protocol problem.
> 
> 
> Perry


-- 
Joseph T. Klein         jtk@titania.net        +1 414 915 7489

  "Omnium rerum principia parva sunt." - Marcus Tullius Cicero


Home | Date list | Subject list