Advanced Carrier Supporting Carrier Design

LDP is the most commonly used label distribution protocol in today MPLS networks. Although it lacks of Traffic Engineering, Admission Control, Fast Reroute capabilities, it scales very well because of its Multi Point to Point Label Switched Path.BGP can also assign a label for the IP and also for the VPN prefixes and in this article I will show you how BGP provides extra level of scalability for the MPLS applications.

LDP can also be used to setup a targeted LDP session which is used by many applications such as L2VPNs, Remote LFA Fast Reroute, LDP over RSVP to scale RSVP networks and so on.

In this post I will explain the differences if you use IGP + LDP and the BGP + Label for the IP prefixes.

I am explaining this topic in deep detail in my Onsite CCDE  Live/Webex CCDE  and  Self Paced CCDE  course.


BGP can assign a label for the IP prefixes and it is defined in RFC 3107 and you should know that that is different than assigning a label for the VPN prefixes. For example BGP assigns a Label for IP or Ethernet VPN prefixes in  MPLS Layer 3 VPNs and EVPN/PBB/VxLAN EVPN.




In this above picture, I show you a Carrier Supporting Carrier Architecture. The carrier which is also a VPN provider receives an MPLS Layer 3 VPN service from the another carrier which is called Backbone Carrier.

In the topology, between CSC-CE1 and CSC-PE1 is running IPv4+Labels. That label can come from LDP , RSVP or BGP. if a vendor doesn’t support any of the labeling protocol , that is the vendor’s problem not the technology limitation.

In this setup, you can use IGP + LDP in one site between CSC-CE and CSC-PE and you can use BGP-LU ( RFC 3107 ) in the other site. We just need at the end, end to end LSP.

The definition of end to end and the places of the ” ends ” depends on what service Customer Carrier provides. If Customer Carrier provides a VPN service ( L2 or L3 ), then you need to have an LSP between PE-1 all the way up to PE-2.

If the Customer Carrier provides only Internet Service ( it doesn’t have to run MPLS then in its network ) then LSP should be between CSC-CE1 and CSC-CE2. This mean, on the Carrier interconnect links ( CSC-CE1 – CSC-PE1 , CSC-CE2 – CSC-PE2 ) MPLS has to run.

The purpose of running in any case an MPLS on those links is to hide the external prefixes from the backbone carrier. If you don’t run an MPLS on those links, CSC-PE devices receives a pure IP packet ( without any MPLS tag ) so they have to perform an IP lookup. Since they don’t know the external prefixes they just drop the packet. If you don’t know why they don’t know the external prefixes and the basics of Carrier Supporting Carrier Architecture, please read my this article.

But what is the benefit of running IGP + Label or BGP + Label ( RFC 3107 )  ?

If it is LDP then you need to run IGP on the CSC-CE – CSC- PE links. If you run an IGP,  all the IP prefixes ( Loopbacks and generally the infrastructure prefixes as well ) has to be leaked between the Customer Carrier sites.

You cannot aggregate it unless you are using RFC 5283. RFC 5283 allows you to aggregate the reachability information and still have an LSP for aggregated FEC.

So if many sites are connected with the CSC service , scalability might be a problem for the customer carrier.

If you use BGP to run an MPLS between the Customer and the Backbone Carriers, then you can carry the loopbacks over the BGP and labels are assigned for the loopbacks by the BGP. ( This is similar to Seamless MPLS right ? Yes that’s correct ).

Within the Customer Carrier sites for the internal label assignment ( VPN or maybe FRR purpose ) you can run an MPLS with LDP and the on the CSC-CE – CSC-PE links BGP + Label. But that’s not make sense since you need to redistribute to loopback address of the remote sites from BGP into IGP in the local site.

If the reason was to scale the solution from the Customer Carrier site that’s why you choose the BGP , you don’t want to redistribute all the remote IGP prefixes from BGP into local IGP.

But the reason to run BGP + Label might be a totally different. Backbone Carrier may not be providing an IGP as a PE-CE protocol. At the end Carrier Supporting Carrier is just a MPLS VPN service from the Backbone Carrier point of view.

If you have BGP + Label on the CSC-CE – CSC-PE links , you want to continue to advertise the remote loopbacks over BGP because the above reasons. ( You don’t want to loose the scalability ). In that case if you are running BGP Route reflector to scale the BGP domain in any of the Customer Carrier sites, choosing a CSC-CE devices as BGP Route Reflector and changing the BGP next hop on those devices provides additional scalability and provides most optimal route selection ( Otherwise BGP Route Reflector would hide the some paths due to Hot Potato ).


To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Perspective” Book. It covers the SP network Technologies with also explaining in detail a factious SP network.  Click here

4 Replies to “Advanced Carrier Supporting Carrier Design”

  1. Thank you orhan for the sharing,
    as already said in the previous CSC article,this solution is not much deployed because it is considered as a complex solution and there are other solutions that simplifying the engineer’s life.
    and i asked myself a question when the CSC could be the ideal solution ? as an answer i think the CSC will be the most scalable solution when you deal with a big customer (more than 1000 site) who want to have some level of separation between departement using VRFs.
    using CSC has the following advantage:
    the SP will use only one VRF for reachability and advertising only loopback interface for CSC CE
    the customer will have the control of creating as many vrf as he need and he wont depend to service provider
    is a win win relationship
    what do you think ?

    1. Hi Driss,

      No actually. If customer has 1000 sites and multiple VRF , Backbone Carrier would require multiple VRF as well.

      But in CSC architecture , customer connection from the global block , so customer want to have an overlay connection over the Backbone Carrier.

      It is not suitable for large amount of sites at all.

      Small amount of sites which have external connections ( And lots of routes , maybe VPN customers or full Internet table ) would be suitable.

      If Backbone carrier is creating different VRFs and each VRF holds every routes from the customer carrier then it is just a plain L3 VPN service.

      For the 1000 sites and multiple VRF, Layer 2 services are better fits. Depends on the topology of the customer , carrier provides either Routed Multipoint ( MEF E-Tree ) or if it is any to any then VPLS of IETF ( MEF Multi point to multipoint ).

      When customer receives for its 1000 sites from the carrier, it can either create multiple VRF which can be complex operationally or customer can implement MPLS to scale ( it doesn’t come for free of course but this is a long discussion )

      Hope it is more clear ?

Leave a Reply

Your email address will not be published.