There’s all sorts of talk these days about carriers wanting to roll out converged backbones – ones that make use of Multiprotocol Label Switching (MPLS) to carry all services over a single Internet Protocol (IP) network.

A key element of this concept involves the creation of Layer 2 MPLS virtual private networks (VPNs) to support legacy services that generate big revenues for telecom operators, such as Frame Relay and Asynchronous Transfer Mode (ATM), and to support newer services such as Ethernet LAN interconnect.

In nearly every case, the technology that makes this possible is based on “Draft Martini,” an Internet Draft from the Internet Engineering Task Force (IETF) whose primary author was Luca Martini, a senior architect with Level 3 Communications Inc. (Nasdaq: LVLT).

Level 3 itself has pioneered the use of the Martini draft in its own network. While other network operators have talked about using an IP backbone to offer legacy services, Level 3 has actually been doing it for a while – and proving that Luca Martini’s Draft delivers the goods.

The fact that Level 3 has been such a pioneer might explain why Warren Buffett, the Wall Street investment guru, bought $100 million of the company’s distressed bonds last year, saving it from likely bankruptcy. Although Level 3 isn’t out of the woods yet, it appears to be on the road to recovery.

If you didn’t know better you might mistake Martini for the late Andy Kaufman. But be assured that Luca is definitely not Latka.

This Italian-born engineer is one of the most well respected members of the IETF – not only because of his eponymous Draft, which has become the de facto standard among equipment vendors, but because of his work on several other Drafts within the Pseudo Wire Edge-to-Edge (PWE3) working group in the IETF.

Light Reading caught up with Martini at Level 3’s headquarters in the foothills of the Rocky Mountains. During our chat, he dished the dirt on the IETF, came clean on virtual private LAN services (VPLS), and told us how he really stands in the Layer 2 vs. Layer 3 MPLS VPN debate. Read ahead to get the full scoop on:

— Marguerite Reardon, Senior Editor, Light Reading

Want a deeper understanding of MPLS? Check out the first module of Light Reading University's course on the topic. Click on this link to check it out for free!

Light Reading: What prompted you to write a new protocol for Layer 2 MPLS VPNs? What problem were you trying to solve?

Martini: We were trying to deploy Frame Relay when Level 3 first started. But we realized that it was really expensive to do this, compared to using IP. The price difference per megabit was outrageous doing Frame Relay or ATM compared to IP.

At the time, we had an ATM core, but we had plans to move to MPLS. So we came up with the idea to take these protocols and transport them over a more efficient core. ATM was just too expensive. We realized we needed something that was simple to implement, easy to manage, and allowed for a point-to-point configuration. We also wanted an implementation that multiple vendors could support, so we could create competition in the market place. That is how the design parameters developed behind the protocol. This approach was quite successful because, in the end, a lot of implementations came out from the vendor community fairly quickly.

Ethernet was also an interesting technology at the time. So we moved in this direction. We saw the potential to use Ethernet in all sorts of metro areas. And it was fairly inexpensive. So we thought it was a good idea to use it as an access technology to drive down the cost per megabit. At the time, transporting Ethernet VLANs instead of Frame Relay was something that hadn’t been done before.

Light Reading: So Level 3 was a pioneer in using Ethernet as an access technology?

Martini: We probably started looking into this about the same time as the Ethernet metro providers. But as far as a long-distance service provider – yeah, we were pretty much pioneers.

Light Reading: So when did that Ethernet service become a product for Level 3?

Martini: Ethernet has been part of our 3 Packet offering for a while now. We just started to offer ATM and Frame Relay recently.

Light Reading: Ethernet services haven’t really taken off as much as people had expected. When do you think we will see mass deployments in metro-area networks?

Martini: It’s happening now, but slowly. The problem is the fiber reach. Right now if you are located in London, New York, or Washington, D.C., you’re probably pretty well off. You can get metro Ethernet access. But if you are in places like Denver, Salt Lake City, or St. Louis, it’s going to take a long time for carriers to build out the fiber to reach most locations. It hasn’t helped that a couple metro Ethernet providers have filed for bankruptcy. That has slowed down things significantly.

In the end, I think Ethernet is a technology of the future. The price per megabit is so competitive that nobody can avoid using it.

Light Reading: So you would expect to see a push toward Ethernet use from the regional Bell operating companies?

Martini: Yes, I think it’s already happening, especially in places where there is already fiber in the ground. The issue is the capital needed to lay new fiber to buildings that don’t have access. Right now, I don’t see a lot of capital being invested in this, and I don’t see it happening for the next few years.

