F6 Networks After Acquisition: AS3367, Fibre Continuity, and the

Summary

F6 Networks was described by its acquirer as an Atlantic Canadian fibre operator with a 1,600 kilometre backbone. The acquisition and a later customer-transition notice are evidence of an operating handover, not proof that every route, circuit, device, contract, or support process continued unchanged.
Current public number-resource and routing records still expose a recognisable F6 identity. ARIN identifies Xplore Inc. as the present registrant of AS3367, while PeeringDB retains the F6 Networks label and identifies Xplore as an alternate name. RIPEstat shows the autonomous system announcing routes at the research date. Those records establish identity and observable routing, not uptime, latency, capacity, security, or customer results.
The important technology question is how responsibility survives a transaction. Registry records, route objects, customer contacts, monitoring, credentials, supplier knowledge, support ownership, and recovery procedures have to remain coherent even when the company name and the current accountable operator are no longer identical.

Image note: The accompanying public-domain photograph shows generic server wiring. It does not depict F6 Networks, Xplore, AS3367, an F6 or Xplore facility, the reported Atlantic Canada fibre footprint, a customer environment, routing reliability, service availability, or a production outcome.

F6 Networks presents a compact but revealing infrastructure case. The current BTW directory entry records F6 Networks Inc as a Canadian company object. Xplore's acquisition announcement says that Xplornet acquired F6 on 1 September 2020 and describes a 1,600 kilometre fibre backbone in New Brunswick and Nova Scotia. A later customer-transition page tells former F6 customers that their services were moving into Xplornet Enterprise Solutions and gives 31 December 2020 as the transition date.

Those corporate records establish a transaction and a planned handover. They do not answer every operational question. A fibre company can be acquired while its route identity, physical assets, customer agreements, monitoring systems, staff knowledge, licences, and supplier relationships move on different schedules. A network can continue forwarding traffic even when public labels disagree about who is responsible. A support channel can remain reachable while escalation authority or diagnostic access changes behind it. Conversely, a registry update can be accurate even if a customer has not yet experienced a practical change.

Public network records show this split directly. The ARIN RDAP record for AS3367 identifies the autonomous system name as F6NET and the current registrant as Xplore Inc. The PeeringDB API record for ASN 3367 uses the name F6 Networks, gives Xplore Inc. as an alternate name, and publishes the routing-set label AS-F6. The RIPEstat AS overview also associates the holder string with Xplore and reports the system as announced. These sources describe the same number resource through different operational and recordkeeping lenses.

This article treats those records as evidence, not as a substitute for an audit. It does not claim to have tested F6 or Xplore equipment, measured customer circuits, reviewed confidential architecture, interviewed network staff, or reproduced a benchmark. It separates historical capability, observable current routing, longitudinal reliability, and customer production outcomes. It asks what an accountable operator must supervise, integrate, maintain, and repair when a network identity outlives a corporate boundary.

The exact identity boundary

Entity precision matters because several names are present at once. F6 Networks is the historical company and continuing public network label. Xplornet was the name used in the 2020 acquisition and transition material. Xplore is the name found in current public routing and registry records. These names are related by the transaction evidence, but they should not be treated as interchangeable in every context. A contract signed with one entity, a route object carrying a historical label, and a current registry record can each be accurate while referring to different points in the operating history.

The current ARIN record is the strongest public source here for present registration responsibility. It assigns AS3367 to Xplore Inc. and retains F6NET as the autonomous-system name. That combination is not a contradiction. Number-resource records often preserve durable identifiers and historical labels while registrant details change. The ASN remains AS3367; the organisation recorded as responsible for it can change through a documented process. The record documents registration and contact responsibility; it does not claim that every router, customer, or fibre segment changed at the same moment.

PeeringDB adds a community-maintained operating profile. Its record uses F6 Networks as the network name, Xplore Inc. as the alternate name, AS3367 as the ASN, and AS-F6 as the published routing-set identity. That is useful because peers and network operators need a recognisable mapping between an organisation, an ASN, a routing policy reference, and operational contacts. PeeringDB is not the legal source of ASN registration, and its presence does not prove that every listed operational detail is current. It is another evidence surface that should be reconciled against ARIN, routing data, and the operator's own records.

