Advice on dealing with Sprint

On Thu, 26 Sep 1996 15:57:06 -0700
Vadim Antonov <avg@quake.net> alleged:

When i was at Sprint it was customary to ask customers to
provide some assurance that routing information Sprint takes
from them is going to stay sane. That was usually achieved
by asking customers to send in their border configurations for
review by SL engineering, and some formal criteria (like "no
unfiltered IGP to BGP redistribution") was applied and said
configuration had problems worked out before the actual peering
was enabled.

yes, true, but custom engineering was a 'free' service back then for customers.
it was not built into the business plan as a revenue stream.
this is exactly what Randy is talking about now. and was thought about
years ago.
it is really a service to offer customers and not a duty.

The solution I recommend is for the provider to charge T&M for dealing
with CPE which they do not supply. When presented with the real costs,
consumers tend toward wiser decisions.

randy

Anyway, that automatically made every customer with BGP to go
down SCA (Special Customer Arrangement) route. I think sales
didn't like that, for whatever reason, and i saw several attempts
to make BGP peering a regular sale during my tenure there.
I guess they succeded after coming with some "guidelines", but
without any understanding of the issues involved.

and engineering didn't like sales giving so many custom solutions away.
by the time the order got to engineering back then the contract was signed, so
the goal was just make it work.

Somehow i became a big fan of Dilbert back then.

Vadim,
When you were at Sprint, I was at Demon and we BGP peered with
Sprint first using NetBSD/sparc IPX's with Morningstar PPP
then using BSD/OS and RISCOM N2 cards. One thing that I remember is
that your routers went insane _far_ more often that ours did.

that was me Neil. what a hack, but the business side of the issue is that
the service was up.

gees, i even remember connecting an old 3Com router just to say the service
was up.
the issue was not that engineering could not make it work, but when it
broke the NOC had no policy or procedure for some special configurations
and hardware. which led to the SprintLink Customer Handbook.

INSC were never much use and the only way we got things done was to
cc: you and Sean in any reporting of faults. Nevertheless, both you
and Sean where always very helpful.

aren't a high percentage of NOC's manage trouble tickets vs actually the
responsible group for fixing?

Cheers,
Neil.
--
Neil J. McRae. Alive and Kicking. E A S Y N E T G R O U P P L C
neil@EASYNET.NET NetBSD/sparc: 100% SpF (Solaris protection Factor)
Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>

Tell your Sprint sales folks that I said it was fine and approve the
SCA. If they have any questions, have them call me.

-Hank Kilmer
Mgr Sprint IP OPS Engineering

like any large organization, you need to manage the mis-information and
Hank obviously did a fine job of that.

-craig