Not at all. Please provide data which would prove your "clearly" statement. Second I would say if there is any impact this is only implementation specific impact. In other words if your bgp implementation does not separate different address family processing, trie maintenance, allow for independent timers etc ... you may be right but I am not aware of any such implementation deployed anywhere so far :).
As a matter of fact a lot of today's mpls-vpn deployments use different set of relflector's hardware for vpnv4 routes plus are using default route for providing internet access for mpls-vpn customers so I don't really see how those SPs/ISPs would impact with mpls-vpns any ipv4 bgp Internet infrastructure or bgp stability. Total AF isolation can be also easily achived even for inter-as mpls-vpns as well with correctly architected design.
I'm referring more to the PE impact, or any other router that participates in unicast IPv4 peering. There's still a single BGP process, a finite amount of memory and CPU resources, etc.., and impacting any of these can adversely effect IPv4 route stability. Or does the separation you refer to suggest that we have no worries with BGP and route table growth, churn frequency, et al., and that it should be left to the academics? I fully agree that if dedicated infrastructure is employed for this purpose then there will clearly be less impact. However, the whole pitch is that existing network elements can be used to offer the service, the same network elements that provide "Internet" connectivity today -- and lots of folks have drank the kool-aide -- all in hopes of generating more revenue from their existing IP infrastructure, not new dedicated or overlay ones. Then every time someone brings up a scalability or convergence or security issue with BGP/MPLS VPNs a slew of Cisco folks tell them it's targeted at private networks and different infrastructures (hence the requirement for BGP, MPLS, etc.., I guess). Rob, I know how you & your cohorts feel, I was looking for operator feedback. Feedback especially regarding the "Security" document I referenced. As well, I felt that feedback on potential impacts to the global routing stability should be of relevance to the community (versus swept under the rug). -danny (who strives to only listen to the rest of this thread)