Summary

  • Cloudflare reported that, around 10:30 UTC on 24 June 2019, a small Pennsylvania network became a preferred path for many Internet routes through Verizon AS701, and that Cloudflare prefixes were among the affected announcements [1].
  • Cloudflare's later analysis tied the failure to a route-optimizer path and to propagation by a large transit provider. That makes the control surface BGP import and export policy, not a generic cloud or software incident [2].
  • Noction publicly responded to the incident because its route-optimization product was part of the public discussion. That response is useful because it separates product intent from deployment governance: automation can optimize paths only inside the routing limits that operators enforce [3].
  • ThousandEyes/Catchpoint observed external reachability effects for Cloudflare users during the routing pile-up, which anchors the harm boundary in measured Internet performance rather than private operator logs [4].
  • RFC 7908 and RFC 9234 explain why the event class matters. A route leak is a violation of intended BGP relationship propagation, and BGP Roles/Only-to-Customer are designed to make those relationship assumptions explicit [6][7].

Why this was a routing accountability case

The incident is often remembered because Verizon appeared in the public headline. That is understandable. Verizon was the large transit network through which many routes became visible to the wider Internet. But an accountability analysis has to start one layer earlier: a route became eligible for acceptance and propagation before the rest of the Internet saw the impact.

Cloudflare's first report said many routes were sent through Verizon after a small Pennsylvania company became a preferred path. In BGP terms, the public issue was not merely that a network announced something. The issue was that other networks treated that path as usable and carried it further. A bad or surprising route announcement becomes an Internet-scale event only when surrounding networks accept it, prefer it, and export it beyond the relationship where it belongs [1].

That is why DQE matters in the article title. The public record around the incident points toward the customer-side route source and the route-optimization layer, while the propagation path points toward upstream filtering. DQE was not the global platform whose users complained, and it was not the only network whose decisions mattered. But a small network at the edge of a transit relationship can still become the place where an accountability chain begins, because BGP does not treat small networks as operationally harmless by default.

The Cloudflare deep dive made the route-optimizer layer central. Route optimizers can select paths to improve price, latency or reachability. They can also create risk when their output is accepted as if it were ordinary customer-originated routing evidence. The distinction is important. Automation is not a defense if it has practical control over exported routes. It is also not the only defendant if larger networks fail to apply import filters, maximum prefix limits, relationship checks, or route-leak prevention controls [2].

Noction's response adds another boundary. The company did not present the incident as a reason to abandon route optimization altogether. It described its view of the incident and the product-control context. That response matters because the accountability question is not whether route optimization is inherently illegitimate. The question is whether the product, its customer deployment, and upstream acceptance rules produced auditable guardrails around what routes could be optimized and exported [3].

What public evidence can and cannot prove

Public route collectors and external measurements are strong enough to prove that a routing event happened. They are not strong enough to prove every private configuration choice. Cloudflare could describe affected prefixes, routing paths and observed propagation. ThousandEyes/Catchpoint could describe user-visible symptoms and external measurements. Kentik could place the incident inside a broader history of consequential BGP failures. None of those public sources can replace the internal route maps, change tickets, optimizer policy configuration, acceptance logs, and incident-room decisions held by the operators [1][2][4][5].

That distinction keeps the article inside a defensible evidence boundary. It would be too strong to claim, from public evidence alone, that DQE intended to attract unrelated traffic, that Noction's software alone caused the incident, or that Verizon deliberately preferred harmful paths. The public evidence supports a narrower and more useful conclusion: the acceptance chain was weak enough that a customer-side route leak could propagate through a major provider and disturb reachability at scale.

The harm boundary is also narrower than some retellings imply. The incident affected many routes and visible service paths, including Cloudflare-related traffic. But public reporting does not give a complete accounting of every packet, every destination, every end-user transaction, or every commercial loss. A serious closeout should therefore measure reachability symptoms, affected prefix sets, duration, and route selection rather than turning the event into a universal outage label [4].

The control surface was relationship evidence

BGP is based on policy as much as reachability. A route learned from a customer can usually be carried to a provider or peer because the customer is expected to be announcing its own networks and its own downstream customers. A route learned from one provider should not normally be exported to another provider as if the announcing network were a transit path for the rest of the Internet. RFC 7908 describes this family of relationship violations as route leaks [6].

