Just got this question from one of my Service Provider friends: “If I am building a new MPLS backbone from scratch, should I design it with Carrier’s Carrier in mind?” Of course you should ... after all, the CsC functionality has almost no impact on the MPLS backbone (apart from introducing an extra label in the label stack).
Carrier’s Carrier architecture looks complex and scary (your customers can build their own MPLS/VPN networks on top of your MPLS/VPN service), but needs just a single feature on top of baseline MPLS/VPN architecture: LDP between PE and CE routers.
In traditional MPLS/VPN architecture you run IGP (or EBGP) between PE routers and CE routers and send IP packets across PE-CE link. CsC adds the ability to run PE-CE LDP, exchange labels for MPLS/VPN routes and send labeled packets across PE-CE link.
The LDP label advertised by the PE router is stitched to the label remote PE-router advertised over MP-BGP, building an LSP from the CE-router to remote PE-router. Likewise, the MPLS/VPN label advertised by the PE-router through MPLS/VPN gets stitched to the LDP label advertised by the CE-router, building an LSP from remote PE-router to local CE-router.
If the customer continues to run pure IP, you’ll still have just two labels in your MPLS core (MP-BGP label on top of LDP label), but the LSP extends beyond PE-routers, which can be useful if the customer wants to implement BGP-free core. CsC architecture also allows your customers to implement layered QoS – they can control both the Traffic Class (former Experimental) bits in the MPLS label and DSCP bits in IP header.
All of the PE-CE functionality is totally invisible to your P-routers. However, if the customer decides to offer MPLS/VPN service on top of your MPLS/VPN service, you’ll see an extra label in your MPLS core – the only precaution you have to make in your network design is to use larger MTU size (add at least 20 bytes – 5 labels – to the maximum MTU you want to support).