LDP-BGP Vpls Interworking

WHITE PAPER
LDP-BGP VPLS Interworking
Copyright © 2010, Juniper Networks, Inc.

WHITE PAPER - LDP-BGP VPLS Interworking
Table of Contents
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
How to Use this White Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
VPLS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
BGP-VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
LDP-VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Scaling Characteristics of LDP VPLS and BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Full-Mesh Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Provisioning VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Flooding and Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Exchanging Pseudowire Signaling State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Inter–Autonomous System Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Scaling Beyond a Single Metro Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Business Drivers for LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Scaling the VPLS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Extending the VPLS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Scaling an LDP-VPLS Network Using BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Pros and Cons of Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Redundancy in Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Interconnecting LDP- and BGP-VPLS Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Basic Interdomain LDP-BGP VPLS Interworking Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Interconnecting and Extending VPLS for Multiple LDP-VPLS Domains Using BGP VPLS . . . . . . . . . . . . . . . . . . . 17
Redundancy in Interdomain LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Simultaneously Providing LDP-BGP VPLS Interworking and PE Router Functionality . . . . . . . . . . . . . . . . . . . . . . 19
Pros and Cons of Interdomain LDP-BGP Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Operational Details: LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Operational Details: Basic LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Operational Details: Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Control Plane Operation of the Interworking PE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Forwarding Plane Operation of the Interworking PE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Example of VPLS Forwarding Between LDP-VPLS and BGP-VPLS Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Redundancy in Scalable LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BGP-VPLS Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Interworking PE Router Redundancy for the LDP-VPLS Groups Using BGP-VPLS Multihoming . . . . . . . . . . 27
Operational Details: Basic Interdomain LDP-BGP VPLS Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Reachability Between PE Routers and the Interworking Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ii Copyright © 2010, Juniper Networks, Inc.

Operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . 29

Control Plane Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Forwarding Plane Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Multihoming Multiple LDP-VPLS Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Table of Figures
Figure 1: LDP VPLS requires a full mesh of LDP sessions to be established
when a new PE router Is added. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 2: BGP sessions need to be set up only between the new PE router and the route reflector. . . . . . . . . . . . . . . . 5
Figure 3: In LDP VPLS, adding a new site requires manual configuration on
all existing member PE routers to create a full mesh of pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 4: BGP autodiscovery automates the member PE router discovery and
requires provisioning only on the PE router to which the site is added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 5: Resource-intensive flooding operation using ingress replication in which an ingress PE router
(PE1) makes multiple copies of an incoming multicast packet to send it to each egress PE router . . . . . . . . . . . . . . . . 7
Figure 6: Efficient flooding operation using P2MP LSP in which ingress PE router (PE1)
forwards the multicast packet on P2MP LSP and may require replication at a router. . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 7: LDP-VPLS network reference topology for scaling methods using BGP-VPLS signaling . . . . . . . . . . . . . . . 10
Figure 8: Scaling an existing LDP-VPLS network using the BGP-VPLS control plane . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 9: LDP-BGP VPLS interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 10: Multiple interworking PE routers placed in the VPLS network to
cap the LDP-VPLS deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 11: Redundancy in scalable LDP-BGP VPLS interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 12: Basic interdomain LDP-BGP VPLS interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 13: Extending the reach of the LDP-VPLS metro domain to the WAN
using the BGP-VPLS control plane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 14: Interconnecting multiple LDP domains on a single ASBR and
extending their reach to the WAN using the BGP-VPLS control plane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 15: Redundancy in interdomain LDP-BGP VPLS interworking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 16: CE device attached to border router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 17: Mapping the group of LDP-VPLS PE fouters to BGP-VPLS signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 18: Mapping the BGP-VPLS group in LDP-VPLS signaling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 19: Mapping of fully meshed BGP-VPLS and LDP-VPLS groups to a different
mesh group on the interworking PE router forwarding plane. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 20: Example of VPLS forwarding between LDP and BGP groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 21: Common MAC table state on interworking PE router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 22: BGP-VPLS signaling providing multihoming to the attached CE device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 23: BGP-VPLS Signaling multihoming procedure providing redundancy to the LDP-VPLS group . . . . . . . . . . 27
Figure 24: Designated interworking PE router becoming unreachable to the LDP-VPLS group. . . . . . . . . . . . . . . . . . 28
Figure 25: Reachability between the interworking router and all PE routers of all LDP-VPLS domains. . . . . . . . . . . 29
Figure 26: Interconnecting multiple LDP-VPLS domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 27: Multihoming multiple LDP-VPLS domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Copyright © 2010, Juniper Networks, Inc. iii

Executive Summary
Virtual private LAN service (VPLS) has emerged as one of the dominant MPLS applications today. Growing demand
for VPLS requires the VPLS network to scale to support many VPLS customers with multiple sites spread across
geographically dispersed regions. Key to scaling the VPLS network is how well the underlying VPLS control plane
scales. There are two widely deployed VPLS control planes, both standardized by the Internet Engineering Task Force
(IETF): one using BGP and the other using LDP. The scaling characteristics of both these control planes differ vastly.
BGP VPLS signaling offers numerous advantages over LDP VPLS. Additionally, the BGP-VPLS autodiscovery feature
offers substantial operational benefits that have already been proven in production networks.
This white paper presents various interworking mechanisms that leverage BGP VPLS to scale VPLS implementations
and augment existing LDP VPLS networks. The LDP-BGP VPLS interworking mechanism does not require any
changes to the existing LDP-VPLS provider-edge (PE) routers; rather, these methods allow for VPLS deployments to
scale by leveraging both BGP VPLS and LDP-BGP VPLS interworking mechanisms.
This white paper also discusses the use of BGP VPLS to extend the reach of VPLS from a single LDP-VPLS metro
domain into the intermetro WAN. This scheme allows service providers to offer regional and/or national VPLS in a
scalable and transparent way.
How to Use this White Paper

This white paper is organized so that you can go from a high-level overview down into the operation details of
LDP-BGP VPLS interworking.
OVERVIEWS
SECTION SECTION CONTENTS
VPLS Overview Overview of the BGP-VPLS and LDP-VPLS control planes, as well as VPLS
forwarding plane operations.
Scaling Characteristics of Overview of the following points:
LDP VPLS and BGP VPLS • Full-mesh connectivity
• Provisioning VPLS
• Flooding and broadcasting
• Exchanging pseudowire signaling state
• Scaling beyond a single metro area
•C
omparison of LDP-VPLS and BGP-VPLS control plane scaling characteristics
Business Drivers for LDP- Overview of the need to be able to scale and extend LDP-BGP VPLS networks
BGP VPLS Interworking
Scaling an LDP-VPLS verview and comparison of basic LDP-BGP VPLS interworking and scalable LDP-
O
Network Using BGP VPLS BGP VPLS interworking, including adding redundancy in the scalable solution
Interconnecting LDP- and Overview of the following points:
BGP-VPLS Domains • Basic interdomain LDP-BGP VPLS interworking scheme
• Interconnecting
and extending VPLS for multiple LDP-VPLS domains using
BGP VPLS
• Redundancy in interdomain LDP-BGP VPLS interworking
•S
imultaneously providing LDP-BGP VPLS interworking and PE router
functionality, including the pros and cons
• Pros and cons of interdomain LDP-BGP VPLS interworking
Copyright © 2010, Juniper Networks, Inc. 1

OPERATIONAL DETAILS
SECTION SECTION CONTENTS
Operational Details: Basic Operational details of the basic LDP-BGP VPLS interworking scheme
LDP-BGP VPLS Interworking
Operational Details: Scalable Operational details of the following points:
LDP-BGP VPLS Interworking • Control plane operation of the interworking PE router
• Mapping the group of LDP-VPLS PE routers to BGP-VPLS signaling
• Mapping the group of BGP-VPLS PE routers to LDP-VPLS signaling
• Forwarding plane operation of the interworking PE router
• Example of VPLS forwarding between LDP-VPLS and BGP-VPLS groups
• Redundancy in scalable LDP-BGP VPLS interworking
• BGP-VPLS multihoming
Operational Details: Basic Operational details of basic interdomain LDP-BGP VPLS interworking, including
Interdomain LDP-BGP details on reachability between PE routers and the interworking router
VPLS Interworking
Operational Details: Operational details of the following points:
Multiple LDP-VPLS Domains • Control plane enhancements
Interconnected Using
BGP VPLS • Forwarding plane enhancements
• Multihoming multiple LDP-VPLS domains
Introduction
Various implementations of VPLS enable the delivery of multipoint Ethernet services. VPLS is not only being
used by service providers to offer transparent LAN service to enterprise customers, but with the emergence of
metro Ethernet networks, VPLS is also being used as an infrastructure technology. Service providers are showing
significant interest as measured by their VPLS deployments; many are now offering inter-provider services. This
interest is further evidenced by the substantial growth of MPLS VPNs, which have a compound annual growth rate
(CAGR) of 12.8% to $6.4 billion in 2011.1 This growth has been fueled by the fact major multiple service operators
(MSOs) and large service providers are increasingly targeting small- and medium-sized businesses (SMB), as well
as large enterprises. Consequently, the growing demand for VPLS requires the underlying enabling infrastructure
to scale to support larger numbers of concurrent VPLS instances with multiple sites spread across geographically
dispersed regions.
This document specifies in detail the very mechanisms that allow the scalable rollout of VPLS, as well as the
enabling mechanisms that allow the interworking of LDP- and BGP-based VPLS.
VPLS Overview
A VPLS network is a Layer 2 multipoint VPN that emulates LAN services across a WAN. VPLS enables service
providers to interconnect several customer sites (each being a LAN segment) over a packet-switched network,
effectively making all the customer LAN segments behave as one single LAN. With VPLS, no routing interaction
occurs between the customer and service provider, and the customer can run any type of Layer 3 protocol between
sites.
The IETF Layer 2 VPN Working Group has produced two separate VPLS standards, documented in RFC 4761 and
RFC 4762 (see Kompella and Rekhter, Jan. 2007, and Lasserre and Kompella, Jan. 2007). These two RFCs define
almost identical approaches with respect to the VPLS data plane, but specify significantly different approaches to
implementing the VPLS control planes.
2 Copyright © 2010, Juniper Networks, Inc.

VPLS Control Plane

The VPLS control plane has two primary functions: autodiscovery and signaling.
Discovery refers to the process of finding all PE routers that participate in a given VPLS instance. A PE router can be
configured with the identities of all the other PE routers in a given VPLS instance, or the PE router can use a protocol
to discover the other PE routers. The latter method is called autodiscovery.
After discovery occurs, each pair of PE routers in a VPLS network must be able to establish pseudowires to each
other, and in the event of membership change, the PE router must be able to tear down the established pseudowires.
This process is known as signaling. Signaling is also used to transmit certain characteristics of the pseudowire that a
PE router sets up for a given VPLS.
BGP-VPLS Control Plane

The BGP-VPLS control plane, as defined by RFC 4761, is similar to that for Layer 2 and Layer 3 (see Kompella, Jan.
2006, and Rosen and Rekhter, Feb. 2006). It defines a means for a PE router to discover which remote PE routers
are members of a given VPLS (autodiscovery), and for a PE router to know which pseudowire label a given remote
PE router will use when sending the data to the local PE router (signaling). With the BGP-VPLS control plane, BGP
carries enough information to provide the autodiscovery and signaling functions simultaneously.
As in the BGP scheme for Layer 2 and Layer 3 VPNs, a route target is configured on each PE router for each VPLS
present on the PE router. The route target is the same for a particular VPLS across all PE routers and is used to
identify the VPLS instance to which an incoming BGP message pertains.
For each VPLS on each PE router, an identifier is configured, known as a site identifier. Each PE router involved in
a particular VPLS must be configured with a unique site identifier. The site identifier is same as the Virtual Edge
Identifier (VEID) referred to in RFC 4761.
A label block is a set of demultiplexor labels used to reach a given VPLS site within a set of remote sites. The PE
router uses a label block to send a single common update message to establish a pseudowire with multiple PE
routers, instead of having to send an individual message to each PE router.
LDP-VPLS Control Plane