RIPEstat contributes observed and aggregated routing information. Its overview says the autonomous system is announced, while its announced-prefixes data returned eleven prefixes at the research date. Its routing-status endpoint showed broad collector visibility for both IPv4 and IPv6. These are meaningful current observations. They indicate that route collectors could see announcements associated with AS3367. They do not establish that every intended route was present, that traffic followed a preferred path, or that customers received a particular service level.

The identity boundary can therefore be stated narrowly. F6 Networks is a valid current directory company object and an historically documented fibre operator. Xplore is the current organisation recorded against AS3367. The F6 name remains visible in operational network data. The transaction links those facts. Nothing in the reviewed public evidence establishes that F6 remains a separate current ASN registrant, that the entire pre-acquisition architecture remains in production, or that every former customer is served under an identical technical and contractual arrangement.

This precision is more than editorial caution. Incident response depends on it. A customer can report a problem using the F6 name. A route record can expose AS-F6. ARIN can point to Xplore. An old runbook can use Xplornet. If a support team treats only one label as valid, the report may be misrouted or delayed. Good operations preserve aliases and transaction history while making the current accountable owner unambiguous.

Historical fibre capability, bounded by time

Before the acquisition, F6 was described as a fibre-network operator serving Atlantic Canada. Xplore's acquisition release says F6 had a 1,600 kilometre fibre backbone spanning New Brunswick and Nova Scotia. That is a substantial physical-network claim from the acquirer and is useful evidence of the scope Xplore said it was buying. It is still a dated statement. It does not prove the exact route mileage, lit capacity, condition, ownership, lease structure, or present use of every segment in 2026.

A 2014 Ciena announcement describes a 100G packet-optical deployment for F6 and discusses 100G, 10G, and 1G service capability. It also describes intended improvements in provisioning and troubleshooting. The announcement is relevant because it identifies a concrete technology generation and a vendor relationship at that time. It does not establish the current network design, software release, hardware inventory, capacity utilisation, or reliability. Twelve years is a long period in optical and packet infrastructure.

The careful conclusion is that F6 had a documented fibre and packet-optical capability before acquisition. Capability means the network was described as having particular transport and service features. It is not the same as reliability. Reliability would require repeated measurements across time, defined service boundaries, incident data, maintenance records, and a method for distinguishing operator faults from customer, access, power, equipment, or upstream failures. The public sources reviewed here do not provide that dataset.

Customer production outcomes are narrower still. A route announcement or a 100G platform does not show that a specific organisation met a recovery objective, reduced cost, improved application performance, or avoided an outage. A customer result needs a baseline, a measurement window, a defined circuit or service, and enough context to attribute the change. No such customer-specific study was used for this article. The historical architecture therefore supports analysis of operating responsibility and potential complexity, not a success story.

The physical nature of fibre also creates a maintenance tail that a product announcement tends to hide. A backbone includes rights of way, shelters, power, splices, patching, optical amplifiers, terminal equipment, inventory records, environmental alarms, field access, and supplier agreements. Some assets may be owned, some leased, and some operated by third parties. A transaction has to preserve enough documentation and authority for the new operator to locate, test, repair, and change them. Public sources do not reveal how F6 and Xplore divided or transferred those details.

Optical capacity and packet service also interact. A 100G optical path can support multiple lower-rate services, but commercial service depends on provisioning systems, traffic engineering, customer-premises interfaces, monitoring, and support. Capacity in a chassis is not necessarily available capacity on every route. A vendor description of faster provisioning is not a measurement of the order-to-service process. The useful question is which control surfaces must stay coherent when the technology, staff, and corporate owner change.

AS3367 as a durable control surface

An autonomous system number is a durable public identifier for routing policy and origin. It allows external networks to associate route announcements with an operator-controlled domain. AS3367 therefore provides a better continuity anchor than a website slogan. The number is visible in ARIN registration, PeeringDB, and RIPEstat even though the associated organisation names reflect different parts of the F6-to-Xplore history.

