Summary

  • BSH's promise of one communications contract and one point of responsibility can make fault coordination cheaper for a branch network, but commercial consolidation is not the same thing as physical or routing independence.
  • Public records around AS8491 show a real, visible network and several declared or observed external routing relationships. They do not disclose carrier contracts, traffic shares, access-tail separation, failover performance or achieved SLA results; a buyer must obtain that evidence directly.

One phone number, several failure domains

When a branch loses service, the first expensive activity is often not repair. It is deciding who owns the fault.

The access provider may say its circuit is up. The managed-network contractor may point to customer equipment. The data-centre operator may see no alarm. A cloud or application team may insist that its own service is healthy. Each party can be correct within a narrow boundary while the customer's office remains disconnected. Time accumulates between queues, hand-offs and repeated diagnostics.

Scientific-Production Enterprise Business Sviaz Holding LLC, which uses the BSH brand, markets a direct answer to that coordination problem. Its single-operator page says communications services for branch networks can be aggregated into one contract with a single point of responsibility across Russia and the CIS. Its technical-support page describes dedicated engineers, response times governed by an SLA and round-the-clock NOC monitoring of incidents.

The proposition has economic substance. One accountable counterparty can maintain an inventory, open cases with underlying suppliers, reconcile incompatible trouble tickets and report to the customer in one language and format. A branch manager no longer needs to understand which carrier, integrator or equipment vendor sits behind every service.

But a simpler commercial interface does not simplify the physical system. It changes who coordinates the complexity. That distinction should sit at the centre of the SLA.

What BSH publicly says it operates

BSH's homepage describes the company as an independent IT integrator founded in 1991. It names infrastructure outsourcing, network solutions and its own Tier III data centres in Moscow and Yaroslavl. Structured information on the same page also describes BSH as a telecom operator and lists corporate data networks, data centres, IT outsourcing, technical support and equipment supply among its areas of work.

Those statements help define the business context. They are not an independent certification record, a map of every service dependency or a measurement of customer outcomes. The distinction matters because an integrator can perform several different roles in the same customer design: contract aggregator, network operator, equipment supplier, support desk and data-centre provider. Each role has a different control boundary.

The public RIPE Database adds a narrower set of facts. Organisation object ORG-BSH1-RIPE names Scientific-Production Enterprise Business Sviaz Holding LLC as a Russian Local Internet Registry and gives a Moscow address. Aut-num object AS8491 names BSH-AS, links it to that organisation and records the autonomous system as assigned. The object contains import and export policy statements involving several other autonomous systems.

These are useful pieces of operational identity. They show that BSH is not merely presenting an unanchored marketing label: the named company is associated with a registered network-resource role and an autonomous system. They do not reveal what a particular customer has bought or which infrastructure carries that service.

The route view is evidence, not a resilience certificate

At the captured point on 28 August 2026, RIPEstat's routing-status service observed AS8491 announcing five IPv4 prefixes covering 22,528 addresses and one IPv6 prefix. The accompanying announced-prefix list contained four larger IPv4 blocks, a more-specific 87.238.101.0/24 inside the listed 87.238.96.0/21, and 2a03:8640::/32. The overlap is a useful warning against treating a list of route announcements as a simple sum of independent capacity.

RIPEstat also reported that all of the RIPE RIS peers counted in that response saw the IPv4 and IPv6 announcements. That is evidence of route visibility at that moment under RIPEstat's methodology. The response says routes with very low visibility, defined there as fewer than ten full-feed peers seeing them, are excluded. It is not an uptime figure. It does not measure packet loss, delay, congestion, customer reachability or the probability of successful failover.

The AS-neighbours response labelled ten autonomous systems as being on the left of AS8491 paths, two as being on the right and three as uncertain. The registered AS8491 policy likewise names multiple external autonomous systems. Together, the two records support a modest conclusion: AS8491 participates in a network context with several external routing relationships.

They cannot safely support the more attractive conclusions. A path neighbour is not automatically a paid transit provider, a customer, a peer or a physically separate carrier. A declared import policy may not carry current production traffic. Two AS paths may share the same fibre duct, building entrance, power supply or wholesale operator. An IPv6 announcement may be globally visible while a particular customer service remains IPv4-only. Public BGP data cannot settle any of those questions.

That is why dependency evidence belongs in the customer agreement rather than in a marketing inference drawn from route records.

One contract transfers coordination, not physics

There are two ways to misunderstand a single-operator model.

The first is to assume that aggregation necessarily creates fragility. It need not. An operator with a coherent inventory, competent engineers and strong supplier-management routines may restore a multi-carrier service faster than a customer that holds several direct contracts but has no one responsible for end-to-end diagnosis. Coordination is a real operating capability.

The second error is to assume that one responsible party has made dependencies disappear. It has not. If two supposedly diverse circuits share one access network, if primary and backup routers use one power source, or if every supplier ticket passes through one thin support team, the failure domain remains concentrated even when the invoices have been consolidated.

The buyer therefore needs two related but distinct promises. The responsibility promise answers: who receives the alarm, owns the case, coordinates suppliers and reports restoration? The independence promise answers: which components are meant not to fail together, and what evidence demonstrates that separation?

A good contract makes both promises observable. Without that separation, a supplier may meet a narrow response-time clock by acknowledging a ticket while the customer's service remains unusable. Conversely, a customer may blame the aggregator for an application failure outside the contracted control surface. Precise boundaries protect both sides.

Turn the SLA into an evidence schedule

BSH's own SLA explainer identifies response time, mean time to repair, recovery time objective, responsibility zones and contractual penalties as matters to define. The practical next step is to attach a data definition to every important term.

Response time needs a start event. Is it the first customer call, a NOC alarm, automated correlation or formal ticket acceptance? It needs a stop event too: a human acknowledgement, an engineer assigned, diagnosis started or a workaround delivered. Each choice measures a different performance.

Restoration needs a service test. Closing a carrier ticket is not the same as restoring the branch. A useful test might require customer-edge reachability, agreed packet-loss and latency thresholds, route recovery, application-path validation or confirmation from an identified monitoring point. The test should specify who can see the raw measurement and how disputed intervals are reconciled.

Diversity needs a dependency map. For each primary and backup service, the schedule can identify the underlying carrier, access medium, building entry, exchange or interconnection location, customer-premises device, power source, logical route-control point and operational team where disclosure is contractually and operationally possible. Sensitive commercial details may be protected; the customer still needs enough information to know which alleged backups share a failure domain.

Change control matters because diversity can decay without a visible outage. A wholesale supplier may reroute an access tail. Two formerly separate services may move into the same facility. A maintenance contract may change. The agreement should say which dependency changes require advance notice, renewed evidence or a new failover test.

Finally, the evidence schedule should survive a dispute. Ticket timestamps, monitoring samples, route observations, configuration changes and supplier escalations need retention periods and export formats. A penalty with no shared measurement record invites argument rather than accountability.

The service BSH is actually selling

The strongest reading of BSH's proposition is not that one company controls every cable, router and facility. It is that one company will manage the boundary between them for the customer.

That service can be valuable precisely because the underlying system remains plural. Its quality depends on inventory discipline, escalation authority, engineering judgement and the ability to produce a coherent account of what happened across organisational lines. Public routing records can help a buyer ask better questions about that system. They cannot answer the contract-specific questions on their own.

For a branch network, the procurement decision should therefore compare more than headline availability and monthly price. It should compare the operator's willingness to name dependencies, test failure domains, expose measurement definitions, coordinate restoration and return usable evidence after an incident. One contract reduces the number of calls. A well-designed evidence schedule determines whether that simplicity also produces control.

Sources