I know I have experienced the engineering department there as well, the
best one was when they wanted paper documentation for every route I
asked to have in our filters... (and they were incapable of using
RADB). It was especially odd since we have > 80 of our own peers and
three other transit providers to who we were announcing over 100 routes
while they still wanted paper docs.
But, filters seem to be an annoyance for most big providers... I have
been trying to get level3 to fix our radb-based filtering for a while
now (it just stopped pulling new updates for some reason). 
John
John van Oppen (list account) wrote:
I know I have experienced the engineering department there as well, the
best one was when they wanted paper documentation for every route I
asked to have in our filters... (and they were incapable of using
RADB). It was especially odd since we have > 80 of our own peers and
three other transit providers to who we were announcing over 100 routes
while they still wanted paper docs.
I've fixed this by throwing their own policies back at them. Point out
to them that the route is already appearing globally through your AS,
and remind them that their policy, section 3b, already allows that. 
On the previous topic, I'd have to say that their two-peer system is
perhaps one of the better, if not best, multihop implementations I've
seen. Amongst other things, it tends to provide a rapid assessment of
"life in the POP". I just wish they'd use their network status messages
to reflect when they were having problems, instead of just problems
that are too large for the call center to handle. 
pt