Summary

  • Route aggregation reduces several more-specific routes to one less-specific announcement. Under modern RFC 9774 practice, AS_SET is removed; ATOMIC_AGGREGATE warns that the displayed AS_PATH may omit actual traversal, while AGGREGATOR identifies the last speaker that formed the summary.
  • A stable aggregate, a valid origin and an Established session do not prove every covered destination is reachable. A missing contributor can turn the aggregate's required discard route into the correct packet outcome while the public control plane remains unchanged.
  • Leadership should authorize this loss of detail only with a deliberately fixed origin, contributor-specific loop filters, verified discard behavior, pre-compression evidence, RIB/FIB and packet tests, and a rollback that restores the entire aggregation contract.

At 02:13, a backbone creates 203.0.112.0/22 from four customer /24s. The purpose is ordinary: reduce updates, suppress unnecessary specifics and give upstreams one stable route. The aggregate is originated by AS 64505. Its AS_PATH is empty before external advertisement, it carries ATOMIC_AGGREGATE and AGGREGATOR, and a ROA authorizes AS 64505 for the /22.

At 03:07, the session carrying 203.0.114.0/24 is lost during customer maintenance. The other three contributors remain. The platform therefore keeps the /22 active. External collectors show no withdrawal. RPKI origin validation remains Valid. The upstream session is Established, the aggregate is in the FIB and the executive dashboard stays green.

A probe to an address in the missing /24 fails. It reaches AS 64505, matches no reachable more-specific route and hits the null route installed for the aggregate. That discard is not a second failure. It is the mechanism that prevents the packet from following another less-specific route back toward a neighbor and looping. The failure occurred earlier: the contributor disappeared. Aggregation made that event invisible to observers who watched only the summary.

This incident is synthetic. Its mechanics are standards-defined. The route did not lie, and ATOMIC_AGGREGATE did not certify delivery. The announcement said something narrower: this AS was willing to advertise reachability for a covering prefix even though the AS_PATH could no longer enumerate every path from which that statement was formed.

A summary is a new routing assertion

Aggregation is often described as compression, which can make it sound like harmless formatting. BGP does more. It combines several routes for more-specific destinations into a new route for a less-specific destination. The new NLRI has its own path attributes, activation rules, export policy and forwarding consequence.

Under RFC 4271's original aggregation algorithm, the speaker found the longest leading sequence common to all contributing AS_PATHs. Remaining AS numbers could be placed into an unordered AS_SET. If two contributors arrived through 64510 64520 and 64510 64530, the common sequence was 64510; the set could retain evidence that 64520 and 64530 had also participated.

That representation was compact, but it was not precise. An unordered set cannot express traversal order. It can make the origin—the rightmost AS used for route-origin reasoning—ambiguous. It also complicates BGP security systems whose decisions require one determinate origin or a verifiable ordered path.

RFC 6472 recommended not using AS_SET or AS_CONFED_SET in 2011. RFC 9774, published in May 2025, moved the Internet further: it obsoleted RFC 6472, updated the base BGP and confederation specifications, and made the default rule a standards requirement. Unless an operator explicitly configures an exception such as a transition, speakers must not advertise UPDATEs containing those set segments and must treat received routes containing them as withdrawn.

Aggregation did not disappear. The representation of what was lost changed. The modern summary keeps a deliberately controlled sequence and uses an explicit warning that other path information was omitted.

ATOMIC_AGGREGATE is an admission, not a seal

ATOMIC_AGGREGATE is path-attribute type code 6. It is well-known and discretionary, and its value has length zero. There is no list inside it, no hash of contributing routes, no timestamp and no signature. Its meaning comes entirely from the protocol contract.

When an aggregate excludes AS numbers because the AS_SET has been dropped, the advertised route should carry ATOMIC_AGGREGATE. A receiver should preserve it when propagating the route. The receiver must not manufacture more-specific NLRI from that route when advertising onward. Most importantly, the receiver must understand that packets may traverse ASes absent from the displayed AS_PATH.

The attribute therefore communicates an epistemic limit: this path is intentionally incomplete. It does not say which ASes are missing. It does not prove that omission was safe. It does not prove that every contributor existed when the route was formed, and it does not authorize the aggregating AS to announce the prefix.

