[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Re: Delays inherent in TRRP's DNS-like lookup?
On Fri, Feb 22, 2008 at 9:56 AM, Robin Whittle <rw@firstpr.com.au> wrote:
> So for IPv4, you think the RIR's server would do this task of
> handling up to 2^16 subdomains. That sounds technically feasible,
> but would the RIR really want to do this?
Hi Robin,
That is how things are constructed for the in-addr.arpa domain. Most
allocations are longer than /16, so the corresponding delegations
happen as /24's. It works in practice, today.
The scaleups necessary for the roots and tlds would probably be
necessary for the /8 level of the TRRP hierarchy, but those are also
well tested.
> Another critique is that this RIR server is going to be very busy
> indeed. You could anycast these /8 level servers, but that would be
> costly and harder to administer, since they all have to know so much
> about the authoritative nameservers for up to 64k subdomains.
>
> Broadly speaking, if there are about 220 /8s in use in IPv4, then
> each such RIR server (really multiple servers) is going to get 1/220
> of the total global ITR initial requests for mapping information.
>
> Wouldn't it be more likely that the RIR gave a /12 of this /8 to
> some ISP, and would simply hand back an answer saying to ask the
> nameserver of that ISP? Then that server might delegate to another
> one, which is authoritative.
Not if it harms performance. At one point the first letter of .com
domains was reserved against the possibility that they'd need to do
that sort of delegation but the operators chose anycast instead.
> looking at your IPv6 example in the same light, the figures are more
> extreme.
>
> Your first asked server is authoritative for a whopping /12 of IPv6
> space. It gives an answer about what server to ask, solving another
> 36 bits of the ITR's problem: it tells the ITR the address of
> another server to ask, which is authoritative for a /48.
>
> Do you expect this /12 server to know about (a theoretical maximum)
> of 2^36 subdomains? That is an awful lot.
That is essentially how the ip6.arpa hierarchy for reverse-DNS is
organized today. No problems are experienced or forecast.
> Overall, I question how your collapsing of what would otherwise be a
> long series of lookups into two or three will be problematic in
> terms of:
>
> 1 - The business and therefore trust relationships probably
> go in steps of fewer bits than the large jumps in bits
> you use in the examples - raising questions of how the
> short-prefix nameservers get to be reliably configured with
> so much detailed information which is actually controlled
> by so many ISPs or end-users.
In a PI world, the administrative relationships -are- relatively flat:
IANA-RIR-Org-Individual and IANA-RIR-Individual
It's only in the PA world we're trying to eliminate that the
administrative relationships get deep:
IANA-RIR-LIR-LIR-LIR-Org-Individual
> 2 - How this collapsing thwarts the ITR's ability to cache
> a larger number of nameservers which will actually be
> used in subsequent requests - thereby requiring it to
> keep asking the /8 (IPv4) or /12 (IPv6) servers time
> and again. The same goes for the world's ITRs and so
> these servers get a hammering.
The worst case of this problem is precisely the dot-com zone problem
which is already solved and deployed at an operations level.
> The real question is whether
> the delays inherent in an ALT or TRRP based system are enough for at
> least some marketing folks to trump it up to the broader end-user
> population as being significant.
Of course they are. And if it's not the milliseconds it'll be the
bytes. You have to transmit more bytes with map-encap so it'll cost
you more.
The marketing game is to make sure that at least some people see the
advantage of selling the new capabilities. "With map-encap, we can
sell you PI for $20/month. That loser who says map-encap is crap won't
sell you PI for less than $2000. Two-kay. Twenty bucks. You tell me
who's full of crap."
Regards,
Bill Herrin
--
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg