Hi 1) control plane (route reflectors ) - you can either run a separate control plane infrastructure for inet vrf or you can use common RRs that depends on your hardware capabilities (or you can run a separate BGP process for reflecting inet vrf). - no need to worry about data-plane as VPN routes are not installed into FIB on RRs. - as it was mentioned already porting inet prefixes into VPN table increases control-plane demands. 2) forward plane (recursive lookup issues) - for inet vrf I'd recommend per CE/next-hop labels instead of per prefix labels to save up some label space. - per next-hop label still points directly to outgoing interface so no recursive lookups. - recursive lookups are only needed with per VRF label -but I would not recommend that as it could introduce loops when PIC is used in some scenarios. 3) Operational - I find it operationally complex to keep inet table on the P-Core boxes/vrf-default. 4) DDOS - as I mentioned you can run a separate infrastructure for inet vrf i.e. dedicated box or SDR for inet PEs and inet RRs. - or you can use separate BGP processes so in case some university decides to test some special attribute on their BGP advertisements it will not reload your VPN BGP process. - or you can deploy enhanced BGP error handling on the edges and hope for the best (actually this is what should be implemented as a first thing). adam