[ppml] question on 2006-2 v6 internal microallocation
Michael.Dillon at btradianz.com
Michael.Dillon at btradianz.com
Tue Aug 29 11:26:16 EDT 2006
- Previous message: [ppml] question on 2006-2 v6 internal microallocation
- Next message: [ppml] ARIN XVIII - Open Policy Hour
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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
- Previous message: [ppml] question on 2006-2 v6 internal microallocation
- Next message: [ppml] ARIN XVIII - Open Policy Hour
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list