nanog mailing list archives
Re: Peering Policies and Route Servers
From: Matt Zimmerman <mdz () netrail net>
Date: Tue, 30 Apr 1996 15:50:24 -0400 (EDT)
On Tue, 30 Apr 1996, John Curran wrote:
At 2:12 PM 4/30/96, Matt Zimmerman wrote:... Setting aside the technological barriers to such an arrangement, an optimal configuration would be one in which all routing entities peer with one another at all available locations, so as to provide the shortest path between routing communities.I believe that the optimal configuration would actually involve only one routing entity and no peering at all. I'm pleased that instead we've implemented a model which (while not optimal) allows for a growing Internet service provider industry. Solutions which are optimal under one constraint tend to degenerate in the real world.
For varying values of "optimal". :-) In terms of decision-making, you can't beat centralized routing...if a single entity knows all there is to know about current state of the Internet topology, it can make optimal decisions. But a distributed system is far more reliable, and more flexible in terms of growth. My "optimal" was slightly more oriented toward the current state of affairs than was yours. ;-)
Shortest-exit routing and equivalent distributed peering is used to avoid settlements for transit costs. If there's a strong demand for dissimiliar peering, then it's likely to appear with settlements.
I, for one, would see this as a far more equitable solution than an SKA arrangement where peering arrangements are subject to strict policy-based discrimination. If I were to peer with Sprint at MAE-East (and MAE-east only), relying on their network to backhaul traffic across the nation, it could be seen as fair for me to compensate them financially, if only as an interim measure until a true peering arrangement is feasible. // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz () netrail net sales () netrail net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
Current thread:
- Re: Peering Policies and Route Servers, (continued)
- Re: Peering Policies and Route Servers Vadim Antonov (Apr 30)
- Re: Peering Policies and Route Servers Peter Lothberg (Apr 30)
- Re: Peering Policies and Route Servers bmanning (Apr 30)
- Re: Peering Policies and Route Servers Tim Salo (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Randy Bush (Apr 30)
- Re: Peering Policies and Route Servers Paul Ferguson (Apr 30)
- Re: Peering Policies and Route Servers Rob Gutierrez (Apr 30)
- Re: Peering Policies and Route Servers Curtis Villamizar (Apr 30)
- Re: Peering Policies and Route Servers John Curran (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)
- Re: Peering Policies and Route Servers Justin W. Newton (Apr 30)
- Re: Peering Policies and Route Servers Michael Dillon (Apr 30)
- Re: Peering Policies and Route Servers Matt Zimmerman (Apr 30)