On 14-apr-2006, at 11:35, Igor Gashinsky wrote:
:: But by taking this position ARIN has effectively declared that the size of :: the routing table isn't something that the IETF should worry about, so if :: operators run into trouble in this area they can either solve this with money:: or filtering.
No, what ARIN has declared is that *routing* isn't something *ARIN* istasked with fixing, and its job is to hand out IP addresses (since, multiple times before it specifically made "no claims as to "routability" of those addresses"). Therefore, it isn't something that *ARIN* should worry about.
Actually your statement and mine aren't in conflict. If ARIN believes that it has no role in making routing scalable (which isn't the case, see below) and/or takes actions that make routing non-scalable then apparently that's ok so the IETF doesn't have to care about this issue either. I'm sure the vendors that make up a large part of the IETF constituency don't have a problem with selling bigger and bigger boxes each year. Having RIR policies that make routing non-scalable and then have the IETF come up with mechanisms to make it scalable anyway is a waste of time. There are plenty of problems in routing that are also important that the IETF can work on and should work on, such as make it secure and improve convergence times.
http://www.arin.net/policy/nrpm.html --8<-- 6.3.4. AggregationWherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables.
This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.
IPv6 address policies should seek to avoid fragmentation of address ranges.
--8<--