When you need to be conscious about your MPLS router’s control plane resources, RFC 4684 Constrained Route Distribution for BGP/MPLS IP VPNs (RTC) is a no-brainer. RTC is a BGP address-family that allows operators to prevent their route-reflectors from sending unimportant routes.
Lets take a look at the topology and review what a standard MPLS network might look like.
When the PE router initiates the BGP session with the RR, they will start exchanging routes as expected. In a sufficiently large network, this is hundreds of thousands or millions of routes. All those routes get sent whether or not the PE is going to need them; the responsibility of which routes to keep rests on the shoulders of the PE.
To determine if a route is kept, the PE router is going to analyze all the routing-instance VRF import policies and place received routes with matching route-targets in the bgp.l3vpn.0 routing table. Then routes are copied into their respective routing-instances routing tables.
So, if the receiving router is already filtering routes that aren't going to be used to prevent further processing, what more can we improve on? Well, what if we simply don't send routes that aren't going to be used?
For obvious reasons, the RR doesn't know if it is exporting a route that is going to be dropped by the PE due to routing policy or unresolvable next-hops. However, we can tell the RR what communities we have locally configured to import into our bgp.l3vpn.0 table which means we can skip an entire step in the process and potentially prevent the processing of millions of routes.
To enable BGP RTC, add the following configuration:
# RR
set protocols bgp group [group] family route-target advertise-default
# PE
set protocols bgp group [group] family route-target
This configuration is going to add an additional auxiliary table called bgp.rtarget.0 where the router can advertise and receive communities that enable the peers to only send what the local PE plans on processing.
The route reflector is going to tell the clients to send it everything
But the improvement here is that the PE can now signal what it wants from the PE router by advertising the route-targets it has configured.
This optimization may not seem like much, but consider that various triggers exist that could cause the route-reflector to send all the routes (potentially millions) to the PE router. Also consider that the PE router could exist only for a single customer L3VPN and may not have the significant control-plane resources your standard PE router may have.
Sources