Summary

  • RFC 10005 defines transitive and non-transitive BGP Link Bandwidth Extended Communities carrying a 32-bit floating-point value in bytes per second. It leaves value derivation, weighted load balancing and multipath arithmetic substantially to local policy.
  • The number may describe one interface, an aggregate path, a server pool or a proportional weight. Operational proof therefore runs from the received UPDATE through policy, multipath eligibility and programmed FIB weights to observed traffic—not from the attribute alone.

The incident begins with a number that looks more objective than it is. An upstream BGP speaker advertises 70 units of Link Bandwidth for a route. Another advertises 30. The receiver forms a multipath set and uses those declarations as a 30/70 weighting ratio. Nothing in the UPDATE tells the receiver that its own connection to the second upstream can carry only 50 units. More traffic is sent toward the narrower local aperture and a queue grows exactly where the remote claim could not see.

This is not a hypothetical invented to criticize the standard. The current BGP Link Bandwidth use-case draft uses this topology to explain why a receiver may need the remote value, the local interface value or a function of both, such as the minimum. The draft also says the displayed units can be proportional weights rather than literal link rates. A later example uses server count as the value behind an anycast service.

The field is therefore not self-describing. It contains a number and a narrow protocol identity. It does not contain a measurement method, time window, confidence interval, utilization sample, bottleneck map, service-health result or promise of delivered throughput. The missing semantics belong to the operators that originate, transform and consume it.

What RFC 10005 actually standardizes

RFC 10005, published in June 2026 as a Proposed Standard, defines two Link Bandwidth Extended Communities. The transitive form uses Type 0x00; the non-transitive form uses Type 0x40. Both use SubType 0x04.

The two-octet Global Administrator should contain the attaching router's ASN, but may contain any two-octet value. If the ASN does not fit, the RFC says to use AS_TRANS; the full four-octet ASN is not supported in this encoding. More importantly, the RFC says this subfield does not affect the community's use or semantics. It is not authentication, proof of resource control or evidence that the party named by the value measured anything.

The four-octet Local Administrator is an IEEE-754 32-bit floating-point value expressed in bytes—not bits—per second. That precise wire rule prevents two speakers from decoding the same octets differently. It does not resolve what an operator put into the field. The RFC explicitly leaves determination or computation of bandwidth out of scope.

That boundary is legitimate. Interoperability needs a common encoding, both transitivity forms, predictable handling and clear error behaviour. It does not require one global theory of capacity. A data-centre operator may use server capacity, a service provider may cumulate downstream paths, and another receiver may use only local interface speeds. Trouble begins when the common encoding is mistaken for common semantics.

The value can change at more than one authority boundary

The originator is not the only speaker with control. RFC 10005 permits a community to be attached or updated during Adj-RIB-In processing and again on an Adj-RIB-Out entry. A route received with one value can therefore leave a policy boundary with another, without any protocol error.

Next-hop handling creates a second decision point. If a speaker changes the next hop when it re-advertises the route, its default may be to remove the community, keep it unchanged or regenerate it. Implementations should expose that default and allow per-session control of the alternatives. If the next hop remains unchanged—as in ordinary route reflection—the speaker should not change the value.

These rules identify separate authorities. The first sender chooses a declaration. An import policy can reinterpret it. A next-hop changer can decide whether the old number still describes the new path and can calculate a replacement. An export policy can expose or suppress it. The receiver decides whether qualified multipaths will use the value as a weight. An audit that records only the last BGP table erases most of that chain.

Arithmetic makes the provenance problem harder. In a multipath environment, a speaker may calculate a re-advertised value from constituent Local-RIB paths, but RFC 10005 deliberately leaves the arithmetic out of scope. The use-case draft describes optional cumulation and allows it to sum remote values, discovered local values or a locally selected contributing value. The same underlying paths can therefore yield different advertised totals under different valid configurations.

Zero is a message, not a universal drain command

