It is a best practice to follow unique per-VRF/ per-LSR Route Distinguisher to allow load-balancing for dual-homed customer sites (when dual-homing is to two separate PEs).
Let's say you have a large customer which connects to many PEs and you follow the per-VRF/per-LSR approach for him. For the ease of deployment you choose RD to be in a format of
IP Address:Value when IP Address is a loopback address used for BGP update-source. Loopback IP address is different on each LSR. Value could be a running number from 1 to max. If you make sure that Customer VRF gets a different Value on each ingress/egress LSR, you will get completely different RD each time.
Now let's say you have LSRA that gets MP-BGP updates with Customer prefixes from many other LSR. Since RDs on the incoming updates will be different from RD assigned to Customer VRF on LSRA, LSRA will import the prefixes into proper Customer VRF and also place them into Null BGP table (Null VRF), this is per normal behavior.
Customer routing will work OK, but with many prefixes received it will cause huge memory consuptions because each prefix will be saved twice. Now take into account many Customers working in this manner...
How do MPLS/VPN Service Providers deal with this? Maybe they do not follow unique RD on a per-VRF/per-LSR bases for all the Customers...
while agreeing with Paresh, I would like to add another point of view. From a customer perspective load sharing might be attractive - my experience is in fact, that it really is (for whatever reason...).
So the feature can be used as a service differentiator for the SP.
As you already pointed out, the need for memory will double (at least) on a PE. But memory is not always a limiting factor, but number of interfaces and CPU etc.
And while a PE today has 256 or more MB RAM, an average customer with less than 1000 routes does not really create a memory hog. So in brief: utilizing more memory is not such a strong argument that I would skip the whole feature in my opinion. But every SP has to make his own decision.
This document is an early notification of a behaviour change that will be introduced in IOS XR release 6.5.
IOS XR configuration principles relevant for this article are:
On router platforms all interfaces must be by defaul...
With XR 4.2.0 the ASR9000 is releasing a new line of hardware models. This amongst others is the RSP440, the next generation RSP with faster switch fabric along with Typhoon based Linecards, the next generation network processor.
The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application ...