That durability has operational value. Peers, transit providers, monitoring systems, security teams, and customers may have filters, dashboards, tickets, and contracts keyed to AS3367. Renaming every reference immediately after an acquisition may be unnecessary or risky. Preserving the identifier can reduce routing disruption. The cost is that labels and contacts must be reconciled so that the preserved identifier does not preserve ambiguity about current authority.

ARIN's role is recordkeeping. It records the number resource and the current registrant information exposed through RDAP. It does not originate routes, validate customer traffic, or guarantee that the registered organisation operates every related device. This is why the record should be treated as a recordkeeping reference rather than as a sovereign command. Its value lies in uniqueness, attribution, contact metadata, and transfer history. The running network still depends on routers, policies, sessions, configuration, and people.

PeeringDB's AS-F6 entry introduces another maintenance obligation. An IRR as-set label can help networks describe routing policy and construct filters, but the actual usefulness depends on the objects behind the label, their accuracy, the consumer's tooling, and the relationship between registered intent and observed announcements. This article does not claim to have audited the full AS-F6 object graph. It treats the label as evidence that a policy identity remains publicly associated with the network.

The RIPEstat WHOIS view aggregates registry information and route-related records from public data sources. Its value is not that it replaces ARIN, but that it helps an operator compare multiple representations. A mismatch can be benign, such as a cached historical description, or material, such as an outdated contact or route object. The correct response is reconciliation, not choosing whichever source supports a preferred narrative.

Public RPKI validation data can provide a point-in-time view for a specific prefix and origin pair. That check must be interpreted narrowly. A result for one prefix does not establish the RPKI state of every route originated by AS3367, and validation state can change as ROAs and announcements change. A responsible operator needs a complete expected-prefix inventory and continuous comparison, not a single green response.

Running-code primacy matters throughout. A registry can identify Xplore correctly while an old route object still says F6. A route object can be correct while a router advertises something else. A router can advertise the expected prefix while traffic is impaired by a downstream interface or optical fault. Each evidence surface answers a different question. Resilience comes from comparing intended state, public records, observed routes, and service telemetry, then assigning discrepancies to an owner.

What routing telemetry proves, and what it does not

The eleven prefixes returned by RIPEstat's announced-prefixes endpoint show a bounded set of route announcements visible in its data at the research date. The routing-status endpoint showed broad visibility among its IPv4 and IPv6 collectors. This supports the statement that AS3367 was participating in BGP and that route collectors observed its announcements. It is not an availability percentage for F6 or Xplore services.

Collector visibility is shaped by where collectors connect, which routes their peers export, route-selection policy, and timing. A prefix can be visible to every listed collector while a particular customer has a local access failure. A prefix can be absent from some collectors because of policy without being globally unreachable. A route can be present while traffic follows an inefficient path, loses packets, or reaches an application that is not functioning. BGP answers reachability-policy questions, not all service questions.

Longitudinal reliability would require repeated sampling and a defined expected state. The operator would need to know which prefixes AS3367 should originate, which upstreams and peers are expected, what route attributes are acceptable, and which changes are planned. It would need to distinguish maintenance, traffic engineering, route leaks, hijacks, collector artifacts, and customer-specific routing. A snapshot cannot provide that classification.

Performance evidence would require additional measures such as latency distribution, packet loss, jitter, path stability, convergence time, optical signal quality, interface errors, and application response. Even those signals need a boundary. A probe placed inside the backbone, at an access edge, or in a customer network measures a different system. Without the boundary, a single performance number can create false precision.

Security evidence also needs separate treatment. RPKI can help networks validate whether an origin ASN is authorised for a prefix, but it does not prevent every routing incident or secure the rest of the service. IRR data can support filtering, but object quality and consumer behaviour vary. DDoS controls, access security, management-plane protection, and incident response require their own evidence. The presence of AS3367 in public datasets is not a security certification.

The strongest defensible conclusion is therefore modest but useful: the F6 routing identity remains active and publicly observable under current Xplore registration. That continuity gives operators a stable object to monitor. It also creates a duty to keep the public identity, expected routes, contacts, and operating ownership aligned. The data helps frame diligence; it does not finish it.

