Policy Statement on Address Space Allocations
smd at cesium.clock.org
Fri Jan 26 17:09:04 UTC 1996
| Now can we try to make things work rather than point fingers!
Yes, indeed; that is the ultimate goal we share.
We just have some differences of philosophy -- you think
that RIPE really can persuade people into having only
1024 announements (preferably far fewer) in 195/8, and
I don't. That's all.
The compromise we could find would involve a practicable
method by which we don't have to put a prefix-length-floor
in place, but at the same time don't have to spend enormous
amounts of (unavailable) CPU time filtering based on what's
in the RIPE database.
Avoiding large amounts of (largely unavailable) staff time
at Sprint and RIPE to chase down offenders and try to figure
out how to stop them from ignoring their contribution to
melting routers is also something I'd like to avoid.
I don't love my solution either, but it does have the
advantages of being CPU inexpensive, does a reasonable job
of guaranteeing an absolute maximum number of prefixes in
195/8 (the sum of the /18s, /17s, /16s ... /7s and the /8
itself) even in the worst case, and provides what has
already proven in practice to be a tractable enforcement
I regret the renumberings which have happened as a result,
but unfortunately people are still being hooked up to the
network with freshly-allocated PI /23s and /21s, and only
after they actually try to use them does it click that they
really won't work.
Moreover, when these people try to find out why things
aren't working, (and sometimes after trying various so-far
unsuccessful means to have an exception made), they often
understand what's happening in core routers and from then on
have tended to do a good job of not introducing new prefixes
into the core.
I am aware of various disclaimers and warnings the
registries issue and I'm grateful for them, actually.
They've been helpful. Some folks at a couple of our
peers/competitors have also been good at protecting their
customers by telling them a great deal about CIDR and PI vs
The large failing of CIDRD and the CIDR effort is one of
being unable to communicate things to precisely these people
receiving new allocations, which in large part is due to the
inability to get any documents published.
So, as a consequence of some parties being religiously
opposed to issuing documents emanating from a part of the
IETF that describe what really is happening now -- in order
to save newcomers and folks who haven't followed CIDRD a
great deal of confusion and effort -- on the grounds that
any such publication would look like the IETF "endorsing"
some evil greedy bastards who are out to rape and screw
small providers, people in small countries, small animals,
or whatever the cause celebre of this type of zealot happens
to be today.
The people being screwed are those who have no information
about how busy routers are and how untenable lots of
addresses of any nature are, and how important aggregation
is, and therefore how good PA addresses are to them *until*
they run right smack into my filters.
The campaign of "keep them ignorant to force providers to
abandon this silly notion that currently available routers
are too busy to deal with as many unaggregated addresses as
people want to present to them" only succeeds in *hurting*
small providers and startup providers.
And those small providers are who pay my salary, and you
better believe that my colleagues and I are very keen on
keeping them in business and seeing their customer base and
income grow substantially, so that they end up buying more
and bigger circuits -- both Internet connections and raw
private lines and international private lines -- and keep
being able to pay for them for a very very very long time.
More information about the NANOG