In contrast to the BGP-VPLS control plane, the LDP-VPLS control plane provides only signaling, but not
autodiscovery. In this control plane, LDP is used to signal the pseudowires that are used to interconnect the VPLS
instances of a given customer on the PE routers. The LDP signaling scheme for VPLS is similar to the LDP scheme
for point-to-point Layer 2 connections (see Martini et al., Apr. 2006). In the absence of an autodiscovery mechanism,
the identities of all the remote PE routers that are part of a VPLS instance must be configured on each PE router.
The virtual circuit identifier (VCID), which is in the point-to-point Layer 2 connection used to identify a specific
pseudowire, is configured to be the same for a particular VPLS instance on all PE routers. Hence, the VCID enables a
PE router to identify the VPLS instance to which the LDP message refers.
LDP VPLS defines the hierarchical VPLS (H-VPLS) scheme in which, instead of all PE routers being fully meshed
with LDP sessions, a two-level hierarchy is created involving hub PE routers and spoke PE routers. The hub PE
routers are fully meshed with LDP sessions, whereas a spoke PE router has a pseudowire only to a single hub PE
router or to multiple hub PE routers for redundancy. Spoke pseudowires can be implemented using any Layer 2
tunneling technology.
Forwarding Plane
Forwarding plane procedures, at least for unicast and to some extent for multicast, are the same for both BGP VPLS
and LDP VPLS. For each VPLS, a PE VPLS data plane functions as a learning bridge and supports all the standard
bridge operations, such as MAC address learning, aging, and flooding. All the pseudowires established by BGP or
LDP signaling and the local customer edge (CE) router ports of a VPLS instance constitute the logical ports of a
bridge domain.
A MAC forwarding table is created for each VPLS instance on a PE router. This table is populated using a source MAC
address learning function and is used to forward unicast VPLS traffic based on the destination MAC address of the
received frame.

VPLS packets received over a pseudowire are not forwarded to any other pseudowire, but rather are forwarded only
on the attached CE router circuit. This behavior has been called split-horizon forwarding and is a consequence of the
PE routers being logically fully meshed in the data plane for each VPLS instance. The use of a full mesh combined
with split-horizon forwarding avoids Layer 2 loops and is the VPLS alternative to Spanning Tree Protocol (STP) within
the service provider network.
Scaling Characteristics of LDP VPLS and BGP VPLS

There are two distinct VPLS control planes: LDP based and BGP based, both of which have been standardized by the
IETF. This section compares the scaling aspects of the signaling and discovery mechanisms of these two control planes.
Full-Mesh Connectivity
To enable VPLS, all PE routers connected to common VPLS customers must be able to exchange VPLS signaling
information amongst themselves. As the number of PE routers in the network increases, scaling this signaling
component of the VPLS control plane becomes essential.
For LDP-VPLS signaling, the exchange of VPLS signaling information is accomplished by setting up a full mesh of
targeted LDP sessions between each pair of PE routers that have at least one VPLS in common (Figure 1). As the size
of the VPLS network grows, the number of LDP targeted sessions increases exponentially on the order of O(N^2),
where N is the number of LDP-VPLS PE routers in the network.
Maintenance of all these LDP sessions creates an additional load on the control plane of PE routers in the VPLS
network. The operational challenge resulting from the O(N^2) increase in LDP sessions becomes even more
noticeable when a service provider authenticates the sessions using Message Digest 5 (MD5) because MD5 keys
must be configured on each end of every LDP session. Adding a new PE router or deleting an existing one becomes a
cumbersome task because the configuration on each of the PE routers in the network must be modified.
PE1 PE4
PE2 PE5
PE3 PE6
Existing LDP session
New LDP session
PE7
New PE added
Figure 1: LDP VPLS requires a full mesh of LDP sessions to be established when a new PE router Is added
Unlike in LDP VPLS, the exchange of VPLS signaling information in BGP VPLS does not require a full mesh of control
sessions among all PE routers. Instead, the BGP-VPLS control plane, including its signaling component, can use a
route reflector (RR) hierarchy, in which only the route reflectors are fully meshed (Figure 2). Each BGP router then
establishes a BGP session to one or more route reflectors. Using route reflectors also makes the provisioning task of
adding or deleting a PE router simpler because only the BGP peering with the route reflector needs to be changed.

PE1 PE4
PE2 RR PE5
PE3 PE6
Existing BGP session
New BGP session
PE7
New PE added
Figure 2: BGP sessions need to be set up only between the new PE router and the route reflector
Route reflectors are a proven technology that is used extensively in networks in which BGP is deployed for Internet
routing or for other types of VPNs. Furthermore, BGP-VPLS route reflectors can be placed anywhere in the network;
that is, they do not need to be on the data path of the VPLS domains they host. This arrangement offers flexibility in
deploying new route reflectors when needed for even greater scaling.
LDP VPLS signaling has no mechanism similar to the route reflector hierarchy that can eliminate the full mesh of
targeted LDP sessions. H-VPLS tries, to some extent, to mitigate the full-mesh requirement by creating a two-level
hierarchy of hub and spoke devices. However, this attempt to scale the control plane changes the data plane behavior
and has a significant negative impact on the data plane. In contrast, because the BGP-VPLS route reflector technique
is purely a control plane technique, it does not change the forwarding path of VPLS traffic in any way, and thus has no
impact on the data plane.
Provisioning VPLS
For each customer attached to a VPLS network, a given PE router needs to know the identity of all the other PE
routers that attach to the customer’s other sites to create a full mesh of pseudowires. The PE router can learn
about other sites either from manual configuration (or provisioning) or by using a protocol to automatically discover
the identity of the other PE routers. In a large-scale network deployment, such an autodiscovery approach is
particularly efficient.
The LDP-VPLS control plane does not have inherent support of autodiscovery. Therefore, LDP-VPLS signaling relies
either on manual configuration to identify all PE routers to which customer sites are attached or on the use of BGP
for autodiscovery (Figure 3). In a large-scale deployment, the task of manual configuration is operationally inefficient
and subject to human error. Equally problematic, moving this task to a provisioning system adds considerable
complexity and expense. Moreover, any addition or removal of a VPLS customer site requires a configuration change
not only on the PE router to which the site is being added or deleted, but also on all the member PE routers of that
VPLS customer. Finally, the use of BGP for VPLS autodiscovery and LDP for VPLS signaling adds complexity to the
overall solution, both from the protocol perspective and from an operational and troubleshooting point of view.

A1 A4
Manual configuration
on all the member PEs
of VPLS Customer A
PE1 PE4
PE2 PE5
A2 A5
PE3 PE6
A3 A6
PE7
New site added A7 Psuedowire
Figure 3: In LDP VPLS, adding a new site requires manual configuration on all existing member
PE routers to create a full mesh of pseudowires
In contrast, the BGP-VPLS control plane supports automatic discovery of all PE routers to which a customer’s sites
are attached; the signaling component relies on this autodiscovery. Any addition or removal of a VPLS customer
site requires configuration changes only on the PE router to which the site is added or from which it is deleted.
The autodiscovery provided by BGP eliminates the need for any changes on other member PE routers of that VPLS
customer (Figure 4).

A1 A4
PE1 PE4
PE2 PE5
A2 A5
PE3 PE6
A3 A6
PE7
Only PE7 needs configuring; all

the member PEs of VPLS
Customer A are autodiscovered
New site added A7
Figure 4: BGP autodiscovery automates the member PE router discovery and requires
provisioning only on the PE router to which the site is added
Adding a new PE router in LDP VPLS requires a full mesh of targeted LDP sessions to be provisioned with all the
other PE routers in the network. In contrast, the task of provisioning a new PE router in BGP VPLS is simplified using
a route reflector hierarchy because only the BGP sessions with route reflectors need to be provisioned.
Flooding and Broadcasting

Flooding and broadcasting operations using ingress replication in a large VPLS topology can be both resource
intensive and bandwidth inefficient. These drawbacks are especially apparent on the first hop link from the PE router,
which may have to bear the full burden of the replication (Figure 5).
PE2 A2
To PE2
PE3 A3
A1 PE1 P
To PE3
To PE2
To PE4
To PE3
To PE4 PE4 A4
Broadcast/Multicast Packet
To flood, multiple copies are made and
forwarded to each member PE: PE1, PE2, PE3
Figure 5: Resource-intensive flooding operation using ingress replication in which an ingress PE router (PE1) makes multiple
copies of an incoming multicast packet to send it to each egress PE router

Point-to-multipoint (P2MP) label-switched paths (LSPs) introduce multicast to MPLS and enable several new
services, such as the distribution of IP-based television (IPTV). Enhancements in BGP VPLS enable the use of a P2MP
LSP VPLS-multicast (see Aggarwal, Kamite, and Fang, ND) for efficient and scalable flooding and broadcasting of
VPLS traffic (Figure 6). Juniper Networks® Junos® operating system supports this functionality using RSVP-TE P2MP
LSP, starting with Release 8.3.
While in principle LDP VPLS can also use P2MP LSP to scale the data plane, in practice no vendor has yet integrated
these two technologies.
PE2 A2
To PE2
PE3 A3
A1 PE1 P To PE4
To PE5
To (PE2, PE3, PE4)
PE4 A4
Broadcast/Multicast Packet
To flood, packet forwarded over P2MP LSP
P2MP LSP created by PE1

for VPLS Customer A
Figure 6: Efficient flooding operation using P2MP LSP in which ingress PE router (PE1) forwards the
multicast packet on P2MP LSP and may require replication at a router
Exchanging Pseudowire Signaling State

In both LDP VPLS and BGP VPLS, for each VPLS customer, signaling updates are exchanged between each pair of
member PE routers to create full-mesh connectivity in the data plane. The amount of signaling state that each PE
router needs to maintain and to exchange with other PE routers increases as VPLS expands, both in terms of the
number of VPLS customers and the number of member PE routers for each VPLS customer.
A single LDP-VPLS signaling update establishes only one pseudowire with one other PE router. In contrast, a single
BGP-VPLS signaling update establishes pseudowires with multiple PE router peers. Consequently, in large VPLS
networks, BGP VPLS requires far fewer signaling updates and therefore many fewer control plane messages than
LDP VPLS to establish a full mesh of pseudowires between pairs of PE routers. Having fewer control plane messages
reduces the control plane overhead on each PE router.
Inter–Autonomous System Operations

