TL;DR

Most enterprise network architectures begin with established design patterns. Engineers choose proven topologies, routing protocols, redundancy models, and traffic-engineering methods because those approaches have understandable failure behavior and operational history. That discipline is necessary, but it also limits how many alternative designs an engineering team can realistically investigate.

AI-assisted architecture discovery offers a different approach. Rather than asking a model to recommend a familiar network design, engineers can define a bounded search space and allow machine-driven optimization to propose unconventional configurations. Deterministic constraint checks, routing analysis, network simulation, and independent laboratory testing then establish whether any candidate is valid and meaningfully better than established alternatives.

This article designs a controlled experiment around a small leaf-spine Ethernet fabric. It explains how to represent candidate topologies, preserve routing and security requirements, test failure conditions, measure workload behavior, and reject designs that optimize one metric at the expense of service reliability or operational supportability. The experiment is an engineering proposal, not a claim of tested or measured AI-generated network improvements.

Takeaway: AI should be allowed to challenge familiar network designs, but every proposed improvement must survive independent verification of connectivity, performance, resilience, security, and operational behavior.

Introduction

A network architect is asked to redesign a datacenter fabric that supports virtualization, storage traffic, Kubernetes applications, and an expanding collection of AI workloads.

The existing infrastructure is functional. Redundant switching is in place, Border Gateway Protocol (BGP) provides routing in the fabric, and Equal-Cost Multipath (ECMP) distributes eligible traffic across available paths. Monitoring shows that the environment is generally healthy, although some links experience congestion while others remain underutilized.

The business wants more usable capacity without a disproportionate increase in infrastructure spending.

The conventional response is familiar. Review utilization, evaluate oversubscription, examine uplink capacity, adjust supported traffic-engineering mechanisms, and determine whether the network needs additional switching resources.

Those are appropriate engineering activities.

But what if the best answer is an arrangement the architecture team has not considered?

Perhaps changing a small number of physical connections would improve traffic distribution. Perhaps an alternative allocation of links would reduce the impact of a particular failure. Perhaps the existing topology is already the best practical option, but an unconventional design could expose a useful relationship between traffic patterns and network capacity.

An AI-assisted search system might investigate those possibilities systematically.

It might also generate thousands of invalid designs.

A candidate may disconnect a workload during a spine failure, oversubscribe an uplink, exceed a switch’s port capacity, violate a segmentation requirement, or depend on forwarding behavior the installed hardware does not support.

A topology may look excellent in simulation while failing under real congestion, route reconvergence, or optical faults.

This makes networking an especially useful domain for testing the discovery-engine concept.

Network architecture combines mathematical graph properties with protocol behavior, physical hardware constraints, security requirements, and measurable application performance. Some of those properties can be checked deterministically. Others require simulation or physical testing.

The challenge is to use that structure to expand exploration without weakening engineering discipline.

Part 1 of this series established the distinction between AI imitating human reasoning and AI searching for independently verifiable solutions. Part 2 defined the discovery engine, including candidate generation, evaluation, search memory, and approval boundaries.

Part 3 applies those ideas to a concrete networking problem.

The objective is not to prove that AI can replace network architects. It is to design an experiment that could establish whether machine-assisted search can discover useful network configurations that a conventional design process did not identify.

Why Network Architecture Is a Difficult Discovery Problem

A network topology is more than a diagram showing which devices connect.

It represents constraints involving port availability, physical reachability, capacity, routing, failure domains, forwarding behavior, security enforcement, and operating cost.

Two diagrams that appear almost identical can behave very differently under load or failure.

Established Patterns Exist for Good Reasons

RFC 7938, Use of BGP for Routing in Large-Scale Data Centers, documents an approach built around BGP and Clos network topologies. It addresses considerations including operational simplicity, network stability, scalable capacity, and ECMP behavior.

The document is informational, rather than an Internet Standards Track specification, but provides a useful foundation for understanding established large-scale fabric design.

A conventional leaf-spine fabric provides predictable structure. In a fully connected two-tier design, each leaf has uplinks to every spine, allowing traffic to use multiple paths through the fabric.

