Verio Peering Question

Thu Sep 27 20:26:50 UTC 2001

[I'll probably regret wading in, but....]

On Thu, Sep 27, 2001 at 07:29:01PM -0400, Patrick W. Gilmore wrote:
> I am afraid you have forgotten many, many other possible answers to those 
> two premises.  For instance, Randy could be an un-believable crank, and 
> Verio has just not gotten around to un-doing his previous policies?  Telcos 
> (especially Japanese telcos) move slowly.

Verio is an ISP, not a telco.

> Then again, perhaps every one of them is wrong, while Randy & Verio are 
> right?  (Of course, this begs the question why AT&T, where Randy works, and 
> XO, where you work, do not filter as Verio does?  Perhaps US telcos move 
> slowly too? :)

I find that in life, it is difficult to make monolithic stances based on
one principle or another, no matter how correct that stance is in
theory. There are always extenuating circumstances that makes one
modify ones response to things, and reasonable people change as
circumstances change around them.

If Verio ever changes its route filtering policy, that won't mean
that it stopped being the right thing[tm] to do. It will probably just mean 
that the overall cost of implementing the right thing[tm] may have become 
to high to maintain. Same would be true for some of the other networks that 
filtered and stopped.

You make an assumption that other major backbones that don't filter as
Verio does think that doing so is a bad idea. That assumption is 
not necessarily true.

I've heard many complaints of Sprint's prefix filtering policy, but never 
from another major backbone providers. If anything, many thanked Sprint
for the public service Sprint provided, and wished they do the same.

I've yet to hear another backbone operator complain about Verio's prefix
filtering policy either.

I think it's fairly well known fact that engineers do not soley run
companies. Even if something is the best thing to do from engineering
perspective does not mean that other factors, such as legal, sales and
marketing may not modify the outcome. I know this is North American
Network _Operators_ Group, but sometimes it's useful to think of 
the rest of the world.

The networks that filtered aggressively did so in the past because they 
thought it was the right thing to do, both for their network and customer 
base after taking every factors into consideration. There was also the 
consideration of public service that this was doing for the rest of 
Internet. As circumstances changed, the factors that went into 
decision processes shifted, and expression of those decisions changed
and some decided that it wasn't worth it anymore.

Aside from the theories of routing table entropy and high principles,
as well as realities of bleak future of global Internet routing on
its current vector, there is another facet of this complex problem
to consider that people should take into consideration.

Global routing system is a fragile thing. There are no good existing
ways of authenticating and authorising origin of prefixen.

This periodically causes suboptimality in Internet's control plane,
such as the 128/9 incident. Those networks that filtered as Verio does
were not affected internally that incident. Those who didn't suffered.

There are no ideal solutions for those types of problems. All of the
solutions have major flaws, and prefix filtering based on RIR a
allocation boundaries protect a network from a subset of them.

Until we have mechanisms to protect our networks better, there will
always be issues with any solution(s) chosen.

Before anyone asks, IRR based filtering of peers has been tried. Given
existing software implementations, this does not scale, even if you
ignore the garbage in garbage out issue of the problematic information
source.

> P.S.  You never did address why Verio preaches one thing and practices 
> another.  Neither has Randy to my knowledge (other than to say "if you are 
> dumb enough to take them" or something like that).  Is hypocrisy an 
> official policy at Verio?

It would be nice if people knew history better. It saves people from having
to repeat old explanations from old days over and over again.

Please see smd's rationale for acl 112 on nanog and other fora archives
circa 1996.

-dorian