The Internet routing security story of the past decade has largely been about fixing route origins. RPKI Route Origin Validation (ROV) gave operators a cryptographic way to verify that the AS announcing a prefix was actually authorized to do so. That work has now reached majority coverage, with over half of all IPv4 and IPv6 routes now protected by Route Origin Authorizations (ROAs).

But origin validation only tells you where a route claims to start. It says nothing about the path it took to get to you. A route can have a perfectly valid origin and still arrive via a completely illegitimate chain of ASes, through a misconfigured transit network, a malicious route leak, or a manipulated AS_PATH. This gap is exactly what ASPA (Autonomous System Provider Authorization) is designed to close.

ASPA has moved from theory into early operational deployment, even though the core ASPA profile and verification work remain in IETF draft form as of March 2026. ARIN and RIPE NCC both support ASPA object creation in production. Major networks have begun deploying ASPA validation globally. Router implementations exist in BIRD and OpenBGPD. This article is intended to explain what ASPA is, how it works technically, what it Continue reading

For over three decades, BGP’s AS_SET path segment has been a legal, if problematic, feature of Internet routing. In May 2025, the IETF formally ended that era. RFC 9774 doesn’t merely discourage AS_SET: it prohibits it entirely.

This post unpacks what AS_SET is, why it was created, what went wrong, and what network operators need to do now that the IETF has made its deprecation a binding standard requirement.

Background: What is the AS_PATH attribute?

Every BGP UPDATE message carries an AS_PATHattribute – a record of the Autonomous Systems a route advertisement has traversed on its way from origin to destination. It serves two critical functions: loop prevention (a router seeing its own AS in the path discards the route) and policy (operators use AS_PATH to make routing decisions based on where traffic comes from or how it’s being forwarded.

The AS_PATH is composed of path segments, each of which is one of four types:

Type	Description	Status
AS_SEQUENCE	An ordered list of ASes the route has passed through. The most common and well-understood type.	Valid
AS_SET	An unordered set of ASes created during route aggregation. Now deprecated.	Deprecated
AS_CONFED_SEQUENCE	Ordered list of Member AS Numbers within a Continue reading

If you’ve spent time supporting AI infrastructure, whether that’s a GPU training cluster, a fleet of inference nodes, or a multi-tenant model serving platform, you’ve probably noticed something: the network telemetry tools that served you well in a traditional data center feel slightly out of place here. Not useless. Just not quite designed for this.

The traffic patterns are different. The failure modes are different. The things you need to catch early are different. And if you’re running NetFlow or sFlow collection – which you should be – understanding where that data genuinely helps versus where you’re looking at the wrong instrument is the difference between a useful monitoring stack and a false sense of coverage.

Why AI Traffic Is Different

Most of the networking intuition you’ve built over a career was forged on north-south traffic – clients reaching services, users reaching the internet, workloads reaching storage. Even in modern microservices environments with heavy east-west traffic, flows are relatively short-lived, heterogeneous in size, and largely TCP-based with normal congestion dynamics.

AI training breaks most of those assumptions simultaneously.

A distributed training job across a GPU cluster is synchronous in a way that most networked workloads are not. Every GPU in Continue reading

Commit Control is a core safety mechanism in the Noction Intelligent Routing Platform (IRP). It governs how routing changes are applied by enforcing bandwidth-related limits, ensuring that traffic shifts toward providers remain controlled and predictable. These limits are essential for protecting networks from sudden overloads and unintended traffic spikes.Historically, Commit Control has relied on configured bandwidth assumptions. While this works well under stable conditions, real networks are rarely static. Physical interfaces may fail, bonded links can lose members, and available capacity may be reduced without immediate operational awareness. In such cases, Commit Control may continue to operate correctly from a configuration perspective, while the underlying physical capacity has already changed.

With IRP v4.3, we introduce Interface Monitoring, a feature that allows Commit Control to continuously align its decisions with the actual state and capacity of provider-facing interfaces.

Why Physical Interface Awareness Matters for Commit Control

Commit Control is designed to answer a critical question: Is it safe to commit a routing change that increases traffic toward this provider?
The answer depends not only on policy and configuration, but also on whether the provider connection can physically handle that traffic.

Physical failures are an unavoidable part of Continue reading