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 don't believe anyone's suggesting that. Full Internet routing tables, unicast IPv4 BGP peering over RFC2547(bis) networks should be done between peers directly, and not with the PE (there's really no reason for the PE to participate in this, all the PE needs is a path to get to the CE and the other PE, and vice versa). So, you do peer with (or import static from) each CE attached to a PE. Per VPN, how many summarized routes are you going to get? a dozen? two dozen per VPN tops? With the average being much less, right? So, a couple of thousand VPNs add a couple of thousand or so more routes in the BGP (counting everything as VPNv4 addresses) don't add all that much grief, or do they? Now, keep in mind that again, all the PE-CE peering needs to pass is enough routes for the CE-PE-PE-CE communications (and the various iterations with n peers) to occur. If CE's peer with BGP, they would exchange routes directly with the other CE in the VPN via eBGP multihop. Otherwise, it's whatever the IGP summarizes and passes to the PE. Maybe I'm missing something here, but that's how I see the world, and I'm not sure this is such a big deal. The work we've done in this area in the past confirms that. It's a tool. And if you decide to blow one or both of your feet away, it's your choice. But there's nothing that says that's the only way to use the tool, or the only reasonable or least ops pain to use the tool. Cheers, Chris -- Christian Kuhtz <ck@arch.bellsouth.net> -wk, <ck@gnu.org> -hm BellSouth Internet Services, Atlanta, GA, U.S. Sr. Architect, Engineering & Architecture "I speak for myself only"