Summary

  • RFC 10005 standardizes how BGP carries a four-octet floating-point Link Bandwidth value in bytes per second, but leaves the number's determination and the weighting algorithm outside scope.
  • Zero, absence, multiple values, transitivity and next-hop changes all invoke implementation defaults or local policy. A valid community therefore does not prove current available capacity, installed forwarding weights or delivered throughput.
  • Pradosh Mohapatra is one of six named authors. His standards contribution helps define a narrow, useful carrier; operational truth still requires a joined receipt from value origin through FIB state to measured traffic.

A border router receives a path carrying the equivalent of 70 gigabits per second. Its own route to that next hop crosses a 50-gigabit link. Nothing in the four advertised bytes says whether the 70 describes a remote interface, several links summed together, a configured preference or a weight derived from servers. Nothing says when it was observed. If the receiver feeds 70 directly into a traffic ratio, the arithmetic is clean and the premise is wrong.

The April 2026 use-case Internet-Draft behind that example suggests a local limiting function. It is useful precisely because it exposes a semantic gap: the value that arrived and the capacity the receiver can responsibly contribute are not necessarily the same thing. The draft is work in progress, not a normative extension of what RFC 10005 guarantees.

RFC 10005, published on the IETF Standards Track in June 2026, defines the BGP Link Bandwidth Extended Community. Its six authors are Pradosh Mohapatra, Reshma Das, Satya Mohanty, Serge Krier, Rafal Jan Szarecki and Akshay Gattani. The document settles wire format and processing choices after years of implementation practice. It also repeatedly leaves the consequential operational decisions where they belong: in implementations and local policy.

Four bytes carry a number, not its genealogy

The community comes in transitive and non-transitive forms, using type 0x00 or 0x40 and subtype 0x04. A two-octet Global Administrator precedes a four-octet Local Administrator. The latter is an IEEE 754 single-precision floating-point value expressed in bytes per second.

Every part of that description matters. Bytes per second are not bits per second. A display that multiplies by eight has performed a transformation and should retain both the raw field and the display unit. A floating-point value has finite precision and special encodings; RFC 10005 says negative values should not be originated and receivers ignore them. An operator who stores only a rounded dashboard label loses evidence before policy even begins.

The Global Administrator is also weaker identity than its name suggests. It should carry the attaching router's autonomous-system number, but it may contain any two-octet value. A four-octet ASN cannot fit and is represented with AS_TRANS. The field does not alter the community's use or meaning. It is therefore unsafe to treat those two bytes as authoritative proof of which speaker measured, owned or approved the number. Speaker identity belongs in a separate route and session receipt.

Most important, the value has no embedded semantic label. The RFC does not say that it is spare bandwidth, measured throughput or an instantaneous queue-aware capacity. It explicitly leaves computation or determination outside scope. A sender can attach an interface rate, a configured estimate or another locally defined input so long as the encoding and processing rules are followed.

Portability without genealogy is useful, but only if the receiver preserves the missing context elsewhere. Record the source system, method, observation time, validity interval, owner and a short controlled definition such as interface rate, remote aggregate, local bottleneck, server weight or maintenance signal. Otherwise two valid communities can share a unit while describing different objects.

Zero and absence are separate policy events

Zero is valid. A router can advertise zero during maintenance, yet the receiving implementation decides what zero does. In a mix of zero and non-zero paths, it may exclude the zero paths, distribute traffic equally, or apply another configured rule. If all paths carry zero, equal sharing is one possible fallback, not a universal meaning.

Absence is different. If one candidate multipath lacks a valid Link Bandwidth community, RFC 10005 gives equal load-balancing as the default unless configuration says otherwise. An ignored negative value is different again. So is a stale value whose original measurement has expired but whose BGP route remains present.

Collapsing those states into a single unknown cell destroys the decision surface. Zero may be an intentional drain request. Missing may indicate a peer that never supported the community. Invalid may indicate bad origin data. Stale may be a suppressed update. Each has a different owner, risk and recovery path.

Multiple copies create another decision. When a route has more than one Link Bandwidth community and the route participates in weighted load-balancing, the default is to use the lowest value, including zero; configuration may override that choice. During transition between transitive and non-transitive forms, an older router may update one form and leave another stale. A downstream speaker can then compute inappropriate weights from two individually recognizable but temporally inconsistent records.

The monitor should therefore compare type, raw value and age as a set. Alert when both transitivity forms exist with different numbers. Preserve which copy the receiver selected and why. A single rendered bandwidth value cannot explain the discarded alternative later.

A next-hop change can change the evidence chain

Re-advertisement is not passive. When a BGP speaker changes the next hop, RFC 10005 permits it to remove the community, retain it unchanged or regenerate it. The implementation should expose its default and allow a per-session override. When the next hop does not change, the speaker should not alter the community.

