Service Provider Networks / MPLS / View from the Edge:

Warning: MPLS and Rapid Spanning Tree could be hazardous to your network

Emerging standards for VPNs, Ethernet recovery are full of holes, experts say.

By Jim Duffy
The Edge, 8/10/01

This week's issue of Network World looks deep into two emerging standards and raises some caveats for service providers planning to or considering implementing them.

The first deals with Multi-protocol Label Switching (MPLS) and one of the killer applications for MPLS, VPNs. Carolyn Duffy Marsan (no relation) writes that two prominent Internet researchers from AT&T Labs say Layer 3 MPLS VPNs - based on RFC 2547 and the BGP protocol - present a potential routing table management nightmare. What's more, Layer 2 and Layer 3 MPLS VPNs are a security risk because they don't encrypt data.

The two researchers also hold leadership positions within the IETF, so their warnings about MPLS should be taken seriously.

The problem with RFC 2547, according to these researchers, is that ISPs must manage a special BGP routing table for each MPLS VPN and store parts of that routing table at every location where the VPN is accessed. This means that ISPs could be managing thousands of routing tables, a situation that's nearly impossible to administer and scale, the researchers say.

This problem can be circumvented by implementing MPLS VPNs at Layer 2, they say. But that approach is prone to security risks because the information is not automatically encrypted; if it is sent to the wrong person, it can be read by that person.

MPLS VPNs are also susceptible to leaked traffic if a connection is disrupted, the researchers say.

They recommend establishing VPNs with encrypted tunnels such as IPSec and forgetting about MPLS altogether, which wipes out one of the killer applications for MPLS.

The other standard to be wary of is IEEE 802.1w, or Rapid Spanning Tree. This algorithm greatly enhances the reconvergence time for Ethernet networks, from 30 seconds with Spanning Tree to a few seconds, or even milliseconds.

But therein lies the problem, as Terri Gimpelson writes in this week's issue: Any recovery time greater than 50 milliseconds - which is the norm in SONET networks - is unacceptable for carrier-grade service provisioning and service-level agreements.

The consensus among vendors, service providers and 802.1w authors is that Rapid Spanning Tree depends on other Ethernet standards, such as IEEE 802.3ad Link Aggregation, and a mesh topology on the metro core - which seems unlikely given the predominance of rings - to achieve restoration in the milliseconds. But then there are other issues with the standard, such as an alleged inability to isolate faults and to scale.

The bottom line with 802.1w is, if end users are considering subscribing to Ethernet metro services, they need to know explicit details of their service providers' network architecture and restoration techniques before they can negotiate meaningful and bulletproof SLAs.

MPLS and Rapid Spanning Tree: Caveat Emptor.