If I input MPLS traffic engineering on any search engines, I will find about 100 articles on the internet providing the same explanations about MPLS traffic engineering.
But unfortunately, nobody ask these questions: do I really need it? What are the reasons behind the implementation of MPLS Traffic Engineering?
Would it worth the time and energy to deploy and learn such a complex technology if there are many easier, resource-friendly alternatives.
In this article, I will explain all the answers to these questions. Undoubtedly, MPLS traffic engineering has many used cases and it helps to solve numerous problems in an MPLS enabled networks.
These used cases include QoS guarantee, end-to-end SLA, fast reroute, admission control, and so on. In the end, all of them are used for reducing cost. The prime advantage of leveraging MPLS traffic engineering is to save cost, not to implement a fancy technology. This advantage also applies to IP Traffic Engineering.
Sometimes network-design experts forget the chief benefits of these technologies, compelling themselves to make it work on any networks even though they could find an easier, simpler, flexible, scalable solution. After all, network-design experts don’t need to focus on the business aspects. In this article, I will show you a couple of alternatives for traffic engineering. After that, I will explain why you don’t need MPLS Traffic engineering for the link bandwidth utilization.
Traffic Engineering Fish Diagram
I will use this good-old-fish topology (as shown below) to explain the reasons behind MPLS traffic engineering.
Given the topology above, if the cost is the same between all routers, top path from R2 to R5 will be used because it is 3 hops; bottom path will not be used at all since it is 4 hops.
IP unicast traffic would follow the top path, since multicast would follow the unicast routing table with PIM. To find the source or rendezvous point for its tree, IP multicast would use the same top path as well. Next, you need to do traffic engineering to send unicast from one link to another link.
What’s more, you need to send multicast from the other link for the better utilization of IP traffic engineering.
Also, with multi-topology routing, you could send IPv4 traffic from the top path by using the lower metric on the top path for the IPv4, and IPv6 traffic from the bottom path by using lower metric between the routers on the bottom path.
Another approach for the traffic engineering is MPLS traffic engineering. It has an admission control capability – at least – at the control plane so that you can reserve bandwidth, thanks to RSVP-TE. Although you can still send traffic at the dataplane more than at the reserve bandwidth for the LSP, admission control will not allow new LSP creation if you allocate all the bandwidth for the LSPs.
Would you really need MPLS traffic engineering to solve the link utilization problem? Unfortunately, the answer is NO.
If you could just assign the metric correctly on the fish topology (as illustrated above), you could get ECMP (Equal Cost Multipath) between R2 and R4 so that both the top and the bottom path would be used at the same time.
In large-scale networks, finding an ECMP path between each source and destination job is done by offline tools such as Cariden MATE.
Network design refers to the process of finding an optimal solution to the requirements given by clients. Business owners want to save cost, so underutilized link is tantamount to wasting money. In sum, MPLS traffic engineering might seem an attractive solution but when you have easier, simpler solution that does not require additional protocol, you will have a better network design. The difficult task is finding those better solutions.