Light Reading: Let’s talk more in depth about the technology. Draft Martini is a Layer 2 MPLS solution, so I’m assuming you advocate that over the use of Layer 3 VPNs.

Martini: Actually, I advocate the correct solution for the problem.

Light Reading: Well, where are Layer 2 VPNs used?

Martini: Right now we are seeing them used by carriers to connect some of their sites together as large pipes. They are also being used in the enterprise because of their low cost.

Light Reading: So from the service provider to the enterprise?

Martini: We see a lot of people with large bandwidth requirements using it to connect different locations together. They use it to transport their traditional ATM services. Not everyone has adopted the Layer 3 MPLS VPN model yet, but it is making progress, too.

Light Reading: Do you see Layer 2 and Layer 3 VPNs as technologies that are in competition with each other, or are they complementary?

Martini: I wouldn’t say they are in competition, because the problems they are solving are different.

The place where Layer 3 VPNs really shine is in connecting a large number of small sites. It can be difficult to scale Layer 2 VPNs in that situation, but for most applications a Layer 2 VPN will scale just fine. And it has a better support model.

One of the problems with a Layer 3 VPN is that you have to learn what your customer information or routing information is, so the boundary between the service provider and the customer becomes more complex. And complexity breeds problems and higher support costs. Layer 2 VPNs offer a very simple interface that is easy to manage for both sides.

Light Reading: What do you say to people who say that people are using MPLS to solve too many problems? They believe it was designed just to do traffic engineering.

Martini: MPLS stands for multiprotocol label switching, right? So I think the original idea was to do all of this, but it was proposed a long time ago and the early application was traffic engineering. Personally, I think that MPLS is a merging of the best features of connection protocols like ATM and connectionless protocols like IP. MPLS offers the best features of both.

Level 3 is different from other carriers, because we have always had one network. To this day, five years later, we still have one network that uses MPLS to provide, voice, ATM, Frame Relay, and Ethernet services. A lot of traditional providers have different networks. And because they have separate networks, it’s costly to integrate them. Since we started with an integrated network, we save a lot of money, and that is the biggest benefit for us. Others might just use MPLS for traffic engineering or to expand some of those existing networks, but for us it is our core network technology to allow all these different applications to run over one single network.

Light Reading: Do you ever see Layer 2 VPNS replacing Frame Relay or ATM in directly connecting to customers?

Martini: This is the same argument that people had years ago about ATM to the desktop. I don’t think MPLS will ever go to the desktop. You might be able to do it, but I don’t think that is what the application was intended to do. MPLS is really a core technology. The protocols that exist today – ATM, Frame Relay, Ethernet, IP, and so forth – are really sufficient for all applications. There is really no need to create another protocol to go to the end user.

Light Reading: Some service providers like Qwest and Sprint, say they don’t want to use MPLS VPNs. They say they’d rather use IPSec. What do you think?

Martini: IPSec puts a huge cost on end devices. Also, it’s difficult to offer quality of service on an IPSec network, if one doesn’t own the core of the network.

Light Reading: Really?

Martini: We are meeting and exceeding current ATM network performance and quality-of-service parameters using MPLS VPNs. Also, IPSec is limited in terms of scaleability and bandwidth.

Light Reading: But some carriers are using network-based gear, like Nortel's Shasta or CoSine's box, so that IPSec doesn’t have be used end-to-end. Qwest says it actually scales better than MPLS VPNs.

Martini: Have you ever priced out a Shasta or CoSine solution?

Light Reading: So you’re saying you can do it more cheaply using MPLS?

Martini: Much cheaper, especially when you talk about using Ethernet as the access technology. One of the biggest reasons to use Ethernet is for its cost-efficient transport of bandwidth. You save a lot of money on the Ethernet interfaces, so you can’t start encrypting packets and buying expensive hardware to do that – it would defeat the purpose of the service.

Light Reading: So do you think there is a place for IPSec?

Martini: I’m sure there is a place for it somewhere. Service providers that don’t own their own networks might be interested in it. Or small service providers that are trying to link together lots of remote sites. I think that a lot of enterprises are doing their own VPNs over the Internet using IPSec. That’s really where the future is for IPSec.

Light Reading: What about multipoint Layer 2 MPLS VPNs like Virtual Private LAN Service? Have you gotten involved in any of the standards work?

Martini: Somewhat.

Light Reading: The Lassere-V.Kompella draft, which most companies are rallying around, uses LDP signaling, just as your draft does for point-to-point, right?

Martini: Yes, and it extends the Martini draft to support multipoint services.

