Hi,
> [WEG] I think I need to clarify what we meant here - this is not
> saying that limiting which routes the PE imports based on which VRFs
> are configured is a bad thing. Rather, it is pointing out that this
> doesn't always help very much when considering how to increase scale.
> It it only helps if the same VRFs aren't present on every router. If
> the VRFs carrying the most routes are present on every PE in the
> network, they're being imported and carried in every PE, meaning you
> gain less value from the optimization. Yes, it's true that not every
> VRF is present on every router, but it often makes more of a
> difference whether the VRF has a large or small number of routes, and
> the provider has little control over it - in other words, it's a
> gamble. The comment about inconsistent routes from one router to the
> next is more about managing capacity and provisioning - as noted
> other places in the document, this is about trying not to strand
> capacity. This inconsistency means that it's one more scaling vector
> that must be tracked when determining the appropriate place to
> provision the next customer.
Actually this problem you are pointing out can be very well solved by
using draft-rekhter-l3vpn-virtual-hub idea. Then on any PEs you only
keep local routes plus pointer to the hub VRF where the actual lookup
will happen.
If you place such hub PE wisely (note that such hub PE does not need to
have sites attached to it) for example on the POP to core boundary your
scaling becomes much more deterministic as compared with today's model.
Further one could enable draft-ietf-grow-simple-va model for virtual hub
to even further scale data plane when you have large multihomed
sites in a VPN.
Best regards,
R.
