Summary

  • RFC 7911 changes a BGP route's wire identity from prefix alone to prefix plus a locally assigned Path Identifier, allowing several advertisements for the same prefix to coexist across a negotiated direction.
  • The sender still chooses which alternatives to expose, while the receiver keeps import, best-path, multipath and forwarding authority. A Path Identifier is not a rank, stable global identity or proof of diversity.
  • A safe deployment proves the negotiated AFI/SAFI direction, the exact advertised and received sets, bounded state cost, withdrawal behavior and the path that reached the FIB. More visible routes are useful only when they remain intelligible and usable.

Route reflection solves a genuine scaling problem by withholding information. In a full-mesh IBGP design, every speaker can hear candidate paths directly. A route reflector reduces those sessions and ordinarily announces the path it selected as best. A client learns a usable conclusion without receiving every premise that produced it.

That bargain is often reasonable. It becomes dangerous when an omitted premise is the route a client would have preferred, the backup it needs after a failure, or the only route its own import policy would accept. The reflector may be healthy, the BGP session may be established, and the client may still have less choice than the physical and commercial network actually contains.

Classic BGP reinforces that compression. From one neighbor, a later advertisement for the same Network Layer Reachability Information implicitly replaces the earlier advertisement. The prefix is the route key. A speaker cannot retain two simultaneous advertisements for the same prefix from the same session and distinguish their lifecycles using the base protocol alone.

RFC 7911 adds a four-octet Path Identifier before the NLRI. The meaningful wire key becomes the pair: prefix and Path Identifier. If the sender announces the same pair again, the new advertisement replaces the old one. If it withdraws that pair, only that path is removed. A withdrawal carrying an identifier the receiver has never seen should be ignored, not treated as an instruction to erase every route for the prefix.

The additional number looks more meaningful than it is. It is assigned by the advertising speaker for that session. A speaker that re-advertises a route chooses its own identifier; it does not preserve an upstream value as an end-to-end label. The number may change after a restart. A receiver must not read priority, origin, age, quality or provenance from its magnitude.

This makes Path Identifier excellent protocol bookkeeping and poor business metadata. A dashboard that says “path 17 became path 31” may be describing the same attributes under a newly allocated token. An incident system that correlates that token across route reflectors may join unrelated routes. Evidence must compare the route attributes and forwarding relation, not worship a locally scoped integer.

ADD-PATH also negotiates direction rather than declaring a session universally multi-path. Capability code 69 carries one or more tuples of Address Family Identifier, Subsequent Address Family Identifier and send/receive mode. Value 1 means receive, 2 means send and 3 means both. Multiple-path encoding operates in one direction only when the sender advertised send capability and the receiver advertised receive capability for the same AFI/SAFI.

The asymmetry is deliberate. A reflector can send several paths to clients without accepting several paths back. A route server can expose alternatives while preventing clients from turning it into a collector of every inactive candidate. IPv4 unicast can use ADD-PATH while another family on the same TCP session retains classic semantics. “ADD-PATH enabled” is therefore an incomplete operational statement.

Capability is only the transport permission. It does not select the set. RFC 7911 says the advertising speaker should include its best route unless that route was learned from the same neighbor, but it does not require every available path to be sent. Implementations can expose all eligible paths, a fixed N-best set, one best path per neighboring AS, multipath-eligible routes or a policy-defined subset.

That choice controls the value of the feature. Sending two routes that share the same next hop, metro, optical conduit and upstream failure domain may add state without adding resilience. Sending one route per neighboring AS may improve commercial diversity while missing topology diversity inside one AS. Sending all available paths maximizes visibility but can reproduce much of the state and work that route reflection was introduced to suppress.

RFC 7964 makes this tradeoff concrete in the narrower problem of persistent oscillation involving MED. Its “all available paths” set approaches the information consistency of a full mesh. Its Group Best alternative advertises the best route from each neighboring AS under stated topological constraints. The second set is smaller, but it is not a universal cure. A path-selection rule is valid only for the mechanism and topology it was designed to control.

The receiver remains sovereign after the additional paths arrive. It can reject routes under import policy, select one route as best, admit several to a multipath set, or retain alternatives without installing them. RFC 7911 does not rewrite the RFC 4271 Decision Process. It does not turn path visibility into ECMP and does not compel the forwarding plane to carry every candidate.

This separation prevents a common reporting error. “The client received four paths” is not the same as “the client has four independent exits.” Some may fail policy. Some may have unresolved next hops. Several may collapse onto one recursive FIB next hop. Hardware may install fewer paths than the control plane selected. The only credible claim follows the chain from Adj-RIB-In through policy and Loc-RIB to the programmed FIB and an observed forwarding test.

Route-server path hiding shows why visibility can matter. RFC 7947 describes an exchange route server applying different outbound policy for different clients. The route server may select a path that a particular client then rejects, while another path present at the route server would have passed. If only the selected path is advertised, that client sees no route. Its local policy is functioning correctly against an artificially narrow input.