Light Reading: Do you think there are issues with VPLS?

Martini: The major problem with VPLS is the management of the service. In a multipoint environment, you really have no idea where traffic is going. If there is a problem, it is very difficult to actually debug it and find out what’s happening. This is a problem that has been solved by IP.

So my question is: Why not just do Layer 3 MPLS VPNs? VPLS does not scale. I think these efforts are a recreation of ATM LAN emulation. People never really deployed LAN-E, and VPLS does the same thing. It is similar to LAN-E, except it has been simplified somewhat. But it’s still very difficult to manage, and I don’t think that carriers will find it profitable to do this.

Light Reading: Do you think that it would make more sense to use RFC 2547 to create Layer 3 MPLS VPNs?

Martini: Yes, or you could create a mesh of Layer 2 VPN tunnels. Layer 2 lets you create point-to-point tunnels, so that you can manage both ends – it’s much easier.

Light Reading: Are you saying that VPLS is unnecessary?

Martini: VPLS came about because metro area Ethernet providers wanted to hook some switches together. They thought, let’s extend this into the wide-area networks. The problem is it’s a lot more difficult to manage once it’s no longer limited to a few switches, and that is where the issues start.

Service providers don’t like a flat network, because they want to associate different costs with different links on the network. VPLS is a flat network. This might not be a problem for the enterprise, but it definitely wouldn’t work in a service provider network.

Light Reading: Carriers want a tiered network?

Martini: Yes. Links have a cost in a network. If you are in New York, you don’t want to charge the same amount for a link to L.A. as you would charge to Chicago, because the distance is different and financially it might cost more to send traffic to L.A. It has a lot do with peering agreements between carriers. Also, some links might be more congested than others. If you build a network that has no links defined, it will be difficult to assign a cost to the different links. If you use a point-to-point link, you can assign a different cost to each end point.

Light Reading: Are there mechanisms in RFC 2547 to keep track of links?

Martini: Actually, I have come out with a solution for assigning different prices to links used with RFC 2547. Service providers can map the cost of the underlying network into the overall cost metric, so you can solve this problem if you want.

Light Reading: VPLS supporters argue that it’s less complicated to configure than RFC 2547. And the big complaint with point-to-point links is that each link has to be individually provisioned.

Martini: In the end, you are going to have to provision at some point. Either the customer does it or the service provider does it, but somebody is going to have to provision the network. Although it might appear to be simpler to the customer to use VPLS, because all they see is an Ethernet plug, in the end the mechanisms to make it appear simple are fairly complicated. These mechanisms are also difficult to manage. There are a lot of networking protocols in place.

Light Reading: So is there a future for VPLS?

Martini: I think the market will decide. I have tried to control at least one implementation, so that it can at least be done cost effectively. But the market really has to decide, and people have to learn from implementation.Light Reading: Tell me a little bit about your role in the IETF.

Martini: It all started because a group of us were interested in getting the IETF to standardize the Layer 2 technology. Right now I am editor of the main drafts in the PWE3 working group. Basically, I am trying to steer it in the right direction. It’s doing pretty well. Everybody is pretty much agreeing right now on the direction we need to go.

But I am struggling to really maintain the service provider point of view. Unfortunately, we need to get more service providers involved in this particular organization. There are a few, but we need more. There’s a lot more vendors. And vendors have a different agenda. They are out there to sell you hardware and to make more money. So we have kind of a conflict of interest, because we [service providers] want cheaper technology.

Light Reading: How can you encourage service providers to be more involved in standards work?

Martini: I usually ask my friends at other service providers to participate and encourage them to come to the meetings. I think one of the issues we’ve had is the economic downturn. Everybody is very busy. We all have less staff, and people have less time to pay attention to these things. Hopefully, that will improve in the future.

Light Reading: Isn’t that true of the equipment vendors too? Or maybe they don’t have anything else to do?

Martini: Exactly!

Light Reading: Speaking of equipment vendors, Level 3 has worked closely with several startups, including edge routing startup, Laurel Networks. How closely involved are you, from a Level 3 perspective, with these companies?

Martini: I’ve worked with several vendors. Laurel was one of them. They are one of the ones with a very successful implementation of the protocol. But honestly, I’d rather not talk about specifics.

Light Reading: Alright – but what about in general? Do you see opportunity for new startups in the Layer 2 area?

Martini: [Laughs] I don’t know. I don’t think any startup has a good outlook right now. It’s really hard to speculate. These are tough economic times for everyone.

For more on the ins and outs of VPN deployment, see the most recent Light Reading Report: Carrier-Managed CPE IP VPNs.