MPLS-TP Camp States Its OAM Case

Some panelists on a recent Light Reading webinar explained why they don't like having a second management standard for MPLS Transport Profile (MPLS-TP), saying it messes up the goal of having a consistent MPLS layer traversing the network.

Operations, administration and management (OAM) wasn't the primary topic of "MPLS in Next-Generation Transport Networks," which took place last week and is now available in the webinar archive.

But when the topic did come up, it was clear that some companies think the International Telecommunication Union, Standardization Sector (ITU-T) shouldn't be standardizing a second OAM specification, based on the Y.1731 standard.

"The first question some service providers asked us, without knowing any debate was happening in the standard, was: 'Can you give me end-to-end MPLS-TP OAM?' If you want that to happen, you need MPLS-TP-based OAM," said Luyuan Fang, a principal engineer with Cisco Systems Inc. (Nasdaq: CSCO).

It's a continuation of the argument that began last fall, as certain vendors and carriers began calling for the Y.1731 option to be added to the standard. That added several minutes of drama to some otherwise normal standards meetings. (See Rumor: T-MPLS Group Gets Shouted Down and MPLS-TP Could Be Headed for a Split.)

The OAM options being argued about have formal names now:
  • G.8113.1: Y.1731-based OAM, originally part of the T-MPLS standard and based on the recent BHH Draft submitted to the IETF. The ITU decided in February to start standardization work on this OAM version.
  • G.8113.2: MPLS-based OAM that the IETF has been working on since 2009, with help from the ITU. Also known as BFD.

Now, it's worth noting that the webinar panel, consisting of representatives whose companies had paid for this appearance, did not include any supporters of Y.1731-based OAM. So, G.8113.1 had no defense as it drew criticism during the Webinar.

The primary concern, as voiced during the Webinar, is that G.8113.1 could disrupt attempts to create MPLS harmony throughout the network. The goal behind MPLS-TP was to create one transport infrastructure for services, especially newer ones, while building from a familiar technology.

"MPLS is being treated in the industry, in some cases, as a separate technology from MPLS-TP, and that's really not the case. What we're really looking for is unified MPLS," said David Sinicrope a director in the standardization development unit of Ericsson AB (Nasdaq: ERIC).

Panelists repeatedly leaned on the idea of unified MPLS, which they described as a smooth, continuous MPLS layer traversing the entire network. The idea isn't to use full-blown MPLS everywhere, but rather, to provide every network segment the option of using some form of MPLS. (Sinicrope stressed that MPLS-TP is a subset of MPLS.) "You use the profile wherever it makes sense, and you're still guaranteed to have a ubiquitous data plane and ubiquitous service that can run over all this architecture and infrastructure without jumping through hoops or having complex bottlenecks with interworking," Sinicrope said.

That MPLS would be a consistent option is important. Access networks are more sensitive to cost, for instance. In those cases, MPLS-TP in a static configuration, one that doesn't need a control plane might be a good option, panelists suggested.

"In different segments you could pick different components of MPLS," Fang said.

Fang asserted that service providers would prefer one OAM standard, but of course, that's not true of all service providers. One reason why the ITU chose to revive a Y.1731-based OAM is because of backing from service providers such as China Mobile Communications Corp. (which has already deployed the technology) and Telecom Italia (TIM) .

— Craig Matsumoto, West Coast Editor, Light Reading

Page 1 / 2   >   >>
Pete Baldwin 12/5/2012 | 5:01:12 PM
re: MPLS-TP Camp States Its OAM Case

I should mention, also -- the Webinar ran long, and while they provided some extra time for questions, not many questions about OAM got aired.

I don't know what questions were submitted, but I'd imagine a lot of them were about OAM.

What questions would you have asked?

Pete Baldwin 12/5/2012 | 5:01:12 PM
re: MPLS-TP Camp States Its OAM Case

I haven't read this whole document, but it seems to do a good job tracing the recent history of the split:


It's from the IETF point of view, written by IETF chair Russ Housley and others.

chechaco 12/5/2012 | 5:01:09 PM
re: MPLS-TP Camp States Its OAM Case

Hi Craig,

I think in "why they don't like having a second management standard for MPLS Transport Profile (MPLS-TP)" you've referring not to MPLS-TP management, which is either NMS-based or GMPLS-based with T-LDP for PWs, but to Operation, Administration, and Maintenance (OAM).


Elton2010 12/5/2012 | 5:01:06 PM
re: MPLS-TP Camp States Its OAM Case

Ericsson stated "MPLS-TP is a subset of mpls", in fact, only data plane of MPLS-TP is subset of mpls, mpls-tp oam and protection is came from ITU-T transport technology. They explain extension mpls for transport is included into new mpls, that's absurdity, so the statement should be MPLS-TP is subset of "new" MPLS.

Fang ask one solution,why not use draft-bhh as one solution, this solution is first draft in ietf, but it is blocked by ietf with political reason without consesus. On the orther hand, BFD extension for MPLS-TP cann't backward to BFD in mpls, how to end to end?


joez 12/5/2012 | 5:01:06 PM
re: MPLS-TP Camp States Its OAM Case

