Don't miss the NFV mind map !

Well! I have done all the efforts and made concepts simple through the Free NFV Mind Map. Get it now before I take it off. Plus get free updates to my blog.

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.

 

Subscribe
Notify of
guest
32 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Wu Yicun
Wu Yicun
7 years ago

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.

Ali Al-Sayyed
7 years ago

i like your innovative idea and perception in this article, you really highlight the main driver of MPLS-TP value proposition selection criteria .

good job

Javed Akhtar
Javed Akhtar
7 years ago

It’s some thing very valuable.

Muhammad Hassan
Muhammad Hassan
7 years ago

Hi Faisal, its quite informative and interesting analysis regarding MPLS-TP vendor selection.

ahmed kareem
ahmed kareem
7 years ago

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

David Bianchi
David Bianchi
7 years ago

Nice article Faisal, with a lot of good points to think about.

Omar Khamis
Omar Khamis
7 years ago

Interesting article Faisal

Feras Alfariss
Feras Alfariss
7 years ago

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?

Majed
Majed
7 years ago

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.

Michael Gronovius
Michael Gronovius
7 years ago

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

Dieter
Dieter
5 years ago

“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

Fred Madison
Fred Madison
7 years ago

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

Ali
Ali
6 years ago

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

Ali
Ali
6 years ago
Reply to  Faisal Khan

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

Huub van Helvoort
5 years ago

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.

Abdul Ravoof
Abdul Ravoof
5 years ago

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 ?

Abdul Ravoof
Abdul Ravoof
5 years ago
Reply to  Faisal Khan

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.

32
0
Would love your thoughts, please comment.x
()
x