That structure is valuable because engineers can reason about bandwidth, failure behavior, routing adjacencies, and expansion using known relationships.

An AI system that proposes a new topology must respect the underlying requirements. Novelty alone cannot justify removing useful path diversity.

A Valid Topology Is Not Necessarily a Good Topology

Graph theory can establish whether two devices remain connected after a link or node failure.

That does not establish whether the surviving path has enough capacity.

Similarly, a routing model may show that a destination is reachable while the actual workload experiences unacceptable latency or congestion.

RFC 2992 examines an ECMP selection algorithm and the disruption caused when the next-hop set changes. RFC 7424 examines mechanisms for optimizing component-link utilization with ECMP and Link Aggregation Groups (LAGs).

These documents help explain why physical connectivity, next-hop selection, and effective bandwidth utilization must be evaluated separately.

The experiment must therefore ask several different questions:

• Can the network forward traffic between required endpoints?
• Can it preserve that connectivity through the defined failures?
• Does routing converge to the intended paths?
• Are security boundaries enforced along those paths?
• Can the topology handle representative traffic without unacceptable degradation?
• Can engineers deploy, monitor, troubleshoot, and recover the design using supported mechanisms?

A candidate that passes the first question has only begun the evaluation.

Bound the Search: A Twelve-Link Fabric Experiment

The proposed experiment uses an intentionally small, constrained network. The objective is to compare different assignments of the same physical uplink budget, rather than give the AI unlimited freedom to buy devices or invent forwarding capabilities.

Assume four leaf switches and four already installed, powered, and licensed spine switches. Each leaf has three approved uplinks, for a total of twelve leaf-to-spine connections. Each spine has four available leaf-facing ports. No leaf-to-leaf or spine-to-spine links are permitted in this simplified two-stage fabric. All candidate links use the same approved port speed and compatible physical media.

This is a partially connected brownfield test model, not a complete nonblocking Clos reference design. A conventional fully connected four-leaf, four-spine fabric would have sixteen leaf-to-spine links. The twelve-link cap is a deliberate constraint for the experiment, not a recommendation to reduce production fabric connectivity.

Fixed assumption	Why it is fixed
Four leaves, four spines, twelve uplinks	Preserves the hardware and cabling budget across candidates
Three distinct spine neighbors per leaf	Prevents a candidate from reallocating all capacity away from one leaf
Four leaf-facing ports maximum per spine	Prevents impossible physical assignments
Spines S1 and S3 in power zone A; S2 and S4 in zone B	Allows correlated power-zone failures to be tested
Approved BGP underlay and supported ECMP behavior	Keeps the experiment inside an implementable protocol model
Existing security segmentation and allowed paths	Prevents an optimization from silently weakening isolation
No production write access	Separates experimentation from change authority

Two design choices need explicit agreement before the experiment begins. First, the failure criterion is that required leaf-to-leaf traffic must retain an eligible common spine after any single spine failure and after either modeled spine power zone fails. Second, passing a connectivity check does not imply sufficient capacity during that failure.

The physical rack, power feed, port, optics, and cable-reach details must be replaced with the real site’s inventory before this model could become a deployment candidate. The power zones are illustrative correlated-failure groups, not assertions about any actual datacenter.

The Counterexample: Better Balance Can Make Resilience Worse

The starting layout connects all four leaves to S1, S2, and S3. S4 is installed and powered but has no leaf uplinks assigned. It is an unusual but plausible transitional brownfield state during fabric expansion.

A search algorithm concerned with distributing links evenly might suggest spreading all twelve links across four spines, three links per spine. On a simple port-utilization score, that arrangement looks attractive. It also passes basic tests requiring three unique uplinks per leaf, connections in both power zones, and two common spines between each pair of leaves.

The trap appears when a whole power zone fails.

Figure: A superficially balanced allocation passes simple per-leaf checks but fails the modeled correlated power-zone outage. The layout illustrates graph connectivity, not measured traffic performance.

This is exactly the kind of subtle failure a discovery engine must catch before performance scoring.

