Are you a transport or a\u00a0mobile backhaul operator with a goal to deploy easy to\u00a0operate\u00a0\u00a0Ethernet\u00a0transport \u00a0solution based on MPLS-TP?<\/p>\n
Do you know that you may\u00a0run into potential\u00a0surprises\u00a0if you treat MPLS-TP as any other technology you evaluate.\u00a0 In fact, not all systems are equal, and this is particularly true about MPLS-TP gear.<\/p>\n
MPLS-TP hadn’t \u00a0had a\u00a0smooth sailing when it comes to standards. For long, the industry was\u00a0divided between two camps of vendors\u00a0supporting 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.<\/p>\n
Furthermore,\u00a0MPLS-TP vendors, broadly, come from two different backgrounds: Some come from a rich experience of the IP domain whereas others\u00a0are more experienced with the transport technologies<\/a>.\u00a0This demarcation\u00a0is clearly reflected in the\u00a0features they offer.<\/p>\n Therefore, there is enough in the vendors’ offerings to\u00a0confuse an operator who plans to buy MPLS-TP equipment.<\/p>\n Hopefully, this\u00a0article will guide you with what to look for in MPLS-TP offerings, and help you ask<\/a> right questions from a potential MPLS-TP vendor to avoid some come\u00a0pitfalls. This comes from my experience of working with multiple\u00a0MPLS-TP vendors.\u00a0Therefore\u00a0I am sharing this with a hope to\u00a0benefit larger audience.<\/p>\n GUI (Graphical User Interface) or CLI (Command Line Interface) based?<\/p>\n Well, you run a\u00a0transport network, so you are already used to SDH like operation of\u00a0\u00a0your system.\u00a0Specifically,\u00a0you are used to equipment and technology\u00a0that is easy to operate, easy to provision and easy to troubleshoot.<\/p>\n Wait for surprises, then!<\/p>\n You will be surprised on\u00a0how many MPLS-TP vendors out there can offer you transport like features.\u00a0 While some\u00a0do give you GUI interface to do all your\u00a0everyday tasks conveniently;\u00a0there\u00a0are others who can not go beyond CLI driven interface.<\/p>\n Imagine, a transport engineer\u00a0is asked \u00a0to write commands for\u00a0 simple provisioning of a point to point link. Worst still, all\u00a0the troubleshooting calls for CLI commands. This would make operation pretty unfriendly for\u00a0someone who is used to point and click\/ GUI based\u00a0 provisioning and troubleshooting tools. Chances of using wrong commands\u00a0or forgetting to activate some\u00a0option\u00a0are quite high, as my experience has shown.<\/p>\n Honestly, MPLS-TP\u00a0 should be an easy to use technology but the very CLI can make it difficult to operate.<\/p>\n So, why not keep CLI to a router itself?\u00a0Since there are pretty skilled engineers, many of them “xCIEs”, who are well-trained\/certified \u00a0to operate routers.<\/p>\n If\u00a0one brings router like operation to MPLS-TP,\u00a0wouldn’t it make sense to bring router like skills for the operators, too?<\/p>\n Now,\u00a0is \u00a0there\u00a0any certification in the\u00a0industry\u00a0that can certify MPLS-TP skills exclusively ?\u00a0 Not that I have heard of.<\/p>\n A counter argument might be, why not bring highly certified MPLS skilled engineers to run MPLS-TP. Isn’t MPLS-TP\u00a0supposed to work like IP\/MPLS, after all ?<\/p>\n Such strategy, in my view, would\u00a0 lead to increasing\u00a0 OPEX (read it as cost of\u00a0hiring\u00a0high 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.<\/p>\n So, it is not only\u00a0a question of\u00a0GUI versus CLI or easy versus difficult.\u00a0Ultimately, it boils down to \u00a0OPEX issues, which should not be overlooked.<\/p>\n 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.<\/p>\n <\/p>\n <\/p>\n RFC5654\u00a0from IETF mandates that MPLS-TP MUST be able to operate\u00a0WITHOUT using control plane with the ability to setup services\u00a0using Management plane.\u00a0Control\u00a0plane, however,\u00a0is\u00a0optional and if used\u00a0then it should be\u00a0GMPLS based.’<\/p>\n Ironically, some vendors DO NOT fulfill this mandatory requirement of MPLS-TP\u00a0with regards\u00a0to\u00a0static provisioning through NMS ( Network Management System) . They use control\/Signalling \u00a0plane\u00a0 based on IP\/MPLS ( not GMPLS) to setup services.<\/p>\n Why is this question so important to ask ?<\/p>\n Since you are used to configure transport pipes in SDH statically without any control plane using NMS\u00a0 and it is so easy to do it that way, why would you bother to change ?<\/p>\n Transport network is all about predictability\u00a0and manageability.\u00a0 If\u00a0a vendor needs control plane\u00a0, it is an indicator that\u00a0\u00a0services are being setup \u00a0dynamically.<\/p>\n Why would you\u00a0worry about setting up\u00a0services dynamically in point to point links or in a ring like architecture? I don’t see\u00a0 value of control plane in such simple scenarios.<\/p>\n Again, setting up LSPs dynamically might be an indicator of another factor-a weak NMS. In the absence of\u00a0a feature rich NMS\u00a0that can help in point and click provisioning of services, the vendor may be calling the control plan to rescue it in provisioning of services.<\/p>\n So make sure to ask this important question from potential MPLS-TP vendor and prefer “No control plane” over ” Control Plane”<\/p>\n <\/p>\n There are two camps here, one supporting Y.1731 based OAM and\u00a0 others support BFD based OAM. Of late, both are\u00a0 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.<\/p>\n So,which tool set is better for you?<\/p>\n There is nothing wrong with any OAM standard.\u00a0 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\u00a0to make the interworking between MPLS-TP and IP\/MPLS easier<\/a>.<\/p>\n\u00a01. GUI based or CLI based?<\/strong><\/h3>\n
\u00a02. Control Plane or\u00a0No Control plane?<\/strong><\/h3>\n
\u00a03. OAM of MPLS-TP ( Y.1731 based or BFD Based) ?<\/strong><\/h3>\n