WEB EXTRA: Andy Malis, Tellabs

Tellabs Chief Technologist Andy Malis is something of a standards guru. He authored the IETF’s widely influential RF2547 standard governing IP VPNs, he has co-authored recent specifications for pseudowires and he serves as president and chairman of the MFA Forum, guiding standard development on multiple levels. He can say “single-segment pseudowire signaling” very quickly, as he did when he spoke with Telephony’s Ed Gubbins recently.

On Layer 2 versus Layer 3 services: Whether an enterprise wishes to buy a Layer 2 or Layer 3 service depends on the amount of outsourcing they want the service provider to do on their network. If you’re a very large enterprise and have your own large IT staff and know how to run the routers yourself, and you prefer to have complete control over your IT services and the routing and the bridging that you’re doing, you’d typically purchase a Layer 2 service from the service provider. That provides you with point-to-point interconnection between the routers you have at various locations. All the IP routing is completely under your control. However, if you’re a smaller corporation or someone who wants to outsource your IT to the service provider, you’d buy a Layer 3 VPN from them. You’re having the service provider do all the IP addressing for you. They take care of all your addressing plan needs; you don’t need to worry about configuring your own routers or anything like that. The Layer 3 VPNs allow the service provider to say to customers, “You don’t need a very sophisticated IT staff. We’ll take care of everything for you.” But the cost of that is the service provider is in complete control of the addressing plan that’s used on the customer network and things like that. That said, it’s become a huge business. In the calendar year 2005, Infonetics estimated service providers sold about $4 billion of Layer 3 VPN services. It’s a real business. Obviously lots of people like the fact that they don’t have to have very sophisticated in-house IT staff. They’re willing to offload a lot of it to the service provider.

On multisegment pseudowire (MS PW) standards: There are two ways to do MS PWs. The first is static provisioning. That work is basically done; you can do it now with a lot of existing vendor equipment. But it’s extremely time-consuming and expensive on the part of the service provider because they have to basically provision everything manually--the entire path of the PW. The IETF is now working on a spec for dynamic signaling for MS PWs. That’s an extension of the signaling what we use now in a single provider to set up a PW. That work is ongoing in the IETF; [Cisco’s] Luca Martini is the primary editor. That was accepted as a working group document at the last IETF meeting in November. It’s fairly well on its way. It will probably go for what’s known as “last call” at the next meeting in March. Following last call, it gets forwarded for final review to the group in the IETF known as the Internet engineering steering group. They do final technical reviews of all documents before they’re released as RFCs. They usually have a three-month review of documents, so I’d expect the earliest we could see it go for an RFC would be some time this summer. In the IETF, there’s a long tradition of specs showing up in equipment very often before they’re RFCs. However, this one’s fairly recent. I’m not aware of any implementations yet, but I believe there are implementations under way. We’ll probably see implementations come out just about the same time it gets published: some time in the summer.

On the Metro Ethernet Forum’s inter-carrier Ethernet specification: That’s a fairly simple spec. It makes the assumption that you have two providers that are providing Ethernet services using basically Ethernet-only equipment. They’ve built up metro Ethernet networks or wide-area Ethernet networks basically just using Ethernet-only equipment. This is the spec for how to interconnect the two service provider networks. It’s based on IEEE spec 802.1ah. They take each of the Ethernet frames from each carrier and encapsulate them into another MAC header for transport across the interface. They’re able to identify which customers the frames belong to. It’s currently a straw ballot. This comes fairly late in the process. It’s basically a last chance for the membership to review the spec and get in any last comments they have on it. At the next MEF meeting, they’ll review all these comments. Normally in the straw ballot stage, unless there’s some really serious problems people point out, it usually takes one more meeting to resolve all the comments and put it out for a final ballot. Assuming things go well in the first-quarter meeting, it would probably go out for member approval late in the spring. In terms of seeing it in vendor equipment, it’s a pretty simple spec. It’s based on IEEE specs people have already implemented. It doesn’t look like it would be difficult for vendors to add in to their equipment. Probably by the end of the year you’d see the ability to do this in vendor equipment. There’s also some provisioning required by service providers. Probably some time in 2007, you’ll see services based on it.

On the MFA Forum’s MPLS carrier interface specification: We’ve had this ongoing since the middle of last year; it’s well along the way. It’s more comprehensive, it’s not only for Ethernet services but a range of MPLS-based services that can go across an interface between carriers. In addition to Ethernet-over-MPLS for end-to-end Ethernet, you can also have IP VPNs and MPLS traffic engineering going between carriers. It specifies resiliency across the interface, quality of service, security and so on. It’s a bit behind the one in the MEF. We expect it will probably go to straw ballot following our April meeting. We’d resolve comments in the June meeting and after the June meeting it would go out for final ballot.