<<   <   Page 2 / 2
materialgirl 12/5/2012 | 1:14:29 AM
re: Juniper's TX Waits Its Turn Why would any service provider buy a $MM box if at the end of the day it will be used to carry ripped versions of movies to peer-to-peer groups, or some else's VoIP traffic? Yes, traffic may be growing, but so what, if the value chain to the service provider is broken?
maxng 12/5/2012 | 1:14:25 AM
re: Juniper's TX Waits Its Turn Hi Tony,

Do not really understand what you are pointing out. But my understanding is the type of business the IP network is serving. If the network serves consumer or even business ADSL internet service, then traffic are mainly aggregate before pushing into a Core Router.

For MPLS based VPNs directed at Enterprise customers, I can understand the need for aggregation and de-aggregation on the routers.

maxng 12/5/2012 | 1:14:25 AM
re: Juniper's TX Waits Its Turn I think the question of multi-chasis or folklift upgrades also depends on the type of Carriers or Service Providers they are. Giving a view of those in Asia or at least those that I speak to, various Carriers or Service Providers have different preference and all have their own beliefs and merits. Some of their choice or decision are based on the size of their business and some on their massive operations structure.

I'm not sure if the views posted here reflects all big Carriers in US like AT&T, Qwest, Sprint etc.

But definitely in Asia, I've seen carriers that like or believe multi-chasis system/architecture are the way to go because the predictability of growth is not so predictable in 3 to 5 years. They do not want massive operations to upgrade Cores.

Then there are other Provider that believes in multiple single chasis Cores. They generally like drop in the middle approach where old Cores are being pushed into aggregation and New Cores drop into position.

Which is superior and better is hard to debate. It really depends on which Carriers/Providers and who is the Planner.


PS: Voice from Asia
maxng 12/5/2012 | 1:14:24 AM
re: Juniper's TX Waits Its Turn Hi Geoff,

How are you doing.

I tend to agree with what you say. I've seen much worse over-subscription particularly here in Asia. The cost of DSL to homes are cheap and Carriers just have to live with the massive oversubscription.

Your point 1 : Even with VoD, the DSLAM will be the one pushing out the video and traffic will not hit the Core or aggregation. With current ADSL2+, its not even near 50Mb. I have yet to see premium traffic being offer to the consumer market. Right now, for customers that need the extra bytes for heavy download or gaming just request for "larger" pipes "real-time" online. The traffic are not treated as premium. But I believe this might change with Carriers coming out with creative packages/bundles.
gbennett 12/5/2012 | 1:14:13 AM
re: Juniper's TX Waits Its Turn Hi Max,
Doing fine, thank you, hope you're the same.

I see the discussion is moving in its usual direction - from how you achieve scalable switching capacity in multi-chassis switches over to "is there a need?" and "who's going to pay for it all?".

You're right. VoD was a poor example because, as you say, the content is generally stored locally and most of it doesn't hit the core. But I guess it still tends to both our positions that we don't see a need for a multi-chassis aggregation platform just yet.

Tony, your points about incremental growth (both the need from carriers and the historical failure by the industry to deliver graceful upgrade paths). I agree on both. But do you think that the need will manifest itself in the core or the edge first?

