Building CsC-enabled MPLS backbone
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).
And you probably know where to find more information about CsC architecture – three guys wrote a great sequel to a great MPLS/VPN book a while ago.
L3VPN might have been there first, or at least it used to be/is the most popular one, but we really had to get it out of our system by now :)
The official name of the technology we're talking about is "BGP/MPLS IP VPN". I guess I'll stick with MPLS/VPN, maybe explaining every time that I actually talk about RFC 4364 :-E
The funniest part of CsC is that it's actually a single command (either to enable LDP or send labels with BGP), but the configuration guides describing that single command are 50+ pages long (yes, there are two of them, one configuration guide describing "mpls ip", the other describing "neighbor send-label" :-P )
CSC also seems to carry a very different service definition in the mind of the largest telco's. While all definitions include running LDP (or at the very least swapping labels on customer interfaces in a VRF) the routing protocol and thus design of the service differ.
Some (like Sprint) want to run LDP with an IGP such as IS-IS to do label exchange and LSR prefix reachability.
Others (like ATT) will only configure a static solution thus preventing dual provider multihoming for a CSC customer.
I have heard about one provider in EMEA that performs BGP peering with label exchange which most other providers consider too dangerous.
So while all of them acomplish the same thing (getting labeled packets to PEs that are customer controlled) by functioning in different ways carry very different configurations and operational headaches. Ever do inter-provider VPN label troubleshooting?
The other consideration is that even without widespread CSC support, many customers are building their own MPLS services over provider networks. There is the payment processing giant FDC I mentioned before running 2547overDMVPN, a voice processing company running MPLS over L2 VPN (VPLS), and financial services such as citi just operating overlay VPNs on top of L3 VPN's. Overlay VPN technology like DMVPN or GETVPN work well when you dont want to expose internal routing to your service providers.
Supposedly there was an MPLS over IP encap standard being written as well to address the headache of CSC, by making the L3 cloud in the middle completely agnostic and unaware of routing other than the connected endpoints.
K.
PS. In regards to those books, I hear one of those authors is a grumpy and crotchety old man who doesnt like anything. This has not been my experience tho.
PPS. Also in regards to those books, read them from cover to cover. That way you wont miss a key concept that has you baffled. The answer was right on page 34 in a highlighted "NOTE" section. GRR!
Because you were never trying to sell me sexier heptagonish wheels ;)
It can be used if a MPLS-VPN Backbone is used to interconnect the POPs of an IPv6 Internet Service Provider. The IPv6 ISP can share the full IPv6 Internet routing table with a BGP session which get through the MPLS-VPN backbone but thanks to CsC, the MPLS-VPN does not have to learn the IPv6 Internet routes. The MPLS-VPN only carries the IPv6 ISP Infrastructure routes but not the Internet route.