Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.
October 10, 2002
DENVER -- As if there weren't enough controversy over Multiprotocol Label Switching (MPLS), engineers from both Cisco Systems Inc. (Nasdaq: CSCO) and Juniper Networks Inc. (Nasdaq: JNPR) are diverging on a key element of the next-generation networking technology.
The companies yesterday presented dueling presentations here at the MPLScon Conference. Now it appears that a large divide is emerging in terms of which protocol to use for the signaling involved in emerging MPLS-based virtual private networks (VPNs).
The ins and outs of emerging VPN technologies, including MPLS, are detailed in a new Light Reading report, Virtual Private Networks. There are already differences in how MPLS should have been extended to support the likes of VPNs, including signaling. Signaling is the process through which the routers and switches talk to one another to set up MPLS routes and VPNs.
Yesterday, Juniper’s distinguished engineer Yakov Rekhter was the first to present his proposal. The audience wasn't exactly throwing rotten tomatoes during Rekhter’s presentation, but it was clear from the responses in the room that he had touched a nerve when he suggested that Border Gateway Protocol (BGP), a routing protocol used to broadcast information between routers in different networks, should be used not only to autodiscover network elements, but also to establish Layer 2 VPN connections between multiple end-points in an MPLS network.
This quickly put Cisco engineers on the attack.
“Is BGP a dessert topping and a floor wax?” asked Bruce Davie, a Cisco fellow, during the question-and-answer period that followed Rekhter’s presentation. “Don’t you think we may be asking too much of BGP?”
According to Rekhter, who was one of the original designers of the BGP protocol, it is completely capable of handling many roles, including signaling for Layer 2 VPNs based on MPLS. He claims that this would simplify the network, because the protocol is also used in Layer 3 VPNs and Ethernet networks. As a result, it would provide interoperability. He also argued that carriers are already using BGP in their networks, and that there is no need to add the overhead of another protocol.
“Why use two different protocols to do the same task?” he asked the audience. “I say you don’t have to.”
But many in attendance were skeptical of Rekhter’s proposal, which is also outlined in the Internet Engineering Task Force (IETF) draft written by Kireeti Kompella, another Juniper engineer. The main reason is that it flies in the face of an already widely accepted technology proposal called the "Martini" (no, it's not a drink), which defines both the method of MPLS encapsulation and point-to-point link setup.
In the draft named after himself, Luca Martini, senior architect at Level 3 Communications Inc. (Nasdaq: LVLT), asserts that Label Distribution Protocol (LDP) should be used as the signaling protocol to establish a Layer 2 VPN link and not BGP. Already several vendors including Cisco, Juniper, Laurel Networks Inc., and Riverstone Networks Inc. (Nasdaq: RSTN) claim to support Draft Martini for point-to-point Layer 2 connections.
Because the Martini draft only deals with point-to-point Layer 2 implementations, and Juniper’s proposal is for multipoint VPNs, Cisco has come up with a separate IETF draft that builds upon Draft Martini and incorporates pieces of Draft Kompella. Eric Rosen, the author of what is known as “The Autodiscovery Draft Extension to LDP,” proposes establishing Layer 2 MPLS tunnels using LDP, as it’s described in Draft Martini, but like Juniper he suggests using BGP for autodiscovery.
Azhar Sayeed, a manager in MPLS and QOS group at Cisco, who presented yesterday after Rekhter, supports the Rosen draft extension and argued that BGP would be unable to scale in large deployments. He claims the technology protocol would become a network management nightmare. He went on to explain that LDP does not create such a scenario.
“BGP is a very useful protocol for broadcasting the same information to multiple nodes,” he said during an interview following his presentation. “That’s why we say it should be used for autodiscovery. But for setting up Layer 2 point-to-point connections, LDP is better.”
Yes, it's that complex, and it points to yet more fragmentation in the MPLS market.
In the end it’s difficult to say how the controversy will play out. The IETF’s Pseudo Wire Emulation Edge to Edge (PWE3) working group, which is working on the standard for Layer 2 MPLS signaling, appears to be leaning more towards Martini draft and the Rosen draft.
But Rekhter scoffs at the standards process.
“The decision between BGP and LDP will be decided by the market and not standards,” said Rekhter. “I think we should keep the standards body out of this. At best they mess things up.”
“Look at RFC 2547 [a proposal for Layer 3 MPLS VPNs],” he continued. “It’s still not a standard, but it has clearly won out over virtual routers.”
Rekhter’s Cisco counterparts agree that ultimately the market will decide the path of the technology. In the meantime, whom will the other vendors follow? Elizabeth Hache, director of product strategies for Nortel Networks Corp. (NYSE/Toronto: NT), said she is leaning more toward Cisco not only from a technical perspective, but also from a practical one.
“It’s ironic that Yakov [Rekhter] used 2547 as his example,” she said. “Cisco actually developed that technology. As much as I hate to admit it, it’s hard to bet against Cisco.”
— Marguerite Reardon, Senior Editor, Light Reading
www.lightreading.comMovers and shakers from more than 100 companies – including Cisco and Riverstone – will be speaking at Lightspeed Europe. Check it outat Lightspeed Europe 02.
You May Also Like
Rethinking AIOPs — It's All About the DataMar 12, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Fiddling with Fixed WirelessMar 21, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Cable and 5G: The Odd Couple?Apr 18, 2024
SCTE® LiveLearning for Professionals Webinar™ Series: Delivering the DAA DifferenceMay 16, 2024