Need help from UUNet's routing specialist!

Sat Dec 11 00:16:33 UTC 1999

> 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 at 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