ACG Research

ACG Research
We focus on the Why before the What

Sunday, December 19, 2010

MPLS-TP OAM: An Informal ACG Survey and an Update on the “Controversy”

ACG analysts have been trying to sort out what's really going on with MPLS-TP OAM by asking service providers worldwide to comment on their usage of MPLS-TP. Their answers ranged from "We have no plans to deploy at all" to "We are still evaluating it." The most common response was "We are waiting to see where the market falls on the OAM approach."

Clearly, the OAM approach is what has folks in bit of a tizzy since there are implementations in China service provider networks and several large European providers as well. What exactly has been implemented? The answer in most cases is a proprietary T-MPLS approach with a subset of Y.1731 OAM functions to amend the current SDH networks to provide Ethernet services. Most providers with this type of installed equipment mention that it is not fully Y.1731 compliant yet, but that they'd like it to be soon. They cite ratification of Y.1731 OAM as a priority because it is already proven in transport networks with SDH and OTN.

Several providers also noted that internally there are “deviating opinions” on this subject, which have a lot to do with internal organizational barriers. This difference reflects the long standing discussion between those who are in favor of circuit switched networks versus packet oriented networks. And they are correct. Inherently, Y.1731 is more transport centric while BFD&LSPing are much more packet centric. Y.1731 originated from the ITU and BFD from the IETF. Regardless of which approach you favor, the move is toward unification; the ITU and IETF are working together on a solution for MPLS-TP OAM.

We also polled some engineers who told us that Y.1731 is actually pretty 'heavy weight' in that it requires more packet processing as opposed to BFD&LSPing. One large provider stated, "We believe that the Y.1731 approach is technically flawed for use in MPLS networks. Y.1731 was designed for transactional OAM flows and not for MPLS LSP environments. To date, transactional OAM flows at the data plane are not always possible in an MPLS LSP environment. MPLS already has different and multiple OAM capabilities and BFD&LSPing have been proven to operationally work well in MPLS environments."

What we've learned is that the data plane hierarchy is completely different between Ethernet and MPLS and so the identifiers used for OAM will have very different design requirements. Some believe that if Y.1731 is used for MPLS it will shorten the time to a final standard and facilitate OAM interworking between Ethernet and MPLS. This is a fairly flawed concept as Y.1731 would need work to fit it into MPLS and MPLS already has OAM functionality.

So anytime there are protocol discussions with passionate discourse, there has to be more behind the game than what is readily apparent. T-MPLS failed and its OAM was based on Y.1731. Creating MPLS-TP OAM with Y.1731 is an attempt by some providers to protect the investment they have already made in their networks. Vendors want the implementation to become the de facto standard to protect their development and time-to-market advantage. Déjà vu? Yes, we have seen this before; however, the de facto implementations do often become scarce and ultimately the full standard is adopted.

Time is the real issue here. The IETF works in a democratic fashion and tries to reflect consensus among all vendors. The reality is that this method of operating is too slow for this market, and they need to find a way to ratify a standard sooner than later. As of the last meeting, 27 additional drafts were submitted to the IETF on the OAM approach. While this doesn't mean that the individual drafts will be adopted as official work or will result in a “working group,” it will slow things down. The current drafts on MPLS-TP have official standing in that they are a working group’s drafts based on the BFD&LSPing. The Y.1731 based approach has yet to be accepted as a working draft.

What’s really controversial? Most companies want to be seen as innovators. If a de facto implementation becomes the standard, companies that created it are viewed as more innovative than the ones fighting for the standard or vice versa.

Often the de facto standard fades into the distance and the standard takes over. That is what most vendors and large service providers would prefer. However, there is a game changer: the de-facto standard has much more cash backing it than the IETF (vendor) group could ever come up with. Not that money always talks, but it can have a significant advantage, which is why there is so much intensity around this topic.

What will happen? Unfortunately, the result may be two standards. Our survey told us that no provider wants to implement two types of OAM in their network; the OAM implementation is complicated enough; and two implementations are simply out of the question. Ultimately, we would like to see the ITU and IETF compromise on a common specification (RFC) for OAM functions to be implemented in MPLS-TP networks. For those with MPLS networks in place today, this is a must have.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.