Divide between ITU and IETF take on MPLS MOA runs deep

A key figure from the International Telecommunications Union Standardization …

A week ago, we reported on long-simmering differences of opinion between the ITU-T (the International Telecommunication Union Standardization Sector) and the IETF (the Internet Engineering Task Force) that erupted to the surface recently. It's hard to escape the conclusion that despite the fact that these are two organizations creating communication standards, and lots of participation and liaising back and forth happened, communication severely broke down between them. Each entertains very different interpretations of the same events.

Originally, the two standards organizations had agreed to work together on protocols to manage MPLS (Multi-Protocol Label Switching)—an IETF technology—in transport networks operated by telcos—traditionally, the ITU's constituency. Two groups of vendors had proposed two different protocols for Transport MPLS/MPLS Transport Profile (T-MPLS/MPLS-TP), and especially its network management (NM), also known as Operations, Administration, and Management (OAM).

The IETF adopted the protocol that is closer aligned with the way it normally does things, much to the dismay of the ITU, which has a proposal that fits better within the traditional telecom environment. After failing to get any traction in the IETF, the second group of vendors petitioned the ITU-T to adopt its protocol in addition to the one being worked on in the IETF. Late last month the ITU-T, after failing to reach consensus, voted on the matter, and decided to go ahead with the second protocol. As we reported earlier, this didn't go over well in IETF circles.

Russ Housley, the IETF chair, has suggested that in the ITU, "optional extensions are added until nobody objects anymore." Greg Jones, Counsellor for the ITU-T Study Group 15, disagrees with Houseley's take. "The ITU's objective is to develop international, interoperable, non-discriminatory standards," Jones told Ars. "We strive to ensure that our standards [meet] the requirements of as much of our membership as possible. This is normally done by consensus but ultimately the membership can decide, by majority voting, to avoid including all the options that various stakeholders want. It is a more democratic process than the IETF 'rough consensus' process, which is subjective and basically leaves the decision to the IETF 'leadership.' In any case, there are many examples of IETF protocols having too many options."

We asked Jones why only 16 of the 192 countries that participate in the ITU actually voted on the proposal. "The vote is taken by the Member States that have registered for and are physically present in the meeting. Unfortunately the vote was called very late on the last day of the meeting and many member States had already left the meeting."

But why now? Why wasn't the ITU's intention to progress two protocols communicated to the IETF leadership during the joint meeting in August? "This was communicated to the IETF leadership in August as documented in the report of that meeting." Jones explains. "The IETF refused to discuss the agreement despite ITU's request. Also, the technical and timing concerns have been expressed both in IETF meetings and on the IETF mailing lists for close to two years."

"It is true that we did not want to discuss changes to the JWT agreement. The people that would be involved in such a discussion were the same people needed to deliver against the existing agreement," Housely responded when presented with Jones' explanation of events. "The ITU was already complaining that the MPLS working group was taking too long. Pulling those people away from the documents to work on a revision to the JWT agreement would make the documents take even longer." (The JWT agreement consists of 115 Powerpoint slides.)

One of the contentious issues is "unilateral disbanding by the IETF of its group assigned to work with ITU." Housley pointed out that this group was merely a design team. In the IETF process, a design team is a small group tasked to hash out some issue. Once that's done, the design team reports back to the working group that created it, and the work is continued in the working group. From the IETF's perspective, the fact that a design team is disbanded is a good thing; it means that the working group as a whole can continue to make progress.

Jones says this caused a problem for the ITU. "The MPLS Interoperability Design (MEAD) team was proposed by the ITU/IETF Joint Working Team. The MEAD team was a key part of the interaction between the ITU and the IETF," he explained. "Since it was disbanded, without consulting ITU, the view of many in ITU is that IETF has taken decisions on the direction of the work without consulting the ITU, informing the ITU of these decisions, or requesting confirmation that the resulting solutions produced by the IETF will meet the needs of all of the members of the ITU."

However, in October 2009, the IETF did send a liaison statement to the ITU which states:

The main MPLS-TP requirements work has been published as RFC 5654, and the two subsidiary requirements documents (NM and OAM) are close to publication with IETF last call ending later this week. The other key documents (the framework documents) have been adopted as MPLS working group documents and their text is substantially in place. Furthermore, a large number of the necessary solutions documents have been started and have good foundations.

With this in mind, we think that the MEAD team has successfully delivered on its objectives. In view of the need to ensure that the MPLS-TP work is fully open to participation by everyone in the IETF and ITU-T communities, and with the desire to "normalize" the process of document production and evolution, we have decided to close the MEAD team with immediate effect.

This is indeed a unilateral decision, but again the IETF says it is in line with how it works. The IETF/ITU Joint Working Team agreement recommends that the groups "jointly agree to work together and bring transport requirements into the IETF and extend IETF MPLS forwarding, OAM, survivability, network management and control plane protocols to meet those requirements through the IETF Standards Process."

Are there clear technical advantages to the "second protocol" that the ITU is developing? "Yes," Jones says. "Packet/optical transport network management requires carrier-grade protocols that can ensure fault detection and repair within strict time limits. It is also important that the OAM solution fits into the existing operational model to minimize the need for staff retraining. The ITU OAM protocol clearly addresses these strict requirements. The IETF OAM tools are still under development.

"The reality is most vendors involved in the debate over the past three years will implement both protocols to address different market needs. The ITU solution offers lower cost and complexity for applications in the optical transport network."

Iljitsch van Beijnum
Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. Emaililjitsch.vanbeijnum@arstechnica.com//Twitter@iljitsch