nanog mailing list archives
Re: Peering Policies and Route Servers
From: Enke Chen <enke () mci net>
Date: Tue, 30 Apr 1996 10:49:02 -0400
Hi, all: Let me add my humble opnions on engineering issues reagarding peering: (1) There is a snowball effect for interconnects. If an organization could simply connect to an interconnect and gain global connectivity without paying for transit, why not? Can you imagine an interconnect with 500 organizations? Unrestricted peering policy would accelerate rolling of the snowball, and lead to the collapse of an interconnect. In order for Internet to survive, this snowball effect got to stop. (2) There is no connectivity gain for a national provider to peer with a single-attached organizaiton as all these organizations have transit providers that are present at multiple interconnects. (3) There is a huge investment involved to build a national backbone. Many providers currently do "hot-potato" routing (closed-exit) because of this cost. Peering with a single-attached organization would require much more backbone investment as traffic to this organization needs to be carried across the backbone, while the cost for this single-attached organization would be small (one DS3 to an interconnect). Regarding the RS (I have many friends there, and they have done many good work), let me echo the fundamental issues that Steve Heimlich has pointed out, would you rather have your peering policy enforced by yourself or by a third party? Would you rather develop a dependency on a third party (which may not be there a few years down the road) to deliver the critical service or depend on yourself? -- Enke (speaking only for myself)
Current thread:
- Re: Peering Policies and Route Servers, (continued)
- 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)
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 29)
- Re: Peering Policies and Route Servers Curtis Villamizar (Apr 30)
- Re: Peering Policies and Route Servers Cengiz Alaettinoglu (Apr 30)
- Re: Peering Policies and Route Servers Steve Heimlich (Apr 29)
- Re: Peering Policies and Route Servers Vadim Antonov (Apr 30)
- Re: Peering Policies and Route Servers Peter Lothberg (Apr 30)