Those three actions carry different meanings. Removal says that the downstream path should no longer rely on the upstream declaration. Retention transports the same number across a new adjacency without adding local capacity. Regeneration asserts a new local calculation, even if the resulting bytes happen to be identical.

Yet the community itself does not contain a transformation log. Once regeneration occurs, a later receiver cannot reconstruct the upstream value, limiting function or reason from the final four bytes. Operations needs a separate lineage event: old and new next hop, incoming value, selected action, local inputs, resulting value, policy version and time.

This is an agency boundary. An originator defines one number; an intermediate speaker may transform or preserve it; a receiver chooses how to combine it; a forwarding platform installs a ratio. If the dashboard retains only the last value, four actors can make consequential decisions while no one remains accountable for the outcome.

Weighted intent is not installed forwarding

When every contributing path carries a non-zero valid value, their values or ratios can guide weighted load-balancing. RFC 10005 deliberately leaves the algorithm outside scope and says the bandwidth value should not become an input to BGP best-path selection. The community influences what happens after eligible multipaths have been identified; it does not rewrite the BGP decision process into a capacity oracle.

A receiver might normalize 50 and 100 into a one-to-two ratio. Its software may approximate that ratio to hardware buckets. The forwarding ASIC may have a limited number of members or resilient-hashing constraints. Existing flows may not move immediately. Small flows, elephant flows and hashing collisions can produce a traffic share unlike the configured ratio even when every table is correct.

That creates at least four receipts: the accepted communities, the receiver's computed weights, the programmed FIB or ECMP weights, and the traffic observed per path. A configuration diff proves only the second. A control-plane show command may prove the first two. A hardware acknowledgement proves installation. Only counters and performance observation show what traffic did.

Capacity needs even more care. Interface line rate, reachable bottleneck, current available headroom and delivered throughput are different quantities. Queue depth, loss and latency can deteriorate while a configured interface-rate value remains unchanged. A bandwidth community can be a sound routing input and a poor description of present spare capacity at the same time.

Churn control can hide staleness

RFC 10005 warns that rapidly changing values can affect protocol stability and operations, and recommends mechanisms that limit churn. Damping, thresholds and update intervals can be prudent. They also create a second clock.

The source may change at 10:01, the local policy may suppress the update until 10:05, BGP may propagate it at 10:06 and hardware may apply new weights at 10:07. A dashboard that displays only the latest received number has no way to say whether it is one minute old or six.

Record source observation time separately from advertisement, receipt, policy computation and installation time. Preserve suppressed changes as audit events even when they never become routes. A stability control should not turn stale evidence into apparently current evidence.

The same discipline supports confidentiality. Link-bandwidth values can expose sensitive capacity information. The RFC recommends policy filtering when routes leave an administrative domain or reach an untrusted network. Filtering ownership should be explicit: which boundary removes or rewrites the community, which exception permits transit and which audit confirms that a capacity signal did not escape with a customer route.

Pradosh Mohapatra's contribution defines a boundary

RFC 10005 records Pradosh Mohapatra's affiliation as Google LLC and names five co-authors. The official Datatracker participant record associated with the work listed eleven RFCs at the 1 September 2026 capture, though it displayed the older spelling “Prodosh Mohapatra”. RFC 10005 and the public ipSpace author page use “Pradosh Mohapatra”, which is the canonical identity used here.

The ipSpace biography provides dated context from earlier routing-software roles at Cumulus Networks and Cisco. It does not prove a current role beyond the RFC's own affiliation, control over IETF consensus, authorship of an operator's policy or responsibility for any production result.

Person-centred standards reporting is most useful when it clarifies the intellectual boundary of a contribution. Here that boundary is unusually practical. Mohapatra and his co-authors standardize a carrier and a set of interoperable processing choices. They do not disguise a locally determined value as universally measured capacity. The restraint is part of the engineering.

Build a bandwidth receipt that can survive disagreement

Start with the route, address family, advertising neighbor and administrative domain. Store the exact extended-community bytes, transitivity type, Global Administrator and decoded bytes-per-second value. Keep the display conversion as a separate field.

Join that record to the value's declared semantic, source method, observation time, validity window and owner. At every next-hop change, record remove, retain or regenerate, together with the input and output. For aggregation, preserve constituent paths, zero/missing/invalid handling and the formula rather than only the total.

Then follow the value into execution: receiver policy version, selected multipaths, computed ratios, FIB weights, hardware acknowledgement and per-path traffic. Add bytes, packets, loss, latency, queues and congestion signals. Record alarms, decisions, rollback and stale-value cleanup against the same generation.

This joined receipt does not make the advertised number less valuable. It makes the number honest. The Link Bandwidth community can remain a compact routing input while source evidence answers what it meant, forwarding evidence answers what was installed and traffic evidence answers what capacity was actually available.

Sources