Service providers are seeking mechanisms to extend VPLS beyond a single autonomous system (AS). In some cases,
a service provider has multiple ASs because of acquisitions and mergers; in other cases, inter-AS operation is a
consequence of inter-provider VPLS.
LDP VPLS faces the following challenges in providing VPLS across multiple ASs.
• LDP VPLS requires one of two setups. One is the setup of LDP sessions between PE routers that are in different
ASs and therefore belong to different administrative entities, and possibly different providers. The other
potential setup is the use of multisegment pseudowires, which has its own complexities.
• The globally significant 32-bit VCID used by LDP signaling requires operationally intensive manual coordination
between ASs.
In contrast, in BGP VPLS the exchange of control traffic between ASs is localized to autonomous system border
routers (the so-called option B) or route reflectors (option C), thus fostering tight control over the information
exchanged and other factors, such as peer authentication. In addition, the use of the BGP route target constraint
further simplifies the task of determining which VPLS networks cross the AS boundary (and to which peer AS)
and which VPLS networks remain within the AS, thus facilitating exchange of control information across the AS
boundaries. Though BGP VPLS also requires site identifier coordination between ASs, the challenges of this
coordination can be mitigated using an autosite identifier.

Scaling Beyond a Single Metro Area

Many VPLS deployments are limited to a single metro area, primarily for fear of scaling to “MPLS in the large.” The
concern is in dealing with a large number of PE routers and provider routers in a single domain and making these
PE routers work together to offer VPLS. One potential challenge of scaling the overall network includes organizing
the interior gateway protocol (IGP) and partitioning the control and administrative domains. Other challenges include
the lack of adequate policy mechanisms to control which VPLS networks remain within a metro network and which
should be intermetro networks.
One useful approach to connecting multiple metro networks and a wide-area backbone in a scalable fashion is
to consider each metro network as a separate AS and the backbone as yet another AS. This approach enables
independent management of each metro network and the backbone, while enabling the inter-AS control plane
(BGP) to work seamlessly. This design also provides intermetro connectivity and intermetro VPLS. In this case,
the techniques described in this document can be used to scale a VPLS network beyond a single metro network to
connect a customer’s sites across the WAN. (Note, the process of connecting multiple metro networks and a wide-
area backbone in a scalable fashion is outside the scope of this paper.)
Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics

The signaling component of the BGP-VPLS control plane provides superior scaling characteristics in comparison
with the LDP-VPLS signaling component. Moreover, the BGP-VPLS control plane inherently supports autodiscovery
and uses route reflectors, both of which provide automation in deployment of
large-scale services, thereby reducing operating costs. Table 1 summarizes the LDP-VPLS and BGP-VPLS control
plane scaling characteristics.
Table 1: Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics

CHARACTERISTIC LDP VPLS BGP VPLS
Full-mesh requirement Alleviated only somewhat by Solved by the use of BGP route
H-VPLS, though at the expense of reflector hierarchy
introducing changes and additional
overhead in the data plane
Provisioning task of adding or Only somewhat simplified by Highly simplified by use of route
removing PE router H-VPLS reflector
Provisioning task of adding or Manual or through provisioning Automated by BGP’s autodiscovery

changing VPLS customer sites
VPLS with P2MP LSP integration to Currently not supported in any Supported in standards and
scale forwarding and data planes commercial implementation currently implemented
Signaling overhead Increases in proportion to the total Minimal because each signaling
number of pseudowires in the update can be used to establish
network multiple pseudowires
Business Drivers for LDP-BGP VPLS Interworking

Currently, both LDP VPLS and BGP VPLS are widely deployed in service provider networks. Two key business drivers
for LDP-BGP VPLS interworking are the need to scale and to extend the VPLS networks.
Scaling the VPLS Network

LDP VPLS works well for small-scale deployments. However, as the VPLS network expands, the LDP-VPLS control
plane does not scale well. In comparison, the BGP-VPLS control plane more easily enables the VPLS network to
scale to support new VPLS customers and to include more sites for existing VPLS customers.
One option for scaling the VPLS network when there is an existing LDP-VPLS deployment is to abandon the LDP-
VPLS control plane entirely and transition the VPLS network to the BGP-VPLS control plane. However, this approach
may not be feasible for a number of reasons, including the following two constraints.
• Legacy PE routers may not support a BGP signaling mechanism. To protect the current investment, replacing
the existing PE routers may not be a viable option.
• Operating overhead and possible disruption to the VPLS network for existing customers may undermine a
transition from the LDP-VPLS control plane to BGP VPLS.

Another option for scaling VPLS when there is an existing LDP-VPLS deployment is to cap the existing LDP-VPLS
deployment and to expand the VPLS network using the BGP control plane. With this approach, both LDP- and
BGP-VPLS control planes, including the signaling mechanisms, must coexist in the network, and there must be
interworking between the two control plane mechanisms.
Extending the VPLS Network

To be able to offer a regional or national VPLS network, service providers are seeking scalable ways to extend the
reach of VPLS beyond a single LDP-VPLS metro domain. One mechanism is the use of BGP VPLS in the WAN to
interconnect multiple LDP-VPLS metro domains. This approach requires a new interdomain technique because the
currently defined solutions for multiple ASs require that all domains be running the same signaling protocol.
One of the critical requirements for such a deployment model is ensuring that the existing PE routers in the
metro domains that are running the LDP-VPLS control plane do not require any changes or upgrades. A second
requirement is the extension of VPLS without significant additional load on the control plane of the LDP-VPLS PE
routers in the metro network.
The solution proposed in this paper meets the above requirements and enables service providers to use a single
protocol, BGP, in the WAN to offer multiple MPLS VPN services, including VPLS and Layer 2 and Layer 3 VPNs.
Moreover, because only a single protocol is used, provisioning the system can provide operating efficiency.
Scaling an LDP-VPLS Network Using BGP VPLS

Service providers can scale an LDP VPLS network by capping the existing LDP-VPLS deployment and expanding the
VPLS network with a BGP-VPLS control plane. Figure 7 shows the reference topology used in the discussion of these
mechanisms.
A1
PE1 (LDP)
PE2 (LDP)
B1
PE3 (LDP)
LDP session
B2 A2
Figure 7: LDP-VPLS network reference topology for scaling methods using BGP-VPLS signaling
The following are deployment methods for scaling a LDP-VPLS network using a BGP-VPLS control plane:
• Basic LDP-BGP VPLS interworking
• Scalable LDP-BGP VPLS interworking wherein service providers can add redundancy to minimize VPLS network
disruptions

Basic LDP-BGP VPLS Interworking

With basic LDP-BGP VPLS interworking, newly added PE routers in the network support both the LDP and BGP
control planes, including the corresponding signaling mechanisms. These newly added PE routers use the BGP-
VPLS control plane when communicating with each other, and use the LDP-VPLS control plane to communicate with
the existing PE routers running LDP VPLS.
The topology in Figure 8 illustrates how to expand the LDP-VPLS network shown in Figure 7 using BGP signaling.
The PE routers PE1, PE2, and PE3 are existing LDP-VPLS PE routers and communicate with the newly added PE
routers using the LDP control plane. The newly added PE routers (PE4, PE5, and PE6) support both LDP and BGP
control planes.
A3 A1
PE4
(BGP LDP)
PE1 (LDP)
PE5
(BGP LDP) PE2 (LDP)
A4
B1
RR
C1
PE6 PE3 (LDP)

(BGP LDP)
A2
C2
B2
LDP session
BGP session
Figure 8: Scaling an existing LDP-VPLS network using the BGP-VPLS control plane
This deployment model facilitates expansion of existing VPLS customer sites, enabling a service provider to add new
sites to BGP-VPLS PE routers while keeping the existing sites unchanged on the LDP-VPLS PE routers. For example,
in Figure 8, VPLS Customer A’s new sites A3 and A4 are attached to the newly added PE routers PE4 and PE5,
respectively, and the customer’s existing sites continue to be attached to the already deployed LDP-VPLS PE routers
PE1 and PE3.
A key feature of this interworking mechanism is that no changes are made to the currently defined LDP-VPLS control
plane (RFC 4762; see Lasserre and Kompella, Jan. 2007). The PE1, PE2, and PE3 routers continue to communicate
using the LDP-VPLS control plane. From their perspective, the newly added BGP-VPLS PE routers (PE4, PE5, and
PE6) are simply LDP-VPLS PE routers. The PE4, PE5, and PE6 routers, on the other hand, use both the BGP-VPLS
and LDP-VPLS control planes. They use the BGP-VPLS control plane between them for autodiscovery and for
signaling, establishing an internal BGP (IBGP) session between themselves. They also use LDP-VPLS signaling to
communicate with the PE1, PE2, and PE3 routers, establishing LDP sessions with the existing PE routers.
For all VPLS customers that have sites only on either the existing LDP-VPLS PE routers or the newly added BGP-
VPLS PE routers, VPLS is set up using only a single control plane and a single signaling protocol. For example,
in Figure 8, VPLS for Customer B is set up using only the LDP-VPLS control plane and signaling, and VPLS for
Customer C is set up using only the BGP-VPLS control plane and signaling.

Pros and Cons of Basic LDP-BGP VPLS Interworking

Table 2 is a summary of the pros and cons of this basic LDP-BGP VPLS interworking deployment model.
Table 2: Pros and Cons of Basic LDP-BGP VPLS Interworking Deployment Model
PROS CONS
• No changes are required on existing LDP-VPLS PE • Each newly added PE router may need to be
routers when the BGP-VPLS control plane is deployed configured with a full mesh of targeted LDP-VPLS
to scale the VPLS network, thus protecting the current sessions to the existing LDP-VPLS PE routers.
investment in existing LDP-VPLS PE routers. Hence, LDP-VPLS deployment is not completely
• Existing VPLS customer service is not disrupted when capped because each new PE router that supports
the BGP VPLS is rolled out in the network. the BGP-VPLS control plane may also need to be set
up for the LDP-VPLS control plane.
• Potentially increases the provisioning overhead
because newly added PE routers need to be
configured for two control planes instead of just one.
• For VPLS networks that span both LDP-VPLS PE
routers and BGP-VPLS PE routers, each newly added
BGP-VPLS PE router results in additional control
plane load on the LDP-VPLS PE routers.
Scalable LDP-BGP VPLS Interworking

Shortcomings of the previous method, which fails to cap the LDP-BGP VPLS deployment entirely, can be eliminated
using a more scalable LDP-BGP VPLS interworking model. Such a model employs two groups of PE routers. All
PE routers in the first group run only the LDP-VPLS control plane among themselves, whereas all PE routers in
the second group run only the BGP-VPLS control plane among themselves. These two groups are interconnected
through a single PE router, referred to as the interworking PE router, which runs both LDP-VPLS and BGP-VPLS
control planes. Figure 9 illustrates how the LDP-VPLS network shown in Figure 7 is expanded using the BGP control
plane in a scalable model.
A3 A1
PE4 (BGP)
PE1 (LDP)
Interworking
PE
A4 PE5 (BGP) PE7

(BGP LDP) PE2 (LDP)
B1
C1 RR
PE6 (BGP) C3 PE3 (LDP)
A2
C2
B2
LDP session
BGP session
Figure 9: LDP-BGP VPLS interworking

