Router-gal: Why is it that routers are used in the core layer to network, can't switches be used?

Jeff_Doyle: Great question, and one that has been asked for years. The chief architects of one of the world's largest Internet carriers told me years ago that if they could get rid of all the routers in their core and build the whole thing with stacks of cheap, dumb, fast switches, they would. The reason that isn't happening is that you still need some intelligence in the core for security, CoS [class of service] and such. The popularity of MPLS is a reflection of this: Moving most intelligence to the edge and leaving the core to do (mostly) just high-speed forwarding.

RoutetoMe: So getting back to your expression of being a fan of single large areas vs. having multiple unnecessary areas. How exactly would you describe this? Is it a total number of routers and routes that would in the end determine how many areas in your networks?

Jeff_Doyle: Actually, the number of routers (the old "rule of thumb") in an area is a bit irrelevant; you can have hundreds; I've seen a thousand or more in a single area with no problems. The real issue is the number of links, the stability of the links, and the number of neighbor adjacencies.

Robert: Is using a Layer-3 protocol such as OSPF/ECMP to provide alternate paths and dynamic rerouting a reasonable approach in a large enterprise network? Or is a Layer-2 alternative a better approach?

Jeff_Doyle: My opinion is that Layer 3 routing is far better - really the only practical - means of dynamic redundancy in a network.

Security and voice

Dsingh: With voice being taken for granted as a key app over the network, the heat is on to make sure that packets get through with low latency. I've heard SP say and some vendors push for the fact that QoS is only a stop gap and the key is to add enough bandwidth in the core. Isn't that really pushing the problem to someone else's domain? I would have thought that queuing to smooth out peaks would be the solution, but then I keep hearing about queues getting synched and Armageddon. What are your thoughts about the QoS vs. Bandwidth debate?

Jeff_Doyle: I absolutely agree that queuing is not a long-term solution. Queuing is simply a means of, when a link is congested and "something" must be dropped, giving you control over "what" gets dropped. It's no substitute for sufficient bandwidth. However, good traffic engineering practices are an intermediate solution that ensures you are efficiently using all of your available bandwidth before going to the expense of adding more.

Robert: I believe VoIP will push the demand to have highly available enterprise networks. What architecture directions do you recommend to build a large, reliable enterprise network?

Jeff_Doyle: Architecturally, there's not much new. More importantly, and newer, is how you manage the network for availability. Being able to dynamically reroute traffic, change queuing, and understand what the loads and flows in your network are doing in real time. That's a huge challenge.

Dsingh: Jeff, with all the hoopla regarding L2 VPNs and pseudowire. Are there actual successful implementations that allow applications that make assumptions about LAN-like access to work across the underlying WAN?

Jeff_Doyle: Sure, L2 point-to-point service has been the quite successful for many providers. And gaining strength quickly is VPLS, which is really just point-to-multipoint L2 VPNs in a fancy dress.

Router-gal: I have heard flowspec mentioned lately. Can you talk a little about that?

Jeff_Doyle: FlowSpec is a means of quickly pushing BGP policies out to the edge of your network to reactively block DDoS traffic. It's becoming more and more in use by service providers and large enterprises using BGP. While we don't have the room or time to go into the details of how it works here, that's a great idea for a blog post! I'll try to write something on it in the next month or so.