A more conservative zone-aware alternative retains S1 and S2 as shared neighbors for every leaf. L1 and L2 also use S3; L3 and L4 use S4. Its spine link counts become 4, 4, 2, 2. That layout preserves a common spine under either modeled power-zone loss, although it concentrates critical shared connectivity onto S1 and S2 and can still fail on bandwidth, policy, routing, or supportability.

None of these calculations proves a real-world performance improvement. They show that even a small topology search can produce different validity outcomes depending on which failure domains the evaluator understands.

Use a Deterministic Gate Before Any Simulation

The following Python 3 example performs two different checks. First, it validates the link budget and basic graph structure. Second, it removes each modeled power zone and tests whether every leaf pair retains a shared spine. It uses only the standard library and does not connect to network equipment.

from itertools import combinations

LEAVES = ("l1", "l2", "l3", "l4")
SPINE_ZONES = {"s1": "A", "s2": "B", "s3": "A", "s4": "B"}


def structural_rejections(topology):
    problems = []
    if set(topology) != set(LEAVES):
        problems.append("unexpected leaf inventory")
    for leaf in LEAVES:
        uplinks = topology.get(leaf, ())
        if len(uplinks) != 3 or len(set(uplinks)) != 3:
            problems.append(f"{leaf}: exactly three distinct uplinks required")
        if set(uplinks) - set(SPINE_ZONES):
            problems.append(f"{leaf}: unknown spine")
        elif len({SPINE_ZONES[s] for s in uplinks}) < 2:
            problems.append(f"{leaf}: both power zones required")
    for spine in SPINE_ZONES:
        if sum(spine in topology.get(leaf, ()) for leaf in LEAVES) > 4:
            problems.append(f"{spine}: port budget exceeded")
    for left, right in combinations(LEAVES, 2):
        shared = set(topology.get(left, ())) & set(topology.get(right, ()))
        if len(shared) < 2:
            problems.append(f"{left}/{right}: insufficient shared spines")
    return problems


def zone_failure_rejections(topology):
    problems = []
    for failed_zone in ("A", "B"):
        for left, right in combinations(LEAVES, 2):
            shared = set(topology[left]) & set(topology[right])
            surviving = {s for s in shared if SPINE_ZONES[s] != failed_zone}
            if not surviving:
                problems.append(
                    f"{left}/{right}: no shared spine after zone {failed_zone} fails"
                )
    return problems


baseline = {leaf: ("s1", "s2", "s3") for leaf in LEAVES}
balanced = {
    "l1": ("s1", "s2", "s3"),
    "l2": ("s1", "s2", "s4"),
    "l3": ("s1", "s3", "s4"),
    "l4": ("s2", "s3", "s4"),
}
zone_aware = {
    "l1": ("s1", "s2", "s3"),
    "l2": ("s1", "s2", "s3"),
    "l3": ("s1", "s2", "s4"),
    "l4": ("s1", "s2", "s4"),
}

for name, topology in (
    ("baseline", baseline),
    ("balanced", balanced),
    ("zone-aware", zone_aware),
):
    structure = structural_rejections(topology)
    zones = zone_failure_rejections(topology) if not structure else ["not evaluated"]
    print(
        f"{name}: structure={'PASS' if not structure else 'FAIL'}, "
        f"power-zones={'PASS' if not zones else 'FAIL'}"
    )

Running this self-contained graph check gives:

baseline: structure=PASS, power-zones=PASS
balanced: structure=PASS, power-zones=FAIL
zone-aware: structure=PASS, power-zones=PASS

The example verifies only the modeled graph invariants. It does not test BGP configurations, effective forwarding, optical feasibility, policy, routing convergence, bandwidth, or application latency. The zone-aware candidate still has to pass those subsequent gates.

Before using this code against a real inventory, replace the illustrative devices and zone map with approved data. Add hard gates for allowed port pairings, physical cabling, line-card failure domains, route and policy dependencies, and service-specific reachability. A production discovery harness also needs strict input validation and safeguards against malformed or excessive candidate submissions.

Evaluate Candidates Through Different Technical Layers

There is no single network evaluator that proves every relevant property. The validation stack should become progressively more expensive and more realistic.

