Re: Peering Policies and Route Servers
To: NANOG <nanog@merit.edu> Subject: Re: Peering Policies and Route Servers Date: Tue, 30 Apr 1996 10:49:02 -0400 From: Enke Chen <enke@mci.net> [...] 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?
This sounds like an argument for an NSP to build their own routers. (Oh,I forgot, that has already been tried...) More seriously, I would like to think that the analysis performed by the NSPs is a bit more detailed. Perhaps the challenges include: o the routing arbiter not having a long-term track record as a vendor against which to compare internal efforts, or as you mention an uncertain future; o the route servers don't save an NSP all that much work; o the NSPs haven't bothered to do the analysis; or o ... -tjs -tjs
peerage, like sex these years, has a great potential for the transmission of disease. so one is very careful about with whom one peers. the route servers are more like a bath house, you're excahnging bodily fluids with every and any body. some exchanges have multi-lats. how many are actually used by the bigger players and how many are ignored in favor of multiple bi-lats? randy
On Tue, 30 Apr 1996, Randy Bush wrote:
peerage, like sex these years, has a great potential for the transmission of disease. so one is very careful about with whom one peers. the route servers are more like a bath house, you're excahnging bodily fluids with every and any body.
Interesting analogy...but not quite accurate. RS-based peering would be more like...a routing orgy among a group of peers, where a central entity organizes the bodily routing fluids and directs them, according to prearranged policy, to the appropriate indirect peers. It breaks down there...:-) Your statement implies that, when peering via an RA route server, one is required to accept (and advertise) any and all routes. This is wholly untrue. The RS's use policy information from the RADB to do routing calculations, resulting in a centralized routing model rather than a distributed one. Yes, it makes policy decisions for you...but based on your own policy indications.
some exchanges have multi-lats. how many are actually used by the bigger players and how many are ignored in favor of multiple bi-lats?
I don't know of very many exchanges that have MLPA's, but at the Ameritech (Chicago) NAP... ----- Date: 29 Apr 96 08:21:16 -0500 From: MARK.A.CNOTA@x400gw.ameritech.com To: nathan@netrail.net Cc: nap-info@aads.net Subject: Multi-Lateral Peering Agreement Nathan, Below is the current list of MLPA participants. Mark Cnota AADS Operations - Chicago Alpha-Net AGIS Argonne Nat. Laboratory Concentric Research Hyperspace Networks ISI/Merit (Routing Arbiter) NAP.NET Network 99 Netcom On-Line Univ. of Chicago One Call Communications // 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]
participants (3)
-
Matt Zimmerman -
randy＠psg.com -
salo＠msc.edu