rickmur

5 min read

Self Driving Networks stop at the edge

Vendors can now close the loop inside their own SD-WAN and SASE stack, but it breaks at the ISP. What agents need from the underlay to cross the demarc.

sdnaiconnectivityispinternetgnx

Last week HPE announced that its SD-WAN and SASE portfolio now runs on Marvis, the same AI engine that already drives its campus and data center networking. HPE calls the result a self driving network, with agents that detect, diagnose and fix problems across the whole stack.

Full disclosure: I used to work at Juniper, now part of HPE, and I believe in their strategy and portfolio. I first heard Kireeti Kompella present his vision of the self driving network (SDN) in 2016. 10 years later, it is finally starting to sound realistic.

Inside a single vendor’s network, it is realistic. Devices stream telemetry over gNMI every few seconds instead of being polled over SNMP every 5 minutes. The controller knows the full topology and the intended state of every device, and it can push configuration back when something drifts. With all of that in 1 place, you can build a closed loop that actually works.

The problem is the layer below. Every SD-WAN edge runs on top of an internet circuit, and that circuit belongs to someone else.

Where the telemetry ends

An SD-WAN edge knows quite a lot about its underlay. It sends BFD or proprietary probes through every tunnel, several times per second, and measures loss, latency and jitter per path. When a path breaks its SLA thresholds, the edge moves the application to a better one. But all of that is measured from tunnel endpoint to tunnel endpoint. Whatever happens in between is invisible to it.

Take a DIA circuit that drops 2% of its packets every evening around 19:00. The overlay reports that perfectly, but it has no idea why it happens. It could be a congested GPON tree in the street, an oversubscribed aggregation link in the ISP’s PoP, a full peering interconnect or a transit provider 3 AS hops away. Each of those has a different fix and a different owner, often at a different company. You can run MTR, but with ICMP rate limiting on router control planes and MPLS cores hiding their hops, it is easy to draw the wrong conclusion.

Diversity has the same problem. A customer orders 2 circuits from 2 different ISPs and the SD-WAN load balances over both. Neither tunnel tells you that both ISPs resell the same incumbent’s last mile. Inside a single MPLS network we handle this with traffic engineering. Between providers, that information doesn’t exist in any usable form. If you’re lucky, you get a KMZ file of the route.

At GNX we work with more than 3,000 ISPs, and a customer with a few hundred sites easily ends up with dozens of them. Each one has its own portal, its own ticket format and its own idea of what a fault report should contain. So as soon as the overlay runs into a problem it can’t route around, a human takes over again. Usually that means someone emailing a carrier NOC with an MTR output attached, and then waiting.

Operators run into the same thing

Orange, Telenor and Vodafone discussed how they use AI agents in their own operations. Root cause analysis came out as their number 1 use case, which makes sense: an agent can find out in minutes what takes an engineer hours.

The example from Vodafone stood out to me. After a fiber break, agents would pull in the right internal teams and suppliers, keep track of who does what and follow up on the SLA commitments. Inside your own network, root cause analysis works because you own the topology, the inventory and the logs. That is how you trace an alarm storm back to 1 failed line card. Once a supplier is involved, you are trying to correlate against data you don’t have.

The panel was also open about what is holding them back: data quality, governance and skills. A smarter model doesn’t help much with any of those. What helps is clean, structured data flowing between everyone involved.

What an agent needs from the underlay

After years of working with these providers, I can tell you that most of the industry still runs on spreadsheets, PDFs and email threads. Quotes take days or weeks. Order updates arrive as free text. A fault ticket’s status lives in someone’s inbox or in a portal.

What frustrates me is that the standards already exist. MEF LSO Sonata defines APIs between providers for serviceability, quoting, ordering and trouble ticketing (we can agree or disagree on how complicated the API framework is and if it’s efficient). Large carriers support them. Most of the smaller local ISPs don’t, and those are exactly the ones serving enterprise branch sites.

An agent can read a PDF, but it can’t do much with it. For the underlay to become part of the loop, I see 5 things that need to be machine readable:

  • Availability and pricing. Which services exist at an address, at what bandwidth, term and price
  • Order state. Provisioning milestones as structured events and real time updates.
  • Faults. Tickets an agent can open, update and close, with clear priorities and responsibilities.
  • Path data. Which last mile provider, building entry, central office and upstream carrier sit behind each circuit. Basically traffic engineering that works across providers.
  • Circuit health from the provider side. Interface counters and optical levels on the NTE, plus routing protocol session state and received prefixes. That lets an agent tell a dead last mile apart from a routing problem further upstream.

This is work we have been doing in GNX+ for years: taking whatever thousands of providers send us and turning it into 1 data model. It is also why we opened the platform up to AI agents. An agent that can check serviceability, track an order and open a ticket through 1 interface is a lot closer to self driving than one that stops at the CPE.

Closing the loop across the edge

Vendors will keep pushing autonomy inside their own boxes, and they should. But the outages enterprises remember rarely start in the SD-WAN/SASE controller. They start with a fiber cut, a congested peering point or a last mile provider that doesn’t pick up the phone.

Extending data only ISPs know today needs agreed data models and APIs between providers, much like routing protocols once gave us a common way to exchange reachability (and terminology).

It took 10 years for Kireeti’s vision to become realistic inside 1 network. I don’t expect it to take another 10 years to cross the network edge, but it will need the whole supply chain to get there.

Sources