Summary

  • RFC 7311 defines AIGP as an optional, non-transitive BGP attribute for several contiguous ASes under one administration, allowing an IGP-like cost to accumulate across their boundaries.
  • The calculation is meaningful only when every contributing IGP, static route and inter-AS increment uses a comparable unit and the recursive path has no unknown metric gap.
  • Safe deployment governs more than the number: session and origination boundaries, candidate visibility, route-reflector behavior, update thresholds, path selection, leakage detection and observed forwarding all need independent proof.

Imagine an operator that acquired three regional networks but kept their autonomous systems. The northern AS uses IS-IS cost to approximate latency. The central AS inherited OSPF values chosen years ago to represent capacity tiers. The southern AS uses static interconnect costs chosen mainly to keep traffic away from expensive circuits.

Management asks for one outcome: choose the shortest internal path across the combined footprint. The routing team enables an accumulated metric. Every router now displays an orderly 64-bit total. The numbers rise as the route crosses each domain. The network looks mathematically unified.

It is not. One segment added milliseconds, another added a bandwidth class and a third added a commercial preference. The sum is exact, reproducible and meaningless. The protocol has performed arithmetic; the organization has not defined a unit.

This is the governance problem inside the Accumulated IGP Metric attribute, or AIGP. RFC 7311 was written for a legitimate operational case. BGP ordinarily connects independent administrations and does not choose an end-to-end path by summing one global metric. Some operators, however, run multiple contiguous BGP ASes inside one administrative domain and want them to behave more like one IGP metric space.

AIGP provides a way to carry and accumulate that internal cost. It is an optional, non-transitive BGP path attribute with type code 26. RFC 7311 defines TLV type 1, whose eight-octet unsigned value holds the accumulated metric. The width allows many ordinary IGP values to be added without quickly exhausting the field.

Field width does not create semantic width. The TLV says “this is the accumulated value.” It does not say whether a unit means delay, inverse bandwidth, an operator weight, a maintenance penalty or some combination. A 64-bit container can preserve a false comparison more accurately than a smaller one.

The true constitutional object is the AIGP administrative domain: the set of ASes under a common administration that agree to treat their costs as parts of one calculation. It is not simply a list of ASNs. It is a trust domain in which the parties accept a common unit, common accumulation rules and common boundary discipline.

That distinction separates AIGP from MED. MED is advice about an entry point, usually across an external adjacency, and standard behavior does not accumulate it along every link. RFC 7311 notes that using MED as a substitute cannot create IGP-like shortest-path routing, in part because AS_PATH and other factors intervene and because MED does not prove a complete sum.

AIGP is also not a universal Internet metric. BGP avoided one partly because unrelated administrations would have to coordinate scale, meaning and incentives. One provider could call its congested path “1” and invite traffic; another could measure microseconds; a third could embed price. An additive global number would become a contest over who gets to define reality.

RFC 7311 therefore builds a boundary. The attribute is non-transitive. AIGP_SESSION controls its use per session. The default should be enabled on IBGP and on EBGP sessions between members of the same BGP Confederation. On other EBGP sessions, the default must be disabled.

If AIGP arrives on a disabled session, it is treated like an unrecognized non-transitive attribute: quietly ignored and not passed onward. The event should be logged with rate limiting. That log is not incidental noise. It is evidence that a metric tried to cross a boundary where its meaning was not trusted.

Origination is separately controlled. AIGP_ORIGINATE must default to disabled. A speaker must not attach AIGP to a route whose path leads outside its AIGP administrative domain. RFC 7311 restricts the route classes on which the attribute may originate and requires the originator to make itself the BGP next hop.

These are minimum safeguards, not automatic sovereignty. A non-transitive bit does not stop two external peers from enabling the feature incorrectly on both ends. RFC 7311 warns that such a configuration can carry AIGP from one provider to another and lead to unsound selection. Boundary safety depends on session matrices, policy and verification as well as encoding.

The arithmetic begins when a speaker changes the next hop. If it forwards an AIGP route without changing the BGP next hop, it must not modify the value. If it changes the next hop to itself, it must add the distance to the former next hop, and the increment must be non-zero.

For an IGP-learned next hop, that addition can come from the IGP distance. For a direct EBGP link on which no IGP runs, the operator still needs to assign a non-zero value that is comparable with the rest of the metric. A static route brings the same problem. “No IGP here” does not mean “zero cost”; it means someone must define the bridge between measurement systems.

Recursive resolution makes the proof chain longer. A BGP next hop may itself resolve through another BGP route, which may resolve again. RFC 7311 walks that chain, accumulating AIGP values found along it and finally adding the non-recursive IGP or static distance.

