Are you asking these Questions from potential MPLS-TP Vendors?

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 can not 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) ?

 

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.