ADD-PATH can expose more of the candidate set, but the trust boundary matters. RFC 7947 warns that bidirectional use at a route server could let inactive, invalid or suboptimal client paths propagate through the server. For that specific environment it recommends a send-only route-server role and receive-only clients. That is not a universal rule for internal route reflectors; it is a careful allocation of authority for a system that does not forward the traffic it helps coordinate.

Inside an AS, the design question is different but related. A reflector may expose different sets to different clients based on topology, capability, role or policy. Such asymmetry may be useful. Edge routers might receive diverse exits, while devices with tight control-plane budgets receive one route. Yet each exception creates a distinct convergence model. Operators must be able to say which client was entitled to which alternatives at a given time.

The cost is not theoretical. RFC 7911 notes that receiving multiple paths for many prefixes can exhaust memory or contribute to network-wide instability. Every extra path consumes RIB state, attribute references, policy evaluation, update processing and telemetry capacity. A failure can turn a quiet reserve into a burst of replacements and withdrawals across thousands of prefixes.

RFC 6774's discussion of diverse path distribution reaches the same governance boundary from another architecture. More planes or more paths can reduce path starvation and reveal alternatives before failure, but each copy carries memory and processing costs. Visibility is a resource allocation, not a free side effect of a capability bit.

Production implementations expose the policy layers explicitly. Cisco documentation separates capability, additional-path selection and advertisement. Junos distinguishes configured send and receive behavior from the negotiated effective state. FRRouting offers choices such as all paths, per-AS best and N-best, along with receive controls and limits. These are product examples, not protocol promises, but they reveal the knobs that an approval record must capture.

A credible deployment starts with an entitlement matrix. For every peer and AFI/SAFI, record locally advertised and remotely received modes. Derive the effective direction instead of trusting a global feature label. Then identify the sender's selection algorithm, maximum advertised count, policy filters and whether the normal best path is guaranteed to appear.

Capture the exact Adj-RIB-Out before rollout: prefix, local Path Identifier, next hop, AS path, origin, local preference where relevant, MED, communities and eligibility reason. At the receiver, capture the corresponding Adj-RIB-In objects and import decisions. The two sets need not use the same Path Identifiers, and identifiers observed through different speakers must never be joined as if they were universal.

Test replacement and withdrawal as operations on the pair. Re-advertise one prefix with the same identifier and changed attributes; only that path should change. Withdraw one identifier; sibling paths should remain. Withdraw an unknown identifier; no existing alternative should disappear. These tests catch implementations, telemetry collectors and automation that accidentally fall back to prefix-only identity.

Restart testing needs different acceptance criteria. Because the advertising speaker may allocate new identifiers, numeric continuity is not required. Match routes using controlled attributes and intended role, then verify that stale identifiers are removed, alternatives reappear within the convergence envelope and no orphaned path survives in the FIB.

Diversity must be measured, not counted. For each advertised set, derive next-hop, neighboring-AS, site, line-card, link, provider, conduit and policy-domain overlap to the extent the operator can know it. Unknown shared fate should be represented as unknown, not converted into confidence by the existence of two identifiers.

Failure trials complete the proof. Remove the selected egress and observe whether an already visible alternative becomes best without fresh remote discovery. Measure update volume, decision time, next-hop resolution, FIB programming and packet loss. Repeat when the chosen alternative is filtered, recursively unresolved or shares the failed resource. The advertised-set policy is successful only across the scenarios it claims to cover.

Capacity is an admission contract. Define per-neighbor and per-family path limits, memory ceilings, update-rate envelopes and telemetry retention before enabling the feature. Alert when actual advertised or received multiplicity exceeds the reviewed set. A receiving limit must fail in a known way; silently discarding arbitrary alternatives can recreate path hiding behind a misleading capability state.

Rollback cannot mean only removing a configuration line. The old state model must be restored without leaving ADD-PATH-encoded residue, stale Path Identifiers or forwarding entries based on a withdrawn candidate. Test capability renegotiation, route-set contraction and session behavior in a laboratory and a bounded production cohort. If rollback requires a reset, leadership should approve that reachability risk before rollout.

Heng Lu's minimum-initial-specification principle clarifies what the standard should and should not decide. The shared mechanism is small: a negotiated directional capability and a local discriminator that lets more than one path coexist. Which paths deserve exposure, how many a device can accept and which one reaches the FIB remain local decisions. Interoperability does not require surrendering future policy.

Running-code primacy supplies the evidence hierarchy. Intended configuration is a claim. Negotiated capability, transmitted tuple, accepted route, best-path reason, programmed next hop and packet observation are progressively stronger facts. If the alternatives never crossed the session or never survived policy, the deployment did not create usable choice.

Data sovereignty appears here as control over visibility. The sender owns the set it reveals. The receiver owns the set it accepts and uses. Neither side owns the physical outcome alone. A design that calls visibility “shared” while one party cannot inspect or bound the other's selection policy has confused formal access with practical authority.

ADD-PATH is therefore neither a command to send everything nor a guarantee of resilience. It is a way to stop prefix-only replacement from erasing every alternative on a session. Its value comes from a deliberate path set, bounded costs and evidence that a receiver can turn at least one exposed alternative into forwarding when the preferred route disappears.

Sources