nanog mailing list archives
Re: Peering Policies and Route Servers
From: "Jeff Young" <young () mci net>
Date: Tue, 30 Apr 1996 11:08:54 -0400
one thing that's been overlooked in this conversation is the fact that routing in the internet between mci/sprint/etc... nsp's is asymmetric. we route shortest exit to sprint, they route shortest exit to us. in this way we share the cost of cross country transit. unless you're in three naps across the country (east, west, and middle) that's kind of hard to duplicate. Jeff Young young () mci net
Return-Path: nathan () netrail net Return-Path: nanog-owner () merit edu Received: from merit.edu (merit.edu [35.1.1.42]) by postoffice.Reston.mci.net (8.7.5/8.6.6) with ESMTP id AAA10529; Tue, 30 Apr 1996 00:14:19 -0400 (EDT) Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA07460 for nanog-outgoing; Tue, 30 Apr 1996 00:04:08 -0400 (EDT) Received: from netrail.net (nathan () netrail net [205.215.6.3]) by merit.edu (8.7.5/merit-2.0) with ESMTP id AAA07454 for <nanog () merit edu>; Tue, 30 Apr 1996 00:04:05 -0400 (EDT) Received: from localhost (nathan@localhost) by netrail.net (8.7.5/Netrail) with SMTP id XAA23252; Mon, 29 Apr 1996 23:59:35 -0400 Date: Mon, 29 Apr 1996 23:59:35 -0400 (EDT) From: Nathan Stratton <nathan () netrail net> To: "M. Christopher Davies" <mcd () onramp i95 net> cc: Ali Marashi <amarashi () interglobe com>, NANOG <nanog () merit edu> Subject: Re: Peering Policies and Route Servers In-Reply-To: <Pine.BSI.3.91.960429214629.17032F-100000 () onramp i95 net> Message-ID: <Pine.LNX.3.92.960429235656.23033B-100000 () netrail net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nanog () merit edu Precedence: bulk Content-Length: 2204 On Mon, 29 Apr 1996, M. Christopher Davies wrote:On Mon, 29 Apr 1996, Nathan Stratton wrote:On Mon, 29 Apr 1996, Ali Marashi wrote:(2) Could anyone share opinions/facts regarding why organizations may or may not exchange routes via the Route Servers rather than direct peering relationships at the NAPs?Well, because say that Sprint and MCI would peer, a provider would only just stay at one NAP. That provider could then sell large dedicated connections and in a way do it on Sprint's and MCI's network. I think they they are trying to keep a lot of startups like me from growing and being a large competitor.I think you've completely missed the boat on 1) what it means to peer, and 2) why one would peer with you. The idea (and I may be wrong here) that the big 6 may or may not choose to peer with you is because they have no contract to provide TRANSIT for your packets, but will gladly accept your packets for MCI or Sprint connected sites. The idea behind peering is that it is a shared dropoff point, but not a free transit to wherever on the net you want to go.No I think you are vary wrong, I know what it is to peer, and I am not askign for TRANSIT. Sprint and MCi will nto PEER unless you are at 3 NAPS.If you peer, it is expected that you will not utilize MCI's (as an example) network to talk to a non-MCI connected site on the other side ofNo kiding.That, I believe, is the reason that people don't peer as readily as you want them to.You have no idea. Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales () netrail net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34
Current thread:
- Peering Policies and Route Servers Ali Marashi (Apr 29)
- Re: Peering Policies and Route Servers bmanning (Apr 29)
- Re: Peering Policies and Route Servers Ali Marashi (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers M. Christopher Davies (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers Jeff Young (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers M. Christopher Davies (Apr 29)
- Re: Peering Policies and Route Servers Michael Dillon (Apr 29)
- Re: Peering Policies and Route Servers Nathan Stratton (Apr 29)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Enke Chen (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers bmanning (Apr 29)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- Re: Peering Policies and Route Servers Elise Gerich (Apr 30)
- Re: Peering Policies and Route Servers Paul A Vixie (Apr 30)
- <Possible follow-ups>
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 29)