Source: Cisco's HFR Tips the Scales

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 3 / 13 > >>

Tony Li 12/4/2012 | 11:17:40 PM

re: Source: Cisco's HFR Tips the Scales
Edgecore,

The control plane workload continues to grow rapidly because some folks continue to find more ways to spend control plane cycles. If folks would commit to not adding new features, we could probably stop. Or at least not grow faster than Moore's law. Since that's not going to happen, the control plane will always need more cycles.

That said, SMP isn't the only way to get there. SMP is good for problems where you don't need a lot of memory bandwidth and you only need a small number of processors. There are other techniques for better scalability. Of course, this is all computer architecture 201.

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

reoptic 12/4/2012 | 11:17:40 PM

re: Source: Cisco's HFR Tips the Scales HFR is a nightmare for Cisco, the only question is which is a bigger nightmare, the strategy or the execution. The strategy of building a monster scalable box with huge footprint and weight while at the same time redesigning the whole software base is the same strategy that was pursued by every scalable router startup; most have gone away and the rest are struggling or dream of getting to the point of struggling. Why? Only that carriers really don't crave too many boxes like this and they are really hard to execute. Juniper was smarter here, they just delivered slideware and have not really put resources into making the scalable implementation work...too busy trying to make it work 40Gb density instead of 20Gb like it does today.
The execution nightmare is that this thing has so many technology rocket science elements that it is taking forever to build, and is slipping 6 months every six months. When and if it is finally announced (say Supercomm) carriers will need to test so much new stuff for at least a year. Mostly the HFR is way to keep customers busy and discourage them from buying competitive product...
So what's worse, the strategy or execution? Huge Failed Router either way.

Reply | Post Message | MESSAGES LIST | START A BOARD

routethus 12/4/2012 | 11:17:39 PM

re: Source: Cisco's HFR Tips the Scales >> The control plane workload continues to grow rapidly because some folks continue to find more ways to spend control plane cycles. <<

so which of the following can we then expect Procket not to be supporting:

BGP/Layer 3 VPNs
BGP/Layer 2 VPNs
BGP/Routing Policy Distribution

Reply | Post Message | MESSAGES LIST | START A BOARD

edgecore 12/4/2012 | 11:17:39 PM

re: Source: Cisco's HFR Tips the Scales THX Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

arch_1 12/4/2012 | 11:17:37 PM

re: Source: Cisco's HFR Tips the Scales I thought the discusion was about the need for additonal Control-plane processing. Tony is describing a "feature creep" phenomenon. As ISPs add more features to the core, the amount of control processing horsepower per unit of forwarded bandwidth in a router increases.

On another note: You are correct that internet data growth is distributed and can then be solved in a distributed fashion. However, as the bandwidth increases, the bandwidth density also increases. In any particular location, it's cheaper to use one big router than a bunch of little routers, because the interconnect costs of the little routers are fairly horrific.

Here's a way to think about this: If you have only a fixed size router, you can still grow a a big internet by using many of them, but if you do, the network diameter must grow. This means that each packet uses more router resources, so the cost of routers per packet goes up with the diameter.

If you instead use bigger routers, the capacity of the internet can increase without increasing the diameter, and tbe routing cost (measured in hops per packet) remains fixed. This is simply another way to say that a bigger router beats a cluster of smaller routers, other things being equal.

As a rough rule of thumb the cost to administer an network increases as the number of routers increases. The exact shape of the curve differs depending on which protocols and services you provide, but the overall rule will hold, so again, fewer bigger routers will beat more smaller routers.

Note that it may very well make sense to use a CPU cluster in the control plane within a router. The control plane bandwidth is a tiny percentage of the data bandwidth, so the equation is different.

Reply | Post Message | MESSAGES LIST | START A BOARD

veluthuru 12/4/2012 | 11:17:37 PM

re: Source: Cisco's HFR Tips the Scales
Tony,

Your analysis assumes the network is centralized - the traffic growth is experienced by the same nodes. However, in a distributed architecture (as in the case of Internet) this is not true. The exponential growth in the traffic can in fact be supported, to some extent, by the same nodes but by increasing the number of nodes. The increase in traffic is perhaps due to the growth of the network footprint itself.

