MPLS Requires Custom Silicon. Really?
I heard the following pretty bold statement while listening to an episode of my favorite podcast: “Bringing MPLS into the data center is impractical because MPLS requires custom silicon.” Really? How about checking the Intel FM 6000 product brief first?
Broadcom Trident chipset supposedly also supports MPLS. I couldn’t verify that because Broadcom considers the capabilities of their hardware highly confidential (but if you know more, do write a comment). Absolutely refreshing for a chipset that you get in almost every ToR switch you buy.
Can we thus expect to see MPLS in ToR switches
Not likely for a number of reasons:
- Customers are not asking for MPLS. Most enterprise data center engineers tend to avoid it like a plague, and large cloud providers focus more on overlay networks, obviating the primary need for DC MPLS (although I was told one of the largest web content providers uses MPLS extremely creatively pulling it all the way down to individual web servers).
- Due to lack of customer requests, MPLS is not the primary focus of merchant silicon vendors. Even though FM 6000 supports MPLS, it needs TCAM to match MPLS labels wasting precious hardware resources – the more MPLS labels a switch supports, the fewer ACL or PBR entries it could have.
- MPLS data plane is easy (how hard is it to swap 32-bit labels?), the tricky part is the MPLS protocol stack (LDP first, then MPLS TE or MPLS/VPN), and not every vendor has one.
I totally agree (as I wrote before) that it’s highly unlikely MPLS will replace overlay virtual networks as the next-generation network virtualization technology (service providers integrating their public cloud with their MPLS/VPN service might be an obvious exception – or so Juniper and Nuage Networks hope), but please don’t claim it’s due to lack of merchant silicon support.
And I couldn’t resist mentioning …
If you need to learn more about MPLS, you will find more information in my Enterprise MPLS/VPN webinar and MPLS/VPN books.
finally, i would recommend a review of the latest segment routing drafts and a bit of pondering about how you can build very large networks out of relatively modest LFIB enabled devices with segment routing at your disposal. you don't necessarily need LDP and RSVP to get the job done in an SR domain.
48x10G, 6x40G
32x40G
Entropy label? You have to wait for that.
Scaling? Well, it's reasonably good on recent chipset (TD2 mainly), it's just a matter of where you want that box. Honestly, if you're not a Tier1 SP (or similar), they usually are good enough.
This is were Custom ASIC still have an edge. But even without a high focus from Broadcom, scaling is increased at each generation and will finally be no more "an issue", and features are also added. Not sure MPLS will continue to add rich new features, so soon enough, no more discussion here.
That being said, as mentioned, swaping label is not a challenge. You'll be linerate on your Tbps+ switch.
Control Plane is all about the software. But don't assume to have the same features on the merchant silicon based switches with a vendor that has custom ASIC dedicated to MPLS (SP) also on their portfolio. You have to adapt the code, it's not trivial.
But I'm not saying merchand silicon is better than custom ASIC. The latter one gives you opportunity to do greater things, to give more control, capability on any kind of protocol where a merchand silicon will limit you up to the next gen.
The moment Vyos codes MPLS features (LDP, TE, VPN) then watch vendors completely lose their stuff.
Hell, it's almost damn near free right now. Mikrotik RouterOS does it for 45$. I'm pretty sure it'd be REAL easy for them to get one of these chipsets and convert it to use RouterOS.
What it ends up coming down to is that no vendor wants to release a device that can do all MPLS related features for cheap because it will completely destroy their more ROI products (the more expensive products) and therefore they'd make a lot less money.