Re: Advice on dealing with Sprint

[craig () kludge net (Craig A. Haney)]

At 10:03 9/27/96, Neil J. McRae wrote:
> 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


--------------------------------------------------------------------
Craig A. Haney            Cando Consulting - The Internetwork People
703-448-9826 :Tel         2031 Madrillon Springs Court
703-448-9786 :Fax         Vienna, VA 22182-3764
http://seamless.kludge.net


- - - - - - - - - - - - - - - - -