Faisal Khan is the author of the TelcoCloud Bridge blog, where this article was first posted.  He draws from his 14 years of experience working with a diverse set of operators across the Middle East and Africa region, including his current position with a leading mobile operator in the region. When he is not working, he loves to share his first- hand experience about the issues faced by telecom operators through his blog.

 

Are you a transport or a mobile backhaul operator with a goal to deploy easy to operate Ethernet transport solution based on MPLS-TP?

Do you know that you may run into potential surprises if you treat MPLS-TP as any other technology you evaluate?  In fact, not all systems are equal, and this is particularly true about MPLS-TP gear.

MPLS-TP hadn’t had a smooth sailing when it comes to standards. For long, the industry was divided between two camps of vendors supporting two different MPLS-TP OAM standards, with no consensus between them. Finally, the industry did reach an agreement on OAM standards, but on TWO parallel standards instead of ONE.

Furthermore, MPLS-TP vendors, broadly, come from two different backgrounds: Some come from a rich experience of the IP domain whereas others are more experienced with the transport technologies. This demarcation is clearly reflected in the features they offer.

Therefore, there is enough in the vendors’ offerings to confuse an operator who plans to buy MPLS-TP equipment.

Hopefully, this article will guide you with what to look for in MPLS-TP offerings, and help you ask right questions from a potential MPLS-TP vendor to avoid some come pitfalls. This comes from my experience of working with multiple MPLS-TP vendors. Therefore I am sharing this with a hope to benefit larger audience.

 

1. GUI based or CLI based?

GUI (Graphical User Interface) or CLI (Command Line Interface) based?

Well, you run a transport network, so you are already used to SDH like operation of  your system. Specifically, you are used to equipment and technology that is easy to operate, easy to provision and easy to troubleshoot.

Wait for surprises, then!

You will be surprised on how many MPLS-TP vendors out there can offer you transport like features.  While some do give you GUI interface to do all your everyday tasks conveniently; there are others who cannot go beyond CLI driven interface.

Imagine, a transport engineer is asked to write commands for simple provisioning of a point to point link. Worst still, all the troubleshooting calls for CLI commands. This would make operation pretty unfriendly for someone who is used to point and click/ GUI based provisioning and troubleshooting tools. Chances of using wrong commands or forgetting to activate some option are quite high, as my experience has shown.

Honestly, MPLS-TP should be an easy to use technology but the very CLI can make it difficult to operate.

So, why not keep CLI to a router itself? Since there are pretty skilled engineers, many of them “xCIEs”, who are well-trained/certified to operate routers.

If one brings router like operation to MPLS-TP, wouldn’t it make sense to bring router like skills for the operators, too?

Now, is there any certification in the industry that can certify MPLS-TP skills exclusively?  Not that I have heard of.

A counter argument might be, why not bring highly certified MPLS skilled engineers to run MPLS-TP. Isn’t MPLS-TP supposed to work like IP/MPLS, after all ?

Such strategy, in my view, would lead to increasing OPEX (read it as cost of hiring high skilled engineers). Whereas MPLS-TP is expected to bring down OPEX compared to IP/MPLS, here we are talking against the very spirit of this objective.

So, it is not only a question of GUI versus CLI or easy versus difficult. Ultimately, it boils down to OPEX issues, which should not be overlooked.

So a good starting question to ask your potential MPLS-TP vendors is,” Is your equipment GUI based or CLI based ?” and prefer a GUI based solution over CLI based solution.

 

2. Control Plane or No Control plane?

RFC5654 from IETF mandates that MPLS-TP MUST be able to operate WITHOUT using control plane with the ability to setup services using Management plane. Control plane, however, is optional and if used then it should be GMPLS based.’

Ironically, some vendors DO NOT fulfill this mandatory requirement of MPLS-TP with regards to static provisioning through NMS (Network Management System) . They use control/Signalling plane based on IP/MPLS (not GMPLS) to setup services.

Why is this question so important to ask?

Since you are used to configure transport pipes in SDH statically without any control plane using NMS and it is so easy to do it that way, why would you bother to change?

Transport network is all about predictability and manageability.  If a vendor needs control plane, it is an indicator that services are being setup dynamically.

Why would you worry about setting up services dynamically in point to point links or in a ring like architecture? I don’t see value of control plane in such simple scenarios.

Again, setting up LSPs dynamically might be an indicator of another factor-a weak NMS. In the absence of a feature rich NMS that can help in point and click provisioning of services, the vendor may be calling the control plan to rescue it in provisioning of services.

So make sure to ask this important question from potential MPLS-TP vendor and prefer “No control plane” over “Control Plane”

 

3. OAM of MPLS-TP (Y.1731 based or BFD Based)?

There are two camps here, one supporting Y.1731 based OAM and others support BFD based OAM. Of late, both are standardized by ITU-T under G.8113.1 and G.8113.2 respectively. However ITU-T was originally supporting the Y.1731 version while IETF supported the BFD version.

So, which tool set is better for you?

There is nothing wrong with any OAM standard.  Each one can work for you. Y.1731 is more mature and comes from the mature ITU-T standard for Ethernet OAM i.e.Y1731. BFD is a newer standard for MPLS-TP and was driven by IETF. BFD is supposed to make the interworking between MPLS-TP and IP/MPLS easier.

Honestly speaking, the concept of end to end OAM including both MPLS-TP and IP/MPLS is easier said than done. There is still a lot of activity going on with respect to refining different models for interworking between MPLS-TP and IP/MPLS. However this interworking does work with special cases as shown by public interoperability tests conducted by EANTC.

If you are primarily using MPLS-TP for Ethernet transport with no relation/interconnection to IP/MPLS network, it does not matter which OAM you select.

However, if you plan to deploy MPLS-TP to interwork with IP/MPLS, now, or in future, I propose to go with the BFD version (since Y.1731 is not designed to support this kind of interworking). If you are not sure about future plans or direction, your best bet is to go with BFD.

 

Conclusion:

As you can see above, MPLS-TP products do not give consistent features. Vendors, sometimes, do not tell about these features, especially 1 and 2 above until you probe more. Point 3 is more of a strategic decision you need to make while choosing product.

In all cases, I am highly recommending to run a Trial/Proof of Concept with the product to make sure that you see the product live in action and you get a true feeling about the product. Remember you are a transport operator and you better get that “transport” feel of the product and do not run into surprises once the equipment has already landed in your network.

Now it’s your turn to tell me, what would you further ask from your potential MPLS-TP vendor before making buying decision  or what do you think about the points I have brought up whether you are a vendor or buyer.