L2VPN vs VPLS vs EVPN: the label is not the service
The acronym on the order form names a family, a forwarding behaviour or a control plane. Four questions separate them before you compare two quotes.
You read "L2VPN" on a quote, then "VPLS" on the configuration sheet, and assume the second word narrows the first. Sometimes it does, and sometimes the two lines are answering unrelated questions. The misconception is treating these names as rungs on a ladder from basic to advanced. L2VPN is a family, VPWS and VPLS are two service behaviours inside it, and EVPN is a control-plane mechanism that can carry either.
Each acronym answers a different question
Start with what the customer attachment has to do, because that is the only question the service model answers. A point-to-point circuit between two sites and a shared Ethernet segment across ten sites are different products, even when both are sold as Layer 2 connectivity.
| Name | Question it answers | What it does not tell you |
|---|---|---|
| L2VPN | Which family of services carries Ethernet frames | Point-to-point or multipoint |
| VPWS | A pair of attachment circuits behaves as one wire | Which control plane builds it |
| VPLS | Many attachments share a bridged broadcast domain | Whether MAC learning is limited or flooded |
| EVPN | BGP distributes MAC and IP reachability | Which service model it is being used for |
That table is not a hierarchy, and reading it as one causes the usual procurement mistake: comparing a VPWS quote with a VPLS quote as if the second were the fuller version of the first. They solve different problems, and neither is a superset in the sense buyers assume.
VPWS and VPLS split at the forwarding decision
In a virtual private wire service, the attachment circuit selects the remote endpoint. Traffic arriving on that port leaves toward the paired port, and the provider edge does not need to learn which MAC addresses sit behind it for the basic forwarding decision.
In a VPLS, the provider edge bridges. It examines the destination MAC address of each frame, learns source addresses per attachment, and floods unknown destinations within the emulated LAN. That is what makes the service behave like a LAN, and it is also where the operational limits come from.
A multipoint-looking diagram does not prove that all sites share one broadcast domain. Two providers can draw the same cloud and sell one bridged domain or several point-to-point circuits, and the difference only becomes visible when a broadcast, an unknown unicast frame, or a MAC move crosses a site boundary. A broadcast ping between two sites answers the question faster than any architecture slide. If the replies arrive from every other site, you have one bridge; if only the pair replies, you have a wire.
EVPN is a control plane, not a topology
The base EVPN specification, RFC 7432, defines BGP MPLS-based Ethernet VPN procedures: MAC reachability is advertised in BGP rather than learned only by data-plane flooding. RFC 8214 then specifies VPWS support using EVPN, which is the point that breaks the ladder model. The same control plane serves a point-to-point service and a multipoint one.
So "we run EVPN" is not an answer to "what did we buy". The provider still has to say whether the service is a pair of attachment circuits or a shared bridge, and whether the transport is MPLS, VXLAN, or something else. Those choices live in different documents and different parts of the configuration.
For an operator, the practical consequence is that choosing EVPN early makes later service changes cheaper, because reachability is already signalled rather than flooded. It does not remove the need to decide the service model first, and it does not make a misconfigured bridge correct.
MPLS is a data path, not the definition
The framework documents describe the family and its requirements; they do not require one encapsulation. MPLS label stacking is a common transport for these services, and it is not the only one. A BGP-signalled service and an MPLS forwarding path are separate design decisions that happen to be commonly paired.
When a vendor says "MPLS L2VPN", ask which half is being described. If the answer is only the transport, the service model is still unspecified, and the attachment behaviour is still unknown.
Four questions that turn a label into a contract
Ask what the handoff is: a port, a VLAN, or a bundle of VLANs, and which of them are allowed to talk to each other. Ask whether the sites share one broadcast domain, because that single answer determines flooding, MAC limits, and how a loop will behave.
Ask for the frame-size budget end to end, then add the encapsulation overhead yourself. Ask what happens when one attachment fails, whether the others keep forwarding, and whether the provider withdraws reachability or leaves it until a timer expires.
Write those four answers next to the product name in your record. When the next quote arrives with a different acronym and the same price, the comparison becomes a comparison of behaviour, which is the only comparison that predicts what the network will do on a bad day.