In Figure 9, the PE1, PE2, and PE3 routers are existing PE routers supporting only the LDP-VPLS control plane. The
newly added PE routers (PE4, PE5, and PE6) support the BGP control plane. The PE7 router is the interworking PE
router, supporting both LDP and BGP control planes and the interworking between these two distinct control planes.
The existing LDP-VPLS PE routers and the newly added BGP-VPLS PE routers are isolated into two groups. The
PE7 router is part of both groups and plays the vital role of interconnecting them. For example, VPLS Customer
A has multiple sites in both the LDP- and BGP-VPLS groups. Customer A’s Site A1 and A2 are connected to the
LDP PE routers, and Sites A3 and A4 are connected to the BGP PE routers. PE7 router provides the LDP-BGP
VPLS interworking function and stitches the pseudowires created by the signaling components of the two different
control planes.
• PE routers in the BGP-VPLS group are provisioned only for the BGP-VPLS control plane. From their perspective,
the interworking PE router (PE7) is a standard BGP-VPLS peer, and they are unaware of the existence of the PE
routers that are part of the LDP-VPLS group behind the interworking PE router.
• Legacy PE routers in the LDP-VPLS group are provisioned only for the LDP-VPLS control plane. From their
perspective, the interworking PE router (PE7) is a standard LDP-VPLS peer, and they are unaware of the
existence of the PE routers that are part of the BGP-VPLS group behind the router PE7.
Containing all the existing LDP-VPLS PE routers in a single group caps the LDP-VPLS deployment and allows
network expansion to occur in the BGP-VPLS group without creating additional control plane or data plane overhead
on existing LDP-VPLS PE routers. Moreover, this method eliminates a fundamental problem with the previous
method: the requirement that all BGP-VPLS PE routers also operate in the LDP-VPLS control plane.
In some network designs, containing all the LDP-VPLS PE routers in a single group may not be feasible because
of geographical limitations or other administrative reasons. In such environments, multiple groups of PE routers
can be running the LDP-VPLS control plane and a single group of PE routers can be running the BGP-VPLS control
plane, which interconnects all the LDP-VPLS control plane groups through multiple interworking PE routers as
shown in Figure 10.
A5
A3 A1
PE9
(BGP)
PE4 (BGP)
PE1 (LDP)
PE7 and PE8 are
interworking PEs
A4 PE5 (BGP) PE7

(BGP LDP) PE2 (LDP)
PE8 (BGP LDP)
C3 B1
C1
RR
PE6 (BGP) PE3 (LDP)
A2
C2 B2
LDP session
BGP session
Figure 10: Multiple interworking PE routers placed in the VPLS network to cap the LDP-VPLS deployment

Redundancy in Scalable LDP-BGP VPLS Interworking

This scalable model in which the BGP-VPLS signaling is added to an existing LDP-VPLS network provides scaling
characteristics similar to those of a pure BGP-VPLS deployment, but suffers from lack of redundancy. Because only
a single PE router connects the two groups of LDP-VPLS PE routers and BGP-VPLS PE routers, this router is a single
point of failure, and any problem with this router can adversely affect service for many customers. To alleviate this
problem, service providers can place redundant interworking PE routers in the network to avoid the problem of a
single point of failure that could disrupt the VPLS network.
Figure 11 illustrates a redundancy scheme in the scalable deployment model. This topology shows two interworking
PE routers (PE7 and PE8). At any given time, only one interworking PE router is designated to interconnect the LDP
and BGP groups. For example, if router PE7 is elected to be a designated interworking PE router, PE8 is in a standby
state. If any failures occur on router PE7, PE8 takes over as the designated interworking PE router.
A3 A1
C3
PE4 (BGP)
PE1 (LDP)
PE7
(BGP LDP)
A4 PE5 (BGP)
PE2 (LDP)
B1
C1
RR
PE8
(BGP LDP)
PE6 (BGP) PE3 (LDP)
A2
C2 B2
LDP session
BGP session
Figure 11: Redundancy in scalable LDP-BGP VPLS interworking

Note that no new mechanisms are needed to provide the redundancy for this scheme. The BGP-VPLS control plane
defines the multihoming procedure for providing redundancy when a CE router is attached to multiple PE routers
(see Kompella and Kothari, Nov. 2007). This same multihoming procedure is used to provide redundancy for scalable
LDP-BGP VPLS interworking.
A key feature of this redundancy scheme is that no changes are required on the existing PE routers belonging to the
LDP-VPLS group. From their point of view, the PE7 and PE8 routers are standard LDP-VPLS peers, and the existing
PE routers are not aware of the redundancy provided by these two routers.
Designated interworking PE election is performed for each VPLS customer whose sites span the LDP and BGP-VPLS
groups. The results of the election can be influenced by the configuration on the interworking PE routers so that
VPLS customers can be load balanced across the redundant interworking PE routers.

Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking

Table 3 is a summary of the pros and cons of the scalable LDP-BGP VPLS interworking model.
Table 3: Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking Deployment Model
PROS CONS
• No changes are required on existing LDP-VPLS PE At any given time, only one interworking PE router
routers when the VPLS network is scaled using the carries the traffic from LDP VPLS to BGP VPLS, thus
BGP-VPLS control plane. Thus, the existing investment creating a choke point. One way to alleviate congestion
in existing LDP-VPLS PE routers is protected. at the choke point is to use different interworking PE
• For VPLS networks that span both LDP-VPLS PE routers for different VPLS. Then each VPLS uses only
routers and BGP-VPLS PE routers, each newly added one interworking PE router, and not all VPLS use the
BGP-VPLS PE router does not result in additional same interworking PE router.
control plane load on the LDP-VPLS PE routers.
• PE routers in the BGP-VPLS group are configured to
run only a single BGP-VPLS control plane. Thus, the
scaling characteristics of such a deployment model
approximate those of a pure BGP-VPLS deployment.
• PE routers in the BGP-VPLS group can use P2MP LSP
technology for efficient flooding and broadcasting,
whereas PE routers in the LDP-VPLS group continue
to use ingress replication to deliver the traffic.
• Placing redundant interworking PE routers in the
network creates a robust solution. No new protocols
are required to affect the redundancy because the
existing BGP-VPLS multihoming mechanism is used.
• Redundant interworking PE routers provide both load
balancing and resiliency.
Interconnecting LDP- and BGP-VPLS Domains

The term domain refers to an AS running a particular VPLS control plane technology. Each metro network is
considered a separate AS.
Previous sections described various LDP-BGP VPLS interworking deployment models within a single metro network
or AS with LDP-VPLS and BGP-VPLS control plane technologies both deployed. Service providers can, however,
set up interdomain VPLS networks in which each domain is running a different VPLS control plane technology.
The main application of such an interdomain scheme is expansion of the VPLS network beyond a single LDP-VPLS
metro domain in the WAN. This deployment model, implemented using BGP VPLS, enables service providers to offer
regional or national VPLS in a scalable fashion.
Two interdomains LDP-BGP VPLS interworking deployment schemes are as follows:
• Basic LDP-BGP VPLS interworking between two domains, where one domain uses LDP signaling and the other
uses BGP signaling
• Interconnection of multiple LDP-VPLS domains using BGP-VPLS signaling

Basic Interdomain LDP-BGP VPLS Interworking Scheme

Figure 12 shows the reference topology used in the discussion of interdomain LDP-BGP VPLS interworking. In this
topology, Domain X is an LDP VPLS domain, and Domain Y is a BGP-VPLS domain. Two VPLS customers, A and B,
have sites in both domains.
B2 A1
Interdomain LDP-BGP L-PE1

VPLS interworking
C-PE1
A4
C-PE3
ASBR1
DOMAIN X
(LDP VPLS)
ASBR2
DOMAIN Y RR
(BGP VPLS)
L-PE2
C-PE2
LDP session B1 A2
BGP session
C-PE = Core PE Router
A3 B3
L-PE = LDP-VPLS PE Router
Figure 12: Basic interdomain LDP-BGP VPLS interworking
Domain Y’s AS border router (ASBR2) performs the LDP-BGP VPLS interworking to interconnect the two domains
running different VPLS control planes. This border router is configured to run both control planes. ASBR2 is the only
router in the topology that is aware that VPLS Customers A and B have sites in both domains.
This interdomain scheme is analogous to the single-domain scalable LDP-BGP VPLS interworking scheme
previously discussed. ASBR2 is the equivalent of the interworking PE router, and the LDP- and BGP-VPLS domains
are equivalent to the two groups containing the LDP-VPLS and BGP-VPLS PE routers.
The PE routers in BGP-VPLS Domain Y are provisioned only for the BGP-VPLS control plane. From their perspective,
ASBR2 is a standard BGP-VPLS peer. The PE routers are not aware of the existence of LDP-VPLS Domain X behind
ASBR2.
The PE routers in LDP-VPLS Domain X are provisioned only for the LDP-VPLS control plane and require minimal
configuration changes to provision additional LDP sessions with ASBR2. From their perspective, ASBR2 is a standard
LDP-VPLS peer. The PE routers are not aware of the existence of BGP-VPLS Domain Y behind ASBR2.

Interconnecting and Extending VPLS for Multiple LDP-VPLS Domains

Using BGP VPLS
Interconnecting multiple metro networks using BGP VPLS is the most efficient and scalable way to extend VPLS
beyond the metro network.
Figure 13 shows how basic interdomain LDP-BGP VPLS interworking techniques can be expanded to interconnect
multiple LDP-VPLS domains using the BGP-VPLS control plane in the WAN. The existing PE routers in domains
Metro X and Metro Y are not aware that the border routers C-ASBR1 and C-ASBR2 are extending their domain reach
using the BGP-VPLS control plane in the WAN.
B2
A4 A1
C-PE1
Interdomain LDP-BGP Interdomain LDP-BGP
M-PE3 M-PE1
VPLS interworking VPLS interworking
RR
METRO Y
(BGP VPLS) METRO X
M-ASBR2 M-ASBR1
WAN (LDP VPLS)
(BGP VPLS)
C-ASBR2 C-ASBR1
M-PE4 M-PE2
C-PE2
B4 A5 B1 A2
A3 B3 LDP session
BGP session
Figure 13: Extending the reach of the LDP-VPLS metro domain to the WAN using the BGP-VPLS control plane
A single autonomous system border router (ASBR) can also be used to aggregate and interconnect several LDP-
VPLS metro domains, thus extending the reach of all the domains in the WAN. In other words, a single ASBR can be
used to extend the reach of multiple metro domains. Figure 14 illustrates such a scenario. In this topology, C-ASBR1
interconnects three VPLS domains: Metro X, Metro Y, and WAN. In addition, this ASBR extends the reach of all the
domains to the WAN core by using BGP VPLS. This method provides seamless VPLS to Customer A, which has sites
in domains Metro X, Metro Y, and WAN.
A3 A1
M-PE1
A5
M-ASBR1
C-PE1
METRO X M-PE5
(LDP VPLS)
A6 RR
M-PE2 METRO Z
M-PE3 M-ASBR3
C-ASBR1
CORE (LDP VPLS)
A7 (BGP VPLS)
M-ASBR2
C-ASBR2
METRO Y M-PE6
(BGP VPLS) C-PE2
A8
LDP session
M-PE4 A4 A2
BGP session
Figure 14: Interconnecting multiple LDP domains on a single ASBR and extending their reach to the WAN using the BGP-VPLS control plane

C-ASBR1 forwards all VPLS traffic between Metro X and Metro Y.

The PE routers in the LDP-VPLS domains Metro X and Metro Y are provisioned for LDP VPLS, and no software
upgrades are required on these routers. Only one configuration change is necessary to provision an additional LDP
session with C-ASBR1. From the perspective of the PE routers in the LDP-VPLS domain, C-ASBR1 is a standard
LDP-VPLS peer, and the PE routers are not aware that it directly or indirectly is interconnecting the local metro
domain with other metro domains. No additional control plane or data plane overhead is placed on the existing PE
routers, so this solution allows VPLS to scale across multiple geographical locations.
The PE routers in the BGP-VPLS domain (WAN) are provisioned only for BGP VPLS. From their perspective, C-ASBR1
is a standard BGP-VPLS peer, and the PE routers are not aware of the existence of either of the LDP-VPLS domains
behind the ASBR.
In the WAN domain, multiple ASBRs can be used to directly or indirectly interconnect multiple geographically
dispersed metro domains, thus facilitating a regional or national VPLS network. Metro domains can be set up using
either the LDP-VPLS or the BGP-VPLS control planes. For BGP-VPLS metro domains, the multi-AS interdomain
options suggested by RFC 4761 can be used (see Kompella and Rekhter, Jan. 2007). For LDP-VPLS metro domains,
the LDP-BGP VPLS interworking scheme discussed in this section must be used.
The border router, which provides interworking between the LDP- and BGP-VPLS control planes, is the most
critical element for providing an interdomain VPLS network for many customers. Any failure on the border router
can constrain the scope of the VPLS network to a single domain, and thus can severely affect the interdomain VPLS
network for many customers. To provide redundancy, multiple border routers can be placed in the network.
Redundancy in Interdomain LDP-BGP VPLS Interworking

