Peering versus Transit

Matt Zimmerman mdz at netrail.net
Mon Sep 30 23:37:36 UTC 1996


On Mon, 30 Sep 1996, Bill Woodcock wrote:

>           Matt Zimmerman <mdz at netrail.net> writes:
>         > because you're using THEIR resources to do so, without
>         > explicit permission from them.
>     That's a repetition of the same position that's been stated over and
>     over, without justification.  If A sends to B directly in the absence
>     of an advertised route, A is "stealing" resources from B.  If B sends
>     to A indirectly through A's transit provider, then B is "stealing"
>     resources from A.  What makes the former case worse in your mind than
>     the latter, when it results in higher reliability, lower cost, and a
>     sounder architecture?

In the latter case, there are established agreements for exchange of
traffic.  In the former case, there are not.  B may not even KNOW that A
is doing this.  The distinction seems rather clear.

Besides this, there are engineering reasons why this is a bad idea, many
of which have been explained to you already.  Also note that dumping your
traffic to an NSP at an IXP may not BE a route of "higher reliability" or
"sounder architecture".  Randomly injecting your traffic into some point
on B's network does not guarantee, or even imply, optimal traffic
patterns.  I also fail to see how this is a lower-cost solution, as,
without a peering agreement with B, you must still purchase transit to
them from another source. 

>     Reiterating the same position over and over without any basis or logical
>     foundation does nothing to convince anyone that your position is of
>     any merit.

I've seen several messages with excellent engineering, economic and
philosopical arguments against this practice.

--
// Matt Zimmerman       Chief of System Management           NetRail, Inc.
// mdz at netrail.net                                       sales at netrail.net
// (703) 524-4800 [voice]    (703) 516-0500 [data]    (703) 534-5033 [fax]






More information about the NANOG mailing list