internet routing table in a vrf

[adam.vitkovsky at swan.sk (Adam Vitkovsky)]

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