Before you add OTV, write down the Ethernet contract you need

A workload moves to a second data centre and starts timing out on a service that answered fine from the first one. Someone proposes OTV, because the existing Layer 2 VPN "does not do broadcast". That conclusion is usually premature. The service category and the specific contract you bought are two different questions, and the timeout has not yet been attributed to either.

The symptom that starts the comparison

Write down what the application actually needs before comparing products. Site count, VLAN scope, address learning, flooding tolerance and failure behaviour describe the requirement. "Layer 2" and "OTV" describe architectures, and neither is a requirement on its own. Five properties on one page will outlast any vendor comparison.

Then check whether the current service already meets those five properties. A provider-managed Layer 2 VPN may include multipoint forwarding and control-plane learning that a quick look at the invoice did not mention.

If the current service does meet them, the timeout is somewhere else: an MTU problem, a routing asymmetry, a firewall rule that differs between sites. Changing the overlay would leave that cause in place and add a migration.

What the label does not tell you

A Layer 2 VPN is a category, not a product. Point-to-point VPWS and multipoint VPLS forward differently, and the category includes services with control-plane learning and loop management as well as simpler ones. Assuming every Layer 2 VPN connects exactly two sites and floods everything is how the wrong comparison gets made. The name on the contract says nothing about the forwarding table behind it.

Ask which forwarding model the existing service implements, and which one the application needs. A hub-and-spoke requirement and a full-mesh requirement produce different designs even when both are described as Layer 2.

Where OTV draws its boundary

OTV runs over an IP transport with control-plane MAC reachability and defined edge roles. Local spanning-tree information stays local rather than being extended as one uncontrolled domain across the transport. That is a real difference from a plain bridged extension, and it is the reason people reach for it.

The boundary matters as much as the benefit. Unknown unicast, broadcast and multicast handling depends on the platform and its configuration, and an edge pair must cooperate through the supported multihoming mechanism. Two independent devices forwarding the same VLAN is not the same design, and it produces a different failure mode.

Flooding is reduced, not removed

Suppressing some unnecessary flooding is not the same as guaranteeing that no broadcast or multicast frame ever crosses the extension. A storm that starts on one site can still consume the transport, and a platform feature that filters one traffic class does not filter the others. That distinction is where most of the disappointment with any overlay comes from.

So the question to ask is not whether OTV stops broadcast storms. It is which traffic classes cross, under which conditions, and what limits the rate when they do.

Confirm the underlay while you are there: supported delivery, packet size, routing and the adjacency the chosen release requires. None of that comes for free with the overlay, and a tunnel that fits a 1500-byte frame is not automatically a tunnel that fits your tagged frames.

The contract to ask for, in writing

For whichever service you choose, request the same six answers: point-to-point or multipoint scope, customer frame and tag handling, MAC learning model, flooding limits, recovery behaviour and the maximum frame size end to end. Two services with the same name can differ on every one of them. Get the answers in writing, because the engineer who configured the service may not be the one answering the question.

Choose a change only for a requirement the current service demonstrably cannot meet. Extending a VLAN further extends the application's and Ethernet's dependencies with it; a new overlay name does not remove them.

The RFC 4664 framework sets out the service categories and their forwarding models, which is the vocabulary you need to ask the right question. Bring the six answers and the failing test to the same meeting, and the decision stops being about labels.