NAP/ISP Saturation WAS: Re: Exchanges that matter...

Fri Dec 20 20:00:14 UTC 1996

> 
> >   > Let me add one more word to this discussion. In case of simple and solid
> >   > FDDI or Ethernet protocol it's not big chance if the whole switch would be
> >   > failed down by one crazy interface card or one crazy router.
> >
> >   In some sense isn't this what is occuring with head of line blocking?
> Line blocking is a throughput problem, it's not protocol incompability.
> 
> >   > In case of ATM nobody can protect the whole ATM system  from being failed down due
> >   > to some software bug since 1 / 5 after system was installed, because
> >   > the number of different featires in ATM network and ATM interface is more
> >   > then 10 - 100 times more in comparasion with FDDI. This means - if your
> >
> >   In that case we should get rid of all of our routers. They certainly support
> >   much more complexity that ATM switches.
> You are right, and if you'll install some new router (not Cisco, not Gigarouter
> based on the old, solid and well  tested gated) into Internet core backbone
> - you'll get good chance to see your router crashes every
> 10 minutes. We had this few times ago when we mixed different routers into
> internet core network. Now we are using CISCO's, and If some
> fluktuation in the Internet
> would make clean new IOS's bug - it would be not my router which crashes first,
> but the
> the router not far from the source of fluktuation.
> 
> It's amazing but it's true.
> 
> >   > FDDI switch works fine just now, it's more than 99% it'll work next
> >
> >   Really? I am surprised that everybody seems to be of the opinion that the
> >   Gigaswitches are not causing any problems. This doesn't seem to me to be
> >   consistent with early discussions from this thread.
> I have not opinion about Gigaswitch, but if FDDI protocol is described by
> 20 sheets of paper and ATM by 20,000 sheets - the number of hidden bugs
> have the same proportion (software bugs I mean).
> 
> >   > 2 years (may be it'll be saturated but would not crash totally); in case
> >   > of ATM it's more than 20% the whole system would be crashed by some new
> >   > neighboar with some new ATM software...
> >
> >   ATM PVCs, as used by the current ATM NAPs, don't require much sophistication.
> >   They are basically just hardwired circuits.
> I am not shure was is PVC or some other .VC in the case I have described,
> but I suspect it was PVC; but it have caused a lot of problems anyway.
> Hope nobody promise LANE to be used by NAP's?
> 
> Shurely PTT's and great vendors who just wast a lot of money for ATM solution
> would not allow ATM to die, and I hope it'll be one of (just as Gigabit Ethernet,
> and so on) solutions for the future NAP's. Sorry, there in Russia we have
> not filled even FDDI (not GigaSwitch) yet, and this do not allow me to
> make any predictions... But if protocol 1 is 1000 times more complex than
> protocol 2, and we;ll mix 10 different providers at the NAP-1 based
> on protocol 1 and NAP-2 based on the protocol 2 - guess how NAP-1 and
> NAP-2 will work?

If you remove UNI, PNNI, LANE, CLIP, etc. from the equation ATM gets pretty
simple. Some degree of testing in a live environment has already occured. As
was pointed out earlier there were many interoperabily issues between Cisco
ATM interfaces (including the lack of DS3 ATM) and the ATM NAPs early on.

My questions are:

1) Are the Gigaswitches failing at the most congested NAPs?

2) Do any viable alternatives exist today?

3) If the answers to 1 and 2 are yes and no respectively are we prepared to
abandon NAPs all together.

Jim