Verio Peering Question

Alex Bligh alex at alex.org.uk
Thu Sep 27 20:40:05 UTC 2001


> Randy (now at AT&T, I believe) and others claim this does not hurt
> performance
...
> Of course, networks much larger than Verio (e.g. UUNET) accept /32s from
> their customers, as well as send and accept as small as /24s from peers.
> No other network seems to have a problem with the extra announcements.
  ^^^^^^^^^^^^^^^^
> Verio cannot explain why these larger networks can accept small
> announcements and still run a network as well (or better) than Verio, but
> Verio insists networks should not accept small announcements.

Many other networks filter, some to the same extent. Few
post public policies. Few people are as vocal as Randy about
it, and he's moved on from Verio. Given he's still vocal
about it, and Verio still filter, either he's a very believable
crank, or he has a point, and has been trying to educate you
for free. You choose.

> One can make one's own judgement what this says about Verio's ability to
> run a network.

I'd be making the judgement once I'd looked at performance and
reliability stats. I'd also, as a customer, be keen to look at
pricing to the customer, and as an investor or customer interested
in long term survival of a supplire, at Capex expended to achieve
whatever service level was given. On what would you be basing
your judgement?

I don't think anyone has ever claimed (Randy included)
that filtering out long prefixes never hurts performance /to
those long prefixes/. Just that the usage of those long
prefixes is small, the effect is often small, and the NET
effect (i.e. on performance to all prefixes) is often improved,
AND the 'public good' effect, in terms of encouraging
CIDR and discouraging disaggregation has benefits for
the global routing table, for everybody, in terms of
reduction of cost (nice statistical demonstration at
last IETF Ptomaine session - please refer to 'belling
the cat' problem).

Are you going to present statistical data to the contrary?

--
Alex Bligh
Personal Capacity




More information about the NANOG mailing list