Figure 15 illustrates the redundancy mechanism for interdomain LDP-BGP VPLS interworking. This redundancy
scheme is the same as discussed for the scalable, redundant LDP-BGP VPLS interworking deployment.
B2 A1
M-PE1
C-PE1
A4
C-PE3 C-ASBR1
M-ASBR1
METRO X
RR (LDP VPLS)
CORE
(BGP VPLS)
M-PE2
C-PE2 C-ASBR2 LDP-BGP VPLS

Interworking
B1 A2
LDP session
A3 B3 BGP session
Figure 15: Redundancy in interdomain LDP-BGP VPLS interworking

Following are the important points to note about the topology shown in Figure 15:
• The redundant ASBRs (C-ASBR1 and C-ASBR2) are placed in the network to ensure that VPLS is not affected if
one of the ASBRs fails.
• Each LDP-VPLS domain is multihomed to both the redundant routers.
• Existing BGP-VPLS multihoming procedures provide the redundancy. At any time, only one ASBR is elected by
the BGP-VPLS multihoming procedure as an interworking PE router for each VPLS customer that is part of an
LDP-VPLS domain. The other ASBR is in a standby state.
• If the designated interworking PE router fails or disconnects from the LDP-VPLS domain, the standby ASBR
becomes the designated interworking PE router.
This solution allows load balancing to occur between the redundant C-ASBR routers. Load balancing can be enabled
so that different primary designated interworking PE routers are selected for different VPLS customers that have
sites in multiple domains.
Simultaneously Providing LDP-BGP VPLS Interworking and PE Router Functionality

One advantage of the interdomain interworking schemes discussed in this section is that they enable an ASBR to
provide PE router functionality (that is, CE router attachment) at the same time that the ASBR is performing the
LDP-BGP VPLS interworking task. Figure 16 illustrates the dual functionality. In this topology, Site B3 of VPLS
Customer B is attached to the border router C-ASBR1 itself. The same VPLS customer also has Sites B1 and B2 in
the LDP and BGP domains, respectively. Thus, for VPLS Customer B, C-ASBR1 simultaneously enables interdomain
VPLS across the LDP and BGP domains and plays the role of PE router.
A1
B2
[LDP-BGP VPLS
Interworking + PE] M-PE1
B3
C-PE1
A4
C-PE3
M-ASBR1 METRO X
RR (LDP VPLS)
C-ASBR1
CORE
(BGP VPLS)
M-PE2
C-PE2
B1 A2
LDP session
A3 B3 BGP session
Figure 16: CE device attached to border router

Pros and Cons of Interdomain LDP-BGP Interworking

Table 4 is a summary of the pros and cons of the interdomain LDP-BGP VPLS interworking model.
Table 4: Pros and Cons of Interdomain LDP-BGP VPLS Interworking

PROS CONS
• LDP-BGP VPLS interworking is achieved with just When the WAN and metro domains are owned
localized changes on the ASBR. A single ASBR can be by different providers, ASBR ownership may be
used to extend the VPLS network for multiple LDP- anissue because the C-ASBR router placed in the
VPLS domains. WAN is performing the critical task of LDP-BGP
• Legacy PE routers in the LDP-VPLS domain require VPLS interworking. A possible solution is to have
no changes except the addition of an LDP session to a metro ASBR perform the task of LDP-BGP VPLS
the ASBR. interworking. This solution makes use of BGP-VPLS
inter-AS options between the metro ASBR and WAN
• The number of LDP sessions and the pseudowire state ASBR. (Details of such a solution are not discussed in
in each LDP-VPLS domain remain approximately the this paper.)
same as when the VPLS network was limited to a single
domain. Therefore, the control and data planes of the
existing LDP-VPLS PE routers are unaffected when the
VPLS network is expanded outside the domain.
Operational Details: LDP-BGP VPLS Interworking

This section discusses the operation details for each of the previously described LDP-BGP VPLS interworking
methods:
• Basic LDP-BGP VPLS interworking
• Scalable LDP-BGP VPLS interworking
• Basic interdomain LDP-BGP VPLS interworking
• Multiple LDP-VPLS domains interconnected using BGP VPLS
Operational Details: Basic LDP-BGP VPLS Interworking

The basic LDP-BGP VPLS interworking method requires minimal configuration changes on the existing LDP-VPLS
PE routers. However, new PE routers that are being added as part of the network expansion must support both LDP
VPLS and BGP VPLS. The support on the new PE routers is the essence of what is needed for basic LDP-BGP VPLS
interworking to succeed. Because the new PE routers support both LDP VPLS and BGP VPLS, they can establish
pseudowires using both the LDP and BGP signaling mechanisms. These pseudowires can be created for VPLS
customers with sites attached to both existing LDP-VPLS routers and the newly added BGP-VPLS routers.
A full mesh of pseudowires is created between the existing LDP-VPLS PE routers and the newly added BGP-VPLS PE
router. As a result, data plane operations on all PE routers adhere to the split-horizon forwarding rule, and the VPLS
traffic is not switched between pseudowires. Additionally, no changes are required to the existing LDP or BGP control
plane procedures themselves.
Figure 8 illustrates the operation of the basic LDP-BGP VPLS interworking method. For the control plane on router
PE4, both BGP VPLS and LDP VPLS are enabled for VPLS Customer A. For BGP VPLS, a unique route target (RT) is
assigned for the customer that enables PE4 to autodiscover router PE5 and subsequently to establish a pseudowire
with PE5 for Customer A. For LDP VPLS, on PE4 the identities of all the remote PE routers (PE1 and PE3) attached to
the same customer must be configured. As a result, PE4 establishes LDP-VPLS pseudowires with PE1 and PE3. No
changes are required in the VPLS forwarding plane operations on router PE4.
Operational Details: Scalable LDP-BGP VPLS Interworking

Scalable LDP-BGP VPLS interworking entails dividing all PE routers of a VPLS network into two groups so that one
group contains all the LDP-VPLS PE routers and the other group contains all the BGP-VPLS PE routers. One PE router,
referred to as the interworking PE router, is part of both groups. All other PE routers can be part of only one group.
This method requires that only the interworking PE router supports and operates both the LDP-VPLS and BGP-VPLS
control planes. All other PE routers support and operate only either the LDP-VPLS or BGP-VPLS control plane,
depending on the group to which they belong.

Note that all PE routers in each group are fully meshed in the data plane using either the LDP- or BGP-based VPLS
control plane. The interworking PE router interconnects the two fully meshed LDP-VPLS and BGP-VPLS groups to
ensure that the VPLS network appears and functions the same as if all PE routers in the entire VPLS network were
fully meshed.
For each VPLS customer with sites that span both the LDP-VPLS and BGP-VPLS groups, the interworking PE router
creates LDP-VPLS pseudowires using LDP signaling in the LDP group, and it creates BGP-VPLS pseudowires using
BGP-VPLS signaling in the BGP group. Then this router stitches the pseudowires created by LDP VPLS and BGP
VPLS to provide seamless VPLS. (Note that if all sites of a VPLS customer are contained within a single group, an
interworking function is not needed.)
Control Plane Operation of the Interworking PE Router

This section describes the interworking mechanisms across signaling domains.
Mapping the Group of LDP-VPLS PE Routers to BGP-VPLS Signaling

Figure 17 illustrates how an interworking PE router and other PE routers that are part of a BGP-VPLS group view an
LDP-VPLS group attached to the interworking PE router. Conceptually, the interworking PE router and all the other
PE routers in the BGP-VPLS group that are running BGP signaling view the LDP-VPLS group as a VPLS site with a
single CE router.
BGP VPLS LDP VPLS
BGP SITE ID:2 PE4 PE1
A3 (Interworking PE) A1
PE3
BGP SITE ID:1
BGP SITE ID:3
Advertised BGP
A4 signaling route A2
PE5 PE2
<Local site:1, Offset:1, Label base:800> LDP VPLS group appears as attached
CE site from BGP signaling perspective
Attached CE device
BGP-VPLS pseudowire
LDP-VPLS pseudowire
Figure 17: Mapping the group of LDP-VPLS PE fouters to BGP-VPLS signaling
On the interworking PE router, from the BGP-VPLS perspective, the LDP-VPLS group is analogous to a VPLS site
with a single CE router. The LDP-VPLS group is mapped in BGP-VPLS signaling by assigning it a unique site identifier
in that VPLS domain. The BGP-VPLS control plane uses this site identifier to create and advertise the VPLS network
layer reachability information (NLRI) to all the other remote PE routers in the BGP-VPLS group. Each remote PE
router uses this NLRI for both the autodiscovery and the signaling that set up the pseudowire between each PE
router and the interworking PE router. The remote PE router treats the interworking PE router as a regular PE
router and is not aware that the pseudowire set up with the interworking PE router connects the remote PE router to
the LDP-VPLS groups. Therefore, this method does not require a full mesh of pseudowires between the PE routers
in both the BGP-VPLS and LDP-VPLS groups. Furthermore, no changes in the BGP-VPLS control plane procedure
defined by RFC 4761 are required.

The BGP-VPLS control plane defines the Layer 2 information extended community to communicate the operating
status (active or inactive) of the attached CE router site to the remote BGP-VPLS peers. Because the LDP-VPLS
group is equivalent to a CE router site, the BGP-VPLS control plane can also communicate the operating status
of the LDP-VPLS group the same way it communicates the operating status of the attached CE router site. The
interworking PE router computes the operating status of the LDP-VPLS group by examining the operating status of
each LDP-VPLS pseudowire in the group.
Mapping the Group of BGP-VPLS PE Routers to LDP-VPLS Signaling

Figure 18 illustrates how an interworking PE router and other PE routers in the LDP-VPLS group view the BGP-VPLS
group attached to the interworking PE router. Conceptually, the interworking PE router and all the other PE routers in
the LDP-VPLS group that are running LDP signaling view the BGP-VPLS group as a VPLS site with a single CE router.
BGP VPLS LDP VPLS
PE1
PE4
PE3
A4
PE5
A2
PE2
LDP VPLS group appears as attached Attached CE device

CE site from LDP-VPLS signaling perspective BGP-VPLS pseudowire
LDP-VPLS pseudowire
Figure 18: Mapping the BGP-VPLS group in LDP-VPLS signaling
On the interworking PE router, from the LDP-VPLS perspective, the BGP-VPLS group is analogous to a CE device.
Remote PE routers in the LDP-VPLS group view the interworking PE router as a standard LDP-VPLS PE router with
an attached CE device. Therefore, for the entire BGP-VPLS group, only a single LDP session is required between the
interworking PE router and each of the other LDP-VPLS routers in the LDP-VPLS group. For each VPLS customer
with sites in the BGP-VPLS group, a single pseudowire is created between the interworking PE router and the LDP-
VPLS routers in the LDP-VPLS group.
Viewing the BGP-VPLS group as an attached CE device is a key concept in allowing the VPLS network to scale
without increasing the number of LDP sessions or pseudowires in the network. This view results in no changes in
the LDP-VPLS signaling procedure defined in RFC 4762. Therefore, existing LDP-VPLS PE routers do not need to be
upgraded when deploying such an interworking scheme.
Forwarding Plane Operation of the Interworking PE Router

