Summary

  • Revision 34 says a metadata-capable peer receiving 0% Site Physical Availability must treat all routes associated with that Site-ID as unavailable for forwarding, with an effect equivalent to withdrawing them individually.
  • The routes can nevertheless remain valid in ordinary BGP. Operators therefore need evidence for the authorized update, the route-to-site mapping, every decision point and actual service traffic—not merely a route-table screenshot.

An edge site loses its last usable server at 09:14. Its egress router sends one BGP UPDATE carrying a Site-ID and a Site Physical Availability value of zero. The receiving ingress router leaves dozens of prefixes in its BGP table, yet stops choosing every route previously associated with that site for metadata-aware forwarding. No burst of individual withdrawals crosses the session. To a routing operator, the paths still exist. To the edge service, the site has vanished.

That split is the most consequential clarification in revision 34 of BGP Extension for 5G Edge Service Metadata. The revision was accepted on 25 September 2026 and its masthead is dated 23 September. It remains an IDR Working Group Internet-Draft in the Datatracker state I-D Exists. The masthead calls it Standards Track, while the current Datatracker field for intended RFC status is blank. There is no shepherd, responsible area director or telechat. A July 2027 milestone aims at working-group last call. None of that is an RFC, an assigned IANA code point, a deployment or an interoperability result.

One compact message reaches a large forwarding set

The draft defines an optional, non-transitive Edge Metadata Path Attribute. A route may carry an association between a service prefix and a 16-bit Site-ID. A separate update can then advertise dynamic site properties without repeating them on every route. In the standalone form, the NLRI is the egress router's loopback, the association indicator RouteFlag-I is zero, and the update applies to the routes already mapped to that Site-ID. When RouteFlag-I is one, the message establishes an association and the percentage value is ignored.

The zero case now has unusually direct language. A speaker supporting the mechanism must regard every associated route as unavailable for forwarding. The draft describes the result as equivalent to withdrawing each route, but without sending a withdrawal for each one. A peer that does not support Edge Metadata still requires normal BGP withdrawals if it is to lose those paths.

“Equivalent” therefore describes a forwarding effect inside the metadata mechanism; it does not collapse the ordinary BGP and service-selection states into one fact. Elsewhere, the draft allows a route rejected for metadata-aware service selection to remain a valid ordinary BGP route. The same prefix can be present in the Adj-RIB-In and local RIB while being ineligible for one class of edge traffic. That is useful: it avoids route churn and separates service health from reachability. It also means a green BGP session and present prefix are weak evidence of service availability.

Zero depends on history

The standalone update contains no list of affected service prefixes. Its fan-out depends on the receiver's prior route-to-Site-ID associations. If one ingress router maps 42 routes to Site-ID 711 and another maps 41 because an earlier association update was lost, both can correctly parse the same zero and still disable different populations.

The minimum useful audit record is consequently not “received Site-ID 711 = 0.” It is a versioned mapping generation: which route keys were associated, when the association became effective, which speaker originated it and which decision points acknowledged it. A count and digest of the resolved target set would let operators compare the intended population with the applied one without exposing every internal choice in the protocol.

Those receipts are editorial operating recommendations, not requirements in revision 34. The draft specifies protocol behaviour, not a fleet-wide acknowledgement system. That boundary should stay explicit. A future implementation can use local telemetry, controller state or signed logs; a common standard need not dictate one observability product. It does need enough interoperable meaning for independent systems to agree on what zero was supposed to affect.

Origin authorization prevents a remote kill switch

The draft also restricts who may send the standalone availability update. A receiver accepts it from the corresponding egress router, or from an authorized route reflector whose Originator-ID identifies that egress router. This condition matters because a forged value of zero can make all associated routes unavailable and create denial of service.

The authorization check is a separate receipt from BGP session validity. A route reflector may be a legitimate neighbour while carrying an unexpected Originator-ID. An egress loopback may be reachable while the session belongs to a different role. Operators need to record the authenticated peer, address family, negotiated Edge Metadata Processing Capability, egress identity, Originator-ID when present, Site-ID, attribute bytes and policy result.

Capability itself is bilateral per AFI/SAFI. The attribute is optional and non-transitive, and the draft provides scoping tools including NO_ADVERTISE, an AS-Scope sub-TLV and normal route filtering. Unknown or unsupported sub-TLVs are ignored. Absence of a value must never be interpreted as zero. These rules limit accidental propagation, but they do not prove that every intended ingress router negotiated support or that an incapable peer received the ordinary withdrawals it still needs.

Availability is measured; application is decided

Site Physical Availability is a percentage between zero and 100. Out-of-range values are ignored. The draft separates the measurement interval from the advertisement interval and recommends a default minimum advertisement interval of 30 seconds unless configured otherwise, with dampening or hysteresis to manage churn. Flow affinity remains implementation-specific: a selected egress may continue serving an established flow until it becomes unreachable.

This creates three clocks. The site measures capacity on one clock; the egress advertises on another; the ingress changes candidate eligibility on a third. Existing flows may follow a fourth lifecycle. At 09:14:00 the site can measure zero, at 09:14:12 advertise it, at 09:14:13 one ingress apply it, and at 09:15:00 a pinned flow still end naturally. Calling the whole minute “the zero event” erases the evidence needed to explain user experience.

The standalone update is also not a next-hop-resolution signal. It modifies service selection for the associated site. Operators should not infer that the egress loopback became unreachable or that BGP convergence occurred. The proof ladder is ordered: source measurement; authorized origin; mapping generation; negotiated capability; update receipt; target-set resolution; local policy decision; RIB and FIB state; flow treatment; service outcome. Skipping a rung turns a protocol message into an unverified claim about customers.

A minimum specification can preserve local choice

Heng Lu's minimum-initial-specification doctrine is useful here. The protocol can standardize the smallest cross-domain statement—site identity, availability meaning, origin conditions and scope—while leaving measurement algorithms and local ranking policy to operators. Running-code primacy then asks whether the implementation exposes the execution boundary where that statement becomes a forwarding decision.

For deployment, require a mapping-generation identifier, affected-route count and digest, per-decision-point apply receipt and a flow canary around zero transitions. These are operational controls proposed here, not text imported from the draft. They create evidence without turning a first specification into a centralized controller design.

Revision 34 makes zero more powerful because it removes the need to withdraw every associated route. Leadership should demand correspondingly precise receipts. The route table can be telling the truth, the metadata engine can be telling a different truth, and users can still experience a third. The system is trustworthy only when those truths can be reconciled.

Sources