We (as8470) are Teleglobe customer. And we experience terrible delays on Teleglobe to UUNet interconnect points. Teleglobe's customer support engineers insist, that the problem caused by UUNet's routes prioritization. But I belive that this assymetric routing initiated by Teleglobe, not UUNet.

We apologise for this customer-provider issue propogating to NANOG. For the information of interested folks, and to clear up any incorrect perceptions, I have copied the list on my reply. Currently, private interconnects from Teleglobe to UUnet are multiple DS-3's, in multiple cities. However, as a result of incremental load, the management and load-balancing of these is tenuous, and event-sensitive. Specifically, internal events on either network, can cause congestion as a new closest-exit path is chosen. We are currently waiting for delivery of several OC-12 circuits to replace the plethora of DS-3's. Unfortunately, provisioning OC-12's is not something many LEC's can do, let alone in a timely manner. When these are in place, the problems should go away for the forseeable future. Provisioning of additional OC-12's should be feasible in the timelines anticipated for further growth of traffic. Until then, there is some traffic engineering being done via MEDs, for the purposes of avoiding congestion. Some of this is steady-state (since certain peerin glocations are currently under-provisioned), and some is in response to congestion events. In the absence of inter-provider MPLS, to handle such things inter-provider and intra-provider outages in a semi-optimal fashion, and in the absense of excess interconnect bandwidth (to handle outage-based peak loads), there will be instances where asymmetry is required to minimize network impact of such outages. The selection of routes for application of MEDs is done on a random basis, for scalability reasons. The choice of exit modulo these MEDs is still closest exit, and will vary based on the geographic location of the end system. (The MEDs are used to de-prefer a couple of peering locations; all others operate naturally, ie closest-exit.) I hope this explanation is clear enough; if anyone has questions about this or other Teleglobe issues, please feel free to contact me directly. -- Brian Dickson, Email: briand@teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com