& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 4   >   >>
Truelight1
Truelight1
12/5/2012 | 1:44:55 AM
re: Make Way for Cisco's HFR
Does this mean the ROUTER guys finally get the idea on how to build non-blocking switches - KISS or should I say KISC - really.


justapeon
justapeon
12/5/2012 | 1:44:55 AM
re: Make Way for Cisco's HFR
It will be interesting to see how successful Cisco will be with a Clos based design. Achieving modular design that doesn't require buying the interconnects up front will be an interesting thing to watch. I'm sure this beast will be hell to get integrated into the product configurator.
reoptic
reoptic
12/5/2012 | 1:44:52 AM
re: Make Way for Cisco's HFR
Seems like the basic routing software is still far from done, chassis still in the works for smaller and narrower model, still doesn't scale up. Rushing the product out beacause they lost market share 2 quarters in a row? Marketing hype or not, folks won't deploy an unfinished product.
null0
null0
12/5/2012 | 1:44:49 AM
re: Make Way for Cisco's HFR
Depends how many queues and how many differentiated services you want to run. Other CLOS architectures are blocking even if you run as few as two diff services!

Null
Tony Li
Tony Li
12/5/2012 | 1:44:49 AM
re: Make Way for Cisco's HFR
Software is never done. There's always another chassis in a slightly different form factor. And scalability is hard if you have a non-uniform fabric, so I'd be surprised if is scaled with the first announcement.

In short, your complaints would apply to every single router that has ever been shipped. Obviously, some of those have been installed.

Tony
andropat
andropat
12/5/2012 | 1:44:48 AM
re: Make Way for Cisco's HFR
This is interesting... so now you have 2 major clos architectures that both scale to multi-chassis (or claim will)...both support 40G per slot bandwidth.

In my opinion, Juniper will have the edege for a number of reasons. First to market so have had a lot of time to work out th e kinks... still full-featured single binary image... 19" rack... already has the half-sized router (t320).....

I think this product is going to hurt cisco longer-term. They are the best marketing company in the world so the hype will probably be incredible but all the true engineers will see the risk factor and time factor involved for deploying this beast.

Procket... this is your chance!

Pat
reoptic
reoptic
12/5/2012 | 1:44:48 AM
re: Make Way for Cisco's HFR
>>Software is never done

Right, its not done, and usually version 1.0 is kind of buggy (or 3.0 in case of Microsoft).

>>scalability is hard if you have a non-uniform fabric, so I'd be surprised if is scaled with the first announcement

Agree, probably not done either. Nasty part may be having to replace the hardware to make it work down the road.

>> your complaints would apply to every single router that has ever been shipped

This is a stretch. Certainly true when people ship things for some trials or to research institutions they are often half-finished, but half-finished products aren't in too many large production networks. When it comes to IP core routers, cycle from trial to production deployment is even longer.

We'll see how many HFRs are deployed this year. What is your guess?
dwdmguy
dwdmguy
12/5/2012 | 1:44:45 AM
re: Make Way for Cisco's HFR
Cisco knows how to design clos architectures that are non-blocking. Their 15600 is fully non-blocking today and supports 320G on a single shelf. According to cisco.com, the 600 also supports 40G per slot (4xOC-192, 16xOC-48). Granted the 600 is TDM, bu if cisco let the 600 team and the HFR team collaborate, the HFR should be in good shape if it uses a clos.
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:44 AM
re: Make Way for Cisco's HFR
=======
This requires some planning. "You have to invest in enough '2' cards up front because the '1' and '3' cards must connect to this component. Basically, you can't 'pay as you grow' like you can with a modular fabric," says Esmeralda Swartz, Avici vice president of marketing.
==========

Esmeralda,

I totally agree with your comment. However, I would contend that scalability is also important. And to have a truely "Pay as you Grow" and Scalable switching fabric it can not be a centralized architecture as is the case with Clos or single stage shared memory. It must be distributed to the resolution of the I/O line card and it must be some form of mesh or matrix (which is simply a structured mesh).

Kerry Davis
Aztech Partners
www.AztechPartners.com
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:44 AM
re: Make Way for Cisco's HFR
Null,

A CLOS architecture is inherently non-blocking (either strictly or rearrangably depending on how you do it) at the TDM level (if configured as Chuck designed it in 1953). Non-blocking, which is the ability to connect one point to any other point at any one time to the full capacity of the I/O. What you describe seems to refer to non-blocking at the PDU level which, from a TDM perspective, requires the ability to connect one point to every other point at the same time. Which is clearly impossible, but we can emulate such a functionality using an arbitrated TDM circuit along with network processing, traffic management and external buffers.

I believe the real issue with a clos architecture used to switch packet/cell data is the inability to change circuit pathways so that the buffers don't overflow due to the inability to construct pathways fast enough to drain them. So the Clos architecture itself is not really the problem. It is the SW or the HW supporting the architecture in combination with the diversity of the traffic that creates the difficulty. And understandably so, because this is a very difficult thing to do, especially as you scale very large like the HFR.

However, I must take this moment to shamelessly plug an alternative that I personally have a stake in. And that is the HyperTorus Mesh that was developed at Brightlink. The HTMESH architecture enjoys a one to one relationship with the Packet/Cell or TDM PHY. Therefore, the centralized switching hub referred to in this article is not necessary at all. Like Clos, it too is nonblocking at the TDM circuit level. And it is far easier (as in much faster) to make and break unidirectional or bidirectional connections from one point to another across the fabric. That speed allows for the draining of the packet/cell data buffers before they overflow. This is largely due to a much simpler provisioning method for the HTMESH than a multistage Clos (most of the work is done in real time in the HW). Anyone who has programmed a multistage stage Clos and/or had to write rearrangement algorithms for the beast can testify to the complexities, especially as the fabric approaches maximum capacity.

Of course one could always simply increase the size of the buffers at the expense of propogation delay or add buffers to the central stages of the switching fabric as is depicted in the lightreading article on buffered and shared memory switching fabrics. So Cisco has many options to make it work. But I would agree that just making it work is not good enough. You wouldn't take a semi truck to the Daytona 500 but it would make it around the track.

Kerry Davis
Aztech Partners
www.AztechPartners.com
http://www.lightreading.com/do...

--------
Depends how many queues and how many differentiated services you want to run. Other CLOS architectures are blocking even if you run as few as two diff services!

Null
-------
Page 1 / 4   >   >>


Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events