An operator may originate zero, and RFC 10005 gives maintenance as an example: set the value to zero so the path should not attract traffic. But the receiver controls the consequence. Where some paths are zero and others are not, an implementation might exclude zero-valued paths or fall back to equal load balancing. Where all values are zero, local policy again decides. Zero is valid and must not be treated as malformed.

The distinction is operationally sharp. A change ticket that says “advertise zero to drain” documents sender intent, not receiver outcome. Proof requires the remote speaker's effective route, the receiver's zero policy, its resulting multipath set, the programmed forwarding weights and traffic counters. Without that return path, a maintenance signal can leave traffic flowing or can redistribute it in a way the sender did not expect.

Error rules are cautious but still configurable. When multiple Link Bandwidth communities exist, the default is to use the lowest value, including zero and regardless of transitivity; configuration may choose otherwise. Negative values should not be originated and are ignored when received. If any candidate path lacks a valid community, equal load balancing should be used unless local configuration overrides it.

The value also should not participate in BGP best-path selection. It can shape traffic among paths that already qualify for multipath; it is not a general instruction to make the largest number the best route. This separation must be visible in evidence. Seeing a community on a route does not prove the path entered the multipath set.

Transitivity is both reach and disclosure

The two forms serve different propagation needs. During migration, a route may carry one transitive and one non-transitive community, and their values should match. The receiver must understand both forms and must not flap or mark a route malformed merely because the type does not match an assumption about an internal or external session.

Mixed deployments remain dangerous. Older implementations may understand only one form. A speaker that receives both and updates only one can send inconsistent values onward; different downstream boxes may then calculate different weights from what appears to be the same route. RFC 10005 suggests filtering the unsupported form at an older speaker, or stripping it on receipt when the sender's limitation is known. Upgrading only a route reflector is explicitly not the solution.

Transitivity also changes who can learn capacity information. The RFC warns that bandwidth and capacity may be sensitive and recommends filtering the community when advertising toward an untrusted network or beyond an administrative domain. A transitive attribute is technically capable of travelling farther; that is not authorization to disclose it farther.

This is an important governance boundary. The operator that creates a capacity-derived value decides not only a traffic input but also a disclosure. Export policy should identify the approved administrative perimeter, recipient and purpose. A later assertion that “BGP propagated it” does not transfer that decision to the protocol.

Vendor knobs show why the RFC is not an operating state

Current vendor documentation exposes the local choices. Juniper's BGP load-balancing guide says the configured bandwidth is not traffic on the link and that a value need not match the actual interface because ratios drive distribution. Its broader guide documents automatic sensing, transitivity choices and implementation-specific forwarding constraints.

Cisco's IOS material describes DMZ Link Bandwidth and weighted traffic sharing, while its ASR 9000 guide exposes explicit policy values as well as interface-derived behaviour. The Arista EOS manual documents per-neighbour regeneration and proportional or aggregate options.

These are useful running-code sources because they reveal real control surfaces. They are not proof that releases behave identically, that defaults match RFC 10005, or that a named network has enabled the feature. A command reference is evidence of possibility. Device readback and traffic outcome are evidence of operation.

Build the claim ledger before changing traffic

For each affected prefix, retain the route before and after policy, including neighbour, address family, next hop, transitivity type, Global Administrator and raw floating-point octets. Record the decoded value and its unit, but also record its source class: configured interface speed, discovered interface speed, remote aggregate, local/remote function, server count, static ratio or another defined input.

Then capture the receiver's decision.

  • Which paths qualified for multipath?
  • What happened to missing, zero, negative or duplicate communities?
  • Was the contributing value remote, local or composite?
  • Which FIB members and weights were programmed in hardware?
  • What traffic, loss, queue, latency and application outcome followed?

Bind each observation to software version, time, change ticket and rollback threshold.

The route advertised 70. That statement is complete only after the ledger adds who produced the number, which path it described, which policy consumed it and what the forwarding plane delivered.