Why Cisco Supports Standards for Interoperable MPLS
I just read a blog from Eve Griliches of ACG Research which highlighted some recent challenges related to the progress of a single, industry-wide MPLS-TP standard being developed by the IETF/ITU Joint Working Team. I tend to agree with her that these recent events are a problem and an undesirable pothole on what is a very promising highway to a standardized next generation packet network. Let me provide a bit more background.
First, the world is shifting from TDM to IP and therefore (of course) the telecommunications infrastructure is also moving from TDM to IP equipment. The industry showed us their understanding of that when T-MPLS was put to rest and an almost revolutionary event happened – the IETF and the ITU joined forces to create a Joint Working Team to define how MPLS is used in a transport network. That was back in 2008.
Here’s a recap of what happened (also documented here):
- Determined that it’s technically feasible to extend IETF MPLS and Pseudo-wire architecture to support transport functions
- In the IETF: Define MPLS-TP
- In the ITU-T: Integrate MPLS-TP into the transport network, align current T-MPLS with MPLS-TP, terminate work on T-MPLS
The industry started out working on MPLS-TP standardization in earnest, and just last week IETF published RFC5921 defining MPLS-TP framework.
However, what happened recently is disappointing. At the last ITU-T meeting, strong efforts were made to resurrect T-MPLS on the final day, when some of the key member countries had already gone home. The justification provided by some members was based on few pilot deployments and older interoperability results of T-MPLS technology between two vendors. The result is a potential paralysis of future work with a possible outcome being two different development tracks – creating significant expense for both service providers and equipment vendors.
T-MPLS is based on Y.1731 Ethernet OAM which is quite different from MPLS OAM. The bottom line is that T-MPLS is not interoperable with MPLS and will create an expensive lack of interoperability between the T-MPLS domains and MPLS domains. A key reason for the joint working group to terminate work on T-MPLS in 2008 was to ensure OAM alignment with MPLS. This would ensure a single OAM infrastructure – protecting investments and promoting interoperability.
To make matters worse, some customers have told me that claims are still being made to them (by certain vendors) that T-MPLS equals and interoperates with MPLS-TP. Additionally assertions are being made that upgrading from T-MPLS to MPLS-TP is going to be painless and trivial. These claims are simply not true.
All of this is unnecessary, and only contributes to confusion in the operators’ minds. As our customers grapple with today’s economic realities to make networks more efficient, adding to their burden with technology uncertainty hurts everyone.
Taking a step back, I feel like I’ve just emerged from a time machine and arrived back in the year 2000. I’m not referring to the Y2K software bug, but instead how 2000 was a pivotal year for the adoption of another key technology – Voice over IP (VoIP). Back then the migration of TDM to Packet Voice was momentous. Arguments were floated then on VoIP’s non-viability as a mainstream technology, the divergence between the worlds of IETF (Internet) and ITU (Telecom), and finally stonewalling tactics by incumbent PBX vendors towards VoIP. Today VoIP is prevalent everywhere, embedded in all types of apps with a common set of protocols.
Ultimately, the goal of any standardization is innovation coupled with investment protection and interoperability. With the developing brawl over MPLS-TP, that is certainly not being fulfilled. And that is not a good thing for our industry.