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