Acquisition and the customer handover

Xplore's transition notice is unusually useful because it addresses former F6 customers directly. It says services were transitioning to Xplornet Enterprise Solutions, identifies a date, and provides support and billing guidance. This is evidence of a planned customer-facing handover. It does not prove that every customer's technical path, commercial term, support experience, or service level remained identical.

A handover of this kind has at least four layers. The corporate layer transfers ownership and decision rights. The network layer transfers or reconciles routing, fibre, facilities, monitoring, and supplier authority. The service layer maps products, circuits, configurations, and support commitments. The customer layer changes contacts, invoices, portals, escalation paths, and expectations. These layers can move on different dates and can fail independently.

The first integration task is identity mapping. A customer record may use F6 Networks, a circuit identifier may use an internal legacy prefix, a route alert may say AS3367, a purchase order may name Xplornet, and a current escalation may go to Xplore. Removing historical aliases can break lookup and automation. Retaining them without a current-owner field can misroute work. A durable data model preserves the old identifier, the new accountable party, the effective date, and the evidence for the relationship.

The second task is authority transfer. Network changes may require credentials for routers, optical platforms, monitoring systems, facilities, DNS, ticketing, supplier portals, and registry accounts. Access alone is not authority. The acquiring operator needs to know who may approve a route-policy change, a fibre repair, a customer migration, or a supplier instruction. Emergency access needs deputies and an audit trail. Credentials that remain tied to departed staff or an acquired legal entity create a latent recovery problem.

The third task is operational knowledge. Diagrams rarely contain every dependency. Field staff may know which splice enclosure is difficult to access, which route has unusual restoration constraints, which customer requires a special maintenance sequence, or which alarm is noisy but meaningful under a certain condition. Capturing that knowledge takes interviews, joint operations, observed maintenance, and tested runbooks. A document handoff without an exercise can preserve files while losing capability.

The fourth task is customer communication. A support number that still answers is not enough if the support representative cannot find the legacy service or escalate to the right network owner. A new portal can be available while old identifiers fail validation. Billing can change correctly while a maintenance notice goes to an outdated contact. The transition notice is evidence that communication was planned. Measuring the result would require customer-specific tickets, service records, and outcomes that are not public here.

Verifying continuity when identifiers outlive organisations

The F6 record makes one operational problem unusually visible: a network identifier can remain useful while the organisation around it changes. AS3367 is still observable, but the labels attached to it span F6 Networks, Xplornet and Xplore. ARIN identifies the current registrant, PeeringDB retains an F6-facing name and an Xplore alias, and routing telemetry describes what collectors can see. None of those records is necessarily wrong. Each answers a different question, and continuity depends on joining the answers without flattening their differences.

A practical verification sequence starts with an identity table. One column should contain the identifier or label, such as AS3367, AS-F6, a former service name or a legacy circuit reference. Another should record the current accountable owner. Further columns should identify the evidence source, observation date, operational use, approved aliases and escalation route. This is more than a migration spreadsheet. It is a control for deciding whether an apparent mismatch is expected history, stale data or a condition that requires action.

The first check is registration. ARIN's record supports the narrow conclusion that Xplore Inc. is the current registrant of AS3367. It does not establish which internal team operates every route, which supplier carries traffic or how customers experience the network. Registration evidence should therefore connect to, but not replace, an internal authority record. That record needs named roles for approving contact changes, route policy, resource transfers and emergency action. If the role changes, the evidence and deputy coverage must change with it.

The second check is routing intent. PeeringDB's F6 name and AS-F6 routing-set label can help peers and operators recognise the network's historical identity. RIPEstat can show announcements and collector visibility. The operator still needs an approved inventory of expected prefixes, origins and broad relationship types. Observed BGP is evidence of running state, not proof that the state is authorised. Conversely, an inventory is only intended state until independent observation confirms it. Reliable supervision compares the two and records the reason for every accepted difference.