The gap rule is crucial. If recursion reaches a BGP-learned route with no AIGP attribute, the outgoing route must lose its AIGP value. The protocol refuses to present an accumulated total when an unknown segment lies in the middle. It would rather remove the claim than publish a sum with a missing term.

That is a strong evidence principle. A gap cannot be treated as zero merely because zero is convenient. Yet operators can still create semantic gaps while preserving syntactic continuity. If every hop carries AIGP but one domain changed what “cost” means, the chain remains protocol-complete and operationally incoherent.

The metric registry must therefore record more than values. For every IGP domain and inter-AS link, it should name the metric source, unit or policy meaning, scale, reference point, owner, last calibration and approved transformation. If one domain uses delay and another uses a capacity weight, the registry should block composition or define a reviewed conversion rather than let arithmetic hide the mismatch.

Even identical IGP protocols do not prove identical meaning. Two OSPF domains can use very different reference bandwidths. Two IS-IS domains can assign costs by separate automation systems. One may cost out maintenance links near the maximum; another may reserve the same range for failure only. Protocol sameness is not unit sameness.

Overflow receives explicit treatment. The AIGP value is capped at the maximum unsigned 64-bit value and must not wrap. A first TLV already at the maximum should be considered malformed because it cannot be increased usefully. Wraparound would be catastrophic: the most expensive path could become a tiny number and appear best.

Malformed handling creates its own visibility boundary. An AIGP attribute with the transitive bit set is malformed and discarded as an attribute rather than trusted. Unknown TLVs and repeated TLVs have specified preservation rules, while only the first AIGP TLV drives the procedures. Operators need decoder output that distinguishes “attribute absent,” “ignored by session policy,” “discarded as malformed” and “present but not selected.”

Path selection is more consequential than the phrase “another metric” suggests. AIGP does not simply appear late in the ordinary tie-break list. When the Decision Process reaches tie-breaking and at least one candidate carries an AIGP TLV, RFC 7311 first removes candidates without one. It then computes each remaining route's value plus the local IGP distance to that route's next hop and keeps the lowest total.

Presence therefore defines a class before the numbers compete. A route with an enormous AIGP value can beat a route with no AIGP at all, because the latter is excluded from consideration. RFC 7311 compares this to an IGP preferring an intra-area route over an inter-area or external route even when the numeric distance is larger.

This behavior needs an explicit migration plan. During partial rollout, one path may carry AIGP while an otherwise attractive alternate does not. Enabling a session can change the candidate class for many prefixes without any change in physical topology. The expected route-set diff must include attribute presence, not merely lower-versus-higher totals.

AIGP also does not override everything. If one route has a uniquely highest degree of preference before tie-breaking, it can be installed without AIGP being considered. Invalid paths, AS loops and unresolvable next hops can be removed earlier. “Lowest AIGP wins” is therefore incomplete; it wins within the candidates and decision stage where RFC 7311 applies.

Candidate visibility remains a dependency. A speaker cannot choose the lowest accumulated path if it receives only one path. RFC 7311 recommends best-external and ADD-PATH procedures so speakers can see useful alternatives. The recommendation is architectural: the quality of a metric cannot repair missing choices.

Route reflection introduces the familiar perspective problem in a new form. A reflector that does not pass all paths may select from its own distance to the next hops and hide a path that would have the lowest total from a client. If the reflector supports AIGP while some clients do not, route choices may no longer express one consistent policy.

The validation must therefore capture candidate sets at the reflector and client, ADD-PATH direction, attribute retention, the reflector's computed total, the client's local distance and the final best-path reason. Seeing the same TLV at both devices does not prove they computed the same complete value.

Metric change couples the IGP to BGP. RFC 7311 warns that frequent changes in IGP distance toward a prefix can generate equally frequent BGP updates. This is the inverse of the desired abstraction: a local link-cost oscillation can become cross-AS control-plane churn.

Implementations may suppress an update when the new distance differs from the advertised value by less than a configurable threshold. The threshold creates a deliberate dead band. It reduces churn but permits the advertised accumulated value to lag the current metric.

There is no universal right threshold. A network using coarse capacity classes may tolerate a difference of ten; a latency-sensitive topology may not. The correct control records maximum acceptable error, update rate, convergence cost and the applications that depend on the path. Threshold changes are policy changes, not mere performance tuning.

Maintenance shows the mechanism's power. IGP operators often “cost out” a link by assigning a very high metric before taking it down. AIGP can carry that increased cost across BGP boundaries, causing routes that include the link to lose to alternatives. One local maintenance action becomes a multi-AS steering signal.