From the control plane perspective, the BGP and LDP PE routers view each other as CE devices attached to the
interworking PE router. Both routers establish both LDP and BGP pseudowires for each VPLS customer having sites
in both the LDP- and BGP-VPLS groups.
For each VPLS customer with sites in both groups, the forwarding plane of the interworking PE router maintains a
common MAC table. This table is critical because it is used for stitching pseudowires between the LDP- and BGP-
VPLS groups. This common MAC table is populated by learning the source MAC addresses from the frames arriving
on LDP- and BGP-VPLS pseudowires. The interworking PE router performs a destination MAC address lookup
on each frame arriving over a pseudowire to determine the pseudowire on which to forward the frame. However,
forwarding across pseudowires requires the following forwarding plane changes on the interworking PE router.

In plain VPLS, forwarding traffic across pseudowires is prohibited by the split-horizon forwarding rule because of
the assumption that all PE routers in the VPLS network are fully meshed in both the control and data planes. This
assumption, however, is no longer correct in this LDP-BGP VPLS interworking scheme because LDP-VPLS PE
routers and BGP-VPLS PE routers are not fully meshed in the control and data planes. In the entire VPLS network,
only the interworking PE router is fully meshed with all other PE routers. Therefore, to connect the LDP-VPLS and
BGP-VPLS groups, the interworking PE router allows VPLS traffic to be forwarded across pseudowires.
Because all PE routers of the LDP- and BGP-VPLS groups are fully meshed within their respective sets and
interworking PE router, the interworking PE router needs to ensure that frames received over the pseudowire are
not forwarded back to the same group from which they were received. To achieve this forwarding plane behavior,
the concept of a mesh group is introduced on interworking PE routers. In the context of the VPLS forwarding plane,
a mesh group is a collection of all the fully meshed pseudowires. Multiple mesh groups can be created on the
interworking PE router: one for each fully meshed LDP or BGP group of pseudowires connected to it.
The split-horizon forwarding rule is modified so that it applies to each mesh group rather than to each of the
individual pseudowires. The interworking PE router uses the MAC table to perform a destination MAC address
lookup for each incoming frame and determines the pseudowire on which the frame should be forwarded. When the
pseudowire is determined, the forwarding plane applies the mesh group split-horizon forwarding rule to ensure that
packets are not forwarded back to the same group from which they were received.
In the topology in Figure 19, the interworking PE router (PE3) interconnects the LDP- and BGP-VPLS groups. All the
routers in the BGP-VPLS group (PE3, PE4, and PE5) can exchange signaling information with each other through the
route reflector hierarchy, and they are fully meshed in the data planes. Similarly, all routers in the LDP-VPLS group
(PE1, PE2, and PE3) are fully meshed in the control and data planes. The forwarding plane of the interworking PE
router maintains a MAC table to connect the two groups. Two mesh groups are created in the forwarding plane of the
interworking PE router (PE3): one containing pseudowires of the BGP-VPLS group (with routers PE4 and PE5) and
the other one containing pseudowires of the LDP-VPLS group (with routers PE1 and PE2).
The following example shows the application of the split-horizon rule for a mesh group. A frame received on
PE3 over the LDP-VPLS pseudowire from PE1 will not be forwarded to PE2 LDP-VPLS pseudowire because the
pseudowires to both the PE1 and PE2 routers are in the same mesh group. However, this frame can be forwarded on
BGP-VPLS pseudowires to routers PE4 and PE5 if the destination MAC address is unknown or has been learned from
one of the BGP-VPLS pseudowires.
BGP VPLS LDP VPLS
PE1
PE4
Common MAC table
PE3
A4
PE5
A2
BGP-VPLS LDP-VPLS PE2
mesh group mesh group
BGP-VPLS pseudowires (PE4, PE5) LDP-VPLS pseudowires (PE1, PE2)

BGP-VPLS pseudowire
LDP-VPLS pseudowire
Figure 19: Mapping of fully meshed BGP-VPLS and LDP-VPLS groups to a different mesh group
on the interworking PE router forwarding plane

Following is a summary of forwarding plane operation on an interworking PE router:

• A MAC table is maintained to switch the traffic between the LDP- and BGP-VPLS groups.
• The VPLS split-horizon forwarding rule is relaxed to allow forwarding across pseudowires.
• The concept of a mesh group is introduced to group fully meshed pseudowires and to apply the split-horizon
forwarding rule to each mesh group.
• The MAC address learning operation remains unchanged.
Note that these forwarding plane changes are localized to just the interworking PE router. All other PE routers in the
BGP- and LDP-VPLS groups do not require changes to their forwarding plane operations.
Example of VPLS Forwarding Between LDP-VPLS and BGP-VPLS Groups

Figure 20 illustrates VPLS forwarding between an LDP-VPLS group and a BGP-VPLS group. In this topology,
Customer A’s sites A1 and A2 are in the LDP-VPLS group and are attached to routers PE1 and PE2, respectively. Sites
A3 and A4 are in the BGP-VPLS group, attached to routers PE4 and PE5, respectively.
BGP VPLS LDP VPLS

PE4 PE1
A3 A1
PE3
(Interworking PE)
A4 BGP-VPLS LDP-VPLS A2
PE5 PE2
mesh group mesh group
BGP-VPLS pseudowires (PE4, PE5) LDP-VPLS pseudowires (PE1, PE2)
Path of flooded frame originated from site A1 BGP-VPLS pseudowire

Path of unicast frame originated from site A3 LDP-VPLS pseudowire
and destined to A1
Figure 20: Example of VPLS forwarding between LDP and BGP groups
Looking at the interworking PE router, consider the control plane operation that creates the LDP- and BGP-VPLS
pseudowires in the LDP and BGP groups. Suppose that routers PE1 and PE2 have an LDP session between them and
establish a pseudowire with each other for Customer A, and suppose that routers PE4 and PE5 have a BGP session
between them and establish a pseudowire with each other for the same Customer A. Because VPLS Customer
A is part of both the LDP- and BGP-VPLS groups, the interworking PE router (PE3) is configured to establish an
LDP VPLS pseudowire with PE1 and PE2. As well, the BGP-VPLS control plane of the interworking PE router
autodiscovers that PE4 and PE5 are part of VPLS Customer A and establishes a BGP VPLS pseudowire with PE4
and PE5. The result is that the interworking PE router joins the fully meshed LDP and BGP groups for Customer
A. Moreover, in the data plane, PE3 creates two mesh groups for VPLS Customer A. One mesh group contains
the pseudowires for all BGP-VPLS PE routers (routers PE4 and PE5), and the other mesh group contains the
pseudowires for all LDP-VPLS PE routers (PE1 and PE2).

Now look at the interworking PE router data plane operation that connects the pseudowires of the LDP and BGP
groups that have been established by the control plane. Suppose that Site A1 sends a frame whose destination MAC
address is in Site A3, but none of the PE routers have learned that MAC address yet. As far as PE1 is concerned, the
other sites of VPLS Customer A are connected to PE2 and PE3, so it floods the frame to these two routers. When PE3
receives the packet from Site A1, it floods the packet to PE4 and PE5 but not to PE2, in accordance with the mesh
group split-horizon rule. Remember, this rule states that packets are not forwarded back to the same mesh group
from which a packet is received. When PE4 and PE5 receive the frame forwarded by the interworking PE router, they
forward it to Sites A3 and A4.
As a result of this process, each PE router that forwards the frame learns that the source MAC address carried in the
frame is in Site A1 and updates its MAC table accordingly. If Site A3 subsequently sends a frame to that MAC address,
the frame is forwarded as follows.
• PE4 performs a MAC lookup and forwards the frame on the pseudowire to PE3.
• PE1 performs a MAC lookup and forwards the frame on the attached CE router interface to A1.
Figure 21 shows the state of the MAC table on the interworking PE router after the VPLS frames have been
exchanged between Sites A1 and A3.
MAC Address Next Hop

MAC (A1) Pseudowire (PE1)
MAC (A3) Pseudowire (PE4)
Figure 21: Common MAC table state on interworking PE router
Redundancy in Scalable LDP-BGP VPLS Interworking

This section discusses how the currently defined BGP-VPLS multihoming procedure is used to provide resiliency
in the scalable LDP-BGP VPLS interworking method. This procedure places multiple redundant PE routers in the
network and configures redundancy for those VPLS customers desiring this service. Thereafter, the BGP-VPLS
multihoming procedure ensures the following:
• No loops occur in the network and no duplicate packets are forwarded. For each VPLS customer, a single
designated interworking PE router is elected to interconnect the two groups. The second redundant
interworking PE router acts as a backup and does not participate in the VPLS forwarding.
• If the designated interworking PE router fails in any way, the backup interworking PE router is elected as the
designated interworking PE router.
Note that a designated interworking PE router is elected for each VPLS customer and that the election can be
influenced by the configuration. This flexibility enables BGP-VPLS multihoming procedures to provide load balancing
along with much needed resiliency.
BGP-VPLS Multihoming
In BGP VPLS, a CE device can be multihomed to multiple PE routers. Traffic to and from the CE device is forwarded
only by the single PE router that has been elected as the designated forwarder (DF). All other PE routers that are
connected to the multihomed CE router are marked as being in standby mode and do not participate in the traffic
forwarding. Figure 22 illustrates a multihoming scenario in which the site containing router CE1 is multihomed to
routers PE1 and PE2 for redundancy.

Local preference:200
PE1
DF for Site 1
<Local site:1, Offset:1, Label base:800, UP>
BGP SITE ID:1
CE2
PE3 CE1
Link to CE1 marked Administrative Down

<Local site:1, Offset:1, Label base:700, UP> Backup for Site 1
PE2
Path of VPLS traffic originating from CE1 BGP-VPLS pseudowire

Path of VPLS traffic destined for CE1
Figure 22: BGP-VPLS signaling providing multihoming to the attached CE device

The key to enabling multihoming is mapping the multihomed CE device to a BGP site using the same site identifier
for all PE routers to which the CE device is connected. When the site identifier is the same, the PE routers all
originate the same VPLS NLRI, and as a result all PE routers in the VPLS domain learn that the specific site is
multihomed. For example, in Figure 22 CE1 is mapped to the site identifier 1 on both PE1 and PE2. Consequently, all
PE routers that have that VPLS (PE1, PE2, and PE3) learn that a site with site identifier 1 is multihomed to PE1 and
PE2. The next step is for all PE routers that have that VPLS to elect a single designated forwarder for the multihomed
site, which is assigned a site identifier of 1.
For all PE routers in the network to elect the same PE router as a designated forwarder, they must use the same
path selection procedure, as specified by the BGP-VPLS multihoming draft (see Kompella and Kothari, Nov. 2007)
for each multihomed site. Moreover, if one wants to elect a particular PE router as the designated forwarder, the
election mechanism can be influenced by assigning a higher local preference to the BGP-VPLS route originated for a
multihomed site by that PE router.
In Figure 22, PE1 is configured with a higher local preference value (200), and is thus elected as the designated
forwarder by all PE routers. To ensure that the VPLS domain has no loops, only PE1 handles traffic between
the attached CE1 interface and the rest of the VPLS domain. Router PE2 marks the attached CE1 interface as
administratively inactive and does not participate in forwarding for CE1.
If PE1 fails for any reason, the VPLS route advertised by PE1 is withdrawn, and PE2 is elected as the designated
forwarder by all PE routers that have sites of that VPLS, thus providing redundancy. To speed up the process of re-
election of a designated forwarder after such a failure, each PE router uses a distinct route distinguisher (RD) rather
than using the same RD for all PE routers of a given VPLS. To be precise, any of the following failures in the topology
just described cause a switchover.
• Access interface between CE1 and PE1 fails. If this occurs, BGP VPLS on PE1 advertises the operating status of
the attached CE device as inactive and triggers the election of a new designated forwarder for the multihomed
site.
• PE1 fails. This failure brings down the BGP session, which results in the withdrawal of all the VPLS routes
advertised by PE1 and triggers the election of a new designated forwarder for the multihomed site.

