Service providers in general seek to better utilize their infrastructure resources utilization in order to raise the convergence in a way the positively reflect on their service offerings.

    One of the features to consider is what so called Route Target Constraint (RTC) which can assist in MPLS VPNs environment.

    Let us have a look at the below diagram which we will use for demonstration and analysis.

    RTC and ORF1.png

    In this simple network, we can see a service provider network consists of a route reflector (for VPNv4 prefix advertisement in our particular case) and three service PEs which handle specific customers.

    The first PE is serving three customers, two of these customer have branches connected to PE2 and PE3 respectively (assuming isolation of the third customer in our scenario).

    What will take place in this case is that the MPLS RR will accept the VPNv4 prefixes for the three predefined VRFs and will advertise it to PE2 and PE3 knowing that each one of them is handling specific customer, i.e. there is no need for some prefixes to be advertised in the first manner.

    PE2 cares only for VRF1 traffic which is associated with a specific RD and respectively the proper route-target value for control.

    Once the prefixes (for VRF2 and VRF3) get to PE2 (in case of PE3 it will be VRF1 and VR3), the prefixes will be denied due to missing import route-target and the prefixes will be dropped.

    The above mentioned behavior is called Automatic Route Filtering (ARF).

    RTC and ORF2.png


    Assuming that we are deploying Internet access for MPLS L3VPN service, what will happen if the advertised prefixes from the RR toward the service PEs represent full routing table? That for sure will affect resources utilization and could bring some downtime, delay or any other design constraint that will negatively affect the overall performance and which will somehow relates to CapEx of the service provider.

    Now RTC comes into play, what RTC really do is that it advertises the route-target values as prefixes after activating the proper BGP session under the address-family of concern (rtfilter unicast).

    So, we have to define extra BGP session on all the participating MPLS P/PEs in order to bring up the functionality of the feature.

    What will happen in this case is that RR will not even advertise the unneeded prefixes (which belong to different VRFs) to the MPLS PEs, it will advertise only the prefixes of concern per the existing customer/VRF.


    RTC and ORF3.png


    What about another feature called BGP Outbound Route Filtering (ORF)?

    Before talking about it, let us ask some questions before.

    Can the customer filter prefixes coming into its side from the service provider side? Yes, it can but this will impact the BW of the circuit/link and it will increase management burden in case the number of prefixes to be filtered out is remarkable.

    Can the service provider filter out the prefixes? Sure it can, but this will be out of control for the customer as it need to consult the provider for any prefix to be manipulated and this will raise dependability which will not be appreciated in many cases.

    What ORF do is it advises the other end (which in our case is the service provider) to apply a certain prefix-list (filter) which is already predefined at the customer premises at the service provider side without traversing the link which will preserve bandwidth.

    This will be achieved by activating a capability (not a new session) at both ends of the connection, like an agreement.




    So, the same goal was achieved by the two features, but let us look at the below table in order to present some differences in regard to design considerations.


    Comparison Table.png