On Sat, 8 Nov 1997, Wade Williams wrote: > I certainly understand that Cisco is not perfect, and I'd like to > understand how you think we (or Ascend) can improve things to what you call > carrier-class. If you can give me some feedback on that, I'll take it back > to some of the guys at TAC to pass to the powers that be. Certainly. I've heard two excuses back from Ascend why things don't get fixed/get broken: 1. This is leading edge technology. 2. There are too many possible combinations for us to find all the bugs before we release software. To address them both: 1. This is leading edge technology. Our 7513 gave a lot of trouble during testing, refusing to swap RSPs properly on hotswap - with hardly any config in it. This is hundreds of thousands of dollars worth of equipment with minimal chance of any conflict with anything else - with one card configured up with an IP address. In the end, our reseller (a Gold partner) replaced the chassis. What testing is done on the hardware to make sure it works before it ships? A carrier-class vendor would have caught this problem before it got to us. We daily analyse RADIUS records, indexed by Max and cause code. We can then pick out chassis' underperforming - many abnormal disconnects compared to the rest. We see an extremely wide variation - even among Maxes at the same POP and on the same switch card (yes, they're all running the same software version, same build, same configuration). A carrier-class vendor would've picked this up. There is very standard equipment around to generate hundreds of calls to boxes - I imagine given a little effort Ascend could even write something to drive a Max in reverse to test against other boxes. Ascend - just think. Ask nicely some of your largest customers for some of their RADIUS data - I'm sure people like Jason and certainly myself would gladly let you have a look since it'd improve the service. Find out how your product performs in the field. And then, just think, how many fewer "disconnects with cause 185" support calls you would have taken if you'd done this earlier and fixed it.... Brand-name PC vendors have been doing this for years. Burn the stuff in, *before* it ships. Even TV manufacturers do that, and I'm sure a lot more TVs get sold than Ascend Maxes... 2. There are too many possible combinations... Fine. Which is why Telcos have the resources to pay for model environments. For instance, we have a model exchange, a model ATM node, and a model POP. So we *can* test for things in our environment in a consistant way before deploying them. NEC give us a software release, which we test, find lots of bugs in, document them all, and send back to NEC - which they fix. NEC trust us - we trust them. The point is - Ascend/Cisco take the commodity paradigm too far. You guys treat all your customers like dummies. In fact, it's worse than that. A few months ago, an Ascend engineer came in to demonstrate a system for us. It didn't work. He declared it a bug. He had to reproduce the thing all over again with new debug before *Ascend* would acknowledge it! Seems Ascend doesn't trust even its own engineers. :( We've been finding bugs in our platform for many months, which our reseller has been escalating to Ascend. Our perception is, Ascend are the black hole. Things get lost in there. Ascend say, "No, there is no accounting problem in release p13." I show the guy some debug with negative IP addresses. No response. One of our Maxes won't take a hash code update. Ascend say I'm typing it wrong. I triple check it - the box won't take it - difficult to type it wrong if I cut and paste between xterms. I let an Ascend employee telnet in on condition he tell me if there's any risk so I can move any customers off. "No risk". Two minutes later, my box is off the air. Permanently. It no longer booted. It had to be replaced. I must say here our local vendor I don't have a problem with - it's Ascend. While access servers are complicated beasts, there's no excuse for a human-complexity "take two aspirin and a new software release and call me if it doesn't work in the morning" approach. I understand this is a somewhat heretical view - but why not stop your customers ringing with complaints by: 1. Treating them not only with politeness but also if they have an IQ above 100. I was self-employed a couple of years ago. I won a lot of business because I didn't treat people who didn't understand what they were using as if they were stupid. 2. Listen to what they say. There is a problem here. Perhaps it's config - perhaps it isn't. The attitude should be - fix it, don't point the finger. 3. Acknowledge their concerns - "that's bad." They're ringing you because their business is going down the drain, and your box has something to do with it. Give them some confidence in the product - *show* them it works somewhere else. 4. Stop firefighting. I have worked at two ISPs where growth has been phenominal. Companies growing at 15%/month. Customers signing up 1000/week. New staff being hired every other week. Yes, it is difficult to manage growth. Yes, it is difficult to cope with software versions. But not impossible and it's been done many times before. We cannot get away with "but you get that on the Internet" any longer. - -- Josh Bailey (<A HREF="mailto:joshb@xtra.co.nz">mailto:joshb@xtra.co.nz</A> - GroupWise <A HREF="mailto:j6bw@telecom.co.nz">mailto:j6bw@telecom.co.nz</A>) Internet Network Specialist Voice (DDI): +64-9-355-5923 Telecom Internet Services Voice (Mob): +64-25-514-899 Extension: 93423 (Lvl. 4, 120 Mayoral Dve) Fax: +64-9-355-5260 Private Bag 92028, Auckland, NZ Pager: +64-26-114-448 PGP public key available at <A HREF="http://www.pgp.net/pgpnet/pks-commands.html">http://www.pgp.net/pgpnet/pks-commands.html</A> DISCLAIMER: Viewer discretion is advised. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQB1AwUBNGTT0/le+GEe9W4hAQE0agL9ED0HrzNtH3wZ7GS1fc+GNm0kXm+cBrdZ pv/Bk1x0C4fPLdcXkOx90gHHhRdVCSjxtX0TvcyyVpkis2ucoG6kQtt2YDMHFAoL hLMPeh3MAAyJSS1UY1mWW/tIjyd083Pr =zGWm -----END PGP SIGNATURE----- ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <HR> <STRONG>References</STRONG>: <UL> <LI><STRONG><A HREF="msg10580.html">(ASCEND) Re: What is carrier-class?</A></STRONG></LI> <UL> <LI><EM>From</EM>: Wade Williams <wwilliam@cisco.com></LI> </UL> </UL> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg10584.html">(ASCEND) (PIPELINE) What is wrong</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg10586.html">Re: (ASCEND) Getting syslog working on Max1800</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg10580.html">(ASCEND) Re: What is carrier-class?</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg10601.html">(ASCEND) Re: What is carrier-class?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#10585"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd235.html#10585"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>