Interworking PE Router Redundancy for the LDP-VPLS Groups Using BGP-VPLS Multihoming
In the scalable interworking method, from the perspective of BGP VPLS, the LDP-VPLS group is equivalent to a CE
device. In Figure 22, the CE device can be replaced with an LDP-VPLS group, and the routers PE1 and PE2 can be
replaced with the redundant interworking PE routers, enabling redundancy in LDP-BGP VPLS interworking. This
scenario results in the topology shown in Figure 23.
BGP VPLS LDP VPLS
A3
BGP SITE ID:2

PE1
DF for Site 1
BGP SITE ID:1
A2 A1
PE3 PE4
BGP SITE ID:3
Pseudowire to PE4
marked Administrative Down
Backup for Site 1
PE2
BGP SITE ID:4
Path of VPLS traffic originating from A1 BGP-VPLS pseudowire

A4
Path of VPLS traffic destined for A1 LDP-VPLS pseudowire
Figure 23: BGP-VPLS Signaling multihoming procedure providing redundancy to the LDP-VPLS group
The following requirements must be met to enable BGP-VPLS multihoming in LDP-BGP VPLS interworking scenarios:
• The LDP-VPLS group must be multihomed to redundant interworking PE routers. Thus, all PE routers that are
part of the LDP-VPLS group must have LDP sessions with both the interworking PE routers. They must also
establish pseudowires with both the interworking PE routers for each VPLS customer that has sites in both
the LDP and BGP groups and that desires redundancy. For example, in Figure 23, for VPLS Customer A, PE4
establishes a pseudowire with both redundant interworking routers (PE1 and PE2).
• Each LDP-VPLS group must be associated with the same BGP-VPLS site identifier on all interworking PE
routers. Different LDP-VPLS groups must have their own BGP-VPLS site identifiers on all the interworking PE
routers. This step is essential because it enables the interworking PE router to notify all BGP-VPLS peers that
the particular site, mapped to the LDP-VPLS group, is being multihomed. Consequently, a single designated
interworking PE router is elected for each such site. For example, in Figure 23, for VPLS Customer A, the
pseudowire that PE4 establishes with the redundant interworking routers PE1 and PE2 is mapped in BGP-VPLS
signaling using the same site identifier, 1.
Figure 23 serves as a reference topology to demonstrate VPLS packet forwarding with redundant interworking PE
routers. Suppose that PE1 is elected as the designated interworking PE router because a higher local preference
value is assigned to the site to which the LDP-VPLS group is mapped. Also suppose that Site A1 sends a frame
whose destination MAC address is in Site A2, but none of the PE routers have learned that MAC address yet. As far
as PE4 is concerned, the only other sites of VPLS Customer A are connected to PE1 and PE2, so it floods the frame
to these two routers. PE2 drops the frame because it is not a designated interworking PE router for the LDP-VPLS
group for that customer. On the other hand, PE1, which is marked as a designated interworking PE router, floods the
frame to both PE2 and PE3, as well as to the locally attached CE router site, A3. PE3, in turn, floods the frame to A2.
Note that PE2 also floods the frame received from PE1 to its locally attached CE router site (A4). As a result

of this process, each PE router that forwards the frame learns that the source MAC address in the frame is in Site
A1 and updates its MAC table accordingly. If Site A2 subsequently sends a frame destined for that MAC address, it is
forwarded as follows:
• PE4 performs a MAC lookup and forwards the frame on the attached interface to A1.
If any failures occur that disconnect PE1 from the LDP-VPLS group, PE2 advertises the LDP-VPLS group mapped site
status as inactive, which causes all the BGP-VPLS peers to elect PE2 as a new designated interworking PE router.
Figure 24 illustrates one such failure in which PE1 loses connectivity to all PE routers in the LDP-VPLS group. As a
result, PE2 is elected as the new designated interworking PE router and handles the forwarding of traffic between A1
and A2.
BGP VPLS LDP VPLS
A3
BGP SITE ID:2 Local preference:200

PE1
<Local site:1, Offset:1, Label base:800, DOWN> Failure causing Site 1 to be unreachable
BGP SITE ID:1
A2 A1
PE3 PE4
BGP SITE ID:3
<Local site:1, Offset:1, Label base:700, UP> New designated forwarder for Site 1
PE2
BGP SITE ID:4
Path of VPLS traffic originating from A1 BGP-VPLS pseudowire

A4
Path of VPLS traffic destined for A1 LDP-VPLS pseudowire
Figure 24: Designated interworking PE router becoming unreachable to the LDP-VPLS group
Operational Details: Basic Interdomain LDP-BGP VPLS Interworking

The basic interdomain LDP-BGP VPLS interworking scheme is analogous to the scalable LDP-BGP VPLS
interworking scheme. An ASBR in the BGP-VPLS group plays the role of the interworking device, and each LDP and
BGP domain is the equivalent of separate groups of LDP- and BGP-VPLS PE routers in a single domain.
The operation details of basic interdomain LDP-BGP VPLS interworking are the same as discussed for scalable LDP-
BGP VPLS interworking. To summarize, an ASBR between BGP-VPLS domains supports both the LDP- and BGP-
VPLS signaling mechanisms and uses a common MAC table to stitch the pseudowire created between the domains.
Multiple redundant ASBRs can be used for resiliency.
Reachability Between PE Routers and the Interworking Router

One important aspect of network design for interdomain LDP-BGP VPLS interworking is ensuring that an
interworking router can reach all PE routers in all parts of all domains. PE routers that belong to only a single
domain must be able to reach all other PE routers and the interworking router.
Interworking router reachability to all PE routers in all domains can be achieved in numerous ways. Figure 25
depicts one approach, which protects each domain from the IGP churn in other domains. In this topology, for both
scaling and administrative independence, the WAN and Metro X domains each have their own IGP instances, referred

to as IGP1 and IGP2, respectively. A third IGP instance, IGP3, is introduced between each metro domain and the WAN,
thus creating a demilitarized zone (DMZ). The loopback addresses of the C-ASBR and the metro-PE (M-PE) routers
must be leaked into and out of IGP3. BGP can be used in the DMZ.
C-PE1 M-PE1
A3 A1
DMZ (IGP3)
IGP2
IGP1 CORE
METRO X
(BGP VPLS)
(LDP VPLS)
C-ASBR M-ASBR
A4 A2
C-PE2 M-PE2
C-ASBR loopback address

No leaking needed M-PE loopback address
BGP-VPLS pseudowire LDP-VPLS pseudowire
Figure 25: Reachability between the interworking router and all PE routers of all LDP-VPLS domains
The C-ASBR must also establish transport tunnels with all PE routers in the Metro X domain and the WAN core. On
the C-ASBR, a different transport tunnel technology can be used for different domains: for example, RSVP-TE in the
WAN core and LDP in the metro domains.
Operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS

The methods discussed thus far require LDP and BGP interworking between only two islands, where each island
can be a set of fully meshed PE routers or a separate domain. In contrast, the approach of interconnecting multiple
LDP-VPLS domains using BGP VPLS allows an interworking router to interconnect a single BGP-VPLS domain
and multiple LDP-VPLS domains. Therefore, the interworking router stitches not only LDP and BGP pseudowires,
but also LDP pseudowires across multiple LDP-VPLS domains. This method requires subtle enhancements in the
control and forwarding plane procedure defined for the scalable model.
Control Plane Enhancements

Fundamentally, the control plane mechanism is the same as defined in the section “Control Plane Operation of the
Interworking PE Router.” In essence, BGP VPLS and LDP VPLS each view each other as a logical CE device. However,
this method has multiple fully meshed LDP-VPLS domains that are connected to the interworking router, unlike
the scalable and basic interdomain methods that have only one fully meshed LDP-VPLS domain connected to the
interworking router. Hence, on the interworking router, all the fully meshed domains need to be mapped to BGP-
VPLS signaling. LDP-VPLS signaling also needs to map the BGP-VPLS domain and all other LDP-VPLS domains.
Multiple LDP-VPLS domains can be mapped to BGP-VPLS signaling in three ways:
• Consider all LDP-VPLS domains as a single logical CE device and then map all these domains to a single BGP site,
which is assigned a single site identifier. This option is the most basic and is used when multihoming is not enabled.
• Consider each LDP-VPLS domain as a distinct logical CE device and then map each domain to a separate
BGP site, with each site assigned a separate site identifier. This option is used when multihoming needs to be
enabled for all LDP-VPLS domains.
• Use a combination of the above two options, with some LDP-VPLS domains grouped and mapped to a single
site, and other LDP-VPLS domains treated as a separate logical CE device. This option allows multihoming to be
enabled selectively only for some domains.
Having multiple options provides multihoming functionality at the granularity of a single LDP-VPLS domain. This
behavior is consistent with the way BGP VPLS allows the mapping of multiple real CE devices.

Forwarding Plane Enhancements

For interconnection of multiple LDP-VPLS domains using BGP VPLS, the key aspects of the forwarding plane on the
interworking device remain the same: a common MAC table is used, and mesh groups are used for split-horizon
forwarding. However, unlike the scalable and basic interdomain LDP-BGP VPLS interworking methods, in which two
mesh groups are sufficient, for this method the interworking router supports multiple mesh groups. Each LDP-VPLS
and BGP-VPLS domain is mapped to a unique mesh group because each domain is fully meshed. This mesh group
provides a mechanism for grouping fully meshed pseudowires and enforcing the split-horizon forwarding rule within
a single domain.
Figure 26 shows the forwarding plane behavior. Suppose that Site A1 sends a frame whose destination MAC address is
Site A5, but none of the PE routers have yet learned that MAC address. As far as M-PE1 is concerned, the other sites
of Customer A’s VPLS are connected to M-PE2 and C-ASBR1, so M-PE1 floods the frame to M-PE2 and C-ASBR1.
C-ASBR1 floods the frame to M-PE3, M-PE4, and C-ASBR2 because they are all in different mesh groups from M-PE1,
but it does not forward the frame to M-PE2 because both M-PE1 and M-PE2 are in same mesh group. C-ASBR2
subsequently forwards the frame to M-PE5 and M-PE6. When M-PE5 receives the frame, it forwards it to Site A5.
Path of flooded frame originating from A1

Path of unicast frame from A5 to A1
M-PE1 A1
Path of unicast frame from A4 to A1
BGP-VPLS pseudowire
LDP-VPLS pseudowire
MG = Mesh group METRO X
A2
A5
M-PE5 BGP SITE ID:2
MG: Metro A
WAN M-PE2
METRO Z BGP SITE ID:1 M-PE3

