North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Links on the blink - reprise
Curtis - | The brick wall is that a particular piece of equipment from a particular | vendor that a lot of service providers have made a large investment in | doesn't really perform all that well in the real world. Please allow me to mitigate your politics with a dose of reality. sl-dc-8.sprintlink.net, a now-fairly-old Cisco 7000 with one of the first four 2MB SSP boards ever shipped outside Cisco's doors has been observed to switch 125kpps through several interfaces over a 15 minute period several times in the past three weeks. The bottleneck is not in terms of switching capacity nor is it in terms of throughput across its backplane at present. The latter issue is looming, but we're simply not there yet. There have been substantial problems with respect to convergence times. Many of these have been ameliorated with experimental code now deployed throughout SprintLink and ICM, which does selective packet dropping to assist convergence rather than having the box keel over dead process-switching packets when the SSE cache is being completely repopulated. We are no longer hovering close to the practical limits of the current limitation, and are not very near the reasonable maximum for the current platform. This is not to say that we have all that much breathing-room, but this and other developments in the works does and will buy us much more time than we would gain by moving towards a system of the kind other providers appear to favour. The immediate danger is still in terms of BGP routing on defaultless routers, and we are all now keenly aware of that and I believe that even you have accepted that despite available alternatives like dedicated route servers, we must CIDRize or die. I am shocked and surprised to see you insinuating that my colleagues here and elsewhere and I simply don't know what the hell we're doing or what we're installing in our backbones. We are all too keenly aware that the growth of much of the Internet is outpacing the ability to build correctly-sized equipment and is forcing most of us to design plans for the deployment of large, scalable and for now over-engineered routers to cope with the current trends in traffic increases which do not look like they're going to shrink before the end of 1997. Not all of us are in the enviable position of being able to sit back and enjoy the air of superiority that seems to accompany being the chief commentator for a once-important and formerly leading-edge backbone. I think that you will find that at least two organizations who aren't in that position have been pushing Cisco very hard on the rather ingenious idea of developing an ISP test lab wherein real problems can be reproduced and studied, and where the characteristics of the current and in-development router technologies with respect to heavy-duty ISP environments can better be understood. You'll probably say that this is all familiar and old-hat, but kindly put your sneer aside and remember that the NSFNET backbone service ended a doubling and a quarter ago with respect to the size of the Internet then and now. These problems are difficult, nobody has complete answers, and "gee, just turn off a whole bunch of customers and you'll be fine" doesn't strike me as a plausible solution for Sprint, MCI, or AlterNet. Sean. P.S.: You might want to consider some "Sprint-did-it-firsts" which developed both within ICM and SprintLink vis a vis Cisco and general router technology deployment: 7000s, 64Mb RPs, BGP4, SSPs, 2MB SSPs, 7500s, reprioritization of forwarding vs other tasks, selective packet drop, and so on and so forth. Vadim Antonov and Peter Lothberg were and are never idle, and I fully intend to carry on the tradition of pushing useful new technology into the field as fast as it is available, because quite frankly, we need it all. DS3? OC3? Hah. You ain't seen nothing yet, baby.