Links on the blink - reprise

Fri Nov 17 21:55:15 UTC 1995

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.