MG: Metro C A3
A6 C-ASBR2 C-ASBR1 MG: Metro B
METRO Y
M-PE6 A4
<Local site:1, Offset:1, Label base:700>
<Local site:2, Offset:1, Label base:750>

M-PE4
Figure 26: Interconnecting multiple LDP-VPLS domains
As a result of this process, each PE router that forwards the frame learns that the source MAC address of the frame
is in Site A1 and updates its MAC table accordingly. If Site A5 subsequently sends a frame to that MAC address, the
frame is forwarded as follows:
• M-PE5 performs a MAC lookup and forwards the frame on the pseudowire to C-ASBR2.
• C-ASBR2 performs a MAC lookup and forwards the frame on the pseudowire to C-ASBR1.
• C-ASBR1 performs a MAC lookup and forwards the frame on the pseudowire to M-PE1.
• M-PE1 performs a MAC lookup and forwards the frame on the attached interface to A1.
The following forwarding path is taken for the frames originating from Site A4 and destined to Site A1. Sites A4 and
A1 are located in adjacent LDP-VPLS domains interconnected by C-ASBR1.
A4 → M-PE4 → C-ASBR1 → M-PE1 → A1

Multihoming Multiple LDP-VPLS Domains

Figure 27 shows two LDP-VPLS domains (Metro X and Metro Y), both multihomed to routers C-ASBR1 and C-ASBR2.
Path of flooded traffic originating from A1

Path of unicast VPLS traffic from A5 to A1 Local preference:
Site 1:100, Site 2:200 M-PE1
Path of unicast VPLS traffic from A4 to A1 A1
BGP-VPLS pseudowire
LDP-VPLS pseudowire
BGP SITE ID:3 BGP SITE ID:1 METRO X

(Designated: Site ID 1) A2
M-PE5 C-ASBR1
A5
WAN
M-PE2
METRO Z M-PE3 A3
A6 C-ASBR2
METRO Y
M-PE6 C-ASBR2 BGP SITE ID:2
(Designated: Site ID 2) A4
M-PE4
Local preference: Site 1:200, Site 2:100
Figure 27: Multihoming multiple LDP-VPLS domains
One simple but powerful aspect of BGP-VPLS signaling that enables multihoming for each LDP-VPLS domain is the
capability to map each LDP-VPLS domain to a separate site that is assigned a unique site identifier. This process
results in generation of a unique VPLS signaling route for each such LDP-VPLS domain. The process is repeated on
each PE router to which the multihomed site is attached. Therefore, all the peers in the BGP-VPLS domain learn
about each multihomed site and elect a single designated interworking border router, which is responsible for
forwarding traffic to and from the multihomed site mapped in that LDP-VPLS domain.
In the topology in Figure 27, the LDP-VPLS domains Metro X and Metro Y are multihomed to C-ASBR1 and C-ASBR2.
On C-ASBR1 and C-ASBR2, for VPLS Customer A, these two LDP-VPLS domains are mapped to BGP-VPLS signaling
using the same site identifiers, 1 and 2, respectively. C-ASBR1 and C-ASBR2 advertise the same VPLS routes for
each of the two site identifiers. Because C-ASBR1 is configured with a higher local preference value for LDP-VPLS
domain Metro X, it is elected as the designated interworking border router for LDP-VPLS domain Metro X. Because
C-ASBR2 is configured with a higher local preference for LDP-VPLS domain Metro Y, it is elected as the designated
interworking border router for LDP-VPLS domain Metro Y.
One question that arises is how does interdomain forwarding between Metro X and Metro Y occur when Metro X and
Metro Y have different designated interworking borders routers, C-ASBR1 and C-ASBR2, respectively. The answer is
that forwarding between the two LDP-VPLS domains occurs using the BGP-VPLS pseudowire in the WAN that is set
up between the two border routers.
Suppose that Site A1 sends a frame whose destination MAC address is in Site A4, but none of the PE routers have
yet learned that MAC address. As far as M-PE1 is concerned, the other sites of VPLS Customer A are connected to
M-PE2, C-ASBR1, and C-ASBR2, so M-PE1 floods the frame to M-PE2, C-ASBR1, and C-ASBR2.
C-ASBR2 drops the received frame because it is not the designated interworking border router for the LDP-VPLS
domain Metro X. C-ASBR1 floods the frame to C-ASBR2 and C-ASBR3 because they are all in different mesh
groups than M-PE1. However, C-ASBR1 does not forward the frame to M-PE3 and M-PE4 because C-ASBR1 is not
a designated forwarder for Metro Y. C-ASBR2 subsequently forwards the frame to M-PE3 and M-PE4. When M-PE4
receives the frame, it forwards it to A4.

As a result of this process, each PE router that forwards the frame learns that the source MAC address of the frame
is A1 and updates its MAC table accordingly. The following forwarding path is taken for the subsequent frames sent
from A4 to that MAC address.
A4 → M-PE4 → C-ASBR2 → C-ASBR1 → M-PE1 → A1
By using the third option, mapping LDP-VPLS domains in BGP VPLS, a network design is feasible in which some
LDP-VPLS domains are multihomed while others are single homed. When multihoming LDP-VPLS domains, the
local preference value is used for load balancing VPLS customers across multiple, redundant border routers. For
a multihomed VPLS customer with sites in multiple LDP-VPLS domains, the local preference value is used for
load balancing LDP-VPLS domains across multiple border routers. This multihoming solution can be scaled to
interconnect multiple LDP-VPLS domains.
Conclusion
Juniper Networks is committed to VPLS development so that service providers can interoperate and interwork with
other VPLS implementations through simpler VPLS configurations that are less error prone. The Juniper Networks®
LDP-BGP VPLS interworking solutions allow large enterprises, telcos, and cable companies to roll out and scale
managed VPLS networks. These solutions offer minimal disruption, maximum scalability and cost efficiency, and
extended reach across metro areas, regionally, nationally, and internationally. For further information, refer to other
documents on www.juniper.net.
References
R. Aggarwal, Y. Kamite, and L. Fang. Multicast in VPLS. draft-ietf-l2vpn-vpls-mcast-03.txt. ND.
K. Kompella. Layer 2 VPNs over Tunnels (work in progress). Jan. 2006.
K. Kompella and B. Kothari. Multihoming in BGP Virtual Private LAN Service (work in progress). Nov. 2007.
K. Kompella and Y. Rekhter. Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, RFC
4761. Jan. 2007.
M. Lasserre and V. Kompella. Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling,
RFC 4762. Jan. 2007.
L. Martini, E. Rosen, N. El-Aawar, T. Smith, and G. Heron. Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP), RFC 4447. Apr. 2006.
E. Rosen and Y. Rekhter. BGP/MPLS IP Virtual Private Networks (VPNs), RFC 4364. Feb. 2006.
About Juniper Networks

Juniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network
infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and
applications over a single network. This fuels high-performance businesses. Additional information can be found at
www.juniper.net.
Corporate and Sales Headquarters APAC Headquarters EMEA Headquarters To purchase Juniper Networks solutions,
Juniper Networks, Inc. Juniper Networks (Hong Kong) Juniper Networks Ireland please contact your Juniper Networks
1194 North Mathilda Avenue 26/F, Cityplaza One Airside Business Park representative at 1-866-298-6428 or
Sunnyvale, CA 94089 USA 1111 King’s Road Swords, County Dublin, Ireland
authorized reseller.
Phone: 888.JUNIPER (888.586.4737) Taikoo Shing, Hong Kong Phone: 35.31.8903.600
or 408.745.2000 Phone: 852.2332.3636 EMEA Sales: 00800.4586.4737
Fax: 408.745.2100 Fax: 852.2574.7803 Fax: 35.31.8903.601
www.juniper.net
Copyright 2010 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Junos,
NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries.
All other trademarks, service marks, registered marks, or registered service marks are the property of their respective
owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves
the right to change, modify, transfer, or otherwise revise this publication without notice.
2000282-002-EN Oct 2010 Printed on recycled paper

LDP-BGP Vpls Interworking

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LDP-BGP Vpls Interworking

Uploaded by

Copyright:

Available Formats

WHITE PAPER

LDP-BGP VPLS Interworking

Copyright © 2010, Juniper Networks, Inc.

ii Copyright © 2010, Juniper Networks, Inc.

Operational Details: Multiple LDP-VPLS Domains Interconnected Using BGP VPLS . . . . . . . . . . . . . . . . . . . . . . . 29

Copyright © 2010, Juniper Networks, Inc. iii

How to Use this White Paper

Copyright © 2010, Juniper Networks, Inc. 1

2 Copyright © 2010, Juniper Networks, Inc.

VPLS Control Plane

BGP-VPLS Control Plane

LDP-VPLS Control Plane

Copyright © 2010, Juniper Networks, Inc. 3

Scaling Characteristics of LDP VPLS and BGP VPLS

4 Copyright © 2010, Juniper Networks, Inc.

Copyright © 2010, Juniper Networks, Inc. 5

New site added A7 Psuedowire

6 Copyright © 2010, Juniper Networks, Inc.

Only PE7 needs configuring; all

Flooding and Broadcasting

Copyright © 2010, Juniper Networks, Inc. 7

P2MP LSP created by PE1

Exchanging Pseudowire Signaling State

Inter–Autonomous System Operations

8 Copyright © 2010, Juniper Networks, Inc.

Scaling Beyond a Single Metro Area

Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics

Table 1: Comparison of LDP-VPLS and BGP-VPLS Control Plane Scaling Characteristics

Provisioning task of adding or Manual or through provisioning Automated by BGP’s autodiscovery

Business Drivers for LDP-BGP VPLS Interworking

Scaling the VPLS Network

Copyright © 2010, Juniper Networks, Inc. 9

Extending the VPLS Network

Scaling an LDP-VPLS Network Using BGP VPLS

10 Copyright © 2010, Juniper Networks, Inc.

Basic LDP-BGP VPLS Interworking

PE6 PE3 (LDP)

Copyright © 2010, Juniper Networks, Inc. 11

Pros and Cons of Basic LDP-BGP VPLS Interworking

Scalable LDP-BGP VPLS Interworking

A4 PE5 (BGP) PE7

PE6 (BGP) C3 PE3 (LDP)

Figure 9: LDP-BGP VPLS interworking

12 Copyright © 2010, Juniper Networks, Inc.

A4 PE5 (BGP) PE7

PE6 (BGP) PE3 (LDP)

Copyright © 2010, Juniper Networks, Inc. 13

Redundancy in Scalable LDP-BGP VPLS Interworking

PE6 (BGP) PE3 (LDP)

Figure 11: Redundancy in scalable LDP-BGP VPLS interworking

14 Copyright © 2010, Juniper Networks, Inc.

Pros and Cons of Scalable, Redundant LDP-BGP VPLS Interworking

Interconnecting LDP- and BGP-VPLS Domains

Copyright © 2010, Juniper Networks, Inc. 15

Basic Interdomain LDP-BGP VPLS Interworking Scheme

Interdomain LDP-BGP L-PE1

Figure 12: Basic interdomain LDP-BGP VPLS interworking

16 Copyright © 2010, Juniper Networks, Inc.

Interconnecting and Extending VPLS for Multiple LDP-VPLS Domains

Copyright © 2010, Juniper Networks, Inc. 17

C-ASBR1 forwards all VPLS traffic between Metro X and Metro Y.

Redundancy in Interdomain LDP-BGP VPLS Interworking

C-PE2 C-ASBR2 LDP-BGP VPLS