In summary, exponential growth in Internet traffic does not necessarily translate into similar requirement from the nodes (of course, core router marketing machine would want you
to believe otherwise :-)

Reply | Post Message | MESSAGES LIST | START A BOARD

stomper 12/4/2012 | 11:17:36 PM

re: Source: Cisco's HFR Tips the Scales Let's assume that the rumors are correct, and a
router fitting the specs outlined in this article
will be formally announced in the near future.

The question: what will this mean to the market ?

I think it is safe to assume that all major
potential customers already know a significant
amount under NDA. If the product has reached at
least the alpha milestone yet, it probably has
seen some testing in a few labs.

The purpose of an annoucement is publicize their
direction and strategy, and market their product
as the best solution - maybe worth waiting
for. Any reversal on specifications or major delay
in release dates from that point on will be an
embarrassment which will be harped on during
quarterly earnings calls and show up in the stock
price.

The design decisions they have made thus far tell
us a lot. The most notable thing is simply that
they believe a two-tier product line is necessary,
lower end running IOS and HFR running new stuff.
Further, they believe multi-bay scalability is
important.

From the customer point of view, new software is
always a double edge sword. It might be better,
but it will definitely have new bugs. And the dual
OS approach will never be seen as a plus, as no
matter how much code is shared, even a minor
difference will require qualification prior to
deployment in any tier 1 network. It appears Cisco
will now place the burden of supporting two major
code bases on themselves and their customers.

Their support of multi-bay scalability is
interesting in that it validates competition
with similar claims, where in the past they have
stated that it was not necessary.

Finally, by designing the HFR as a new product
with all new hardware and OS (probably necessary),
they will have to compete against other vendors in
an apples-to-apples core router solution bakeoff.
When their core router 12K series was simply newer
hardware, they might have been able to leverage
software which was already qualified in a
customers edge router deployments. By definition,
it weakens their end-to-end solution story from a
non-business perspective. Now they will need to
consistently have the best core and edge solution
or a customer will have no technical reason to
stick with Cisco.

-S

Reply | Post Message | MESSAGES LIST | START A BOARD

teng100 12/4/2012 | 11:17:36 PM

re: Source: Cisco's HFR Tips the Scales "If you instead use bigger routers, the capacity of the internet can increase without increasing the diameter, and tbe routing cost (measured in hops per packet) remains fixed. This is simply another way to say that a bigger router beats a cluster of smaller routers, other things being equal."

If you can sell the bandwidth not just
best effort traffic.

Reply | Post Message | MESSAGES LIST | START A BOARD

Tony Li 12/4/2012 | 11:17:35 PM

re: Source: Cisco's HFR Tips the Scales
Bulk reply:

routethus: Procket is customer driven and will do what customers need.

veluthru: As we have found over the years, if the bandwidth is not aggregated, then we come to suffer the "small switch penalty". Basically to combine many smaller switches, you need many more of them and many interconnects. Today folks that play this game have to pay for the interconnects between routers as they would for customer facing interfaces. This is onerous. Assuming that the traffic demands it (i.e., there are large Tier 1's), it is more efficient for them to use a larger, scalable system. I will certainly grant you that if all of the Tier 1's implode and everything is run by Mom & Pop's OC-3 shop, that the Internet could grow without this need. However, that seems exceedingly unlikely at this point.

teng100: Whether bandwidth is sold as best effort or not doesn't really matter. The Internet will continue to grow and someone will find a way to be sufficiently efficient to make money at it. It is up to the vendors and carriers to find this way. Hopefully it won't involve questionable accounting practices. ;-)

Tony

Reply | Post Message | MESSAGES LIST | START A BOARD

mboeing 12/4/2012 | 11:17:34 PM

re: Source: Cisco's HFR Tips the Scales "If we look at history, IBM thought of Microsoft much in the same way... Look how that turned out."

What I see is this: IBM is doing quite well and Microsoft is creating inferior products. So what is the lession learned?

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 3 / 13 > >>