The third check is security metadata. An operator should compare expected routing with relevant RPKI and IRR records, while recognising that different networks apply those controls differently. A valid route-origin authorisation does not prove that a route change was well planned, and an IRR object does not prove that every router follows it. These records reduce ambiguity when they are current and connected to change control. They create additional risk when teams assume that updating one system automatically updates all consumers.

The fourth check is physical continuity. Xplore's acquisition announcement described a 1,600 kilometre fibre backbone in New Brunswick and Nova Scotia, while Ciena's 2014 announcement described a packet-optical deployment at that time. Those are valuable historical scope and capability records. They are not a current asset inventory. A present-day operator needs route records, facilities, access rights, power dependencies, splice information, supported equipment, spares and restoration contacts at the level required to repair service. The cost lies in keeping those records aligned with the network that actually exists.

The fifth check is service identity. Xplore's transition notice shows that former customers were given a new organisational context for support and agreement continuity. An effective handover must also preserve the technical path from a legacy name to the current service record. A support agent should be able to start with an old F6 circuit, hostname, invoice label or contact and find the present customer, entitlement, logical service, physical dependency and escalation owner. Testing a sample of real legacy identifiers is stronger evidence than confirming that a new support channel answers.

The sixth check is regulatory interpretation. CRTC records establish specific proceedings and a later licence disposition. They do not, by themselves, establish the operating state of AS3367, the fibre footprint or any customer service. Regulatory, registry, routing, physical and commercial records belong in the same evidence model, but each must retain its boundary. Otherwise an administrative event can be misread as a network shutdown, or active routing can be misread as proof that every regulatory and customer obligation is current.

These checks should converge in an exception register rather than a claim that migration is complete. Each exception needs a description, evidence, impact, accountable owner, next action and review date. Examples include a legacy contact that still receives notices, a prefix visible but absent from the approved inventory, an expected route that disappears, an old service label that support cannot resolve, or a physical record that has not been exercised. Age matters because a small unresolved set can contain the hardest dependencies and the largest recovery cost.

Exercises are the bridge between records and capability. A route-control exercise can ask an operator to explain an observed AS3367 announcement, identify its authority, compare registry and security metadata, and describe reversal. A service exercise can begin with a legacy F6 identifier and follow it through current support and network ownership. A physical exercise can test whether the right team can locate a dependency, obtain access and find restoration instructions outside normal hours. The result should be evidence of what was demonstrated, what failed and who owns correction.

The same discipline limits claims about reliability. Broad collector visibility supports a statement about observed routing visibility at the time queried. It does not reveal application availability, packet loss, optical degradation, customer equipment, support quality or recovery time. Historical product announcements support statements about capabilities described when issued, not the present architecture. Acquisition and transition notices support statements about organisational intent and process, not measured customer outcomes. Keeping these layers separate makes the analysis more useful because every conclusion has a known boundary.

Maintenance then becomes a recurring operating cost rather than a one-off integration task. Contacts expire, staff move, suppliers change, route policy evolves, equipment ages, systems are renamed and customers retain old references. Periodic reviews should sample both records and real workflows. A registry contact should be tested, not merely present. An expected-prefix list should be compared with multiple observations. A legacy service crosswalk should resolve a ticket. A restoration record should support an exercise. Controls that cannot answer those tests need repair even if their fields look complete.

This approach also clarifies accountability after an acquisition. The current operator does not need every public system to erase historical names at the same moment. It does need a defensible mapping between those names and current authority. That mapping should be accurate enough for peers, customers, regulators and responders to reach the right party, and detailed enough for operators to distinguish registration, routing, physical infrastructure and service responsibility. When the mapping is maintained and exercised, a durable identifier can support continuity. When it is neglected, the same durability preserves ambiguity.

The public record cannot show whether Xplore performs every one of these controls, and it should not be used to infer that it does or does not. It does show why the controls are necessary. A live ASN, historical fibre claims, retained network labels, a customer transition and regulatory records form separate pieces of an operational reality. The research conclusion is therefore bounded: continuity is not proved by any one record. It is produced by repeated reconciliation between authorised intent, running network state, physical capability, service ownership and evidence of exception closure.

