Nosx added a very valid point-of-view to the MPLS/VPN Common Services Design that uses a shared common service Route Target across numerous client VRFs:

This is an overly complex and unsupportable approach to shared services. Having to touch thousands of VRFs to create a shared services VPN is unacceptable. The correct approach is to touch only the "services" vrf, and import/export to each RT that you wish to insert the services into.

As always, the right answer is “it depends.” If you have few large customers, it makes way more sense to add their RTs to the common services VRF. If you have many small customers, adding RTs to the common services VRF does not scale.

Ignoring for a moment the great fun you’d have trying to troubleshoot an MPLS/VPN network where some BGP routes have hundreds of route targets (so much for supportable), you’re bound to hit some hard limits as you increase the number of customers.

Route targets are propagated around the network as extended community attributes attached to BGP prefixes. You get the first hiccup when you have around 100 route targets attached to a route: extended community attribute gets too large and cannot fit into small buffers any more. Every router receiving the BGP update will generate a syslog message like this:

%BGP-6-BIGCHUNK: Big chunk pool request (832) for extcommunity. Replenishing 
with malloc

Around 500 route targets, the BGP path attributes (primarily the extended community attribute) will get larger than the maximum size of the BGP UPDATE message (4096 bytes, specified in the RFC). At that moment, the originating router will refuse to send the update and every other PE-router will lose the routes to the common services VRF:

%BGP-5-BGP_MAX_MSG_LIMIT: BGP failed to send update message because the 
message size reached bgp maximum message size 4096.

I’ve tested the limits with IOS release 15.0M. Not sure whether older releases would degrade as gracefully as 15.0M does.

Conclusion: the theoretical limit of the “add customer RT to CS VRF” design is 500 customers.

Does it matter?

Common Services VPN topology is hard to use in typical service provider networks as it requires non-overlapping customer address space (as Nosx said: “It created far more problems than it solved, and better solutions (more secure, more scalable, more managable) are available now”).

It still has some utility in environments with coordinated address space (large enterprise/governmental networks) as described in my Enterprise MPLS/VPN Deployment webinar.