Where do we all think QoS has a role to play (or do we agree with Andrew Odlyzko that it shouldn't be there at all - bandwidth will do the job)?

I've stated my own opinion on this several times on these boards, but basically it's that the core should have little or no QoS, and therefore should be running at low contention rates. Most of the carriers I've spoken to seem to agree with this, and feel that they can exploit "IP Economics" by over-provisioning.

As you move out to the edge this becomes less true, for the obvious reason that you have exponentially more connections the further out you go. True over-provisioning just isn't economical.

So in the SP network QoS is important if they plan to offer "premium" services over the same infrastructure as "loss leader" services like Internet. The overall infrastructure can be run at a moderately high contention rate, and the economics work out.

But materialgirl hinted at my favourite question - where is the incentive for a WHOLESALE bandwidth provider to upgrade their network when the resulting additional revenues will simply go to the RETAIL SP? Right now the bandwidth is being sucked up by P2P, and nobody gets paid for any of it.

Interesting things that I saw this year...

- Cisco's acquisition of P-Cube. IP has a screwed up way of showing what application is running, and so Deep Packet Inspection and Stateful Inspection are really the only ways to crack the problem. In theory with wire speed classification in place Wholesale SPs could bill Retail SPs on a per-service basis and claw back some of that revenue to fuel infrastructure investments.

- Juniper's demo of Qos over ADSL at Supercomm. Basically an ADSL-attached client PC signalled the BRAS to create a prioritised connection for a given application, and this included an authentication (and therefore billing) phase. Early days, but an interesting direction to go in.

Tony Li 12/5/2012 | 1:14:12 AM
re: Juniper's TX Waits Its Turn your points about incremental growth (both the need from carriers and the historical failure by the industry to deliver graceful upgrade paths). I agree on both. But do you think that the need will manifest itself in the core or the edge first?

IMHO, the edge is far less painful to deal with because in most carrier architectures, there need to be numerous edge boxes anyhow. If you exceed the capacity of the edge box, adding another one in parallel is already part of the architecture and imposes no hardship.

This strategy is intractable for the core, as the core boxes are the focii of the WAN links which are non-trivial to replicate.

However, once you DO have incremental growth of the core boxes, I would expect to see consolidation of the edge boxes into the core, and thereby the eventual availability of incremental growth in edge capacity as well.

One box to rule them all,
myoptic 12/5/2012 | 1:14:07 AM
re: Juniper's TX Waits Its Turn Granted IP traffic continues to grow at 100%, but it is Logical Routing which will finally drive the need for multi-chassis systems. Traditionally, Cisco and Juniper have made out like bandits by advocating PoP architectures which look like a NYC subway map. Lots of single-function routers for edge, aggregation, peering, core, etc... and redundant for good measure.

Now carriers are getting fed up with the cost of this approach and demanding logical routing in which a single (highly scalable) routing platform can be partitioned into multiple logical routers each performing a separate task. The beauty of this architecture is that it preserves the network topology, but eliminates costly interconnects and provides a lot of flexibility to dynamically allocate ports among the logical routers.

It is early days, but Cisco, Juniper and Avici are all beginning to promote their Logical Routing implementations. Once logical routing takes hold, there had better be a way to grow beyond 8-14 useable slots!

volkot 12/5/2012 | 1:14:03 AM
re: Juniper's TX Waits Its Turn >Granted IP traffic continues to grow at 100%, >but it is Logical Routing which will finally >drive the need for multi-chassis systems

I am probably missing your point here.
MC systems have absolutely zero added value over non-MC except for the fact that they allow scalability beyond physical dimensions of one box. Now you are saying LRs will allow to have edge, core and peering routers sharing the same hardware. Why is this degree of separation still necessary if those LRs are not fully independent and restartable ? OTH, if you want LRs to be truly independent software entities, you are looking into putting significant overhead on the control plane, with MC case only getting worse due to the massive amount of software to run. Realistically, I do not think anyone designs routing engines under assumption they will ever run multiple concurrent OS instances.
Tony Li 12/5/2012 | 1:14:02 AM
re: Juniper's TX Waits Its Turn
I was under the impression that the point was simply the prelude to a full blown marketecture.

myoptic 12/5/2012 | 1:13:58 AM
re: Juniper's TX Waits Its Turn >Realistically, I do not think anyone designs >routing engines under assumption they will ever >run multiple concurrent OS instances.

I agree that a Logical Routing implementation which relies on a single routing engine to run multiple OS instances introduces serious scaling, security and complexity issues. The right way to design logical routing is with a dedicated route controller for each OS instance. This approach preserves the scaling, security and operational separation of discrete routers while providing the benefits of cut-through routing (no intra-PoP interconnects) and flexible port allocation.

<<   <   Page 2 / 2
Sign In