[address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")

Gert Doering;

>>According to my upper bound, it's already unnecessarily too large.

> So the *proof* mentioned above consists of "your personal feelings what 
> the upper limit on the routing table size should be"?

No. I gave the upper bound considering the current number of unit
of global policies ((UN approved) countries and (self qualified)
tier1 providers) and concluded 1000 is large enough.

> While I honour your feelings (I also think that the routing table 
> shouldn't grow out of bounds), this is no "proof" that it's not going
> to scale.

As you agree that there should be bounds, any policy not
incorporating the bounds does not scale. QED.

> Also it brings back the problem of "who is worthy enough to receive
> one of 8192 TLAs", which was abandoned some 5 years ago, because there
> is no entity that can make this decision.

But, we have entities to define address allocation rules.

So, it is merely an issue to have an agreeable rule.

For example, assign 3 TLAs to NICs operating ccTLDs. NICs of
countries are assigned one more for each population of 10 million.
Then, have 500 for initial auction with lease period of a year with
10 more supplied monthly for 5 years. There will be about 2,000
TLAs, yet.

> Of course.  But I tend to believe if people tell me "10k routes are no
> problem today".  Oliver is building routers, with fast memory, and 
> good routing table lookup algorithms.

Be careful. I'm not offending Oliver. But, it should be noted
that, in general, router vendors, especially large ones, want
to keep their product as expensive as possible.

And, now, though I may offend Oliver, router engineers do their
work in a way they have been doing.

So, it is possible to have a router with 10k routes today
and tomorrow. But, it will costs almost as much as today
even in tomorrow.

However, it is a lot less expensive if global routing can be
performed only by looking 13 bits of the address.

There is no associative memory necessary.

It's just a memory of 8K entry with no associativity.

I think it is still reasonable to have an associative memory
of, say, 1K entry, for local routing.

> Today, high end routers can handle 140k routes.

How much does it costs?

How much do low end routers with 1G ethernet interfaces costs?

>>If the size of global routing table is limited by a hard upper
>>bound, it simplifies the design of routers a lot (you can put
>>a backbone router (or many of them) with a global routing table
>>in a chip), reduces cost of routers a lot and increases speed
>>of routers a lot.

> This is not going to work.  *Inside* your AS, you will always have
> some more routes,

Sure. It does work. See above.

> and depending on the quality of your IGP aggregation,
> you might easily end up with more than 10k *internal* routes.

It's a poor operation, which costs.

> So no matter what upper bound you put on the external routes, you
> cannot assume that nobody will ever need more routing table entries.

Those requiring a lot IGP entries should pay the cost by
themselves.

> Out of interest: what number do you suggest for the hard upper bound?

8K for the global routing table, though I think, with reasons,
1K is large enough.

>>Note that, for scalable (thus, end to end) site multihoming properly
>>work, all the sites are required to circulate global routing table
>>within the sites.

> Actually, no.  Not even in IPv4 today (which is part of the problem,
> that you can inject your prefix from a Cisco 2500 router, while
> everyone else needs to buy $costly hardware to *carry* your prefix).

Yes and no. IPv4 today is hopeless, because of legacy randomized
allocation of class Cs, which is why multi6 is not multi4.

The charter of multi6 says:

   but IPv6 represents an opportunity for more scalable
   approaches. IPv6 differs from IPv4 in ways that may allow for
   different approaches to multihoming that are not immediately
   applicable to IPv4.


   relatively few IPv6
   address blocks have been given out (i.e., there are no issues with
   legacy allocations as in IPv4).

						Masataka Ohta