That makes change authority important. Who may cost out a link? Which prefixes inherit the effect? How quickly does the new AIGP propagate? Does attribute presence cause an unexpected path without AIGP to be excluded even when it is the intended escape? A maintenance runbook needs predicted totals and route-set diffs, not just a link command.

Security follows the same path as operations. RFC 7311 says erroneous or malicious introduction of AIGP can select undesired paths. An attacker or mistaken policy does not need to forge reachability; changing the ranking within a trusted administrative domain may be enough to divert traffic toward observation, congestion or a fragile link.

Boundary monitoring should alert on AIGP received on disabled external sessions, AIGP-originated routes outside approved prefix classes, unknown originators, unexpected next-hop rewrites, non-zero increments outside the unit registry, gaps that cause attribute disappearance and values near the maximum. Rate-limited protocol logs should feed a durable security record rather than vanish inside device buffers.

Modern implementations widen the design space. Cisco's current IOS XR documentation describes AIGP in multi-AS environments and exposes total AIGP values, with support varying by release and platform. Junos 25.2 documents IGP-metric-based AIGP path selection for Flex-Algo topologies and policy expressions for actual IGP cost.

Those capabilities make topology identity part of the unit. A low-latency Flex-Algo cost and a default-topology cost may both be integers but represent different constrained graphs. If a route crosses domains using different algorithm identities or colors, the total can again be syntactically continuous and semantically broken.

Product commands also do not replace RFC scope. A vendor may say AIGP enables “optimal” selection. The honest meaning is lowest approved accumulated metric among eligible visible candidates under that implementation. It is not proof of lowest latency, least congestion, cheapest transit or best application outcome.

The first production artefact should be an AIGP domain charter. It lists the ASes, IGP domains, address families and sessions included; the tunnels that satisfy the forwarding assumption; and every external boundary at which AIGP must be disabled and stripped or ignored.

The second is a metric semantics registry. It defines the meaning and scale of each link cost, inter-AS increment, redistributed static value and topology algorithm. It names the authority permitted to change each source and the validation required before two sources can be added.

The third is an accumulation trace for representative prefixes. Start at origin, record the initial value, every next-hop change and increment, recursive chain, final local IGP distance and computed total. Capture candidate paths with and without AIGP and the precise elimination step. Then follow the chosen next hop into the FIB and measured packet path.

The fourth is a boundary matrix. For every BGP session, record whether AIGP_SESSION is enabled, why the peer belongs to the domain, which directions carry the attribute and what alert fires on an unexpected reception. Test both-sided misconfiguration deliberately in an isolated lab because the non-transitive flag cannot protect a boundary both operators chose to dissolve.

Rollout should begin with a small address family and prefixes that have observable alternatives. Test mixed-support reflectors and clients, absent attributes, recursive gaps, cost changes below and above threshold, maximum values, cost-out maintenance, lost candidates and an attempted external leak. Compare intended and actual route-set diffs at every stage.

Rollback has two dimensions. Disabling AIGP can restore ordinary BGP selection, but it also changes the candidate class by making the attribute absent. Withdrawing origination, disabling sessions and clearing stale received state must occur in an order that avoids inconsistent islands. The reverse path and FIB need fresh proof after the rollback.

Authority should be divided. Network architecture defines the administrative-domain boundary. IGP owners define local metrics. Interconnect owners assign the cross-AS increments. Routing policy owners govern origination and sessions. Security monitors leakage. Service owners validate the resulting traffic. No single team should create the unit, publish the number and certify its effect.

Heng Lu's minimum initial specification supports this narrow settlement. RFC 7311 supplies a mechanism for voluntarily coordinated ASes under one administration. It does not require unrelated networks to adopt a common metric or surrender local policy. The shared specification is small; the future decisions remain local and reversible.

Running-code primacy sets the evidence order. The configured metric is a declaration. The AIGP TLV is a carried claim. The Decision Process log is an explanation. The FIB and packet path show what the network did. If the observed route contradicts the intended unit, the number does not gain authority from being standards-compliant.

Practical data sovereignty means controlling both the metric and its consequence. An operator that owns the routers but cannot trace which automation changed a link cost, which speaker added an increment or why a route lost does not control the accumulated decision. It merely hosts it.

AIGP can make a fragmented internal network behave as one metric space. That is useful precisely because the public Internet should not be one. The deployment succeeds when the boundary is narrow, the unit is coherent, missing terms remain visible and packets confirm the arithmetic.

The decisive question is not whether all routers can add. It is whether the organization has earned the right to call the sum a distance.

Sources