The job of the telecom consultancy or procurement advisor — in France, the AMO, assistance à maîtrise d'ouvrage — is to help an organisation define its needs and write its tender: the technical specifications (CCTP) of a public contract, the specifications of a private invitation to tender, the renewal file for an operator contract. On multi-site networks, this job has been stuck for ten years on a badly framed dilemma: should we ask for MPLS, or for SD-WAN? The answer is that you should ask for neither. You should ask for functions.
The problem with tenders written by technology
A tender that requires “an MPLS network” excludes, in effect, any solution based on standard Internet links, even one more controllable than MPLS. A tender that requires “an SD-WAN solution” excludes solutions that act on the core network rather than at the edges, and forgoes the voice and hosting convergence that SD-WAN does not handle. In both cases, the consultant has settled, without meaning to, a technical debate that should have been left to the bidders.
Public procurement rules in any case require needs to be described, not brands. The reflex applies in the private sector too: the more the specifications describe what the network must do, the fairer the comparison.
A neutral functional definition
The wording we propose to consultancies, free to reuse, fits in one sentence:
Multi-site wide-area network solution providing the customer with a dedicated virtual backbone router, administrable by the customer, hosted in a virtualised and segmented operator core network (VXLAN/EVPN), reachable over standard multi-technology access links (FTTH, FTTO, xDSL, 4G/5G), and capable of carrying data, voice and hosting flows on a single infrastructure.
This sentence names no brand. An MPLS operator can respond: it will have to explain what the customer controls in its core, and how it carries voice and hosting. An SD-WAN vendor can respond: it will have to say which backbone its overlay sits on and who controls it. An sdMPLS-type solution can respond: it will have to demonstrate, point by point, that it meets each criterion. The comparison is made on functions, not on the label.
Ten requirements to turn into clauses
The tender-writing kit details ten model clauses, with their rationale and the points to check. In short, multi-site network specifications should require:
- a dedicated virtual backbone router, administrable by the customer (routes, QoS, segments), with a defined access mode and time to take effect;
- a virtualised and segmented core network, distinguishing what is dedicated (the routing instance) from what is shared and segmented (the core);
- multi-technology access links (FTTH, FTTO, xDSL, 4G/5G) chosen site by site, with mobile backup;
- convergence of data, voice and hosting flows on a single infrastructure, or a transparent answer on the separate infrastructures;
- open standards and demonstrated reversibility (VXLAN, EVPN, BGP, configuration export);
- quantified, contracted monitoring and operations commitments, distinguishing the core and the links;
- demonstration of isolation and the customer's ability to segment its own network;
- measured processing capacity, with the measurement method;
- target and maximum lead times per site, distinguishing link delivery from activation in the core;
- an explicit statement of the architecture's scalability limits.
Three pitfalls to avoid
Presupposing equivalence. Specifications must not presuppose that a solution offers “the equivalent of an MPLS SLA”; they must require quantified commitments and check that they are contractual. This applies to all bidders, including the incumbent MPLS operator.
Confusing dedicated with reserved. Asking for a “dedicated infrastructure” without specifying what is expected leads to unverifiable answers. What the customer needs to require is a dedicated routing instance (the dedicated VRB, in the case of an sdMPLS-type solution) on a shared and segmented core, whose isolation the bidder demonstrates.
Forgetting voice and cloud. A WAN tender that leaves telephony and hosting to other contracts perpetuates the double infrastructure. Asking for the number of infrastructures, contracts and points of contact for WAN, voice and hosting is often enough to reveal the gaps.
Questions rather than names
Finally, the kit offers eighteen questions to ask operators, worded to apply to any bidder. Three of them do the sorting on their own: who controls the core network, and which changes can the customer make alone? Is the backbone router proposed an instance dedicated to the customer? Can we obtain at any time a full export of our configuration, and in what format? An answer that refers to a ticket, stays vague about what is shared, or makes the export conditional on fees says a great deal about the customer's real control.
The consultant does not have to recommend a technology. It has to write a need precise enough for the best answer to stand out. If that need is a core network controlled by the customer, on standard links, carrying WAN, voice and cloud, the tender is open to the third way, and it is up to the market to respond.