Peering versus Transit

Craig A. Huegen c-huegen at quad.quadrunner.com
Tue Oct 1 03:55:02 UTC 1996


On Mon, 30 Sep 1996, Sanjay Dani wrote:

==>That does not make your one sided arguments stand any more than
==>they did. Goes to prove experience does not necessarily equate
==>insight into all aspects of the business. You have a stake in
==>perpetuating the status quo. Me in changing it because it
==>doesn't make sense.

Unfortunately, you can't change it unless you understand how the
OPERATIONAL aspects work.  Vadim, Avi, Sean, Curtis, et al. have been
running networks for _years_ and understand what something means as an
impact.  These are people who can fine-tune a little bit, and make a world
of difference with performance.  Obviously a lot of the ideas in the mail
flood today were not thought up by people who run networks; just people
who want free connectivity everywhere.  A few years ago it could be
understood that the "network engineer" you were talking to on the phone
was TRULY a network "engineer"--he/she understood impact and operational
aspects of everything; and also had half a clue when it came to working
with equipment.  After all, most network engineers didn't have the
mentality that "the net" was this utopia, where everyone could do whatever
they wanted to, like some think of it today.

BGP was designed to give network operators control over how traffic goes
out of _AND_ into their networks.  Which also means that if I want your
traffic to come in over what I have designed as the best route
into/through my network, so be it.  It also means if I don't want your
traffic, so be it.  I don't have to take it.

==>> So why you just don't learn why the present system is here,
==>> and why it delivers while others only promise.
==>
==>No, it is beginning to suck. Have you checked reliability
==>of the backbones lately? Sigh.. old hats like you have a

Unfortunately, people who think non-operationally tend to have their heads
in the clouds.  People who think both operationally and developmentally
are hard to find, but are the best at realizing better methods that are
scalable.

"Old hats" might have a problem accepting some change, but they are a bit
wiser.  Most "old hats" at least know what an RFC is.  Or can at least
pass up marketing hype and find real-world results as a basis for judging
performance within a network (and I'm not just referring to hardware).

The problem is that "new hats" tend to re-invent the wheel way too many
times.

/cah








More information about the NANOG mailing list