MPLS-TP is becoming fragmented, and tied too much with MPLS. Those of us without MPLS is being saddled with MPLS complexities. My company is moving towards an Ethernet-based solution. Using IEEE 802.1ag, 802.1ah, 802.3ah, with Y.1731, and G.8031+G.8032. Much simpler.

chechaco 12/5/2012 | 5:01:05 PM
re: MPLS-TP Camp States Its OAM Case

"... tied too much with MPLS ..."

Well, it should have been expected since it is MPLS first and TP second.

"Those of us without MPLS is being saddled with MPLS complexities."

I can understand that taking a dive into MPLS for the first time might be shocking experience. Would greatly appreciate if you could give brief on most frustrating issues from your perspective.

chechaco 12/5/2012 | 5:01:05 PM
re: MPLS-TP Camp States Its OAM Case

I'll note that OAM and protection are functions of the data plane, not of control plane. Yes, to meet requirements formulated by JWT and outlined in RFC 5654 and RFC 5860 a well-known label, GAL and its use in G-ACh were defined in RFC 5586. But the G-ACh/GAL are equally applicable to MPLs-TP as well as non-TP MPLS PSNs. Thus I don't agree with your conclusion that there's "new" MPLS since the paradigm of MPLS has not been changed as, in fact, is fully compatible with or without TP.

IETF does not give any preference to "who was here first" but allows development of thorough and complete technical solutions. When several proposals are addressing the same problem, authors encouraged to merge their solutions or the WG decides which one to advance. I'll note that only IETF's CCM (CC-CV-RDI) is BFD-based while LI-LB and LM-DM are clearly not. And the Y.1731 has more narrow scope if compared to BFD-based IETF CCM. The former addresses only bi-directional corouted LSP, while the latter that and associated bidirectional LSPs as well in coordinated and independent modes. And I wonder where you see incompatibility of proposed extension of BFD for use in MPLS-TP CCM? Would you mind to give technical argument not just a bumper sticker?

joez 12/5/2012 | 5:01:04 PM
re: MPLS-TP Camp States Its OAM Case

Maybe that's the problem..."MPLS first and TP second". The reason for eval of this technology is TP first and MPLS second, not the other way around...or at least that's how I approach this.

Most frustrating? Not sure, possibly combination of items, such as different OAM approach in industry, lack of consensus on the simple ID issue (ongoing discussion in IETF), need for PW features on top of MPLS even if I don't need it for my deployment, and with that all the "subset" of extensions to various protocols. Is the vendor community going to charge me for a box that will only have these "simple" feature sets, or am I going to be saddled with R&D overhead for these superset protocols that I don't plan to use?

chechaco 12/5/2012 | 5:01:04 PM
re: MPLS-TP Camp States Its OAM Case

Thank you for your expedient response to my questions.

I think that there are two groups of providers that are looking at MPLS-TP. One group - providers that already have IP/MPLS networks and realized benefits of TE and dynamic control plane. Another group - providers with broad transport experience in TDM (SONET/SDH) that are looking to add packet transport to responcibilities of their transport team. Perhaps providers from the first group are more prepared to adopt MPLS-TP in its IETF interpretation. I expect that ITU-T interpretation of MPLS-TP will emphasise, as you've suggesting, the TP component. But that will take time and even then it will use all constructs and mechanisms defined by IETF and compatible with MPLS data plane.

The MPLS, and I agree with you, might not be needed to solve every provider's problem. Some providers might be absolutely satisfied by using solutions you've mentioned.

Duh! 12/5/2012 | 5:01:00 PM
re: MPLS-TP Camp States Its OAM Case

who was a bit nonplussed by the way this was handled.

I don't have a dog in this fight.   I viewed the webinar because I wanted to get a quick intro to MPLS-TP without having to really dig in and start reading RFCs and Recommendations:  that's a project for another time. 

Now, I've seen more than my fair share of standards battles, sometimes as a combattant, sometimes on the sidelines.  And I know they get pretty emotional.  And personal.    And sometimes bleed out of the standards arena.  And sometimes become turf battles between committees.  And are often proxies for marketplace competition between companies.  And often have competing patent strategies embedded in them.  And that often, participants' personal performance goals are based on winning them.  So I understand where this was coming from. 

But I still thought that the attack on G.8113.2 was a bit...  heavy handed.  It would have been very nice to see a substantive technical comparison between the two approaches.  Maybe even a little bit about why this schism arose.  Maybe less emphasis on process issues (which are really relevant only to the committees involved).  Possibly even an attempt to address the other side's arguments.  Not that I'd expect complete neutrality.  But at least I'd think that presenters would think about the effects of such blatant partisanship on their own credibility.  One can make one's point more effectively by not beating their  audience over the head with it.

But I certainly understand that this was a free, sponsored webinar.  You get what you pay for.

p.s., when I think of the epic standards battles of the past,  few of them, in retrospect, turned out to be as significant as they seemed at the time. 

Edit:  Particularly the ones that were about killing an option.  The marketplace seems to have a way to deal with those things.

Page 1 / 2   >   >>
Sign In