Four cost centres that survive the transaction

Supervision cost

Supervision establishes who is accountable for intended state and who may change it. For AS3367, that includes registry contacts, route policy, prefix inventory, upstream relationships, monitoring ownership, and incident escalation. For fibre infrastructure, it includes physical assets, access rights, maintenance contractors, power, spares, and restoration priority. For customers, it includes service ownership, support entitlement, and communications.

The cost is recurring because records age. Staff change roles, suppliers merge, email domains change, and systems are replaced. An acquisition creates a burst of reconciliation, but it does not remove the need for periodic review. The control should verify that a published contact reaches the right team, that a route change has an accountable approver, and that the owner can produce current evidence. A role field without an exercised handoff is administrative appearance rather than supervision.

Independent verification is part of supervision. The person applying a high-impact route or registry change should not be the only source of confirmation. A second control can compare the approved intent with ARIN, PeeringDB, IRR data, RPKI, collector visibility, and service probes. Independence need not mean a separate company, but it should reduce the chance that one mistaken assumption controls both action and evidence.

Integration cost

Integration joins systems that evolved under different organisations. The acquiring operator may need to connect F6 inventory to Xplore's configuration management, monitoring, ticketing, billing, identity, and reporting. Field asset identifiers need to map to logical circuits and customers. Route and prefix objects need to map to current policy owners. Alerts need to open tickets with enough context to cross old and new naming systems.

Integration failures are often partial. Data can import successfully while losing a relationship. A customer can exist in billing but not in network inventory. An alert can contain AS3367 but fail to map to a current on-call team. A route policy can deploy while the evidence system still expects the legacy state. End-to-end tests should therefore follow real operating questions, not just record counts. Can an operator start with a customer report, identify the circuit, find the route and physical dependencies, contact the current owner, and verify recovery?

API and schema work is only part of the cost. People need shared definitions. Does "owner" mean legal registrant, commercial account owner, configuration approver, on-call responder, or physical-asset custodian? Does "active" mean announced in BGP, carrying traffic, billable, monitored, or supported? Ambiguous fields turn integration into a source of silent error. A glossary and evidence-backed state model are operational controls, not documentation polish.

Maintenance cost

Maintenance keeps the combined system useful after migration. Registry and PeeringDB contacts need review. Expected prefixes and route policies need version control. RPKI and IRR records need reconciliation. Optical and packet equipment need lifecycle planning, security updates, spares, configuration backups, and tested recovery. Monitoring thresholds need tuning as traffic and topology change. Customer records need current contacts and entitlement.

The 2014 Ciena announcement illustrates lifecycle risk. It documents a then-current technology decision, but the public evidence does not say what remains in service. An operator cannot safely infer current architecture from an old press release. It needs an internal asset record tied to software, support status, dependencies, spares, and replacement plans. If older equipment remains, the operator needs evidence that it is supportable. If it was replaced, diagrams and recovery procedures need to reflect the replacement.

Maintenance also includes evidence retention. A route change without a recorded reason becomes difficult to interpret later. A fibre repair without updated splice records increases the next restoration time. A customer migration without a mapping between old and new identifiers creates support ambiguity. Evidence should be proportionate, but critical state needs enough history to reconstruct who changed what, why, and how the final condition was verified.

Exception-handling cost

Automation handles the normal case. The expensive work begins when public records disagree, a prefix appears unexpectedly, an old customer identifier cannot be found, or a physical route does not match the diagram. Exceptions require classification, authority, evidence, communication, and closure. They also expose whether the operating model is real.

An exception queue should record impact, age, owner, next action, and accepted risk. Average closure time is insufficient because the oldest cases may represent the most obscure or consequential dependencies. Repeated mismatches should trigger a control change. If operators repeatedly struggle to map F6 labels to Xplore ownership, the answer is not more individual reminders; it is a better identity mapping and alert context.

The cost of exception handling should appear in acquisition planning and service economics. A transaction can look complete when contracts and systems have moved, yet legacy exceptions can consume staff for years. The relevant question is not whether every inconsistency can be eliminated immediately. It is whether each one is visible, owned, bounded, and prevented from becoming an unexamined production dependency.

