[ppml] question on 2006-2 v6 internal microallocation

[Michael.Dillon at btradianz.com]

> I see.  The Global Routing Table is not the list of all routes 
> on a given router, but some superset of routing tables among
> routers in a DFZ AS.

Not a superset of the routing tables. It is the set of
all routes announced into the DFZ regardless of whether
they end up in some table or not. The key thing is that
a route must be announced to exist. Acceptance of the
route is not relevant to its existence.

> Your definition says, "the routing table in a peering 
> router of any member of the default-free zone will consist 
> of the "Global Routing Table" "
> I took "member" to be "router," since I think of a routing
> table as a router's routing table.

The is a flaw in my statement. I actually said that
the router would contain the global routing table
plus additional local routes. Of course, the router is
likely to contain a subset of the global routing table
plus the local routes because the network operator is
unlikely to accept 100% of the routes announced in the
DFZ.

> Yes.  But in our current context, discussing whether there should
> be a rule or guideline that a prefix not be advertised in the DFZ, 
> if a prefix is advertised between two DFZ ASes, is it in the Global
> Routing Table?

There is where a measurement tool helps to clarify things.
For instance, I would say that a route announced between
two DFZ members by mutual agreement is not part of the 
global routing table but is an extension of their local
routing detail into some form of extranet. But then, does
this mean that a route must be announced to 100% of DFZ
members to be considered part of the global routing table?
Probably not because when MEASURING something like this,
100% will be difficult to achieve. In fact, MEASURING who
is and who is not a member of the DFZ will also be difficult.

However, if we have an accepted theoretical definition,
then we can use that to develop some practical rules of
thumb to use in policy (or building measurement tools).

> > P.S. many of the larger network operators will also operate
> > IP networks and IP internetworks that are not part of the 
> > public Internet. They may not be default free in those 
> > extra-networks but that is not relevant. The concept of 
> > Default-Free Zone only applies to the public Internet.
> 
> How do you tell the difference? 

I cannot think of any technical means to measure membership
in the DFZ that would not require network operators to divulge
whether or not they are truly default free. In other words,
we can't spy on the network and make this determination. We
need the network operators to cooperate in order to access the
traffic that would let us determine who is default-free.

So, this boils down to a situation in which we have to trust
that a network operator is telling the truth when they say
that they are default free. This list of default free networks
could be honed by removing any network that receives too many
complaints from other default free networks saying that the
network really is not default free. But this may not be necessary.

Since we can't measure the default-free zone or the global 
routing table exactly, we could still work with an approximation
and still make good policy. However, at this point in time
there is no accepted ARIN definition of default-free zone or
global routing table. So our policy is less of a match to the
real world than it could be.

ARIN has a tendency to accept slippery-slope arguments and
throw the baby out with the bath water. I believe that there
are reasonable ways to calculate benchmark values at regular
intervals for the size of the global routing table and to
apply those benchmarks in ARIN's policy-making.

For instance, a PI policy could have different criteria
for address allocations which will end up in the global
routing table and for those that will not. The criteria
for those that will could be based on the benchmark size
as calculated by ARIN, for instance that ARIN will not
issue more than x PI blocks per quarter to limit the rate
of growth of the GRT. This factor x could be recalculated
once a year according to some formula. Then, the PI policy
would require all PI applicants to either undertake NOT to
announce their prefix in such a way that it ends up in the
GRT or wait until the end of the quarter when lots are
drawn to see who gets their allocation.

This kind of thing will likely become more and more important
as we get closer to the exhaustion of the IPv4 address space
because we might need to apply similar restrictive growth
policies to all IPv4 allocations. We may as well start
experimenting with this now.

--Michael Dillon