If any contributing route already carries ATOMIC_AGGREGATE, a newly formed aggregate must inherit it. Loss of provenance cannot be washed away by another layer of summarization. The warning survives even when the operator no longer knows whether the first omission happened one hop or five aggregations earlier.

This is the correct institutional analogy. A thin public statement may be operationally useful, but it cannot acquire authority over the facts it excludes. The shorter AS_PATH is not superior evidence. It is shorter because part of the evidence is gone.

AGGREGATOR names an act, not a chain of custody

AGGREGATOR is type code 7, an optional transitive attribute. The speaker forming an aggregate may add its own AS number and IP address, normally its BGP Identifier. Under RFC 9774's consistent-brief operating model, AGGREGATOR and ATOMIC_AGGREGATE are included together.

That pairing answers two different questions. ATOMIC_AGGREGATE says that the path statement lost detail. AGGREGATOR says which AS and speaker last formed the represented aggregate. Neither reconstructs the contributors. Neither records the policy version, engineer, controller decision, customer state or earlier aggregation acts.

RFC 4271 makes the boundary explicit. AGGREGATOR attributes found on contributing routes are not simply copied into the new aggregate. The speaker forming the new route may attach its own identity. The field is therefore an attribution for the present aggregation act, not an append-only custody ledger.

Nor is it authentication. A transitive BGP attribute is not a cryptographic signature. A route collector can display an AGGREGATOR value, but it cannot infer from that value alone that the speaker controlled the address block, followed the intended policy or still retains the evidence behind the summary.

Four-octet ASNs add compatibility rather than greater authority. Between capable speakers, AGGREGATOR carries a four-octet AS number and is eight octets long. Across an old-speaker boundary, AS_TRANS and AS4_AGGREGATOR can preserve a non-mappable four-octet identity. Those reconstruction rules prevent number truncation; they do not authenticate the actor.

Malformed warning and attribution fields are handled with limited blast radius. RFC 7606 directs attribute discard for malformed ATOMIC_AGGREGATE or AGGREGATOR instead of resetting the BGP session. That is good availability engineering. It also means a session can remain healthy while the route loses the very metadata that warned of compression or named the aggregating speaker. Error telemetry must survive independently of the accepted route.

The origin must not depend on which contributor woke up first

Dropping AS_SET produces what implementations commonly call brief aggregation. The speaker retains the longest common leading sequence and discards the non-common remainder. That looks deterministic until the set of contributing routes changes.

Suppose one contributor has path 64520, another 64530, and the aggregating AS is 64505. With both present, the paths share no leading AS, so the aggregate may present an empty AS_PATH before 64505 advertises it externally. With only one contributor present, the unmodified brief result can end in that contributor's AS. The apparent origin can therefore change according to route availability rather than an explicit authority decision.

RFC 9774 calls this problem out because RPKI Route Origin Validation needs a stable origin relationship. A resource holder would otherwise need authorizations for every origin the changing contributor set might produce. The remedy is consistent brief aggregation: configure the path to truncate after the rightmost instance of a deliberately selected origin AS. The aggregating AS itself may be that origin. The covering prefix then needs the corresponding ROA.

This is not merely a security convenience. It separates a policy decision from an accident of timing. The operator names the AS responsible for originating the aggregate rather than allowing the last surviving contributor to inherit that role implicitly.

The distinction between BGP's ORIGIN attribute and the origin AS also matters. ORIGIN records whether routing information entered BGP through IGP, EGP or another mechanism; the origin AS is inferred from the right side of AS_PATH. Aggregate ORIGIN takes the least favorable contributor value under RFC 4271. A dashboard that labels both fields “origin” can claim consistency while comparing different concepts.

A Valid RPKI result remains narrow. A ROA says that the address-space holder authorized one AS to originate specified prefixes. It does not validate the omitted contributor sequence, AGGREGATOR address, aggregate activation rule, NEXT_HOP, null route, FIB installation or packet delivery.

Removing the set moves loop prevention elsewhere

