When I refer to problem as it relates to 'any-to-any', I am talking about the N-squared scalability problem of full-mesh peering of multiple customer routers over a traditional FR or ATM backbone. Any new site that a customer will want to add to such a backbone will require that the customer order many more virtual-circuits and then create a whole slew of new peering sessions. Clearly you can understand why this is a problem. L3 MPLS VPN's eliminate this N-squared scaling problem because customer routers no longer have to peer with other customers routers, they peer with a VRF on a provider router. This is the only clear advantage that L3 MPLS VPN's hold over other solutions.
But the real question is how many customers really have any-to-any peering? I'm not talking about peering within the provider, I'm talking about customer peering. For example, how many customers really have lots of branch offices that actually communicate with each other a lot, enough to justify any-to-any peering? At this time, almost none. Most customer networks are set up such that most of the WAN traffic consists of traffic from a branch office to a main "headquarters" office, and branch office to branch office traffic is low. Therefore, most customers really only need a hub-and-spoke model of peering.
So my point is, the advantage of L3 MPLS VPN's consists of eliminating the problems of customer any-to-any peering. But right now, how many customers really have this problem? Very few. So if you provide this service, how many customers will really want to order it? I regret to say that the answer will probably be very few. Your company will certainly find it difficult to earn high profits from such a service, because the fact is, the service doesn't really provide anything that most customers can't get already get by ordering a different service.
And the problems of L3 MPLS VPN's are well documented. Basically, you are taking partial responsibility for customer routing, which is a very dangerous thing. For example, what if one of your customers accidentally imports the entire BGP table and then propogates it to one of your PE's? Almost certainly, your router will crash, which takes down every customer attached to that PE. Or what if a customer's network is unstable? This will mean that the PE's VRF route table will be unstable which is very stressful for that PE. Things like that. So basically you end up with all these problems with linking your routers with a customer's routers, so any problems that a customer is having will become your problem also.
Which is why I'm much more enthusiastic about the L2 MPLS VPN's, which is simply providing L2 services like FR, but using IP and MPLS in the core of the provider. For example, Cisco's martini-draft implementations in its AToM technology. Or Juniper's kompella or martini-draft implementations. Either way, you are no longer linking the provider's network to the customer's network. If a customer's routing is having problems, it doesn't affect the provider's network. As long as you are properly providing L2 connectivity, your job is done. If the customer's routing is broken, it is not your problem because you are not responsible for providing routing services.
