Summary

  • RFC 7911 lets a BGP speaker advertise multiple paths for one prefix by pairing each NLRI with a four-octet Path Identifier after matching send/receive capability negotiation for that address family.
  • The Path Identifier is opaque and local, not a preference signal. More visibility leaves the receiver's best-path decision intact while adding memory, restart and observability costs.

One path was both an answer and a limit

Base BGP presents a neighbor with at most one advertised route for a given NLRI. When the speaker advertises another route for the same prefix, the new route implicitly replaces the old one. That behavior keeps the wire representation simple, but it also binds visibility to the sender's selection. A receiver cannot act on an alternate that was never exported.

RFC 7911 separates those concerns. In an UPDATE using ADD-PATH, a four-octet Path Identifier precedes the NLRI. The pair of prefix and identifier names one advertised path, so another path for the same prefix can coexist instead of replacing it. A later advertisement with the same pair replaces that particular path, and a withdrawal removes that pair. A withdrawal for an identifier the receiver never saw should be ignored silently.

The new identifier is deliberately modest. It is assigned by the advertising speaker and has meaning only in that speaker's relationship with that neighbor. If the route is advertised onward, the next speaker must assign its own identifier. The receiver must not infer that a larger number is better, older, safer or globally stable. Path ID is identity, not judgement.

That boundary preserves decision authority. The sender decides which alternatives to expose within policy. The receiver still runs its own selection process over the routes it accepts. RFC 7911 says the advertising speaker should include its best route when it sends multiple paths, except when that route was learned from the same neighbor. Even then, “best” remains the sender's local result rather than an instruction to the receiver.

Permission is asymmetric and family-specific

ADD-PATH is capability code 69. Its capability value carries one or more tuples containing an Address Family Identifier, a Subsequent Address Family Identifier and a Send/Receive value. Value 1 means receive, 2 means send and 3 means both. Other values are treated as not understood.

A speaker may send multiple paths for a family only when two conditions meet: it advertised send capability for that AFI/SAFI, and it received the neighbor's receive capability for the same AFI/SAFI. The direction can differ on the opposite side. Authorization is therefore not a single session-wide switch and not an inference from software support. It is an explicit intersection of peer, direction and address family.

This design identifies both power and beneficiary. The sender gains power to expose more alternatives. The receiver benefits from additional routing information it may use for convergence, route-reflector diversity or other locally chosen purposes. But the receiver also bears part of the cost: every additional accepted path consumes state and processing, and a peer that sends many paths for many prefixes can create resource pressure.

The standard does not prescribe a universal path count or memory budget. It also does not prove that a named implementation deploys ADD-PATH safely. Those remain operational questions. A capability exchange proves permission to use the extended encoding; it does not prove that route policy, forwarding installation or failure recovery is correct.

Local identity complicates restart evidence

Path Identifiers do not have to survive a control-plane restart. That is consistent with their local purpose, but it means an identifier observed before restart cannot automatically be treated as the same path afterward. Graceful Restart makes the distinction material because forwarding state may be retained while control-plane advertisements and identifiers are rebuilt.

Telemetry must preserve the capability context as well. The same UPDATE bytes are decoded differently depending on whether ADD-PATH was negotiated for that address family. A passive analyzer that misses the OPEN exchange may mistake a Path Identifier for NLRI data and produce a confident but wrong interpretation. Packet evidence without negotiation evidence is incomplete.

Routing and forwarding also need to remain consistent. Retaining several control-plane alternatives is useful only if withdrawal, replacement and forwarding behavior agree about which path is active and which alternatives remain eligible. The extension exposes more state; it does not reconcile inconsistent state on an operator's behalf.

Evidence and limits

RFC 7911 defines the identifier, NLRI encoding, capability tuples, direction rules, replacement and withdrawal behavior, best-route inclusion guidance, restart caveat and resource warning. RFC 4271 supplies the base one-path advertisement model. RFC 5492 supplies capability negotiation, IANA records capability code 69, and RFC 4272 describes underlying BGP security concerns. The framing of visibility, authority and cost is analysis.

The sources do not identify deployment by a particular operator, specify how many paths every peer should receive or establish a universal safe resource threshold. They do not make Path IDs persistent or globally meaningful. They also do not prove that receiving more alternatives improves outcomes in every topology.

Sources