too many routes

Sean M. Doran smd at
Thu Sep 11 18:00:00 UTC 1997

Alan Hannan <hannan at> writes:

> > Sprint recently announced that they are deploying 622Mbps
> > POS cross-country links, and the GSRs are the only things
> > you can put on the ends of such beasts that are available
> > today. 
>   This is untrue.

Other people have pointed out that the statement is
perfectly true, but we can ignore the semantic misunderstanding.

AFAICT there is only one orderable, deployable and tested
IP router which observably terminates multiple 622-Mbit/s bit
pipes, notably that made by cisco.  

One thing I find amusing is your own company's recent
heavy investment in cisco's only likely competitor. 

Maybe this will mean cisco will stop paying so much
attention to the ridiculous requirements UUWHO coughs up
because it insists on a heavily meshed architechture for
what has since become essentially purely political
reasons, and start paying attention to people who are
building sensible hierarchical networks that display much
better scaling properties on nearly all fronts.  (I hope

Maybe this will also make people shy about helping Juniper
because that translates directly into helping UUWHO as well.
Who knows, maybe such things aren't so important,
especially since the cisco product a/ works and b/ is *cheap*.

>   These can be disaggregated into OC3 ATM pipes that can be fed into
>   many routers with proven technology and reliability.  Granted, the
>   disproportionality of the edge ckts to the backbone ckts provides
>   for interesting flow aggregation dynamics, but it does work.

Oh sure it works if you turn LS IGPs on their head and
try to avoid thinking too hard about how to build spanning
trees without building a physical VC topology for
multicast and can put up with interesting buffering and
switching effects and, as you say, the dynamics of WHY it
works vs. why it doesn't work when things break.

I hate to say it but I think I have become old and this
might explain why I like really simple and straightforward
failure modes.

>   Your disdain for ATM does not stop its existence and use by the
>   larger NSPs.

Technical merit has only been offered up as a reason for
using cells by your organization and ATMNET, AFAIK.

Everyone else who has been using ATM has done so because
it was one of only three obvious scaling paths, with the
other two being also gross (large numbers of parallel DS3s
using load-balancing and flattening the network with lots
of DS3s resembling lots of VCs, which is essentially what
UUNET did with its physical topology anyway).

>   Aggressive statement, though the timbre is occasionally marked by
>   usefulness.  I wonder how the world would develop without Sean's
>   input.....  {music, clouds, harps... visions of ATM faeries
>   dancing with sugarplums...}

Hahah.  Well, don't forget the Russian and the Swede who
also sang from the same songbook, and the other
congregation members who were at NANOG meetings when
everyone was angry at the BELLCORE twits prior to the
NSFNET wind-down (hi Curtis).

Many of the people who did actual engineering work at
cisco were also not very agnostic when it came to cells,
and had an effect on the company, which is one of the
reasons I have always liked cisco compared to its
competitors, who were not quite agnostic either but in the
opposite direction.

>   There is another router vendor who has OC-12 router interfaces
>   about ready for production.  Another (#3) is expected to release a
>   bang-up product real soon now.

As Peter Löthberg pointed out, there are BFRs in
production right now.  Sprint is also not the only vendor
who is using them to move traffic, although the majority
of other users are currently using the BFRs as really fast
star-shaped LANs, essentially.  (I expect this to change
very soon)

>   There is a choice in the market today for OC12 router interfaces.

Not today there isn't.  Maybe next month.

There may be choice in what you can put at the end of an
OC12 though, but it's either something smart or something
you'd find at Hobson's Tavern.


More information about the NANOG mailing list