Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

Cloud Native Infographic

Don’t Miss the “Cloud Native Infographic” !

Everything is cloud Native from 5G core to RAN, transport and orchestration. Either you know about it or Nothing about Cloud. In this “FREE” one page infographic poster, I have made it a QUICK and EASY reference for Cloud Native main concepts which are otherwise very complex to understand. Plus get notified when important blogs are published.

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

 

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.

 

32 thoughts on “Are you asking these Questions from potential MPLS-TP Vendors?”

  1. It is a fine article which truly reflects the beauty of MPLS-TP with respect to operator experience. No doubt it is a paradox to have every features in one box. It never ever exists. However MPLS-TP operator shall still consider those transport-like features as a MUST while any extra one could be adding flavour. Thank Faisal indeed for your contribution of sharing MPLS-TP in a way of acdemy plus operator-experience.

  2. Hi faisal
    Its really great article for sure you will never find vendor that give you all advantage and disadvantage for his system.
    Your article is simple and clear i hope to see such article from you in other telecom area as will
    Thank you

  3. Thanks Faisal for presenting about three major points. Also, I would like to add two questions to vendors as follows:
    1- Does the vendor system support the integration with OSS, if yes, what types of interfaces does it support?
    2- Does the vendor support actual utilization per port in easy and clear format?

    1. Hi Feras,

      You brought up a very important point considering integration with OSS is a major thing when one is working with multiple vendors and it should be done through standard interfaces in easy manner.

      Again the second point is also worth noting since I see some vendors struggle with it. Thank you for bringing up these addtional perspectives.

      Regards,

      Faisal

  4. Dear Mr. Faisal,
    it is my pleasure to thank you for the valuable brief article about MPLT-TP. I hope to read from you soon in other telecom technology invention.

  5. Michael Gronovius

    Dear Faisal, excellent article
    1. GUI based or CLI based? In my opinion end-to-end point & click provisioning using an NMS is a must, if you want to scale your deployments. The whole idea for MPLS-Transport Profile was to make the managing packet networks the same way as transport networks. Feedback I got from an Latin American operations manager was that with MPLS-TP he could manage 100x more NEs with the same number of people. Keep it simple, keep the cost low, this is especially important in the aggregation network.
    2. No Control plane needed with MPLS-TP. I agree with you. The intelligence is in the NMS during the provisioning phase. As a result the NEs don’t need a large protocol stack, which makes them simpler, cheaper with lower power consumption. In addition it allows 50ms protection switching times.
    3. Two MPLS-TP OAM standards. The ITU-T Standards did approve 2 non-interoperable OAM mechanisms. One is the T-MPLS based on y.1731, the other is the IETF based on BFD which is more future proof and makes OAM interworking with IP/MPLS easier.
    Regards,
    Michael

    1. Thanks Michael,

      For stopping by and sharing your views.

      I have seeen some operators suffering especially the backhaul ones, because of CLI based MPLS-TP products with the IP/MPLS back engine running in the background :)…. imagine you have to provision and troubleshoot tens and hundereds of circuits using CLI when the right skills for the CLI are not available with the transport operators….

      thanks,

      Faisal

    2. “In my opinion end-to-end point & click provisioning using an NMS is a must, if you want to scale your deployments”

      I strongly agree. My company is developing Ethernet Switches and we have plans to support also MPLS-TP. I am interested in multi-vendor MPLS-TP NMS solutions to integrate in our portfolio. Is there something available ?

      Thanks,

      Dieter

      1. Thanks Dieter for commenting. I dont think so there is any multi vendor NMS solution. The reason being, there are dispersed standards and many vendors follow their own way of implementing MPLS-TP NMS.

  6. Hi Faisal,

    thanks for this post. I agree with you, it is interesting to see the different aproaches equipment vendors take towards MPLS-TP. As you mentioned, there is the ‘router-type’ equipment vendors, which come from designing IP and IP/MPLS routers and on the other side there is the ‘OTN-type’ vendors, which have more of an SDH-, Ethernet-, etc background.
    So while the router vendors rely on IP interfaces, ARP, etc for destination/next hop MAC resolution, not all of the traditional OTN vendors will have IP capabilities and will use L2 approaches like static MAC configuration, reserved multicast Ethernet addresses, LLDP, etc in order to discover the peer L2 address.
    This raises additional questions about interoperability, for example if the MPLS-TP network has to interwork with an IP/MPLS network as you mention in the OAM section of your post. Interworking between an IP-based MPLS-TP equipment and a L2-based MPLS-TP equipment might require the use of static ARP entries, static MAC address configuration, etc. So even though this approaches will do the job, it is not a very elegant solution.

    What is your take on this?

    Best regards,
    Fred

    1. Thanks Fred, For thoughtful comments. You are right. The job of interworking between IP/MPLS and MPLS-TP is easier said than done. There are challenges moving from static based network to dynamic based network. Different environment altogather. However there are some instances in which they have been shown to work togather especially for end to end OAM for fault mangement like indicating fiber cut.

      Usually multi-segment pseudowires (MS-PW) are built between the IP/MPLS network and the MPLS-TP
      network. The pseudowire segments in the IP/MPLS network are signaled using LDP while the MPLS-TP network relies on static pseudowire segments.
      BFD is used for OAM purpose. May I point you to a white paper from EANTC on more details about how this kind of interworking is done and tested.

      http://www.eantc.de/fileadmin/eantc/downloads/events/MPLS2011/EANTC-MPLSEWC2011-WhitePaper-1_0.pdf

  7. Hi Faisal

    Would love to get your thoughts on MPLS-TP vs seamless MPLS, which one of the two would emerge as a next generation technology?

    Ali

    1. Salam Ali,

      There is no competition between the two however there are some gray areas. As IP/MPLS can give layer 3 services which MPLS-TP CAN NOT. MPLS-TP can only provide layer 2 services. When it comes to access, MPLS-TP has powerful OAM features, which IP/MPLS does not have. Some people might prefer to have seamless MPLS, that is extending MPLS all the way to Access, but again it depends on how is the operation structure of an Operator. MPLS-TP is much easier here and can be easily handled by transport engineers compared to IP/MPLS.

      1. Thanks Faisal

        Remember there was once a white paper which was used in one of the meetings by our dept and the then IP/MPLS, if you have any interesting links/docs please share them with me.

        Thanks
        Ali

  8. Here is an additional question:
    How many simultaneous OAM sessions does your equipment support?
    I.e., how many connections with G.8113.1 OAM and/or how many connections with G.8113.2 OAM can be supported?
    So far vendors have been very secretive about this. IMHO this is because the difference is significant.

  9. Many thanks Faisal for sharing this valuable information on MPLS-TP. Yes, off course it is very important to have GUI based.

    As you said, MPLS-TP can provide only Layer 2 services and Layer 3 CAN NOT ? Still , it is same ?

    Why MPLS TP cannot provide Layer 3 VPN ? can you put some highlight on this ?

    1. Salam Abdul Ravoof,

      MPLS-TP does not use IP for forwarding. It is just a layer 2 technology. It can understand VLAN and MAC only. Layer 3 VPN needs an IP layer for forwarding traffic. That is why MPLS-TP cannot create a layer 3 VPN.

      1. Wa alaikum Salaam Faisal.

        Thanks for your quick response. Yes, MPLS-TP does not requires control plane capabilities and enables management plane to set up LSPs manually. I was just thinking, Layer 3 VPN services over Layer 3 MPLS tunnel should have the functionality to enable MPLS – TP.

Leave a Comment

Your email address will not be published. Required fields are marked *