AS_SET was awkward, but it carried AS numbers that could trigger BGP's ordinary loop detection. If a contributing AS received the aggregate and found itself in the set, it would reject the path. When the set is prohibited, that automatic evidence disappears.

RFC 9774 replaces hope with a clear export rule. The aggregate should not be announced to its contributing ASes. Each contributor should instead receive the other applicable more-specific routes, excluding any route learned from that contributor. The policy is directional and contributor-specific; a single generic outbound filter may not express it correctly.

This shifts the control from a path object into configuration. The operator must know the contributor set, which peer supplied each specific, which aggregate covers it and which direction may receive the summary. If that mapping is stale, the AS_PATH no longer contains enough information to repair the mistake automatically.

The data plane needs a second guard. RFC 4632 requires a router generating an aggregate to discard packets that match the less-specific route but no reachable more-specific route. The ordinary implementation is a null or discard route for the aggregate. Without it, the packet can follow a less-specific default or peer-learned route back out, return through the aggregate and loop.

The null route is therefore evidence of safety but not of service. A packet discarded there demonstrates that the loop guard worked and that the covered destination was not reachable through a known contributor. If monitoring counts only aggregate installation, it turns correct containment into a false claim of availability.

The evidence ledger must exist before compression

Public collectors can prove that an aggregate was visible, which origin AS appeared and whether ATOMIC_AGGREGATE or AGGREGATOR survived to that observation point. They cannot show the contributor routes that were absent, rejected or suppressed before the summary was formed. They cannot recover AS numbers that ATOMIC_AGGREGATE explicitly says may be missing.

The operator needs a pre-compression ledger. For each aggregate, record the configured prefix, required and optional contributors, activation condition, exact accepted contributor paths, computed common sequence, selected consistent origin, ROA state, aggregation policy version and the speaker that performed the act. Preserve pre-policy Adj-RIB-In as well as the accepted routes; otherwise a rejected contributor becomes indistinguishable from a silent peer.

Then record the generated route at every stage: Loc-RIB, pre-policy and post-policy Adj-RIB-Out, ATOMIC_AGGREGATE presence, AGGREGATOR or AS4_AGGREGATOR values, NEXT_HOP, ORIGIN, communities and more-specific suppression. Keep malformed-attribute events even when RFC 7606 discards only the attribute and continues the session.

Forwarding evidence completes the chain. Verify the discard route in the RIB and hardware FIB. Test one address in every active contributor and one address in an intentionally uncovered part of the aggregate. The first probes prove delivery; the last proves that the network contains a gap instead of looping through it. Label those outcomes differently.

Four states deserve separate alarms: a contributor present; a contributor absent while the aggregate is legitimately present; the aggregate absent; and the aggregate present without its discard route. The fourth is often the most dangerous because the control plane looks complete while the loop invariant is missing.

Change the aggregate as one indivisible contract

An aggregation change is not just one configuration line. It changes the public NLRI, contributor eligibility, origin identity, path-loss warning, aggregator attribution, peer exports, suppression policy, ROA coverage and data-plane discard.

Begin by computing the desired state from a frozen contributor inventory. Decide whether one active contributor is sufficient or whether a quorum is required by the service promise. Choose the origin AS deliberately and validate the exact prefix and maxLength relationship in the ROA. Generate peer-specific export expectations before enabling the summary.

Use a canary with both positive and negative packet tests. Confirm that a covered active /24 forwards, then withdraw a designated test contributor and confirm that an address in it reaches the local discard rather than a neighbor. Inspect the exact external AS_PATH, ATOMIC_AGGREGATE, AGGREGATOR, origin-validation state and more-specific advertisements. Repeat across old- and new-speaker boundaries if AS4_AGGREGATOR is involved.

Rollback must restore the full contract: contributor import, suppression, aggregate generation, origin selection, ROA, outbound filters and discard route. Restoring the aggregate command while leaving a changed ROA or contributor filter is not rollback. Neither is withdrawing the summary without restoring the more-specific routes on which reachability now depends.

The authorization record should name who can accept controlled discard, who can pause on an origin change and who can withdraw the aggregate when evidence is incomplete. Otherwise the summary becomes institutionally sticky: everybody can see it, but nobody is clearly empowered to remove it.