The 2019 event belongs to that family. Whether the first bad choice sat in a customer route map, a route optimizer policy, or an upstream import rule, the critical missing proof was relationship evidence. Which routes was DQE authorized to announce? Which routes did the optimizer mark as exportable? Which route acceptance policy did Verizon apply at the customer edge? Which maximum-prefix, AS-path, IRR, RPKI, prefix-list or role-based checks existed? Which alerts fired when the accepted path set expanded beyond the normal customer boundary?

RFC 9234 is useful here because it shows where later standards work tried to move the industry. BGP Roles and Only-to-Customer make provider, customer and peer relationships more explicit in BGP sessions. They do not magically repair every legacy interconnection. They do, however, turn a hidden assumption into protocol-visible evidence. That is exactly the kind of evidence the 2019 incident lacked in the public record [7].

RPKI origin validation also has a boundary. It can help when the origin ASN is unauthorized for a prefix. It does not necessarily reject a path whose origin is legitimate but whose middle relationship is wrong. A route leak can preserve a valid origin while violating the business and topology relationship in the AS path. That is why the accountable repair has to include route-leak detection, relationship tagging, import policy, export policy, and route monitoring, not only origin validation.

Who had practical control

DQE or DQECOM had the closest practical control over the customer-edge export boundary. If the leaked path began with a route-optimizer deployment at or near that edge, then DQE needed evidence that only authorized customer routes could leave its network. That evidence would include route maps, accepted prefix lists, optimizer guardrails, change review, max-prefix thresholds, and a withdrawal timeline.

Noction had practical control over product behavior, defaults, documentation and incident learning. A route optimizer that can influence BGP announcements must be treated as routing infrastructure, not as a neutral analytics accessory. The relevant evidence is not marketing intent. It is whether the product made dangerous exports difficult, whether customer deployments were warned about transit propagation risk, and whether post-incident changes reduced the chance of recurrence [3].

Verizon had practical control over upstream acceptance and propagation. A large transit provider is not expected to know every private mistake a customer can make. It is expected to maintain filters and anomaly controls so that one customer cannot easily become a path for unrelated portions of the Internet. If a customer suddenly announces a broad or abnormal route set, the provider-side question is why those routes were accepted, preferred or exported before the incident was contained [1][2].

Downstream and peer networks also had smaller but real roles. The Internet is not a single hierarchy. Other networks can dampen or amplify a leak depending on their import policy, route preference, monitoring and route-leak controls. That is why public accountability should not stop with one headline network. It should ask each operator in the path what relationship evidence it used before accepting the route.

What repair should have looked like

A credible repair record would start with a route inventory: the prefixes involved, the AS paths observed, the timestamps when the leak began and ended, and the collector locations that saw the path. It would then attach operator-side evidence: DQE's export policy, Noction's optimizer guardrails, Verizon's customer filters and alerts, and the withdrawal messages or route-map changes that ended propagation.

The next layer is recurrence prevention. Operators should be able to show maximum-prefix limits, prefix-list generation from trusted route objects, IRR review discipline, RPKI origin validation where applicable, AS-path filters for customer sessions, and route-leak detection tuned to relationship violations. Where supported, BGP Roles and Only-to-Customer provide a stronger way to make customer, provider and peer roles explicit [7].

The final layer is public communication. A routing incident that crosses many networks should not require every affected customer to reverse-engineer BGP tables. A basic public closeout should state what class of route leak occurred, what was observed publicly, what remains unknown, what control changed, and what evidence would show recurrence reduction. That does not require publishing confidential route maps. It does require enough specificity that customers can distinguish real repair from public-relations closure.

The accountability test

The 2019 DQE/Noction/Verizon leak is not useful because it lets observers assign a simple villain. It is useful because it shows how Internet routing turns small control failures into shared dependency events. A customer-side route source, an optimizer, a transit provider and remote networks each held part of the practical control. If any one layer treated relationship assumptions as someone else's problem, the leak could travel farther than it should.

The correct accountability standard is therefore evidence-based. DQE needed to prove that its exports stayed inside authorized customer boundaries. Noction needed to prove that optimizer behavior could not silently convert optimization into unsafe propagation. Verizon needed to prove that customer import filters and anomaly controls protected the wider Internet. Other networks needed to prove that they did not accept a leaked path merely because it arrived through a large provider.

That is the Heng.lu surface in this case: routing records, relationship roles and running code decide operational reality. Reputation, company size and after-the-fact explanations matter less than the evidence encoded in filters, route objects, telemetry and withdrawals. The public lesson is not that BGP is fragile in the abstract. It is that relationship evidence has to be maintained before the next small network becomes a surprising path for the rest of the Internet.