Evaluation layer	What it can establish	What it cannot establish
Graph and inventory validation	Allowed edges, port limits, modeled path diversity, shared-risk failures	Actual control-plane operation or delivered bandwidth
Configuration and reachability analysis	Routing and policy implications of modeled device configurations	Hardware timing, all dynamic behaviors, throughput
Discrete-event simulation	Modeled packet behavior under specified traffic and failures	Faithful reproduction of every vendor ASIC, NIC, firmware, or workload characteristic
Routing emulation	Behavior of chosen routing implementations and configurations	Fidelity to production hardware data planes
Physical laboratory test	Device-specific forwarding, congestion, optics, fault and recovery observations	Every future workload or correlated production failure

Validate the Control Plane Separately

Network analysis tools such as Batfish can reason about supported configuration snapshots, topology, routing, forwarding, access controls, and differential behavior. That makes them useful for checking whether a generated network configuration preserves approved connectivity and isolation properties.

A candidate still needs a supported device configuration model. A passing graph test cannot substitute for route-policy analysis. Likewise, static reachability analysis is not a throughput benchmark.

If the experiment uses BGP, test expected neighbor relationships, route advertisement and filtering, next-hop resolution, withdrawal, path selection, and effects on permitted and prohibited flows. Explicitly include management access and recovery paths, not only application data paths.

Simulate Representative Traffic

A network simulator such as ns-3 can provide a repeatable environment for testing modeled packet-level behavior. Its suitability depends on the specific protocol and queue models configured and whether they capture the mechanisms that matter for the workload.

The comparison should use identical traffic inputs and equivalent resources for the baseline and qualified candidates. Test steady-state load, bursts, asymmetric traffic, and failures. If the objective involves distributed AI, include traffic patterns representative of the relevant collectives or service communications rather than relying on a generic uniform-flow generator.

Keep the performance measures tied to services: completed useful work, flow completion time, high-percentile latency, retransmissions or loss, queue occupancy, and the degree of degradation after failure. Vendor telemetry, including NVIDIA’s published Spectrum-X examples, illustrates why transient congestion and link errors may require finer-grained measurements than ordinary interface polling.

Do not assume the simulator’s ECMP or congestion model matches the hardware. That claim requires its own validation.

Verify With Physical Equipment When the Claim Warrants It

Only the strongest candidates should consume laboratory hardware time. On the intended devices and software baseline, verify supported cabling and optics, route convergence, link and switch failures, congestion behavior, security enforcement, and recovery after the test.

This is also where a mathematically elegant topology may become unappealing. It might require awkward recabling, consume unusual port combinations, complicate maintenance, or create a failure pattern that the operations team cannot readily diagnose.

A physical test is a necessary escalation for consequential claims, not permission to bypass the enterprise change process.

Use a Fair Experiment Instead of a Benchmark Contest

The purpose of the experiment is to find an improvement, not to guarantee that an AI-generated candidate wins.

Establish three competitors before search begins: the approved current configuration, a credible conventional engineering alternative, and the machine-generated candidates. Where the search space is small, also include enumeration, constraint solving, or conventional heuristic optimization. If an exact method finds the best qualified layout cheaply, using a language model adds little engineering value.

Separate search scenarios from holdout scenarios. The generator may receive scores from an approved development evaluator, but it should not repeatedly tune against the final acceptance suite. Otherwise, strong scores may reflect benchmark overfitting rather than robust network behavior.

The following is the proposed experiment’s evidence plan, not a report of completed test results.

Question	Evidence required	Stop or rejection condition
Is the design valid?	Port inventory, graph gates, approved hardware combinations	Any hard constraint fails
Does it preserve security?	Allowed and denied flow analysis for normal and degraded modes	Required inspection or isolation fails
Is routing correct?	Configuration analysis, route tables, neighbor state, failure replay	Persistent blackhole, loop, or unacceptable convergence
Is performance better?	Paired workload replay, distribution of latency and useful throughput	Improvement absent or protected service regresses beyond agreed tolerance
Is it robust?	Holdout traces, multiple load levels, link, switch, and power failures	Claimed benefit disappears or critical failure behavior worsens
Is it operable?	Change plan, diagnostics, support matrix, maintenance and recovery exercise	No acceptable support or recovery path

