Thank you for your kind words.
Sprint's filtering policies have led directly to a more
survivable SprintLink and ICM, which is to the benefit of
Sprint's Internet customers.
The trade-off is the inability to reach people who have
just hooked up to other parts of the Internet for the first
time and who are using addresses that are in conflict with
what we feel our routers can support.
So far the two (yes, two) customer-originated complaints
involving reachability affected by our filtering have been
resolved by straightforward renumbering of the non-SprintLink
entity. There have, by comparison, been several hundred
rather angry messages from non-customers who hook up and find
that they can't use their freshly-acquired addresses to talk
to SprintLink/ICM, and who claim never to have been warned
that this was a virtual certainty.
Two troubles in several months are rather obviously
dwarfed by the thousands of customer-originated complaints
about routing problems after major exchange points or other
major routing transitions happen (we have observed major
peers having serious difficulties with their routing system
scaling recently), not to mention the most recent serious
connectivity problem which involved working very closely
with our vendor on getting new technology out the door
that will let us scale with increasing traffic and
hopefully better deal with the scaling of the increase of
globally-announced routing informaiton.
Customer feedback I have gotten about our CIDR and other
routing policies tends to be very positive. Indeed, a
number of our customers are active participants in CIDRD,
NANOG, EOF and other forums where these policies sometimes
are discussed at length, and none of them seem very shy
about putting forward their own points-of-view, all of which
is remembered and thought about frequently.
We are, after all, very keen as a corporation to develop
and maintain long-lasting relationships with our customers.
It is possible that a number of unhappy customers have
not made themselves heard, or that a number have simply
voted with their feet on this precise issue, however there
certainly has not been enough of the latter to justify any
sort of re-think on this particular policy.
Whenever I see "Sprint sucks" in newsgroups and
mailing-lists, it's almost always because of reliability
problems. One of our most serious backbone reliability
problems involves routing convergence times and long-term
stability, and this particular routing policy in combination
with BGP dampening and other tools and techniques we've
developed here, goes directly to the heart of those problems.
I am always interested in proposals that will help
provide a more robust and stable level of connectivity and
performance to our entire customer base, and if you have any
ideas that would make it reasonable to withdraw our
prefix-length filters and _improve_ our routing stability, I
would be very glad if you could detail them.