& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 2 / 4   >   >>
technoboy
technoboy
12/5/2012 | 1:44:39 AM
re: Make Way for Cisco's HFR
re post 11

I pose the question why do you think this is a problem. Of course we would all like to push our platforms out of the door with all of the features and functions available and already tested, regression tested, and ready for to go. Let me ask another question. Suppose this box has everything ready now. What service provider is ready to use all of the functions? Answer=darn few.
sigint
sigint
12/5/2012 | 1:44:39 AM
re: Make Way for Cisco's HFR
Tony:
In short, your complaints would apply to every single router that has ever been shipped. Obviously, some of those have been installed.
__________________________________________________

Tony,

I admire the candour. However, is there a way around this "problem". And, do we acknowledge it to be a problem at all?

Thanks,
Sigint
morerouting
morerouting
12/5/2012 | 1:44:38 AM
re: Make Way for Cisco's HFR
You might want to scratch Hyperchip off the list of fierce competitiors. They appear to have axed their software team, Virginia office and finally succumb to the inevitable.
C'est la mani+¿re que le biscuit s'+¬miette.
Tony Li
Tony Li
12/5/2012 | 1:44:36 AM
re: Make Way for Cisco's HFR
>> 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.


Ok, cards on the table time. Which core routers do you claim have shipped "fully featured"? I can vouch for the 7000, 7500, M40 and 8812 personally. All of them were still very much "work in process" as of announcement and first ship. Stability and reasonable 'feature completeness' came later. Sometimes much later.

Tony
Tony Li
Tony Li
12/5/2012 | 1:44:35 AM
re: Make Way for Cisco's HFR
However, is there a way around this "problem". And, do we acknowledge it to be a problem at all?

a) I don't think it's really a problem. It's not been a problem for the customers and it's not been a problem for the vendors. It is obviously a problem for certain mailing list gadflys, but then they're not in the middle of the sales process, are they?

b) Yes, of course, with enough thrust and time, you can have every feature that anyone has ever dreamed up implemented by FCS. But this is not a strategy that will make vendors, customers or investors happy, and is therefore unrealistic.

Tony
Tony Li
Tony Li
12/5/2012 | 1:44:35 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.

And, after you've gotten two Cisco BU's to cooperate, could you please fly to the middle east?

;-)

Tony
Tony Li
Tony Li
12/5/2012 | 1:44:35 AM
re: Make Way for Cisco's HFR
Kerry,

Two issues for you:

1) First, I can't speak for Null0, but I'll point out that the bursty nature of IP packets is VERY different stochastically from a TDM circuit switching arrangement. In a router, any bandwidth limitation at all can become a congestion point, and because all interfaces and independently gang up on a single output interface, it is impossible to create an architecture that has no bandwidth limitations.

To be practical, there must be buffering before congestion, and the buffering must be segregated to avoid HOLB. Thus, one way to mis-design a Clos would be to not have sufficient traffic segregation before or internal to the switch. I'll ignore the question of whether this is a real, practical issue or just a theoretical one.

2) Regarding the 'pay as you grow' model. In all of the designs and rumors that I've heard, all proposals are incremental growth. Granted, they do involve hardware other than what originally ships, but the switching fabrics are all incremental additions. Thus, the customer is still paying as they grow, but the granularity of the hardware investment might be larger for some than others. Considering that with current price schedules, most of the CapEx goes into the line card, it's not at all clear that this is a practical, significant issue.

Tony
coreghost
coreghost
12/5/2012 | 1:44:31 AM
re: Make Way for Cisco's HFR
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).


Meshes don't scale. And the cost and complexity
of a mesh (or a matrix) switching system gets
worse as the size of the system increases.
People who build them always talk about n-way
connections and then after probing "n" turns out
to be some tiny number forced by the complexity
involved in going beyond "n".
coreghost
coreghost
12/5/2012 | 1:44:30 AM
re: Make Way for Cisco's HFR
Marketing hype or not, folks won't deploy an unfinished product.


Maybe not deploy, but they will buy. Sprint
will buy whatever cisco tells them to. Same
with SBC. They will go to trade shows and
tell everyone how wonderful the HFR is and how
happy they are with it even if never makes it
into the real network.

And its very possible for certain customers of
cisco to announce a deal for the purchase of
a whole lot of HFRs that internally ends up
involving the "temporary" deployment of a whole
lot of GSRs with the HFR getting no further than
a lab toy.

Cisco gets most of the benefit of the HFR even
if nobody ever uses it for real in a production
network. And if it takes them years to get it
right, they have the cash to spend to do it.

They can go into customers and sell the HFR
with its theoritical feature set against
competitors, win contracts and then substitute
GSRs when it comes time to deploy until the
HFR is ready.
Kerry Davis
Kerry Davis
12/5/2012 | 1:44:26 AM
re: Make Way for Cisco's HFR
Tony,

Thanks for your comments. I totally agree with your first comment. I believe you must have alot more switching bandwidth than you terminate to make this work.

As for comment 2, if you are implementing a Clos switching fabric you usually want to fully populate the switch up front and grow the I/O as needed. This saves alot of problems in the future. Although it is possible to scale the fabric as you grow it can be a very complex procedure and can depend alot on the equipment providers software. So it is pay as you grow to some degree but not what is possible if the switching fabric scales one to one with the I/O.
<<   <   Page 2 / 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