Carrier Diversity Must Be Proven, Not Declared

Two circuits can arrive on different invoices, carry different service IDs and terminate on different routers while still depending on the same duct outside the building. The commercial arrangement is diverse. The failure domain may not be.

Carrier diversity should be assessed as a chain of claims, each supported by appropriate evidence. The objective is not to demand a public map of protected network infrastructure. It is to establish what has been demonstrated, credibly attested or left unknown before the design is treated as resilient.

A logical circuit describes a service. It does not, by itself, describe every physical resource beneath that service. The Internet engineering concept of a shared risk link group exists for exactly this reason: separate links may share a common physical resource and fail together. RFC 4428 gives fiber links and cables as examples; RFC 5212 explains how two paths that appear separate at one layer can share fiber at a lower layer.

Consider two concrete cases. A buyer orders services from Carrier A and Carrier B. Carrier B leases the metro access segment from Carrier A, so both circuits use the same outside-plant cable near the facility. In another design, both carriers own their access networks and enter the property separately, but both customer cross-connects pass through one meet-me room and one internal cable pathway. The shared dependency is different, but the business consequence is similar: a single event can remove both services.

This does not mean either service was misrepresented. “Two carriers” may be an accurate commercial statement. The error occurs when that statement is silently promoted into “end-to-end physically diverse.”

In a provider decision matrix, commercial diversity and physical diversity therefore need separate criteria.

Useful distinction: separate contracts, separate providers and separate physical routes are three different properties. None should be used as shorthand for the others.

The Diversity Proof Stack prevents one proven layer from being mistaken for the entire route. Work from the customer contract outward and record evidence and limits at every step.

[TABLE]

The stack is cumulative. Evidence at layer five does not repair a shared termination device at layer four. Two independent facility entries do not prove separate long-haul routes. Conversely, an unknown at one layer should not erase valid evidence at the others. It should remain an explicit uncertainty attached to the decision.

Evidence should be proportional to the claim and the buyer’s exposure. Contracts and service records can normally establish commercial diversity. Facility teams may be able to confirm entrance facilities, meet-me-room assignments and internal cross-connect paths. Carriers may provide a route-diversity letter, an engineering attestation, a controlled map review or a more limited confirmation under NDA.

None of those formats is universally available. Detailed outside-plant maps can carry security and commercial sensitivity, and a provider may reasonably decline to release them. Non-disclosure is not proof of shared routing. It is also not proof of separation.

The correct response is to narrow the claim. For example: “Separate carriers and facility entrances are documented; external route separation is provider-attested but was not independently observed.” That wording is more useful than a binary diverse/not-diverse label because leadership can see both the evidence and the residual exposure.

Evidence also ages. Construction, carrier grooming, migration and emergency restoration can alter a path. The register therefore needs an owner, verification date and reassessment trigger.

The segment between a carrier’s demarcation and the customer rack is easily overlooked. Ask whether the services use separate building entrances, entrance rooms, meet-me rooms, frames, pathways, cross-connect panels and customer-side ports. The answer may be complete, partial or deliberately shared infrastructure.

An approved technical site visit can reconcile drawings, explanations and physical observations. It cannot establish a hidden metro route by looking at two cables. Observation must stay within facility permissions.

Physical verification can still find consequential mismatches. For example, an order may specify terminations in two meet-me rooms while the installed labels show both cross-connects handed off through one cabinet. That observation does not identify the external route, but it is sufficient to reopen the facility-layer claim before go-live. Where local checking is appropriate, controlled on-site verification should follow an approved scope and produce evidence rather than an informal “looks separate” response.

The purpose of the review is not to achieve perfect knowledge. It is to decide whether the demonstrated separation is adequate for the workload and, if not, what additional control is justified.

Hypothetical scenario: A platform team requires continuity through a single metro fiber cut. Two providers, two building entrances and two meet-me rooms are confirmed. One carrier will not disclose its metro route but attests that the services are geographically separated until a named aggregation site. The team could accept that residual uncertainty, request a controlled engineering review, add a third service using a materially different access method, or redesign recovery to another location. Which answer is proportionate depends on recovery objectives, application architecture and the consequence of correlated loss.

Testing adds evidence, but its meaning must be precise. Administratively shutting one port can validate routing, convergence and application behavior; it does not prove duct separation. AWS makes a similar distinction in its Direct Connect resiliency models: separate connections, devices and locations address different failure scopes. State which layer a test exercises and which layers it leaves untested.

The decision brief should contain the required failure scenario, demonstrated layers, unresolved dependencies, consequence, acceptance owner and next action. This turns “diversity” into an accountable design decision.

Use these questions for each primary and alternate path:

1. Are the services held under separate contracts and service identifiers?
2. Which organization owns delivery at each segment, and where is wholesale capacity used?
3. What exact meaning does each provider assign to “diverse,” “protected” or “redundant”?
4. Are the building entrances and entrance facilities separate?
5. Are meet-me rooms, internal pathways, frames and customer terminations separate?
6. What shared ducts, bridges, poles, aggregation sites or regeneration facilities are known?
7. What evidence supports each answer: document, attestation, observation or test?
8. Which route details cannot be disclosed, and can a narrower confirmation be provided?
9. When was the route last verified, and what changes trigger revalidation?
10. What failover behavior has been tested, and what physical claim did the test not cover?
11. Who can accept the remaining uncertainty on behalf of the business?
12. What alternate design reduces exposure if sufficient proof is unavailable?

For each answer, assign one evidence status: confirmed, qualified, unverified or contradicted. Add the source, date, scope, limitation, owner and required follow-up. The resulting connectivity dependency review is a better procurement output than a diagram with two colored lines: it preserves exactly how much confidence the organization has earned.

A carrier-diversity claim is decision-ready only when its scope is explicit. The strongest conclusion may be full end-to-end separation; in other cases, the honest and useful conclusion is partial evidence plus a managed residual dependency.

Evaluating resilient connectivity for a deployment in Azerbaijan? I provide independent connectivity assessment and local technical coordination, including evidence-gap registers and provider clarification support.

For continuing analysis of physical failure domains and recovery assumptions, see my infrastructure resilience notes.