x
Optical/IP

Juniper: The VPLS Odd-Ball?

PARIS -- A demonstration of MPLS interoperability at the MPLS World Congress ’05 conference here has illustrated a couple of key points about Virtual Private LAN Service, the multi-point Ethernet service supported by Multiprotocol Label Switching (MPLS) (see MPLS Bigwigs Get Edgy).

First, significant progress has been made in solving scaleability and manageability issues that have held back VPLS deployments until now.

Second, everything isn't quite sweetness and light, notably because Juniper Networks Inc. (Nasdaq: JNPR) is persevering with promoting an alternative (and some would say better) version of VPLS that's imcompatible with everybody else's.

The interoperability demo was organized by the MPLS/Frame Relay Alliance and facilitated by European Advanced Networking Test Center AG (EANTC) (Light Reading’s testing partner).

Test equipment from Agilent Technologies Inc. (NYSE: A) and Ixia (Nasdaq: XXIA) was used (see Agilent Touts Multiservice Testing & Deal and Vendors to Demo MPLS Interoperability).

The demo indicates a fair degree of interoperability among vendors that have implemented hierarchical VPLS -- a new(ish) version of VPLS that sidesteps the issue of creating too many MPLS label-switched paths if a fully-meshed network is extended towards customer sites.

Hierarchical VPLS has a fully meshed core, which is linked to customer sites via pseudowires (point-to-point connections over MPLS infrastructure).

A total of 10 vendors participated in the interoperability demo, which spanned basic traffic engineering signaling, various pseudowire technologies, and management tools in addition to hierarchical VPLS. The gear that was tested for hierarchical VPLS interoperability was:



Cisco Systems Inc. (Nasdaq: CSCO) and Ciena Corp. (Nasdaq: CIEN) also participated in the demo, but didn’t field equipment supporting hierarchical VPLS.

Although the demo shows that hierarchical VPLS gear from different vendors interoperates in a small configuration, there are still some rough edges.

For instance, equipment extending VPLS towards customers often doesn’t support OSPF (Open Shortest Path First), so devices have to be configured manually. Also, vendors had implemented different versions of label switching path “ping” and “traceroute,” which meant that interoperability of operations, administration, and management (OAM) functions couldn’t be achieved in all cases.

Among notable absences from the demo is Juniper. Its version of VPLS is based on BGP (Border Gateway Protocol) rather than LDP (Label Distribution Protocol). It maintains that its BGP version of VPLS doesn’t suffer the scaleability issues of LDP-based VPLS, and thus doesn’t need a hierarchical structure.

The issue of which version is best is “a dead debate. Only Juniper is trying to revive it,” says Marc Lasserre, Riverstone’s chief scientist, noting that the proposal needs support from at least three vendors to become an Internet Engineering Task Force (IETF) RFC (request for comment).

Sources say that Juniper’s BGP version of VPLS is better technically than the LDP version, and that Juniper has persevered with it because of encouragement from some of its carrier customers. Although Juniper’s equipment wouldn’t interoperate with LDP-based VPLS equipment in the same cloud, carriers can connect Juniper VPLS clouds to LDP VPLS clouds, notes Hector Avalos, Juniper’s technical director of product and technology, EMEA.

Another notable absentee from the interoperability demo was Nortel Networks Ltd. (NYSE/Toronto: NT), which only announced VPLS equipment this week, and has yet to introduce hierarchical VPLS (see Nortel Adds to Multiservice Portfolio).

— Peter Heywood, Founding Editor, Light Reading

allidia 12/5/2012 | 3:26:07 AM
re: Juniper: The VPLS Odd-Ball? expected. Storage and Security is not a target. Who is Juniper wooing???
ChatEnChapeau 12/5/2012 | 3:26:10 AM
re: Juniper: The VPLS Odd-Ball? Wikipedia tells us that Sony continued to make and sell Betamax VCRs from the 80s until 1998 in the US and 2002 in Japan. Not clear how long Juniper is going to push BGP for VPLS.

http://en.wikipedia.org/wiki/B...

C-en-C

Laff of the day: just noticed the LightReading University ad - LRU. To us OS guys, it means Least Recently Used :-)
metroman 12/5/2012 | 3:26:10 AM
re: Juniper: The VPLS Odd-Ball? And who does K Kompella work for hmmmmm.....

They backed down against Martini when they initially said they would go with and developed only the kompella draft, I would not be suprised if they are privately working on LDP VPLS. I wonder what Peter Heywood's list of customers would think of that....

Metroman
Peter Heywood 12/5/2012 | 3:26:11 AM
re: Juniper: The VPLS Odd-Ball? Yes, it looks like another example of the classic technology versus market momentum issue, but if it was that simple, why has Juniper perservered?

I guess one reason might be that Juniper has already installed it.

Time Warner:
http://www.lightreading.com/do...

India's RailTel:
http://www.lightreading.com/do...

Italian Research Organization:
http://www.lightreading.com/do...

Sweden's Citylink:
http://www.lightreading.com/do...

light-headed 12/5/2012 | 3:26:11 AM
re: Juniper: The VPLS Odd-Ball? There is no proof that BGP4 is the "betamax" for VPLS or that it is more scalable. Juniper almost always wins when they are right with technical issues in IETF but perhaps juniper just is not right this time. Perhaps there are a few areas that they are no longer the technical leader in and they now resort to marketing and buying the technical leadership (yakov)to spout it. NO, that is heresy. Yakov would never advance company/his own goals if it was not the best technical solution. Heaven forbid.
metroman 12/5/2012 | 3:26:16 AM
re: Juniper: The VPLS Odd-Ball? OEM
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE