Ethernet services

MEF Certifies Seven

LONDON -- Ethernet Expo: Europe 2006 -- Seven carriers were today awarded Carrier Ethernet Services certificates by the MEF that shows their services meet the specifications as set out by the industry group.

The seven are the first carriers to receive the MEF's service certificates:

"It's all about interoperability," said MEF president Nan Chen at the certification ceremony held at Light Reading's Ethernet Expo Europe in London today. "This will be a step-by-step process, but this is a foundation for making ubiquitous end-to-end Ethernet services across multiple service provider networks a reality."

The process follows on from the vendor equipment certification process that began late last year. (See MEF Rubber Stamps Ethernet Gear and MEF: Certification Wasn't Easy.)

So how did these carriers -- all MEF members, of course -- make the grade? Each had to build a service infrastructure in its lab for initial verification of compliance against MEF specifications, and then undergo a field test of production circuits set up on its live production network, says Bob Mandeville, president of test lab Iometrix Inc. , which conducted the verification process.

Mandeville says his company had to develop network probes to add to the carriers' networks that could monitor the EPL (Ethernet private line), EVPL (Ethernet virtual private line), and E-LAN (Ethernet multipoint-to-multipoint) circuits that were tested.

So did anyone fail? Mandeville says all seven carriers had issues along the way that needed to be addressed and worked on to meet the MEF specifications, but that all the carriers in the first phase of testing passed eventually. Now Mandeville and his team are starting work on the next 10 unidentified carriers keen to get their certificates.

While the MEF won't name them, BT Group plc (NYSE: BT; London: BTA), Colt Technology Services Group Ltd , and Orange (NYSE: FTE) are believed to be among those involved.

But do these certificates count for anything when it comes to selling Ethernet services to enterprises? The carriers say a resounding "Yes!" Brian Fabiano, senior VP for network services at Optimum Lightpath, believes the certificate gives his company credibility. "Our customers are technically sophisticated and they know the MEF," he says. "They've been asking how we can show that our services are resilient, and this is a milestone in achieving that."

Anthony I'Anson, strategy director at NTL:Telewest Business -- the new name for NTL's wholesale business unit following its recent merger -- concurs. "The MEF is widely recognized by enterprises. That was a driver for us being part of this process," says I'Anson.

— Ray Le Maistre, International News Editor, Light Reading

mtb826 12/5/2012 | 3:55:57 AM
re: MEF Certifies Seven "Our customers are technically sophisticated and they know the MEF," he says. "They've been asking how we can show that our services are resilient, and this is a milestone in achieving that."

IG«÷d welcome anyone to explain how the MEF or MEF9 cert makes Carrier grade Ethernet services resilient; or scalable, deployable, manageable. Perhaps itG«÷s all of those cool MEF acronyms that make the CarrierG«÷s Ethernet services sound G«£technically sophisticatedG«•, so therefore it makes them believe they are resilient. But if the customer is truly sophisticated theyG«÷d point out that the B.S.ometer has been pegged.

It is great to see the MEF is now extorting money from those that have helped perpetuate this zero mandate forum.

richardd 12/5/2012 | 3:55:51 AM
re: MEF Certifies Seven I hope this helps

Empowers informed decisions re equipment / CPE purchases
Service Provider efficiencies and cost savings can be passed to end users
Service Providers
Provides immediate assurance that vendors equipment complies to the MEF Specifications
Saves money and time on complex testing between vendors, especially on global accounts
Establishes solid foundation for Carrier Ethernet ubiquity, & interoperability
Equipment Vendors
Globally recognized interoperability standard improves G«ˇapprovalG«÷ process, increases tender opportunities and dramatically reduces testing costs and time-to-market
Independent validation of function and conformance
ozip 12/5/2012 | 3:55:50 AM
re: MEF Certifies Seven Have any of you ever met a carrier sales rep that sells to enterprise? I cant imagine one of them explaining why MEF certification of their network is important.

I understand why vendors need to participate in standards marketing organizations (they are not recognized standards organizations) like MEF but this was a complete waste of time. Obviously profits at these carriers are not so bad that they can waste time and money on this kind of thing.

mtb826 12/5/2012 | 3:55:49 AM
re: MEF Certifies Seven
That doesn't help me at all, just more MEF gibberish. Do you understand the MEF9 cert? It verifies the most mundane L2 parameters that just about any L2 managed switch can support.

Can you swap a tag and recalculate the checksum?
Can you support basic L2 flooding behavior?
Can you support frame or pbit transparency?

If you can’t properly calculate an Ethernet checksum you wouldn’t be able to pass traffic to any other Ethernet device. The latest MEF SLA cert is just as trivial. Can you support 1 SLA, o.k. how about 2 SLAs?

What’s next, an L3 vpn service certification? We could verify that DSCPs can pass transparently and we don’t route to the wrong subnet. I’m going to hit Ebay and buy and Ixia. I hereby declare that I am the sole source for this valuable industry certification.

The MEF has been a floundering forum since their inceptions. To resurrect their organization someone came up with a brilliant scheme to extort money from vendors, and now service providers, under the guise of an industry certification. I don’t understand why the industry supports such a meaningless certification. And how can they justify passing all of this cert business to Iometrix? I don’t know how these folks sleep at night.
ethertype 12/5/2012 | 3:55:47 AM
re: MEF Certifies Seven MEF has its issues, but the fact you guys keep forgetting (or maybe never got in the first place) is that nobody else actually defines what an Ethernet service provided by a service provider should do. IEEE 802 certainly doesn't. IETF doesn't.

Sure, if you're going to call it an Ethernet service it clearly has to deliver Ethernet frames from A to Z without modifying the contents, but the devil's in the details. For example, does the service support transparent delivery of the customer's VLAN tagged frames, or does it use the VLAN ID to determine where to deliver the frame, or does it prohibit/discard customer VLAN tags? Does it look at customer-set 802.1p priority or DSCP and, if so, how does that translate into the performance SLA? The list goes on an on. Every Ethernet service to date has been developed with different answers to these questions, often with non-standard features (remember that 802 refused to standardize Q-in-Q for years, despite its growing and obvious value, until the recent provider bridges work). And worst of all, all the vendors and carriers used inconsistent vocabulary. Carrier sales people were predictably unable to understand or articulate many of the finer points. The result has been major headaches for enterprise buyers and for carriers trying to make their services interoperable.

MEF doesn't have all the solutions, but they're the only ones seriously working on the problem.
Mark Seery 12/5/2012 | 3:55:42 AM
re: MEF Certifies Seven Trying to deploy Ethernet without a well defined services UNI did have its problems (from personal experience) so it was good to have some group chew on that issue. There of course was the need to convince people that Ethernet is "carrier class" though I'm a little skeptical about to what extent some traffic tests can verify that; I'd rather see a focus on being "transport class".

The Frame Relay forum when dealing with the possibility of a core technology that was different to Frame Relay took the approach of developing interworking standards (with ATM for example). It added value in that sense, along with all the UNI work it did. MEF on the other trys to take a core network agnostic approach to its network model, and as a result, does not certify anything of meaning beyond the UNI itself - even though it infers that it does by the nature of the tests. I have spoken to carriers about this, and I have confirmed with one very visible carrier representative that it provides nothing compelling in terms of interoperability (with respect to the service infrastructure), and it should be clear why.

The MEF, IMO, has put the cart before the horse. It needs to define what core networks it interworks with (raw Ethernet, PBT, PWE3, ATM,....), and how, and then it can start down the road of doing end to end certification that has meaning. It would seem that starting with PWE3 (Dry, MPLS, LT2Pv3 - not sure it matters) interworking would be a good start, and IEEE provider bridging would be a good next step (perhaps the first step if we are focused on carrier "Ethernet").

This situation is complicated by ecosystems that don't understand, and to some extent don't respect, each other, attacking a problem from two different starting points. From that perspective, a certain complication and confusion was unavoidable. A little more focus on transport, as opposed to service, would also illuminate some issues.

So I would say it is a mixed record. They have done some things that were good, but the complicated nature of the current technology and industry evolution environment has positioned expectations ahead of reality. Choice is good, but it had costs. Frame Relay had it so much easier in only having to worry about itself initially, and then ATM for most of the rest of its life (MPLS later on). Ethernet steps in to what is already a complex array of possible core network technologies - this is the key to the problem. The other core technologies (from IETF, ITU, IEEE, .....) should simply take the MEF UNI and adopt it, or the MEF will need to create interworking standards for each of the possible cores, and then test them - an expensive proposition.
mtb826 12/5/2012 | 3:55:42 AM
re: MEF Certifies Seven Ethertype,
I disagree with your assessment that the IETF doesn’t define Ethernet services. They have very detailed specifications under the L2VPN and PWE3 WGs that define Ethernet services. Just to name a few:


Now you may say that IETF pertains to Ethernet over MPLS and point out objective #1 of the MEF’s charter: “Build consensus and unite service providers, equipment vendors and end-customer on Ethernet service definitions, technical specifications and interoperability”. But the reality is the MEF has failed, definitions such as E-Line and E-Lan don’t apply ubiquitously to all Ethernet service technologies. For example, the vast majority of service providers are deploying a point-to-point Ethernet services based on pseudo-wires. If you’re positioning a product or architecting a service based on the PWE3 specs you need to use the IETF terms.

From a SP perspective, when an RFP is issued “conditional and unconditional unicast service frame delivery” is irrelevant; the SP needs to know if the vendor supports PWE3 vc-type 4 and 5. If they ask “How many E-Lines does your product support? The answer could be anything depending on the product being positioned; the SP must know how many Ethernet pseudo-wires per the PWE3 drafts are supported.

From a vendor perspective how do you write a configuration guide on how to configure the broad technologies being deployed? Point-to-point Ethernet services on a 7600 could be based on TLS or AToM, you have to differentiate; you can’t call them both E-Lines in a technical manual. How do you merge technologies such as interworking using MEF definitions? There’s a lot of ground to cover for Eth-ATM, Eth-FR and FR-ATM interworking that applies to both mesh and p2p Ethernet services.

Similarly, the IEEE is evolving Ethernet to be scalable in the carrier space and an entirely new set of terms are being defined such as MIPs, MEPs, etc. The MEF terms will never apply here either. You can’t merge the technologies with a new lexicon.

You can go up the food chain and apply the MEF specifications to SP sales and marketing, but even there you will have ambiguity that requires clarification. And even if you did that successfully, how would that involve the vendor or the architects? They still must be consistent in their implementation and documentation based on IETF and IEEE terms. Where does MEF9 vendor cert apply and why is it such nonsense?

I applaud the effort of those that sat on the MEF forum attempting to tackle this challenge, but at some point you have to evaluate the success. My main beef with the MEF is that they’re trying to justify their existence with these meaningless certifications under the guise that the MEF is advancing and enabling carrier class Ethernet services and that’s nonsense. The IETF and IEEE are advancing and enabling carrier class Ethernet services and the MEF is finding ways to extort money from the industry.
Sign In