A comparison should distinguish the best normal-operation result from the most defensible operating result. An extra percentage point on a simulated throughput score is not enough to justify a design with materially weaker fault tolerance or an unmanageable change path.

For candidate selection, store the topology input, generator and evaluator versions, traffic-trace identifiers, simulator configuration, random seeds where relevant, rejected cases, results, reviewer decisions, and the cost of verification. Use consistent identifiers so the reported winner can be independently replayed.

Treat the Search Budget and Operational Cost as Design Constraints

Search has its own economics. A generator may produce thousands of layouts quickly, while detailed network simulation and hardware tests are much more expensive. Use inexpensive graph and static-policy gates first, then reserve costly evaluation for a small set of qualified, diverse candidates.

Do not let one optimization metric hide the full cost of change. A topology requiring recabling or new operational procedures has a transition cost even when the switch inventory is unchanged. Consider optics, structured cabling, maintenance windows, redundancy during cutover, routing-policy complexity, monitoring, training, and rollback.

This proposed trial also illustrates why performance must be expressed as more than one number. The balanced graph has attractive link-count symmetry but fails a correlated-outage condition. The zone-aware graph passes that condition, yet concentrates shared paths onto particular spines and may perform worse for certain traffic matrices. Without simulation and laboratory results, no candidate has earned a performance recommendation.

The search should stop when further evaluation cost exceeds the plausible value of the remaining candidates, when the improvement is no longer reproducible, or when no qualified candidate offers a meaningful advantage over conventional engineering alternatives.

What Would Count as a Genuine Network Discovery?

A technically valid candidate is not automatically novel, and a novel candidate is not automatically useful.

The experiment should reserve the word discovery for a candidate with a defensible difference from known approaches and a meaningful, independently reproduced benefit under the approved requirements. An alternative that works only in an unrealistic simulation should remain a research result. A design that improves one workload while violating security or recovery requirements should be rejected.

There are three legitimate outcomes. The machine-search approach may discover a reproducible improvement worth advancing to a controlled hardware pilot. It may uncover a tradeoff or failure mode that improves the team’s understanding without changing the architecture. Or it may demonstrate that the existing design or a conventional optimizer remains the stronger option.

All three are useful when the evidence is retained. None requires pretending that AI has invented a universally superior network fabric.

Conclusion

AI-assisted network architecture discovery is a reasonable engineering research direction precisely because networking exposes the difference between plausible proposals and verifiable results. Graph structure can be tested, routing and policy can be analyzed, traffic can be simulated, and selected candidates can be challenged on physical hardware.

The twelve-link example shows why that process must be layered. A balanced-looking candidate can satisfy local redundancy rules and still break connectivity when a shared failure domain disappears. A different candidate can survive that failure while creating a new concentration of critical paths. Structural validity, performance, resilience, and operational acceptability are separate decisions.

The recommended first step is to select a narrow, non-production search problem and establish the full baseline and failure-domain model. Build the rejection gates before increasing search volume. Compare every machine proposal with credible human-designed and conventional optimization alternatives, then require independent replay before discussing production changes.

Part 4 will address the final boundary: how an organization decides whether a machine-discovered solution deserves production trust, including ownership, change authority, evidence retention, rollback, and ongoing monitoring.

The question for network architects is not whether AI can draw a topology we have never seen. It is whether we can prove that the unfamiliar topology is better without sacrificing the properties that make the network dependable.

Continue the AI discovery series or explore the Enterprise AI hub.

External References

• RFC Editor: RFC 7938, Use of BGP for Routing in Large-Scale Data Centers
• RFC Editor: RFC 2992, Analysis of an Equal-Cost Multi-Path Algorithm
• RFC Editor: RFC 7424, Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks
• ns-3 Project: ns-3 Tutorial
• Batfish: Packet Forwarding, pybatfish Documentation
• NVIDIA Technical Blog: Next-Generation AI Factory Telemetry with NVIDIA Spectrum-X Ethernet

The post Can AI Discover Better Network Architectures? Designing a Controlled Experiment appeared first on Digital Thought Disruption.