|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Advice on dealing with Sprint
At 10:03 9/27/96, Neil J. McRae wrote: >On Thu, 26 Sep 1996 15:57:06 -0700 > Vadim Antonov <[email protected]> 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 >[email protected] 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 - - - - - - - - - - - - - - - - -
|