Failure modes and concrete controls

1. Registry owner and operational label diverge

ARIN identifies Xplore while PeeringDB retains F6 Networks. Both can be useful, but an automated workflow may interpret the difference as an error or choose the wrong contact. The control is an approved identity map that records current responsibility, accepted aliases, evidence sources, and effective dates.

2. An expected route disappears

A prefix expected from AS3367 is withdrawn, filtered, or originated elsewhere. The control is a current expected-prefix inventory, multi-vantage observation, change correlation, and an escalation path that distinguishes planned engineering from a leak, hijack, or equipment failure. One RIPEstat snapshot cannot substitute for that control.

3. An unexpected route appears

AS3367 begins originating a prefix absent from the approved inventory. The change may be legitimate, stale documentation, or an incident. The control is a fail-closed reconciliation workflow: verify authorization, registry and RPKI state, configuration intent, and customer impact before normalising the new route.

4. IRR and RPKI state disagree with running BGP

The AS-F6 policy object, ROA state, and observed announcements no longer align. The control is a scheduled comparison with named owners for each data source. Operators should not assume that updating one registry automatically updates every consumer or that every peer applies the same filtering policy.

5. Legacy contacts remain reachable but unauthorised

An old F6 mailbox or supplier account still works after responsibility has moved. That creates confusion and potentially unauthorised change risk. The control is a credential and contact inventory, explicit revocation, tested role accounts, deputy coverage, and an audit of high-impact access after corporate transitions.

6. Current contacts exist but cannot resolve a legacy service

The new support channel answers, but the team cannot map an F6 circuit, hostname, or contract to current records. The control is searchable alias retention, migration crosswalks, sample-ticket exercises, and escalation tests using actual legacy identifiers.

7. Monitoring proves route presence but misses service failure

BGP remains visible while an optical path, customer interface, DNS dependency, or application fails. The control is layered observation across routing, transport, interfaces, service probes, and customer workflow. Each alert needs a declared boundary so that route health is not presented as end-to-end reliability.

8. A physical asset cannot be located or accessed

Documentation says a fibre component exists, but field location, access authority, key, spare, or contractor information is stale. The control is asset verification, geospatial and splice-record maintenance, access exercises, and restoration drills that include off-hours conditions.

9. An old architecture description is treated as current

The 2014 Ciena deployment is copied into a present diagram without verification. The control is evidence dating. Every architecture claim should identify its observation date, source, current owner, and verification status. Historical vendor material belongs in the change history until current records confirm it.

10. A customer transition preserves billing but loses technical context

The commercial account migrates, but circuit dependencies, maintenance restrictions, or monitoring ownership do not. The control is an end-to-end migration check that connects customer, service, logical network, physical route, support entitlement, and escalation owner.

11. Licence disposition is misread as network state

CRTC records document F6's participation in telecom proceedings and a later BITS licence surrender. A reviewer might equate that administrative record with shutdown. The control is to keep regulatory status separate from observed routing, physical assets, and customer service. A licence record supports only the disposition it states.

12. Acquisition language becomes an outcome claim

A release describes a network footprint and strategic rationale, and later reporting treats that as proof of better service or lower cost. The control is an evidence ladder. Transaction and capability statements belong at the capability layer. Reliability requires repeated operational measures. Customer outcomes require customer-specific baselines and results.

13. Shared systems create correlated failure

Consolidating F6 operations into Xplore systems can reduce duplication but may increase common-mode exposure. The control is dependency mapping, staged migration, rollback, independent verification, and recovery tests that assume the shared control plane is unavailable.

14. Exception debt becomes invisible

Most records migrate successfully, while a small group of difficult circuits, contacts, route objects, or field assets remain unresolved. The control is an aged exception register with impact, owner, next action, and an expiry for accepted risk. Closure quality matters more than a high migration percentage.

F6 Networks After Acquisition: AS3367, Fibre Continuity, and the Cost of Operational Handover

Why it matters