Replacing a 300-store retailer's MPLS-only WAN with SD-WAN, how do you choose each store's transport mix, and what guarantee do you give up?

## What MPLS actually sold you A carrier's MPLS VPN gives a retailer more than connectivity. It gives a **service agreement** covering the whole path between sites: the carrier commits to loss, latency and availability targets inside its own network, and it honours the customer's traffic classes. RFC 2475 describes exactly this: differentiated services extend across a domain boundary by establishing an SLA between the networks, which may specify how packets are classified and re-marked at that boundary. With MPLS there is one such agreement and one accountable provider. The price is the reason for the project: bandwidth is expensive per Mb/s, a new circuit takes weeks or months to deliver, and every store depends on one carrier. ## What each internet transport offers | Transport | Strength | Weakness | |---|---|---| | Broadband | Cheap, high bandwidth | Best effort, often asymmetric, contention at peak hours | | Dedicated internet access | Symmetric, contracted to the ISP's edge | The contract stops where the ISP's network ends | | LTE / 5G | Installed in days, different physical medium | Metered or capped, variable latency, often behind carrier-grade NAT | | MPLS (kept) | Contracted end-to-end bound, private | Cost, lead time | Two details shape the design: - **Markings stop at the boundary.** Voice marked EF (DSCP 46, codepoint `101110`, RFC 3246) is honoured inside a network that has agreed to honour it. Across the public internet there is no such agreement, so an edge can queue and shape its own uplink but cannot buy priority beyond it. - **Mobile transports often sit behind carrier-grade NAT.** Many mobile carriers number subscribers from the shared address space `100.64.0.0/10` (RFC 6598) or similar and translate them, so the store's LTE port cannot accept unsolicited inbound tunnel setup; the store's edge must initiate its tunnels outward, and how tunnels survive a translator is a separate subject. ## Tiering the estate Not every store needs the same answer. Tier by what an hour of outage costs and by which applications must survive: 1. **Data centres and hubs**: keep MPLS or dedicated internet plus a second transport, because every store's tunnels terminate here and stores with only internet transports must be able to reach them. 2. **Flagship and high-revenue stores**: MPLS or dedicated internet plus diverse broadband, with LTE for payment and voice if both fail. 3. **Typical stores**: two broadband circuits from different providers on different media, for example cable and fibre, plus LTE as a last resort. 4. **Small or temporary sites**: broadband plus LTE, or LTE alone while a line is installed. LTE is controlled by policy, not just installed: only payment, point-of-sale and voice may use it when it is the sole path, and guest Wi-Fi never does, so a broadband outage does not run up a data bill. ## What diverse really means The point of two transports is that they do not fail together. The availability gain from parallel paths assumes independent failures, and real failures are often shared: - two providers reselling the same copper or fibre in the same street cabinet; - two circuits entering the building through one duct; - two ISPs that both depend on one upstream network; - a power cut that takes out the cabinet feeding both lines. Ask providers for the physical route, prefer different media, and treat LTE as the one transport most likely to be truly independent of the fixed lines. ## What you give up, and what you get - **Given up:** a contracted end-to-end bound on loss and latency, one accountable carrier, and enforced traffic classes across the WAN. - **Gained:** more bandwidth for the money, circuits in days rather than months, several providers instead of one, encryption on every path and per-application steering. The honest framing is that SD-WAN turns a **guarantee** into a **probability**: with two or three independent, measured paths, the chance that none meets an application's thresholds is usually small, but nobody has signed for it. ## Migration without a cliff - Start hybrid: bring up the overlay with MPLS as one underlay and broadband as the second, so nothing is removed on day one. - Move application classes to the overlay's steering one at a time, starting with guest and bulk traffic. - Shrink MPLS bandwidth, then remove it store by store once the measured paths meet the thresholds over a full trading season, including peak days. - Keep MPLS where the contract is still worth its price, typically at hubs.